It kind of makes me think of how odd it would have been if many of the old forums named themselves like bookclub.phpbulletin.com, metalheads.vbulletin.net, or something.

There’s nothing wrong with doing that, obviously, but it’s struck me as another interesting quirk of fediverse instances/sites. Generally as soon as you visit them you can tell by the site interface or an icon somewhere what software they’re using.

  • CrayonRosary@lemmy.world
    link
    fedilink
    English
    arrow-up
    6
    ·
    edit-2
    10 months ago

    Because Lemmy is bigger than one domain. If it were just one domain it would be Lemmy.com, but since it’s federated, the names must be different, but you still want people to know it’s a Lemmy instance because they all interoprate.

    “Hmm, what’s bajesus.com? Oh, its a Lemmy instance. What’s lemmy.bajesus.com? A Lemmy instance, of course.”

    Lemmy is a technology where each instance follows the same rules: a compatible federation API. You want people to know your website is a Lemmy instance.

    A bulletin board might one day change to entirely different back-end and migrate all of the posts and users. That’s highly unlikely you’re going to do that with a Lemmy instance. It will always be a Lemmy instance or it will go away. You’re not going to migrate the content and users to some other technology. And even if you did, you can buy a second domain easy peasy!

    • rglullis@communick.news
      link
      fedilink
      English
      arrow-up
      0
      ·
      10 months ago

      you still want people to know it’s a Lemmy instance because they all interoprate.

      No, no, no. I don’t care that the server on the other side is running Lemmy, kbin, mastodon, wordpress or some dude running his own scripts. The only that should matter is that everyone uses the same protocol. The server should be nothing but a detail.

      That’s highly unlikely you’re going to do that with a Lemmy instance.

      If this whole threadiverse thingie ever takes off, It’s highly likely that Lemmy will not be a good fit for the majority of users. We will likely have servers working only to validate and relay messages from clients, and data will be fully distributed (instead of replicated to every instance). Any substantial growth will quickly show the limits of the current architecture.

      • PeriodicallyPedantic@lemmy.ca
        link
        fedilink
        English
        arrow-up
        0
        ·
        10 months ago

        You do care, though. Mastodon is a social network. You want to know if this server is part of that social network. Lenny is the same, even if “social network” doesn’t apply to it in the traditional sense.

        Not all the networks on the fediverse interoperate, and that’s not even the goal with activitypub. All servers of the same network should interoperate, but Pixelfed doesn’t and shouldn’t need to integrate with Lemmy, for example.

        • rglullis@communick.news
          link
          fedilink
          English
          arrow-up
          0
          ·
          10 months ago

          You want to know if this server is part of that social network.

          Hard disagree. There are no separate social networks, and it is not the software that makes the network. That is the whole point of the Fediverse. I shouldn’t care about the identity of the servers, all I should care is about the having a common language and a way to identify the actors.

          If a user can not post a picture on Pixelfed and other people can not vote on it, then it’s a shortcoming of the software, not an integral quality of the system. I could switch my Lemmy server to, e.g. Takahe with extensions to support voting and you would be none the wiser.

          • PeriodicallyPedantic@lemmy.ca
            link
            fedilink
            English
            arrow-up
            1
            ·
            10 months ago

            Idk what to tell you then. Not only is that not how activitypub works, not all fediverse networks even use activitypub. Idk where you’re getting your definition of fediverse, or how you think that’s even possible. You can’t have every app/network support every feature of every other.

            Imagine I make a fediverse MMO turn based RPG. How is a Lemmy app support to present that? How am I supposed to consume that from a mastadon server? Mastadon shouldn’t need to support turn based MMORPGs, and MMORPGs shouldn’t need to support streaming video.

            There is not only is there no common API for fediverse networks, there isn’t even a common protocol.

            • rglullis@communick.news
              link
              fedilink
              English
              arrow-up
              1
              ·
              10 months ago

              How is a Lemmy app support to present that? How am I supposed to consume that from a mastadon server?

              You don’t.

              There is no place that says that a client needs to process every message that is received on an actor inbox. It doesn’t mean that one client should support only one specific type of activity, or even servers for that matter.

              • PeriodicallyPedantic@lemmy.ca
                link
                fedilink
                English
                arrow-up
                1
                ·
                10 months ago

                Maybe I don’t understand your position then.

                Fediverse doesn’t make any claims for SSO or shared user accounts between server types. And servers aren’t required to interoperate with servers of other types. And clients aren’t required to interoperate with multiple server types.

                It’s nice when servers and client do Interop between types (what I’m calling networks for lack of better word), but that’s not really fundamental to the fediverse, and is pretty rare. Afaict the only requirement is that servers of the same type can interoperate with eachother and user accounts from other servers of the same type are addressable.

                • rglullis@communick.news
                  link
                  fedilink
                  English
                  arrow-up
                  1
                  ·
                  10 months ago

                  server types

                  That is the problem. Assuming that we need different “server types” is a mistake made by Mastodon that benefitted them in the short term but screwed the developers who were looking at activitypub as a simple protocol for bidirectional exchange of data.

                  What we need is smarter clients and let the servers be completely dumb relays. Instead of thinking of “Mastodon API” or “Pixelfed API” or “Lemmy API”, we could be looking at a single browser extension that could talk Activity Stream directly with the server, let the client be responsible for signing messages and know how to present the context when/how to serve the different activity types.

  • PeriodicallyPedantic@lemmy.ca
    link
    fedilink
    English
    arrow-up
    6
    arrow-down
    1
    ·
    10 months ago

    Lemmy / Mastodon is the social network. To show that your server is part of that social network, they include it in the name

  • distant plant@microblog.lakora.us
    link
    fedilink
    arrow-up
    4
    ·
    10 months ago

    @[email protected] I think part of it is the “branding” of Mastodon - if everyone someone follows uses a Mastodon server, they might just think of “Mastodon” as the social network they want to join, and never really consider that other people on the network might be using something like Firefish or Pixelfed or microblog.pub. After all, most Mastodon servers’ web UIs look pretty much the same and the default Mastodon name and graphics are often pretty prominent.

    I don’t think this is usually an issue, but there are some Mastodon instances out there whose names are `mastodon.[something] and I think that can mislead people into thinking that’s the one they “should” join just because it seems “official”.

  • BlueÆther@no.lastname.nz
    link
    fedilink
    English
    arrow-up
    2
    ·
    10 months ago

    well mine is not named after the service, and I thought having the user handle as @@no.lastname.nz quite fitting for a decentralised, semi-transient social media

  • Die4Ever@programming.dev
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    10 months ago

    Another thing is that ActivityPub uses the hostname as the unique identifier, so I don’t think you can easily switch from Lemmy to KBin or something like that if you’re trying to use the same hostname as before

  • Admiral Patrick@dubvee.org
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    10 months ago

    Each fediverse service needs its own domain and cannot share with others.

    So we put them as subdomains, (service).domain.com, so we can run multiple under the same top level domain.

    The majority of Fediverse instances are run by volunteers at their own cost or subsist strictly on donations. Domain registrations can get expensive and are a variable recurring cost*, so subdomains (which are free) are the natural choice. That also leaves the apex doamin available for other purposes.

    *The cost to renew each year can change and often goes up.

    • Max-P@lemmy.max-p.me
      link
      fedilink
      English
      arrow-up
      0
      ·
      10 months ago

      Domain registrations can get expensive and are a variable recurring cost*, so subdomains (which are free) are the natural choice.

      Or for personal instances like mine, I don’t even know what I would name it that would make sense to have as a whole TLD.

      It would be nice if it supported domain delegation like Matrix does.

      I’m generally not a big fan of how Lemmy just assumes its got the domain all for itself forever. I would have liked to have the webfinger API live on the root, so I can have clean handles and community names, but the inbox endpoints and UI would be on a subdomain.

      I’ve been thinking of making some proxy thing that can intelligently route ActivityPub from the root to Lemmy/Mastodon/Pixelfed and whatnot so that they can behave like one big instance and browse the same content but differently, but it sounds like as big of a project as making Lemmy itself.

      • Admiral Patrick@dubvee.org
        link
        fedilink
        English
        arrow-up
        0
        ·
        10 months ago

        I’ve been thinking of making some proxy thing that can intelligently route ActivityPub from the root to Lemmy/Mastodon/Pixelfed and whatnot so that they can behave like one big instance and browse the same content but differently, but it sounds like as big of a project as making Lemmy itself.

        That’s basically what SRV records accomplish. When I looked a while back to see if ActivityPub had support/plans to support them, I landed on, I think, a Mastaton feature request where the response was “won’t implement SRV” because “webfinger already does that” (it does not).

        Personally, I think SRV records and webfinger solve different problems and can complement each other. The ActivityPub software would lookup the SRV record matching its platform and use the result from that to query the correct webfinger endpoint to resolve the user’s URI for that platform.

        I have no idea why SRV records seem to have fallen out of fashion, but they would easily solve the delegation problem since that’s exactly what they were designed for. lol

        • Max-P@lemmy.max-p.me
          link
          fedilink
          English
          arrow-up
          0
          ·
          10 months ago

          but they would easily solve the delegation problem since that’s exactly what they were designed for. lol

          So much yes. You’d think that’d be the first thing they’d bake in the ActivityPub spec, given it governs how the user handles are handled, they even look like E-Mail addresses. Yet nobody seems to have thought about making the usernames sane. It’s the first thing I looked up while setting my Lemmy, can I make the username look less stupid, as I did with Matrix when I set that one up.

          There’s a weird trend towards stuffing everything as HTTP(S) web APIs and JSON. We’re about to get to a point where everything will talk over websockets because we forgot TCP exists.

          • kopper [they/them]@lemmy.blahaj.zone
            link
            fedilink
            English
            arrow-up
            1
            ·
            edit-2
            10 months ago

            ActivityPub does not govern how user handles work. All AP actors are defined by their IDs (which in Lemmy’s case happens to be the URL their profile is hosted in, which is a mistake as you cannot change your username without breaking federation, but at least Lemmy isn’t alone, both Mastodon and I think *oma family of software do the same thing)

            AFAIK the @username@instance convention is Webfinger’s doing, and (to the best of my very incomplete knowledge) the convention of “preferredUsername @ the hostname of the object ID” is a hack Mastodon pulled that got adopted as a de-facto standard (as is quite a lot of other things in AP).

  • density@kbin.social
    link
    fedilink
    arrow-up
    1
    ·
    10 months ago

    Answer 1:

    with an old forum like running phpbb, it doesn’t matter to the user what the site is running. if it works, it works.

    with the fediverse, because it is interacting with other instances in a way forums never even conceived of, it is really important to the end user what software is running. the software is center stage.

    Answer 2:

    The blossoming of the threadiverse in the past 6 months has prompted/necessitated the creation of a lot of “general purpose” domains.

    Your examples are bookclub.phpbulletin.com and metalheads.vbulletin.net. But most lemmy instances are not themed around literature or music or anything else. More apt example would have been phpbbtalk.io or chatvbulletin.xyz. Such sites did start back in the day. But in the absence of federation they were not likely to cohere. So you don’t remember them, if you ever found them in the first place.