Skip to content

Instantly share code, notes, and snippets.

/extensions.md Secret

Created September 21, 2017 18:14
Show Gist options
  • Save anonymous/63ab026fbe1eef1442db7f572d9ea6f1 to your computer and use it in GitHub Desktop.
Save anonymous/63ab026fbe1eef1442db7f572d9ea6f1 to your computer and use it in GitHub Desktop.

Things people need from an extension/feature/capability-checking thing, from my perspective (I'm personally more interested in client-to-server-relevant info than maybe y'all are so since Masto afaik doesn't have current plans to support the ActivityPub C2S protocol I haven't looked into that too much so this may need adaptation if we want to be more APub like):

  1. Some idea of what an extension/feature/whatever is
  2. A way to identify a particular extension
  3. A place to expose a list of extensions supported by the instance
  4. A convenient (though not necessarily mandatory) place to stick additional info about a particular instance's support for an extension

My ideas on how best to handle those needs

  1. Extensions are just bundles of functionality with a name and it's up to each extension what it means to support that extension
  2. URLs are good imo especially since then you can do URLs that point to a spec or docs for the extension. Probably exact textual equivalence as the rule for comparing them? Or whatever the WHATWG URL spec says URL equivalence means, I guess. Both OStatus and ActivityPub use URLs(/IRIs) as identifiers for a lot of stuff and it provides natural ways for avoiding naming conflicts.
  3. We should just stick a JSON array somewhere of strings containing the extension URLs. I personally want an instance/server metadata endpoint for other things so like a "supports-extensions" or something property there would be good IMO, but we might also just want a separate endpoint for it. If we want to expose this to OStatus imo we should link to it in /.well-known/host-meta; sounds like for ActivityPub we should stick it in the "endpoints" thing cwebber and nightpool are talking about?
  4. A JSON object next to (or containing) that array where the property with an extension's URL as the key is reserved for that extension to stick whatever they want in there is enough.

For example, the glitch-soc Mastodon fork supports a few extensions relative to upstream Mastodon that are exposed or that we'd like to expose in Mastodon's client-server API and for clients to be able to easily check for, so if we did my idea, we might have an extensions thing that was in part like:

{
	"supports-extensions": [
		"https://spec.glitch.social/FR/do-not-federate/",
		"https://spec.glitch.social/FR/mute-details/",
		"https://spec.glitch.social/FR/optional-notification-muting/",
		"https://spec.glitch.social/FR/bio-metadata/",
	],
	"https://spec.glitch.social/FR/bio-metadata/": {
		"max-entries": 5
	}
}

and clients could check for that and check out the mute details (if we wanted to go more into the linked-data aspect like ActivityPub does, we might want links to relevant API endpoints in metadata for some of those extensions).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment