Let me start with the last question and move back to technical points…
Well, first of all, you can stop being defensive: we’re having this conversation because we admire what you’ve been doing and support it fully. When I set expectations about the importance of Mobilizon, it’s because I saw how PeerTube changed the game 
, and I think the same can happen with Mobilizon: therefore it’s important that the community works together on the prospect of moving along to interoperability using ActivityPub, in a way that works for all, with all our differences.
This is not the case. A Person is an Actor in ActivityPub, and so is a Group: both appear as a single field in the form of an URL that can be dereferenced to an object (an Actor is a subclass of an ActivityPub Object, and both a Person and a Group are also subclasses of an Actor). So it does not matter to Radar whether your Actor is a Person or a Group as long as they can dereference it to what it is.
A reason why an event posted by a Person would not appear in Radar would be because this Person is not followed by anyone on the Radar instance; there’s no reason why Radar would not be able to wrap this Person into an internal representation that appears to the system to be a Group – with the limitations that Radar would only implement what is needed to make its magic work: and so, if Mobilizon couples the Event with a Person, implementing some fields that will be required by Mobilizon to interpret what an Event is, then there would be an issue for Mobilizon to understand Activities taken by some Actor on Radar’s side; Radar would still be able to consume Events from Mobilizon, but Mobilizon would be unable to handle Group-based Events from Radar. This is where it’s important that Mobilizon does not over-determine what an Event is. I assume that an Event created by a Person in Mobilizon is only the first step, since you mentioned Groups would be supported later.
IMO, Actors are commodities: some people over at SocialHub were recently complaining that an Object cannot be followed, and that we should amend the specification to allow that use-case; I think it’s a wrong approach, as we can instead create on the consuming side an Application or Service Actor that would follow the original Actor that owns the Object to be followed, and ignore all Announces except for this specific Object of interest. Since the consumer only wants to follow this Object, it’s easy-peasy to circumvent the perceived limitation of the specification by creating a commodity Actor that implements collection filtering – which is how I understand what you call “social masks”. Maybe a way to understand “multiple identities” in practice would be to have the user have multiple Persons representing it:
- https://event.example/framapouhiou
- https://event.example/pouhiou-after-dark
- https://event.example/pouhiou-musician (obviously, one would choose “John Doe”, “Dr. Doe”, “John”, “HoneyBunny”, “Uncle Joe”, etc., not necessarily disclosing their name across all “identities”, but in the end, it’s mostly a matter of who is looking at you.)
This is all the difference between an understanding of ActivityStreams objects as “identities” vs. an understanding as “relations”: ActivityPub is very good at handling relations, and a Person is just another Actor, interchangeable, as much as possible, as long as the implementation actually accepts this fact, and does not try to put more there than there is. But this kind of diffraction can only happen if one stops to reflect from a static model, and embraces instead a dynamic process.
