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.
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!
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.
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.
Uh, OK. I have a Lemmy client on my phone. It doesn’t work with anything else you mentioned. Those are different apps with different features. I need to know if a server is a Lemmy instance, not Mastadon, etc.
This is for you to connect with your server, not for people who are interacting with you via your server.
Clients can be made to work with different servers. e.g Soapbox can work with both Pleroma and Mastodon servers.
My server’s name is communick.news . Can you tell that is a Lemmy instance by looking at its name? You can go look at the API and see that it responds as being a Lemmy server. What if I told you that someone could take another software like GoToSocial and implement Lemmy’s API to make it usable for both microblogging and link sharing? This is perfectly possible, and wouldn’t need to know or care what is behind the API
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.
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.
@rglullis@communick.news definitely agree with this - Pixelfed accounts should at least be able to reply to (or “comment on”) a Lemmy post. Doesn’t look like they can right now, though; my reply from my pixelfed account didn’t seem to federate. Seems like a bug to me.
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.
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.
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.
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.
Isn’t this just the difference between an API and a protocol?
The payload of a message for one social network will be different based on the capabilities of that type. There are API architectures that are discoverable, like HATEOAS, but that only gets you so far (and that example is based on HTTP not Activitypub).
I don’t really see anything wrong, in the absence of a standard body, for each social network to define its own activity type, since they typically have some degree of unique capabilities anyways.
I kind of see where you’re coming from, and I think the reason I wasn’t thinking of it in those terms is that I see ActivityPub as the more important underlying tech across the fediverse than say Lemmy/Mastodon/Friendica/etc.
I say that in part as I’ve come into the fediverse from Mastodon, where there’s more than two options in play, e.g. Akkoma/Firefish/Misskey/Pleroma/etc. each of which has some commonalities, but also some pretty distinctive features, particularly from the Misskey side. Hell, Mastodon itself even has Glitchsoc, which is what the original instance I joined on that side of things runs.
On reflection, I don’t know that the microblogging instances mix in the name of the software they’re using as much, which you’d think with more options they might be inclined to, but the more I think of it the more I remember a lot of them use some fun, odd names instead.
Activitypub is the protocol. Mastadon/Lemmy is the API. Just because two applications share a protocol doesn’t mean they can talk to eachother.
The Spotify app uses the HTTP protocol, like your browser does, but that doesn’t mean you can view any webpage from the Spotify app. Idk if activitypub is actually a protocol, but it is at least analogous.
While it makes sense for apps/networks of a similar type to interoperate (like microblogging), apps/networks of different types may not make sense to integrate.
So for servers on the same network/app, it makes sense to include it in the server name, so that people know what app/network it belongs to.
Also the practice of using a subdomain to indicate which program is running is pretty old. That’s what the www subdomain on so many websites is.