If lemmy created a community the same name as the username when someone signs up. You could follow a lemmy user and then when your on mastodon (once we’re federated with mastodon) you could see their self posts in their community as a mastodon post and vice versa.
The way I look at it is that federation between different services using ActivityPub can be a huge differentiating factor from commercial social media. Commercial services are walled gardens because their incentive is to keep users on their service, and they see other services as competition for users creating a zero sum game scenario.
On the other hand, ActivityPub federation is a positive sum game. The more services federate with each other the more overall content is available to everybody in the federated network. I think this is the core argument for different services being interoperable.
I totally agree it’s not a priority though, but definitely something to consider in the long term.
Sure, and Lemmy is completely open in that way, we are not preventing anyone from federating with Lemmy (in fact we would be happy to help with that). But its just a lot of work, and so far no developers have shown interest.
Right, it’s something to look at in the future when there is time or help available.
Oh no, I don’t doubt that you’re all for federated platforms. Thing is, platforms like Mastodon / Pleroma shouldn’t have to maintain special code for Lemmy, which seems to be what you’re suggesting (?). It’d be easier for Lemmy to use standard protocols :-)
We are using the standard ActivityPub protocol (with some deviations needing to be fixed). But that protocol is extremely vast, and there are many different ways to do the same thing. Its possible that implementing federation with another project might take almost as much time as implementing Lemmy-to-Lemmy federation.
Can appreciate that. From reading the other post, I got the impression that the Lemmy project doesn’t care about fediverse functionality, and I’m glad that’s not the case (?).
I’m not doubting your statement, but could you explain what’s a lot of work? If Lemmy speaks ActivityPub, shouldn’t other services be able to accept its Activities and display them accordingly? I know there might be polishing that could be done to display them in a nicer way (by using one field instead of another, less characters in a certain field, etc)
EDIT: I saw your other comment about ActivityPub being vast. Is Lemmy using Activity’s or Objects that aren’t in wide use?
Lemmy speaks activitypub, but we are the very first to center around the activitystreams term groups, IE communities here. The entire rest of the fediverse is based around following federated users (IE, the twitter model), while we’re focused on following federated communities (reddit / forum model).
So no other implementation supports group follows yet, and we likewise don’t support user follows yet.
I understand a bit of ActivityPub, but I haven’t done any development with it so excuse me if I’m mispeaking. Here’s my understanding.
A Group is a type of Actor and a Person is a type of Actor. All Actors have an inbox and outbox. The actor
POSTs activities (Create,Delete, etc) to their own outbox, which other actors can view. AFollowsignifies to the receiving server that an actor at the originating server wants to know when there are new messages in the receiving actor’s outbox. So when the actor adds a new activity to the outbox, the server would notify any follows, and they would check the outbox for the activities.So wouldn’t following a group be the same as following a user? Software that supports one already knows how to support the other. I can see how a server may want to display messages from different actor types differently, but that’s stylistic. Isn’t a
Createfrom a group essentially the same as aCreatefrom a person?Afaik one problem with Mastodon are the HTTP signatures, because they are using an older version. So theres more than just ActivityPub which might need changes. And just figuring out what needs to be adjusted will take time.
A create post in a group, originates not from the group, but from one of its members, who may not even live on that server. Then that create needs to get pushed in some way to the federated community, which then needs announce to all its followers. Its very different from a person create, which always originates from the same server, and goes to its own followers.