Opened a PR on fediverse.party to start incrementally improving the various "landing pages" of the Fediverse... feel free to pile on if you have input! I'll open other PRs on the explainer copy as well tomorrow.

All I know it gets me thinking that I need to work with @[email protected] on documentation!

Please tag me/msg me if you want a reviewer of a draft! I have been working a little on "normal-human"-facing docs this month, so it's not entirely selfless of me to offer!

There’s also no requirement for actor-specific inboxes in S2S (the actor inbox can refer to a server-level inbox), so it seems to me that the relationship between the two is relatively loose. However, actor-specific inboxes are useful for the rarely used C2S API where a client needs to dereference a URI to a Collection of their specific inbox activities.

Make Clients Powerful Again! Actor-specific in/outboxes open up a lot of freedom for actors having multiple servers, doing client-side signing, being discoverable via multiple networks, etc etc.

Over in another thread, Steve said something that stuck with me:

The ActivityPub Recommendation added additional requirements for an actor to have inbox and outbox endpoints. (However, the inverse isn’t necessarily true. An object with an inbox and outbox endpoint may or may not be an AP actor.)

I think a Collection could have an inbox, without becoming an Actor, and that kinda makes both options defensible logically, although I can see pros and cons to both. "Collection with an inbox" seems to me appropriate for collections objects that emphatically aren't Actors (say, a subreddit, a channel, a thing Actors post into), while "Actor Group" (the multi-type enthusiasts might even want to insist on the "type": {"Group", "Actor"}" rather than just refining Group as an extension of Actor!) seems more appropriate for a group chat, a mailing list, a group of Actors who act collectively and can be blocklisted or moderated as if they functioned as one Actor.

Basically I'm worried our fear of neologism is leading us to cram disparate things into the same data model to avoid writing a FEP with an @Context extension-- maybe Groups and Collections both deserve to exist for different use-cases!

Lemmy may expect Announce(Activity), but I bet it also accepts Announce(Object) if one of their users were to follow a Hubzilla/Friendica group actor...

Would it help to add a "Legacy Compatibility"/Postel's Law section explaining this to the FEP itself? As in,

"An implementation MUST produce Announce(Activity) messages to conform to this FEP, but it MAY also accept [edit: and/or emit] Announce(Object) as well for wider compatibility, and if you do, the recommended behavior is... { Normalize | Drop | Translate | etc }"

This is helpful to people writing test suites/test-cases because it can give warnings for what an implementation will receive that still help compatibility without giving anyone "Fails" for the core feature