![](https://lemm.ee/pictrs/image/b5644329-1d41-47b7-a17a-fb055c071b5a.webp)
![](https://sh.itjust.works/pictrs/image/045a2049-eb61-4960-88ba-97e7f1ffbf31.jpeg)
We finally have a release date for Microsoft Flight Simulator 2024!
We finally have a release date for Microsoft Flight Simulator 2024!
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.
Banning a local user from a local community does actually federate already
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).
You can check the federated/defederated instances for any instance on the /instances page. For example:
I’m in the middle of this book right now and I can’t believe how many spoilers they managed to fit in the trailer 😅
Friendly tip if you don’t like spoilers: don’t watch more than the first minute of this trailer.
incorporated into the UI, rather than a piece of text in the post.
How would other instances (or other ActivityPub software) know about it if it’s not a piece of text in the post?
I think nearly all big Lemmy instances have in fact defederated, you can check this list: https://fedipact.veganism.social (filter by software: Lemmy)
This “ads as posts” thing was one of my two biggest concerns with Threads federation. I really hoped I would turn out to be wrong about it, but at the end of the day, both Facebook itself, as well as big social media influencers, rely on advertising for their profits. For anybody looking to avoid ads on Lemmy, it seems like direct federation with Threads is not a good idea currently. On lemm.ee, “no advertising” has been one of our 4 core instance rules from the start.
My other major concern was Threads having the ability to enforce their feed algorithms on federated instances through sheer number of votes on things they show in their feeds, but judging by what you’re saying about the engagement, at least that concern has not materialized (at least yet).
I think community discovery can (and should) be improved for sure!
Currently it’s true that you can use topic-centered instances for this, I do this myself as well, but I do think it has quite significant downsides in terms of creating pockets of centralization. For example, if you’re a user who is ONLY interested in french cinema (or any specific topic) on Lemmy, and all of the related communities and other invested users are on a single instance, then for you, the experience is absolutely no different from any centralized platform - the french cinema instance admins have 100% control over your Lemmy experience.
IMO, in practical terms, 3 key things should imapct instance choice:
Content specialization really shouldn’t matter IMO, because as long as the federation policy is OK for you, then you can participate in any communities, regardless of what instance they are on. In other words, even if you’re super interested in french cinema, there is no need to centralize all users interested in this topic on a single french cinema instance. Thanks to federation, users from all instances (accounting for federation policy) should be able to become fully fledged participants in any french cinema communities.
Of the points I listed above, #1 and #2 are easier to include in an instance introduction, I’m not sure how to properly and reliably reflect #3 in any kind of overview. At the end of the day, I think most users tend to figure out their long-term home instance a while after they first join Lemmy, and quite often, it’s not their original instance, so maybe it’s not that important to emphasize the initial instance choice too much?
If I have several backends that more or less depend on each other anyway (for example: Lemmy + pict-rs), then I will create separate databases for them within a single postgres - reason being, if something bad happens to the database for one of them, then it affects the other one as well anyway, so there isn’t much to gain from isolating the databases.
Conversely, for completely unrelated services, I will always set up separate postgres instances, for full isolation.
The core issue here is that there are too many things to do, and too few developers to do them. By the way, for a huge number of these things that need to be done, there is most likely at least one person who thinks it’s the absolute highest priority for Lemmy. Forking would not help fix this issue, it would only make it worse.
In other words: if you’re a Rust dev, you can just fix it in Lemmy anyway, so there is no benefit from forking. If you’re not a Rust dev, then after forking, you will have a new repo to create issues on, except you’ll have 0 devs to actually fix them.
They specifically called it “child abuse content”, not “child abuse”. This seems perfectly valid, no?
By the way, just because these are digital renderings does not mean that there is no harm. Seeing such content can still be harmful to past victims. Just try to put yourself in this situation: imagine just playing some video game online, and suddenly being exposed to people recreating traumatic experiences from your past. Not only that - you also discover that the creators of the video game are involved & actively enabling such content. Seems completely messed up to me.
Good luck with the upgrade!
Important note, this feature is only available for US customers.
Good luck with the update! One great thing about 0.19 is that it allows users to check federation status between instances, will be awesome to get that for lemmy.world as well.
Nowadays it’s allowed only for users with >4 week old accounts. It’s not perfect, but having this barrier to entry will hopefully prevent at least some problems.
I think the OP is talking about Lemmy having both a content preview and a text area for link posts.
Some users tend to write their own summary in the text area, so when opening up a post, the result will be:
I agree that this is a bit clunky in terms of UX
It’s a full new game that you need to purchase separately, but all the marketplace stuff you’ve bought for 2020 will also come with you to 2024