We need both options. Some systems like USENET use a global groups list (rec.radio.amateur.misc is the same group everywhere). Federated communities need a similar option.

Sure, let me create my own c/gaming if I want, but also give the option to… merge? combine? cross-federate? Not sure what term fits here.

!gaming@me, !gaming@you, and !gaming@them can be 3 separate, distinct, and independent communities (like it is today).

!gaming@me, !gaming@you, and !gaming@them could also be the same !gaming community, replicated and synced across all 3 servers.

Here’s an idea. Add another name to the community designation. So you could have !gaming#context@instance. (Or whatever separator makes sense. You could even just use a subdomain like !gaming@context.instance, but that might be harder).

In this model, #context refers to a shared view of the world that instances can choose to participate in. As the instance admin (or maybe a mod??), I choose to join #context1 but not #context2. When I do, All the !communities under #context1 become available for me. I still choose the ones that are appropriate for my instance. This would mean that when a new instance joins the federation, it acquires the shared set of #contexts that the federation publishes. A different federation of instances could still have different contexts.

(All of this still feels clunky. USENT’s simple hierarchy still makes so much sense, but it unfortunately places all the control at the group level, not the instance/user level.)