• Head admin @ lemm.ee, a general-purpose Lemmy instance
  • Creator of lemmy-ui-next, an alternative Lemmy frontend
  • Lemmy contributor

ko-fi

  • 8 Posts
  • 149 Comments
Joined 1 year ago
cake
Cake day: June 9th, 2023

help-circle




  • To be honest, neither Hexbear nor Lemmygrad has caused any noticable issues for lemm.ee. I recently compiled some stats for lemm.ee rule breakers by home instance, and as you can see in this post (in the “Administration” section), neither of those instances even made the top 10.

    In general, mods haven’t complained about those two instances either, and the stats for community bans by independent community mods are more or less very similar. If any users creates issues in a lemm.ee community, then the community mods are free to just ban those users, regardless of what instance their account is hosted on.

    if fact I wouldn’t even be able to as my home instance is defederated from these instances and thus such posts would be invisible to me

    Preventing such situations for lemm.ee mods is actually one of the many reasons we don’t want to use defederation as a moderation tool on lemm.ee - we rather use site bans etc. Too much collateral damage with defederation, especially when dealing with larger instances which probably have vastly more innocent users than problematic ones. We reserve defederation for more extreme cases, like spam instances & CSAM.






  • 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.



  • 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).




  • Hey! Do I understand correctly that your app is trying to fetch any /post/<id> directly from its source instance API? If so, I have a few ideas:

    1. If you detect anything that looks like a Lemmy post URL (<host>/post/<id>), you could first try to make a request to <host>/version, and only treat the post as a Lemmy post if you get a JSON response from that endpoint where .software.name === 'lemmy'. Otherwise, open that URL in the browser.
    1. The above will already “fix” the issue, but custom frontends on subdomains is actually quite common, so if you want to handle those links without resorting to a browser, then: in cases where <host>/version is not a Lemmy response, but <host> includes a subdomain, you could repeat the same logic from step 1 for the parent domain as well. If you detect a Lemmy API at the parent domain, then just use that to fetch the post.