Document policy for adding extension terms into the normative context

[trwnh]

Please Indicate One:

• [ ] Editorial
• [x] Question
• [ ] Feedback
• [ ] Blocking Issue
• [ ] Non-Blocking Issue

Please Describe the Issue:

For years, some of the earliest "extension properties" were initially defined inline as context overrides: https://docs.joinmastodon.org/spec/activitypub/#as

This includes terms like Hashtag, sensitive, manuallyApprovesFollowers, and movedTo, which were loosely defined in 2017/2018 but never formally adopted. Consequently, everyone just inlined them as context extensions and we all pretend that they're part of the activitystreams namespace and context despite not actually being in there.

Some official guidance on this would be appreciated:

• Do people have the authority to define whatever extension terms they want within the activitystreams namespace?
  • If yes: are there any guidelines to govern when this is or is not allowed? Can we determine a set of "best practices" for using the activitystreams namespace with permission?
  • If no: which namespace should they use instead? Can we provide a namespace for incubating extensions, or some path to adopting externally-defined terms within the normative activitystreams context?
• For historical terms like the ones mentioned above: can we work on defining some or all of them formally and officially within the SocialCG, then adding them to the normative context? (This depends partially on the answer to the previous point.)

[evanp]

So, I think no, people can't just add things to the namespace willy-nilly. That's why we have namespaces.

I think the proper steps are something like this:

1. Define an extension with the property you want. Include it in its own context.
2. Get it widely used, with at least 2 implementations.
3. Propose to SocialCG to add it to the AS2 context, but maintain the namespace.

For namespaces: there are a few possibilities. I think the SocialCG could set up a namespace namespace (!) for extensions that it has a team working on. I think the FEP process could have a namespace namespace, but I don't see one there now.

Otherwise: namespaces are cheap as dirt. The organisation, project or individuals creating the extension can use their own domain. At worst, it's possible to create a PURL at https://purl.archive.org/ and elsewhere.

For the historical terms: it's a good question. My inclination would be to document them and exclude them from future properties of the namespace, but to ask the creator(s) to redevelop them in their own namespace.

[evanp]

So, I split out the question of the historical terms to #541 . On the issue triage call, I agreed to write a SocialCG note for how we manage extensions and getting them into the main context. I will try to have this done for the next CG meeting.

[evanp]

There's a draft here. https://w3c.github.io/activitystreams/draft-extensions-policy.html

[evanp]

There is now a draft report in the SocialCG, so I'm going to close this ticket. https://github.com/swicg/extensions-policy is the next step.