Not with gentoo!

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.

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.

Yes, precisely. The existing implementation in the Fediverse does the opposite: everyone you follow has to insert their posts into the feed of everyone that follows them, which has its own issues.

Oh my bad, I can explain that.

Before I do, one benefit of this method is that your timeline is entirely up to your client. Your instance becomes primarily tasked with making your posts available, and clients have the freedom of implementing the reading and news feed / timeline formation.

Hence, there are a few ways to do this. The best one is probably a mix of those.

Naive approach: fetch posts and build news feed when user requests it

This is not a good approach, but I mention it first because it’ll make explaining the next one easier.

• User opens app or website, thereby requesting their timeline / news feed
• server fetches list of user’s subscriptions and followees
• for each followee or subscription, server fetches their content via their static file wherever they are hosted
• server performs whatever filtering and ordering of content they want
• user sees the result

Cons: loading time for the user may be long, depending on how many subscriptions they have it could be several seconds. P90 may even be in double digits.

Better approach: pre-build user’s timeline periodically.

Think like a periodic job (hourly, or every 10 min, etc) , which fetches posts in a similar manner as described above, but instead of doing it when user requests it, it is done in advance

Pros:

• fast loading time compared to previous solution
• when the job runs, if users on the same instance share a followee or subscription, we don’t have to query it twice (This benefit already exists on current fediverse implementations) Cons: posts aren’t real-time, delayed by the batch job frequency.

Best approach: hybrid

In this approach, we primarily do the second method, to achieve fast loading time. But to get more up-to-date content, we also simultaneously fetch the latest in the background, and interleave or add the latest posts as the user scrolls.

This way we get both fast initial load times and recent posts.

Surely there’s other good approaches. As I said in the beginning, clients have the freedom to implement this however they like.

1. I write a post, and send a request to the server to publish it
2. The server takes the post and preprends it to the file housing all my posts
3. Now, when someone requests my posts, they will see my new one

If a CDN is involved, we would have to properly take care of the invalidations and what not. We would have to run a batch process to update the CDN files, so that we are not doing it too often, but doing it every minute or so is still plenty fast for social media use cases.

Have to emphasize that I am not expert, so I may be missing a big pitfall here.

Anyone looking for the best package manager needs to look only at portage/emerge and nix

I tried LFS one time, and accidentally ran one or more of the commands on my host machine, rendering it unusable

Deleting the bottles directories from the repos directory seems to fix it, thanks for the advice!

Update: Following your advice, I proceeded to delete the files for “bottles” from the repo folder in /var/lib/… and that seems to solve the issue! thanks for the help! :)

thanks for the tip about storage space, although I do seem to have 100 GB of free space so I do not think this is the issue?

However I noticed I have a filesystem /run/user/1000 it seems to be created by flatpak, and it has 1.6 GB of total space. Should this be a source of worry?

The other advice about deleting the directories does not seem to work either :(

While I love the idea, many RSS users may not use Lemmy, and I would not want to restrict the use of this to lemmy users only. But for now, this seems to be the best existing option. Thank you!

My claim is admittedly not based on trying it myself. I suppose I should test out friendica and see for myself.

what do screen recording softwares for wayland use under the hood then?

My issue with MBin is similar to that of Friendica. It’s more expensive to self-host. Lemmy scales better.

What I am proposing would use the same exact lemmy backend. How would it magically use more resources with the same backend?

What you said is incorrect, the difference in features offered is not the only reason for the difference in resource utilization. Lemmy meme communities have plenty of images going around.

The argument that I want to test is that Lemmy is as up to this task as LemmyBB being a phpBB experience but with a lemmy backend. I am proposing something like that.

The reason not to go with the other alternatives is that lemmy seems to do much better on resource utilization, which would make it much easier to host and scale.

does OBS just do everything with ffmpeg, or does it introduce extra functionality?

Following users can be simulated by the client. Behind the scenes, every user will have their own community, and their personal posts will go there. If you follow the user, the client would make you follow that community behind the scenes.

But I suppose you would need to prevent other users from being able to post there, I did not consider that. Lemmy does not have that kind of permission control. So maybe this is not viable … hmm

You’re right that lemmy never intended to be a Facebook mock-up (and I hope my post did not seem to allude to that), but I was wondering if it could be made to be so by changing only the client but keeping the rest intact.

My limited knowledge makes me think that lemmy is easier to host, consuming less resources in general, hence why I want to consider it first. But I could be wrong.