v2 - Capabilities API (SPEC-95)

[matrixbot]

See SPEC-6 for client-server cap negotiation.
See SPEC-4 for client-client cap negotiation.
See SPEC-57 for server caps (possibly a subset of SPEC-6?)

(Imported from https://matrix.org/jira/browse/SPEC-95)

(Reported by @kegsay)

[matrixbot]

Jira watchers: @kegsay @richvdh

[matrixbot]

Links exported from Jira:

relates to SPEC-57
relates to SPEC-4
relates to SPEC-6

[matrixbot]

what is this? a parent of the other bugs?

-- @richvdh

[matrixbot]

ok I think the other bugs were merged together here.

The other bugs assert that this is handled via the URI path prefixes, and sensible handling of 404s, but I'm not so sure. A server may not support all modules in the spec, so we need a way to determine which it does. Relying on 404s is a bit flaky as 404s can result from misconfiguration as well as lack of support.

-- @richvdh

[turt2live]

For my future self when I inevitably come back and try and find the issues: SPEC-57, 4, and 6 cannot be found.

[richvdh]

For @turt2live's past self: you just have to spelunk in the right database.

---

SPEC-4:

(@ara4n): Client capability negotiation (for VoIP and other features)
We need a way to decide whether a given client is allowed to try to place a VoIP call to another client - i.e. is the other client WebRTC capable?

(@NegativeMjark): Can this be sent along with the presence information when a client connects?

If multiple clients are online for a given user at the same time how would we aggregate the different capabilities for the different clients?

(@leonerd): This could/should become part of the per-device presence information, along with "am I a mobiile phone"-like signal to suggest limited typing/screen space.

(@ara4n): The fact we still haven't got a way to negotiate what features are available between a given pair of clients is increasingly unfortunate, especially for VoIP. I'm not sure that presence solves this, given presence isn't currently per-device, and we may need to announce/query a large set of capabilities for the extensions a given client supports rather than use brute force.

Philipp Hanke recommended we take a close look at XEP-115, as a way of advertising & negotiating caps with minimal bandwidth by doing it in terms of hashes rather than actual content.

---

SPEC-6:

(@ara4n): Need a way to negotiate features between clients & homeservers
If my homeserver implements some funky extension (e.g. a super-efficient client-server transport) then I need a way to tell my clients that it's supported.

(@kegsay): That and versioning of said features would be nice, e.g. super-efficient client-server transport v 2.1.3

(@leonerd): Versioning of the protocol itself is already nicely handled by that /v1/ prefix - eventually could we not just start by having a client request something out out /v2/ or /v1.1/ or whatever? If the server doesn't understand, it'll just return a 404 and the client will have to fall back on v1.

---

SPEC-57:

(@erikjohnston): We need a way to get a list of services. E.g. contact servers, content repo.

(@kegsay): SPEC-95

---

All three issues were resolved by @kegsay at more-or-less the same time as this issue was created.

(Sorry to those who got binged by the above)

[turt2live]

I think this is solved by #1753