Federating servers

So, one part of the popular imagination about ActivityPub I've seen is the idea of server federation.

I think the idea is that if two servers have interacted in some way, all (?) public (?) content from one server will be sent to the other server, and vice versa.

This comes up a lot with new servers; people ask to have a post shared broadly so that their server rubs shoulders with others, getting the federated feed flow going.

ActivityPub does in fact have a mechanism defined for this:

Additionally, if an object is addressed to the Public special collection, a server MAY deliver that object to all known sharedInbox endpoints on the network.

As far as I've seen, most (?) servers don't implement this; it would overwhelm small servers pretty quickly.

However, some (?) servers do implement it for some (?) activities, especially profile update and delete activities.

Is this the origin of the idea that new servers need to have their content shared around? Are people misunderstanding the way that relays work? Is it just a trick to get your content shared?

@evan At Friendica we have a third way. When configured, we distribute posts to other servers that subscribed to the hashtags that the item contains.

But anyway: I would like to have got something like the AppView in the Atmosphere. Means: not a dumb relay but something like tags.pub, but much more sophisticated.

@heluecht@pirati.ca like a public firehose of sorts?

Suppose there's no reason why not, you would just get yelled at constantly for "scraping" posts.

@julian To which point do you refer? For my first mentioned one we have got a special document at .well-known/x-social-relay that every Friendica server publishes that contains information about the subscribed hash tags.

And concerning the second point, I imagine some relay service that does not simply forward everything, but that knows which content you you are interested in. So when you subscribed to user A and user B posted something in a thread that user A started, then the relay would forward it to you, although you never subscribed to B. And when then the account B got deleted or blocked, then of course you would be notified as well.

@heluecht @julian

This can be done with inbox forwarding or special activities (FEP-171b or FEP-1b12).

Selective relays may be used for other things though. There is https://github.com/dtp-mstdn-jp/selective-relay that apparently can filter activities by hashtags, domains and number of attachments

@heluecht @julian I concur, but what capabilities you're interested in?
Almost everything in ActivityPub could be done peer to peer, without a relay in the middle.

@silverpill @julian When A follows B and C comments in a thread from A, but on the server from B no one follows C, how will then A be notified by comments or edits from C? And what happens when C got banned for spam. How does this information reach A? On C's server you can see where the now banned contact wrote comments. But you don't see, that comments from C where distributed (or fetched) from A.

And it gets worse, when you simply fetch messages, that hadn't been pushed to you. Then you won't get any updates, except when you would pull it from time to time.

And of course some "give me all posts with that specific hashtag but only in these languages" will not work quite well, when you are on a stand alone server.

@heluecht @julian I am not sure if I understood your example correctly, but here is how it all works with FEP-171b / Conversation Containers:

- A follows B
- C comments on B's post (Create activity)
- B generates Add<Create> activity and sends it to A
- A receives Add and adds C's comment to their copy of the conversation

If C is banned for spam (and their comment removed):

- B removes C's comment (Delete activity)
- B generates Add<Delete> activity and sends it to A
- A receives activity and removes C's comment from the conversation

@silverpill sorry to butt in, but all of this would be solved by respecting what the canonical representation of a reply thread is: the replies collection of the top post[1]. I think it makes much more sense to built that correctly and rely on it instead of trying to keep all the nodes of the network in sync with countless activities.

[1] Caveat, this requires that all replies to a post, include in their inReplyTo property at least their parent and the top post - ideally they should include the whole chain of parents to the top post.

@heluecht @technical-discussion @julian

@mariusor @heluecht @julian I think both solutions have advantages and disadvantages. Activities are more efficient

the canonical representation of a reply thread is: the replies collection of the top post

The most popular representation is context collection containing posts. I know 10 implementers, including some big ones: https://codeberg.org/fediverse/fep/src/branch/main/fep/f228/fep-f228.md