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?
-
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?
Another possibility is that when someone asks to have their content shared, that will result in a few Follow requests, which does result in their future content being distributed to other servers (and public content goes to Fediverse and hashtag feeds).
So, it seems like the sharing is what got the distribution going, even though it is indirect (sharing causes following causes appearing in the Fediverse feed).
-
@evan I think - reviewed it given that you corrected my misapprehension the other day - that other than for those who live'n'breathe protocol, the nitty-gritty details are really not spelled out in the platform documentation for users or admins.
Or even those of us who understand enough to read along (I did remember that I "knew" this, just not that expert in expressing), it's more detail than we can articulate when there's a new user or instance showing up.
-
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?
In FEP 1b12, that is what occurs (most of the time) - as soon as an instance has a dozen users their interests will be varied enough that almost every active community in the threadiverse is subscribed to and they'll be receiving almost all the traffic.
It works out ok at our current scale (small).
-
Another possibility is that when someone asks to have their content shared, that will result in a few Follow requests, which does result in their future content being distributed to other servers (and public content goes to Fediverse and hashtag feeds).
So, it seems like the sharing is what got the distribution going, even though it is indirect (sharing causes following causes appearing in the Fediverse feed).
@evan in the Mastodon sphere, boosting a post has these side effects:
- servers that receive the boost will now be aware that the boosted post exists. if it contains hashtags, then that post might show up in hashtag timelines/searches and the home timelines of anyone following that hashtag.
- servers will also be aware that the author of the boosted post exists. their profile can appear in search results based on their account's name/summary.
-- (in the future, their outbox might be backfilled) -
Another possibility is that when someone asks to have their content shared, that will result in a few Follow requests, which does result in their future content being distributed to other servers (and public content goes to Fediverse and hashtag feeds).
So, it seems like the sharing is what got the distribution going, even though it is indirect (sharing causes following causes appearing in the Fediverse feed).
@evan personally I think "server federation" is best achieved through relays.
The distribution model fits best, and the technology already exists, even if not broadly implemented.
One could be able to plug a server instance actor in to subscribe to its relay.
-
@evan personally I think "server federation" is best achieved through relays.
The distribution model fits best, and the technology already exists, even if not broadly implemented.
One could be able to plug a server instance actor in to subscribe to its relay.
@julian yes, I agree. This is a different idea -- that somehow interaction between actors on different servers will make their servers connect and share data. It's incorrect, but it's interesting.
-
@julian yes, I agree. This is a different idea -- that somehow interaction between actors on different servers will make their servers connect and share data. It's incorrect, but it's interesting.
@evan oh I see what you mean... that a server merely discovers another, and that kickstarts a mutual sharing of activities.
I'm afraid that would be a bit of a scaling challenge
-
@evan oh I see what you mean... that a server merely discovers another, and that kickstarts a mutual sharing of activities.
I'm afraid that would be a bit of a scaling challenge
@julian here's an example I found with a search:
-
@julian here's an example I found with a search:
-
@julian here's an example I found with a search:
@evan I think it is a misunderstanding of the current activity distribution styles... and it's entirely understandable isn't it? You install some software, it knows nobody, nobody knows you, and somehow you're supposed to kickstart content discovery.
I don't know what the solution is, but I did mentally note while implementing relay support that it would be simple to turn NodeBB into a relay itself, and have all NodeBBs just use a central NodeBB (aka mine) as a source of content.
-
A similar feature exists in Pleroma. I actually find it useful, my server follows a couple of Pleroma instances in addition to relays
-
A similar feature exists in Pleroma. I actually find it useful, my server follows a couple of Pleroma instances in addition to relays
@silverpill@mitra.social really? How does it work?
-
@silverpill@mitra.social really? How does it work?
Does it use the relay method? I always thought that if I implemented something like that I'd be the first. Cool to know Pleroma already supports.
-
@silverpill@mitra.social really? How does it work?
It's a LitePub relay actor, located at
/relay. Announces all public posts if relaying is enabled in config. -
It's a LitePub relay actor, located at
/relay. Announces all public posts if relaying is enabled in config.That makes sense.
When I implemented the Litepub style relay logic I figured it would immediately work the same way as well (since two-way relay communication uses the Follow-Accept flow as well.)
It did not work immediately with NodeBB, have yet to figure out why
-
Does it use the relay method? I always thought that if I implemented something like that I'd be the first. Cool to know Pleroma already supports.
@julian @technical-discussion @evan pleroma ships a /relay actor turned on by default that follows back other relays, this server subscribes to a thousand or so of them, announces get turned into remotefetches for efficiency, and the network is filled effortlessly without follow for follow botting
wish the network had some sort of shared as:public /outbox too for backfill
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better ๐
Register Login