Current Fediverse Implementation
From my understanding, the prominent fediverse implementations implement fanout via writing to other instances.
In other words, if user A on instance A makes post A, instance A will write or sync post A in all instances that have followers for user A. So user B on instance B will read post A from instance B.
Why this is Done
From my understanding, to prevent a case where post A is viral and everyone wants to read it, and instance A’s database gets overwhelmed with reads. It also serves to replicate content
My Question: Why not rely on static files indeed of database reads / writes to propagate content?
Instead of the above, if someone follows user A, they can get their timeline via a static file that contains all their posts.
Reading this file will be a lot less resource intensive than a database read, and with a CDN would be even better.
This introduces one issue: when post A is made, the static file must be updated. This may be slower to read-after-write than a database, and if using a CDN have to deal with invalidations and TTLs, which makes posts a lot less “real time”
But the benefit is that hosting a fediverse server is more accessible and cheaper, and it could scale better. Federation woes of posts not federating to other instances can potentially be resolved.
What are your thoughts on this? Please be kindly constructive, I do not claim to be an expert and this is simply an idea that came to mind.
Sure, but constantly having to do it is not really a bad thing, given it is automated and those reads are quite inexpensive compared to a database query. It’s a lot easier to handle heavy loads when serving static files.
I’m really not sure about that being inexpensive. The files will grow and the list of people to follow usually grows as well. This just doesn’t scale well.
I follow 700 people on Mastodon. That’s 700 requests every interval. With 100-10000 posts or possibly millions of interactions in each file.
Of course you can do stuff like pagination or something like that. But some people follow 10000 accounts and want to have their timeline updated in short in intervals.
Pulling like this is usually used when the author can’t sent you something directly and it works in RSS Feeds. But most people don’t follow hundreds of RSS feeds. Which reminds me that every mastodon profile offers an RSS feed - you can already do what you described with an RSS reader.
bringing up RSS feeds is actually very good, because although you can paginate or partition your feeds, I have never seen a feed that does that, even when they have decades of history. But if needed, partioning is an option so you don’t have to pull all of its posts but only recent ones, or by date/time range.
I would also respectfully disagree that people don’t subscribe to 100’s of RSS feeds. I would bet most people who consistently use RSS feed readers will have more than 100 feeds, me included.
And last, even if you follow 10,000, yes it would require a lot more time than reading from a single database, but it is still on the order of double digit seconds at most. If you compare 10,000 static file fetches with 10,000 database writes across different instances, I think the static files would fare better. This isn’t to mention that you are more likely to have to write more than read more (users with 100k followers are far more common than users with 100k subscriptions)
And just to emphasize, I do agree that double digit seconds would be quite long for a user’s loading time, which is why I would expect to fetch regularly so the user logs onto a pre made news feed.