I still have an account. It is still useful for grabbing binary content like TV shows and movies, but that takes a lot of setup.

What I really miss are the discussions. There, it’s not as useful as it once was. All the groups still exist, but many are overrun by spam. It would be nice to see a solution that makes USENET actually useful again.

This might not be the official answer, but it feels like the right answer.

USENET. Actually useful USENET.

It’s not about allowing a single instance to own the name. The name would belong to the federation in a global namespace.

A possible scenario is to define multiple namespaces. Each namespace can be local to a single instance, or shared between many. Within each namespace, a single community name is unique.

In this model, each instance would have a namespace that it owns, and the ability to participate in many others.

The trick is in how we name the namespaces and communities. We could do this the USENET way and do something like <namespace>.<community>, so beehaw.gaming vs. global.gaming. There are other models that could work too.

What about users who want to intentionally register without an email address? Maybe to give more anonymity to their account?

Signed up, downloaded, launched.

Nice work. I’ve been using Mlem. It’s been working fine for me, but I’m eager to try out other apps!

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 [email protected], 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.)