sunaurus

joined 2 years ago
[–] sunaurus@lemm.ee 3 points 1 year ago

That's definitely not intentional - it's a custom error message which we have just for lemm.ee, not a standard Lemmy error, and it seems I need to tweak it a bit for it to work correctly in 0.19.4. Thanks for reporting this!

[–] sunaurus@lemm.ee 11 points 1 year ago (2 children)

Yes, lemm.ee has all the standard Lemmy features. However, the format for this request has changed, and it seems the app has not been updated yet.

For technical context: your app is trying to use the singular post_id field when marking posts as read. This field was marked as deprecated several releases ago, as it was replaced by a post_ids array field, in order to enable marking multiple posts as read at the same time. The deprecated post_id field has been removed in Lemmy 0.19.4.

[–] sunaurus@lemm.ee 5 points 1 year ago

Regarding your question:

Lemmy federation basically works by copying stuff from their source instance to all other federated instances. So if I write a comment on lemm.ee, other federated instances will get their own copy of my comment. They will also all know that the "authority" for this comment is lemm.ee.

If an admin on another instance decides to delete their local copy of my comment on lemm.ee, then they are always free to do so (for example, some instances might want to moderate more strictly), but any actions they take like this are limited to their own instance - for the rest of Lemmy, lemm.ee remains the authority for this comment, so individual remote instance admins taking actions won't have any effect on any other instances.

As for the original topic of modlog federation, basically it just boils down to this: just like with the comment example above, Lemmy instances also save a local copy of incoming federated mod logs. The Lemmy software does not yet have 100% coverage in terms of federating mod logs (for example, there are no federated logs yet for instance admins banning remote users), but this coverage has been increasing, and I expect this will eventually get to 100% (just needs more dev time really).

Also, if some instance admins try to tamper with their mod logs, then other instances can still see the real history, because there is no way for an instance admin to delete copies of their mod log from other instances.

[–] sunaurus@lemm.ee 5 points 1 year ago

Banning a local user from a local community does actually federate already

[–] sunaurus@lemm.ee 15 points 1 year ago (2 children)

Most actions federate, any exceptions which aren't federated yet are generally just there because the federation logic has not been implemented (but improvements are constantly being worked on).

Generally federating the modlog is mostly just there for informative purposes. As in, we can check what mod actions were taken on instance A through the modlog on instance B (and there is no mechanism in Lemmy for other instances to retroactively remove or hide federated modlog items, btw).

[–] sunaurus@lemm.ee 2 points 1 year ago

Sure, the lemm.ee federation policy is here. You can also always find a link to it in the sidebar on our front page.

[–] sunaurus@lemm.ee 16 points 1 year ago

Basically, yes!

For the backend: our traffic is load balanced between multiple servers, so I can just spin up a new server with the latest version of Lemmy, add it to the load balancer, and then start taking down the servers with older versions. That way, there is no disruption at all for users, because there is always a server available to handle incoming traffic. The only requirement for this is that the new version of Lemmy can't have database migrations which break the old running servers.

For lemmy-ui: it's a bit more complicated, because even with a load balancer, it's still possible that one user making multiple sequential requests can end up getting responses from different servers. This is problematic, because during an upgrade, files from the new version are not available on the old servers, and vice versa. Fortunately, there are many ways to solve this problem, for lemm.ee, the solution I use is to just always serve lemmy-ui files from object storage, for all versions. In other words, after I upload lemmy-ui files for a new version, these will immediately also be available on old servers.

[–] sunaurus@lemm.ee 71 points 1 year ago (5 children)

By the way, as a mini-present, I have sneakily updated our Lemmy to 0.19.4! It was possible to do this one without any downtime, so I just did it quietly in the background.

[–] sunaurus@lemm.ee 8 points 1 year ago

It's the first option in the dropdown:

[–] sunaurus@lemm.ee 43 points 1 year ago

Big thanks to all maintainers and contributors!

[–] sunaurus@lemm.ee 3 points 1 year ago* (last edited 1 year ago) (1 children)

While there isn't any built-in ban appeal in Lemmy, there are still a few ways to reach lemm.ee admins even after a full ban: creating a new account (as you did), contacting me on Matrix (I am @sunaurus:matrix.org), or contacting the admins on Discord (there is an invite to the lemm.ee Discord in the sidebar of this community).

[–] sunaurus@lemm.ee 6 points 1 year ago

Well, one advantage we have over commercial social media is that they need to pay people to write code and maintain the infrastructure, but a lot of work on Lemmy is volunteer-based.

Many admins for bigger instances are basically on-call the whole year for free, open source contributors provide code for free, etc. Even the core maintainers are effectively losing money by working on Lemmy, because while they are getting some income, the sum of money they are getting from working on Lemmy is way smaller than what they would get if they worked typical software engineering jobs.

Basically, if any non-volunteer organization wanted to replicate Lemmy, it would cost them quite a bit more in terms of payroll alone.

Another aspect is scale - Lemmy is able to spread the costs between different instances, and while growth of the network can generally increase costs for individual nodes, they will still end up paying less compared to if they were hosting the entire social network in a centralized way.

view more: ‹ prev next ›