matrix-org / matrix-org/matrix-spec
New transport protocol (sunsetting JSON)
- Dominant language
- HTML
- Stars
- 330
- Forks
- 150
- Avg merge
- 2h 21m
- Merged PRs (30d)
- 3
Description
**Problem**
The Client-Server API is not bandwidth efficient enough. matrix-org/matrix-spec-proposals#3079 was supposed to help with that, but it has too broad scope and has the own issues. One of them is E2E — despite having CBOR as data format, encrypted messages are represented as Base64 string.
**Suggestion**
I suggest allowing client and server to specify request and response media types as by [RFC 7231 Section 5.3.2](https://datatracker.ietf.org/doc/html/rfc7231#section-5.3.2). This does **not** affect HTTP API and shouldn't require such changes.
Client and servers must set supported formats in `Accept` and `Content-Type` accordingly.
```
Accept: application/msgpack, example/vnd.elementx, application/json
Content-Type: application/msgpack
```
In this example I'm using [MessagePack](https://msgpack.org/) instead of CBOR, because its encoding is less complex (~~and wasn't a product of IETF bikeshedding~~), so it would provide better performance with the same bandwidth efficiency.
After some time, new proposal can be made to switch underlying E2E data encoding to most efficient one that are already being used, but only if MSC3079 would be useful enough to justify such changes.
Contributor guide
Research direction
No implementation files or tests are named. Start by reviewing MSC3079 and RFC 7231 Section 5.3.2; the issue is done when the specification defines request and response media-type negotiation and the corresponding Accept and Content-Type requirements.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- json
- Domain
- api, backend-api-design
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100