they won't be sent by infosec.pub directly, but other instances may send activities referencing content from infosec.pub, which will lead lemmy.ml to pull it from the source as well.
this includes for example posts and comments in lemmy.world communities, because lemmy.world will announce those to lemmy.ml.
the mod got banned from blahaj, which, when set to also remove their content, removes communities they're head mod (or only mod?) of as well: https://lemmy.blahaj.zone/modlog?page=1&actionType=ModBan&userId=124892
ugh, i didn't notice they're even hiding domains of remote communities for "simplicity" in most cases. that seems so much more dishonest tbh.
delegating authentication to another service.
one of the more commonly known options would be sign in with google, but this is also quite useful for providers hosting multiple services. a provider could host a service that handles authentication and then you only have to login once and will automatically get logged in for their lemmy, xmpp, wiki and other services they might be providing.
you may want to redact the names as this spam is framing another person pretending to be originating from them
lemmy updates did some improvements on the receiving side, parallel sending on the sending side is not yet part of a new release. it'll also likely take some time for that to be deployed on lemmy.world to have those changes be tested by other production instances first. my activitypub-federation-queue-batcher is currently used by at least 2 other high latency instances and would address the issue at the cost of a small (like 3 bucks or so) vps in Europe and some time investment for the setup.
this is a lemm.ee limitation, not a Lemmy limitation, so this is the wrong community.
if you look at the instance sidebar at https://lemm.ee/ you can see that it's 4 weeks.
Retaining old content has value
this 100%. this is exactly why i wouldn't recommend any communities to be removed if there is still content in there, worst case just lock it.
The "fediverse link" on a post always points to the instance of the person who posted it, not the community instance. When posting from a lemmy.world account this means the fedilink is always the lemmy.world post link.
It is only shown for content coming from remote instances in Lemmy UI 0.19.3, although a later version changed that to always show.
this is by design. actor ids (unique identifier for accounts) should not be reused due to undefined behavior for how other instances will deal with that.
if you want to have a more technical explanation, https://socialhub.activitypub.rocks/t/reuse-of-identity-channel-addresses-revocation-reissue-of-keys/2888 does a decent job at explaining some of the issues with this.
It should be noted that the (visibility of) community bans are a result of better enforcement of site bans in 0.19.4, which for now is implemented by sending out community bans for local communities when a user gets instance banned: https://github.com/LemmyNet/lemmy/pull/4464
Prior to this, when a user got instance banned from .ml, they were also implicitly banned from .ml communities, but this was only known to the instance they were banned on. As a result, users were still able to post, comment, and vote on those communities, but it would be visible only on that user's instance, not federated anywhere else. Visibility of this ban was exclusively on the banning instance's modlog.
this doesn't really change anything for how remote users are displayed, it's a change to properly support hosting lemmy-ui on a different domain than the lemmy backend/api.
what are you referring to with mastodon short.domain handles?