• 0 Posts
  • 8 Comments
Joined 1 year ago
cake
Cake day: June 13th, 2023

help-circle
  • 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.




  • 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.



  • It’s very early. There are a lot of great ideas here, but also a lot of details yet to be worked out. Also lots of bugs.

    I wasn’t on Reddit in the early days, but I expect it had problems too. I know twitter did.

    If you’re a developer or have any skill in that area, I’d encourage you to contribute. If not, I’d ask for 2 things:

    1. Have patience and a bit of grace with the devs, operators, and mods, especially in these early days.
    2. Get active and talk about what you want and what’s not working for you.

    This is your chance to help make “Thing n+1” better than “Thing n”. Chances like that don’t come around very often.



  • 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.)