ActivityPub as an evergreen standard / iterating on the editor's draft

In the last few meetings the SocialCG has discussed whether ActivityPub (or ActivityStreams) should move towards the evergreen standards process, and if they even can.

I think @nightpool pointed out that it’s not clear what benefits we may get from this over going just the editor’s draft process that we have now. I’ve asked a contact at the W3C for their thoughts and will follow up with that here.

In the meantime maybe it’s worth noting that the real point might be that we should remember that we do have an editor’s draft, and thus it is perfectly feasible for us to start adding to it to capture such items as the usage of vocabulary that is not currently codified in the AP spec.

I think there’s probably a broader question here: “What documents is it most useful to the community for Social CG to draft/maintain?” An editors draft of ActivityPub and ActivitySteams vocabulary are definitely the most obvious documents, but maybe there are other useful documents that are less obvious, like ActivityPub security recommendations, profiles for different usecases, etc.

I would say that at a minimum we need to have:

  • ActivityPub itself
  • ActivityStreams vocabulary
  • A document that describes the current composition of how WebFinger, HTTP Signatures and ActivityPub fit together.

Some aspects of the OCAP work will be done in other places, such as the IETF. On that front, bearer capabilities come to mind, as we are talking about doing an i-d track at IETF for that, as it’s an easy way to get the URI namespace reserved quickly. But at the very least, a document explaining how the OCAP standards are formally composed is also a good idea.

This is almost off-topic but is there a writeup somewhere of bearer capabilities I could familiarize myself with? I’ve been trying to keep on top of all the different stuff that’s been in motion recently and I think that’s the one piece I don’t have so much as a rudimentary handle on, besides being vaguely aware that it requires a new URI scheme.

Writing a simple blog about how bearer capabilities work is something I intend to do this evening, so I will link it here once it’s published. Bearer capabilities on their own, of course, aren’t very exciting, they’re just a nice way of combining a URI and an access token for that URI into a single logical construction.

As an update to this, I have blogged about how bearcaps work. If anybody has questions as to how bearer capabilities fit into ActivityPub, I will be blogging about that soon.