Like does content get mirrored to my instance and then mine distributes it ala BitTorrent or is my instance it’s own thing?
Text gets mirrored but not images. In general it helps, but not by much unless you host for several hundred users.
Broadly, yes. The way federation works means anything any user on your instance is interested in will be sent to you once (at least posts/comments/votes/etc). Whenever someone on your instance views that thing that is a request that would otherwise be made to another instance. This does, however, increase the load of federation on servers hosting popular communities, as now they have to send each post/comment/vote/whatever to your instance. Unlike bit torrent there is only one place responsible for sending you all of the content that exists in a community, so the fediverse doesn’t get p2p-style network effects where every peer/sever helps even a bit.
A single user instance is a little inefficient, unless you are actually looking at most/all of the content your instance receives, in which case it is probably a wash. The ideal for how federation is implemented in ActivityPub would be many similarly-sized (in terms of user count) instances with the most popular communities being spread out among them.
Sadly right now the most popular instances (lemmy.world, lemmy.ml, lemmynsfw.com, kbin.social) are both where users and communities are, so the real gains to help those instances (several of which continue to struggle under the load) are really only medium and larger sized instances.
What is the easiest way to learn about ActivityPub?
These posts are really useful to get a grasp of ActivityPub (if you have a programming background): https://rknight.me/building-an-activitypub-server/ https://blog.joinmastodon.org/2018/06/how-to-implement-a-basic-activitypub-server/
And of course the official spec (although its less useful): https://www.w3.org/TR/activitypub/
In effect, not really.
All the communities you’re subscribed to will now also have to push all their updates (posts, comments, upvotes) to your server, even when you’re not interacting with Lemmy.
As someone else mentioned, it would only be efficient once you have a decent (hard to pinpoint) amount of users on your server.
They’ll do it once, though. Then every time you view it, you’re helping the bigger servers by serving it from your instance.
Yes. Once for every post, comment and vote.
So say you have your own personal instance, and you use that to follow community
newson lemmy.world. If throughout the day that community receives 10 new topics, 50 comments and 100 upvotes, it would have to make 160 calls to your server.So when you decide to read those 10 topics (if you even read all of them), you would then make roughly 10 api calls.
You would be saving those last mentioned 10 calls by using your own instance, but at the cost of 160 calls made throughout the day.
The thing is that when you interact with the remote server directly it’s not 10 api calls, it’s 10 full-blown HTML webpages that have to be served to you, which are way bigger than REST API calls.
Generally speaking, lemmy is much more cpu bound than it is bound by bandwidth - so the added bytes don’t matter that much. The example above was just for 1 community. Now imagine the user is subscribed to a dozen communities, but doesn’t even browse lemmy that day. That’s probably thousands of api calls made to keep his server on sync, and 0 requests saved.
Like the big instances have literally hundreds of thousands of workers running in order to get all the updates out. If one of those calls fails, it gets put back into the queue for retry.
OP asked if having his server added to the lemmiverse would alleviate the load “Like with torrent”. That is demonstrably not the case - it only adds more workload on the other servers, with a break even point that’s highly variable. Yes, your server will be nice and snappy, but the origin servers have to pay the price - death by a thousand
papercutssynchronisation calls.Yeah you’re right, I just felt the need to point out that API calls are not really comparable to serving a full website.
