Let’s say we have lemmy instances A, B, C.
alice from A makes a post “Hello, world” to B. What happens? How is it processed on servers A, B, C and how do users from A, B, C receive her post?
Let’s say we have lemmy instances A, B, C.
alice from A makes a post “Hello, world” to B. What happens? How is it processed on servers A, B, C and how do users from A, B, C receive her post?
Alice can’t make a post to B, but I assume you mean a community on B, let’s call it foo. When Alice makes a post it first goes through A’s local API and creates the local (and canonical) version of Alice’s post. Once A has finished processing Alice’s post, it will create an ActivityPub representation of Alice’s post to send to B.
ActivityPub is basically a bunch of assumptions laid on top of JSON. An ActivityPub ‘file’ can be divided into broadly 3 types,
Object
,Activity
and actors.[1] These types then have subtypes; for example, both Alice and foo are actors but Alice is aPerson
while foo is aGroup
.A second important assumption of ActivityPub is the concept of inboxs and outboxs, but, for Lemmy, only inboxs matter. An inbox is just a URL where Lemmy can send activities and it’s something all actors have.
So when instance A is finished processing Alice’s post, it will turn it into a
Page
object, wrap that in aCreate
activity and send it foo’s inbox.Round about what the JSON would look like
{ "@context": [ "https://join-lemmy.org/context.json", "https://www.w3.org/ns/activitystreams" ], "actor": "https://a/u/alice", "type": "Create", "to": ["https://www.w3.org/ns/activitystreams#Public"], "cc": ["https://b/c/foo"], "id": "https://a/activities/create/19199919009100", "object": { "type": "Page", "id": "https://a/post/1", "attributedTo": "https://a/u/alice", "to": [ "https://b/c/foo", "https://www.w3.org/ns/activitystreams#Public" ], "audience": "https://b/c/main", "name": "Hello world", "attachment": [], "sensitive": false, "language": { "identifier": "en", "name": "English" }, "published": "2024-12-29T15:10:51.557399Z" } }
.
Now instance B will then receive this and do the same kind of processing A did when Alice created the post via the API. Once it has finished, it will turn the post back into a
Page
but this time wrap it in anAnnounce
activity. B will then look at all the actors that follow the foo (i.e. are subscribed to it) and send this Announce to all of their inboxs. Assuming a user on instance C follows foo, it will receive thisAnnounce
and process it like A and B before it, creating the local version of Alice’s post.Edit: I made a small mistake, I said that foo wrapped the
Page
in anAnnounce
, when it actually wraps theCreate
in anAnnounce
.Technically,
Activity
and actors are themselves objects, but they’re treated differently. There’s alsoCollection
’s which are their own type, but Lemmy doesn’t really utilise them. ↩︎deleted by creator
Lemmy is pretty bad about backfilling content. Communities do have outboxs, but these only list the last 50 posts and you can’t get the vote or comments on any of them. See GitHub issues #5283, #3448 and #2004.
ActivityPub works like a magazine subscription. They don’t send you back issues for subscribing.
Why does a mastodon user get completely different profiles and history when viewed from different lemmy instances? They look like 2 completely different users when compared except for having the same @address. In fact this makes them immune from moderation if they comment from a different instance than the mod is on.
Mastodon doesn’t have
Group
support (fep-1b12), so when they reply to a post, they don’t send it to the community’s inbox (only to the inbox of thePerson
they’re replying to), thus breaking Lemmy’s model of federation.Okay, thanks.
Does ActivityPub really send copies of all activities to www.w3.org?
No, the
https://www.w3.org/ns/activitystreams#Public
is just there to indicate that it’s ok for receiving instances to display this publicly, nothing actually gets sent to it. See the spec for more details.Why not a binary flag or something? Is it just to avoid making it a formal part of the protocol?
I actually don’t know, you’d need to ask someone privy to design decisions made with ActivityPub, like Prodromou or Lemmer-Webber. It’s definitely not to avoid making it part of the protocol, because it already is (see the link in the last comment).
Thanks—I meant “formal” as in “formal grammar”, not that it wasn’t described in the published protocol. As in, there’s nothing in the protocol’s explicit form that distinguishes between this implied meaning and a real extra recipient—so it simplifies the parsing but adds an extra post-parsing step.
It’s because it’s JSON-LD.
What about JSON-LD makes it so they have to include the “this is public” declaration in the
to
field instead of having anas:public
property on the object? (I don’t know a whole lot about JSON-LD or RDF more broadly)Because it is JSON-LD and that’s how JSON-LD works. It’s an extensible format. Similar to XML namespaces.
deleted by creator
I don’t understand the comment. It’s like calling the fact that
firstName
is in the JSON{"firstName": "Bob"}
“over engineered bullshit” when they should’ve made some application specific protocol instead of using JSON. ActivityStreams and ActivityPub are built on top of JSON-LD to utilize existing libraries to represent linked data (that’s what the LD is). To specify what schemas are used there is a “context” field. There are other schemas as well. Take a look at https://schema.org/ to see them.If it feels over engineered it’s because it’s meant to be able to represent a wide variety of types of social media and typical interactions with them. I seriously doubt Mastodon (micro blogging) and Lemmy (link aggregation forum) would be able to interact easily if they weren’t “over engineered”.
deleted by creator
Then go complain somewhere else, you asked for an explanation of how it works.