Well, the whole idea behind them being resolvable is so that when they are acted upon (by the context owner), they can be queried. For example if I receive a Delete(Context), I'll resolve it to find the root level post, and from there find my local representation, and delete it, assuming the actor was allowed to delete it. They're only server generated views per current usage... but why do they have to be constrained to that usage?

[email protected] Yes you're right, some messiness is bound to happen. I'm not trying to force all implementations into a specific inheritance pattern, that's why it's a "should", not a "must". Even then one of my concerns is that while in an ideal scenario, everybody inheriting their parent context leads to an entire collection all referencing the same context... in reality a lot of messiness will occur, objects will reference other contexts all over the place, etc. At the end of the day it's best effort, and if we are able to handle all that and still get to a point where backfill is achievable, then that's a win in my books. > it depends on how much you embrace the idea of each publisher being allowed to make their own claims (and how much you allow "clean up" after the fact) Part of me would like this to not happen, but it is unavoidable.

You're right! NodeBB serves an outbox but doesn't put anything in it. Happy to work towards rectifying it... It just didn't seem to break anything and you're honestly one of the first who even noticed

Hey [email protected], I am all-in on more, simpler FEPs over monolithic impenetrable FEPs. I take it that points 1 and 2 are due to concerns raised by [email protected] about how OAuth2 properties are already advertised in a standardized manner (I believe per OIDC or similar?) — no objections there. On the topic of scopes, I know [email protected]'s 3b86 (Activity Intents) had some ideas on defining intents that have some parallels to scopes. I don't agree with hardcoding them all into the FEP itself, but I'm interested in exploring how we structure scopes so that they're more straightforward as not quite as fine-grained — a single scope for every ActivityStreams activity type might be a bit of overkill.

That's a really good question, I am not actually aware of any list of software implementing the ActivityPub API. [email protected] and [email protected] may have some leads.