Hi, I’m wondering if it’s standard to provide a “Federated” timeline view to users, where they can see all activity of all peer servers on the network?, and how can this be achieved?
The spec indicates:
If an object is addressed to the Public special collection, a server MAY deliver that object to all known sharedInbox endpoints on the network.
My server opts for this firehose approach and pushes all Public activities to all known peers. “Known peers” is any server with a sharedInbox URL that has ever interacted with mine.
This has come up as an issue a couple of times (is this “spammy”?), but I was doing it this way because I thought that was key to federation.
However, no other server seems to be pushing all their activities to my server. (I have noticed that public Deletes of user profiles seem to get federated by Mastodon, but not Creates, Likes, etc.)
It looks like Mastodon provides a GET /api/v1/timelines/public endpoint so I could theoretically pull the data, but that feels a little strange. Plus I think this is a Mastodon-specific endpoint and not part of the ActivityPub spec.
[2023-04-05 11:49:38+0000] M Puckett via SocialHub:
However, no other server seems to be pushing all their activities to my server. (I have noticed that public Deletes of user profiles seem to get federated by Mastodon, but not Creates, Likes, etc.)
No idea for Mastodon, but for Pleroma what it does is:
Map visibility to to/cc/bto/bcc
When present, expand the actor followers collection
(exclusively for Delete) Add instances that fetched the message
Reduce to sharedInbox except for directMessages
AFAIK Friendica also adds thread participants in cc. And I would quite consider that the Mastodon approach is annoyingly spammy and inefficient but more when it comes to account Deletes (sends deletes for all posts rather than accounts).
It looks like Mastodon provides a GET /api/v1/timelines/public endpoint so I could theoretically pull the data, but that feels a little strange. Plus I think this is a Mastodon-specific endpoint and not part of the ActivityPub spec.
That’s a Client-to-Server endpoint anyway, you shouldn’t mix the two, filtering of activities in timelines being a Mastodon-ism, ActivityPub Client-to-Server just has a single inbox with all activities addressed to you + maybe as:Public.
I think that sending all public activities to all known peers is too much. It breaks the idea that if you are on a server of like minded people, your federated timeline will contain content you like. Instead it would lead to all federated timelines being the same.
On the flip side, your approach is not wrong wrong. It is just a different approach to how federation should work. I’ve started to collect ideas on the future of the FediVerse in fediverse-ideas in order to get a clearer picture on where one wants to be headed.
Edit: I think posting lots of stuff to the sharedInbox is also the mechanism that ActivityPub Relays use to populate Federated Timelines.
To my understanding this has to do with Mastodon’s store forever policy. So pushing Deletes of users to the known universe is the only possible way for a delete of an account to make remotely sense in the Mastodon Network. See above on “We should have a discussion on this … but I don’t feel ready for it”.
public timelines are not really a “standard” thing so much as just being something the big players do. the “federated timeline” as pioneered by GNU Social, Mastodon, Pleroma, Misskey, etc. is not required; it’s just an artifact of lacking proper discovery through directories or aggregators. in other words, it’s driven mainly by the UX assumptions of those softwares.
in practice, delivery is done to followers only. the sharedInbox is used to reduce network costs by deduplicating recipients, as long as you’re willing to have the other server completely decide who those recipients ought to be.
it’s worth noting that sharedInbox is often cited as a huge mistake by authors and editors of the activitypub spec, both as written and as implemented. the primary reason it exists at all is because Mastodon wanted to scale requests between “instances” rather than between actors. this breaks the actor model that activitypub was designed around.
one or two things ought to have been done instead:
make each “instance” an actor. use that instance actor for replicating/syndicating/relaying posts between two instances.
specify a “multibox” endpoint, where multiple inbox URIs can be declared in some way such as an HTTP header, and the server still delivers directly to those inboxes.
ironically, it might make more sense to instead have a “shared outbox” endpoint, which contains all Public activities on the server. anyone interested in “all activity of all servers on the network” can periodically fetch from such an endpoint, or they could follow a special “public relay” actor on the server that simply forwards such activities to all followers.
Alice is on Abel. Bob is on Banach. Bob follows Alice.
Alice sends a message to her followers; Abel delivers the message to Banach’s sharedInbox.
In order to deliver the message to Bob, Banach needs to know Alice’s followers collection. As Alice’s followers collection is on Abel, Banach does not know it. Instead Banach uses Bob’s following collection.
This means addressing has been delegated from Alice’s followers to people having her in their following collection.
It’s homework to work out how this doesn’t play nice with user level blocks.
In order to deliver the message to Bob, Banach needs to know Alice’s followers collection. As Alice’s followers collection is on Abel, Banach does not know it. Instead Banach uses Bob’s following collection.