This does exist, Pleroma has the Message Rewrite Filters or MRF functionality. There's also ActivitySieve or ActivityColander I think it was called, which attempted to do similar. I've personally been arguing that we need federation management via policies more akin to a firewall: https://writings.thisismissem.social/moving-beyond-the-false-dichotomy-for-federation-management/

@silverpill Thank you - I wasn't aware of Mitra supporting conversation containers and nomadic identity, happy to learn.I have some questions about Mitra, I will ask them in a separate thread. @osma

This is an extension of the discussion from Topic removal from a category/community. In it, rimu@piefed.social shared the Lemmy federation primer which details that Delete(Object) is federated whenever a post is removed from a community. I needed a way to communicate when a topic/context (not the top-level post) is removed from a category/audience, but is not deleted. You might ask — how is removing a context different from deleting it? In this case, a removed context still exists and is still resolvable. A context can removed from an audience in NodeBB. Note that Lemmy and Piefed don't have a concept of an audience-less context, so if a context is removed from an audience, it would simply be deleted. No additional logic required. Anyhow — when a topic is moved into Uncategorized (which is a catch-all bucket for... you guessed it, uncategorized content), NodeBB will federate a Remove. It looks something like this: { id: '#activity/remove/', type: 'Remove', actor: '', to: [], cc: [, object: '', origin: '', } This is live on activitypub.space already. This goes hand-in-hand with topic moving, which would follow similar mechanisms, except it'd be a Move instead of a Remove. I will likely write an FEP with technical details for both Remove and Move, and will include existing behaviours (Delete(Object)) as well.

The problem for us is that we actually did take advantage of the bi-directional data flow available with web sockets. However, probably > 90% of our websocket calls were simple data requests, so we dropped back to bog-standard GET and POST. Why re-invent the wheel? It's that other half where you want to communicate events in real-time, where SSE makes sense.

Dagnabbit. Here's a comment from 11 years ago on this topic! https://github.com/w3c/activitystreams/issues/20#issuecomment-58034202

@helge>used by MastodonThey are changing it: https://github.com/mastodon/mastodon/pull/30354

@elvecio Further investigation showed that this wasn't a Mastodon's fault. There was some weirdness on behalf of the originating instance.Mastodon server received a post addressed to public and I received a post addressed to followers.

Good morning Fediverse. Should direct HTML links, i.e. the a tag, to ActivityPub objects have the type application/activity+json? I'm thinking here about an embedded external reply. The link resolves to an ActivityPub object, whose id corresponds to the link's target.

Thank you, @julian.One thing I am concerned about is how that affects forums and communities.But then I think, so what if a NodeBB forum or PieFed community wanted to highlight people because those people represented the values of that community (even if they were not necessarily a part of it)?This is something that no forum software that I am aware of does because we always think of forums as only something we join into.And it is so amazing to me that the FediVerse and the social web movement could provide a forum or group the opportunity to grow in the opposite direction—sending people outwards for new shared experiences.

If I used an object observer for a topic/context, and proceeded to delete that context, the object observer would go away too. That is, unless you're inferring that I take steps to preserve the object observer for some period of time (if not forever?)

@julian that might be it, yeah. languages outside of javascript generally don't make a distinction between null and undefined, and even in javascript these are used inconsistently. for example localStorage.getItem will return null for a missing key. practically speaking, the "intentionally" distinction is a distinction without a difference in most processing contexts.

One consequence of trying to separate identity hosting from the other components of the system is that it makes the other components harder to bootstrap. If I run just one component of my instance in isolation, how can I authenticate to it in order to configure/manage/test it, if I don't have an identity that I can use?The answer might be to use a did:self identifier. The flow would look something like Management CLI tool generates a JWT describing a did:self identifier, and stores the private key locally Admin uses scp or something to copy this JWT to the right place on the server The server now has the ID's public key and so the CLI tool can prove that it "owns" the identifierWhich seems like a reasonable fix for the classic problem of "how do you create the first user", and also a useful fallback for when the system is too badly borked to be able to look up real identities.Another interesting property of did:self is that seems to be possible to add extra metadata, such as a human-readable name, to the ID, by using standard JWT claims - without needing the data to appear in the DID document.Of course these identities will only be visible to the server they're copied to, not to the whole network, but that shouldn't be a major problem.(Cue the peanut gallery, with their suggestions of "it's easy, just do so-and-so", because everything looks easy when you take it out of context...)#ActivityPubDev #FediDev

@julian no, mastodon doesn't use salmon anymore, not since a long time ago. they switched to websub then activitypub direct delivery.on the indieweb side, salmention is an extension to webmention, where upon receiving a webmention where someone replied to you, you add that reply to your html then send a webmention up the reply chain to whoever you replied to, and they will fetch your html and find the new downstream reply, add it to *their* html, send a webmention upstream, and so on.

@evan HTTP 420/CHILL OUT?Actually I do see HTTP 429 TOO MANY REQUESTS, which seems exactly what we want. I don't know what support is like though, I've not seen explicit support for it in the few bits of AP Federation code I've taken apart.

@flancian It's an egregiously backwards-incompatible change, so probably no.

@thisismissem@activitypub.space Ah, I seem to have misread the code. I was confused by Mastodon serving its own instance actor from /actor. Thanks for the clarification!

@mastodonmigration That's mostly me speculating, based on what would be least frustrating. Though I suppose there could be a safety angle, too.

@Configures huh, weird, will check that out in the morning, thanks for letting me know. i assume still some bugs in the quote implementation

@julian @snarfed.org @quillmatiq @rimu this is at the forefront of exciting fedi dev and I can't wait to see where this leads!

@blainsmith @rimu @jwildeboer there is a forthcoming FEP from the AP T&S taskforce that introduces the idea of a Moderation Actor for Actors, so like "Moderated By", which would be a Group or Service actor probably, but it would not be required to disclose it's members.