@julian I've done a review on FEP-fe34 and here's a more nuanced answer.The same-origin assumption is necessary for authentication, because it is not possible to not trust the server of origin.But it is not necessary for authorization. It is desirable, because that makes authorization procedures aligned with authentication procedures. But we can shift the burden of permission checks to the recipient.We might even have to do this, if we discover that servers accepting arbitrary payloads (C2S, FEP-ae97) can't reliably enforce the isolation of actors.But for the time being, you can accept same-origin admin deletions.

My understanding from a reading of the relevant section from fe34 suggests a claim of A → B is reciprocal if there is an inverse claim B → A.Yes, and in my understanding these claims are:- This actor is authorized to delete/update this object.- This object is hosted on the server where this actor is an administrator.But I don't insist on importing this concept.I would want to point out that keeping with prior art has the benefit of making this FEP much easier to adopt by threadiverse implementors.I consider myself a threadiverse implementer too, and I don't really like the idea of dealing with ambiguous properties At the very least, could you add inbox and outbox properties to the Application actor example? https://codeberg.org/devnull/feps/src/branch/instance-admins/fep/baf5/fep-baf5.md#instance-actor-and-application-actor

@julian @benpate fixed on WordPress.com! (it was a CORS issue, because the API runs under a different domain on DotCom).You should now be able to test on activitypub.blog

Thanks @chocobozzz@framapiaf.org for the explanation. It does seem like the library is still usable. In a separate thread, @mradcliffe@nokoto.org mentioned that he had a PR/branch that introduced RFC 9421 support: https://nokoto.org/user/3/replies/317 It looks like you're the maintainer... would you be open to having that merged if someone (aka me) implements and tests it?

@evan 429? Amateur hour. You need to keep banging on the API until the server is overwhelmed and times out. That's the 2026 way.

@julian @technical-discussion @evan pleroma ships a /relay actor turned on by default that follows back other relays, this server subscribes to a thousand or so of them, announces get turned into remotefetches for efficiency, and the network is filled effortlessly without follow for follow bottingwish the network had some sort of shared as:public /outbox too for backfill