This page exists to document extensions to the ActivityPub protocol. Extensions are developed as part of the SWICG.
Debatable about whether it's an extension, but see also ActivityPub and WebFinger.
- uploadMedia: Upload endpoint URI for this user for binary data. Part of the
endpointsmapping. See ActivityPub MediaUpload.
Possible future extensions
This list has come from a variety of sources. Of particular note: pump.io's "protocol" label, ActivityPub's GitHub repo, IRC, and cwebber's blog.
- Importing old posts into user inboxes when following someone new (such that their stream becomes "immediately usable" without waiting for future activity distribution)
- The ability to change usernames
- Distribution failover such that an admin could set up a secondary server which would then be tried for distribution if the primary server failed (similar to email's MX records)
- Future distribution model - http://dustycloud.org/blog/an-even-more-distributed-activitypub/
- Anti-abuse - https://dustycloud.org/blog/possible-distributed-anti-abuse/
- End to end encrypted wrapped objects (which lack server to server side effects) - https://github.com/w3c/activitypub/issues/225#issuecomment-304938193
- Revision IDs to detect and prevent race conditions - https://github.com/w3c/activitypub/issues/188
- Object history (possibly related to revision IDs?) - https://github.com/w3c/activitypub/issues/155
- Concrete auth protocols based on LDN (or whatever)
- WebSockets(? also value in something like SockJS) interface for clients to get streams like the inbox sent to them in realtime
- Priority flags - https://github.com/w3c/activitypub/issues/196
- Actor profile discovery via rel= links instead of content negotiation - https://github.com/w3c/activitypub/issues/204
- Direct message differentiation - https://github.com/w3c/activitypub/issues/196#issuecomment-304958984
- Useful "extra" inboxes for clients (conceptually similar to pump.io's major/minor inboxes; could also be used to e.g. query for all direct messages)
- Inbox search (very similar to above - i.e. an "extra" inbox constructed with the client's parameters, not the server's)