wholetrans/docs-matrix-spec
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

incorporate further feedback

Browse source
This commit is contained in:
Matthew Hodgson 2019-04-01 10:27:30 +01:00
parent 417f3a3e8b
commit 88f533f0db
1 changed files with 12 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

23
proposals/1884-replace-slashes-in-event_ids.md
View file

@ -80,10 +80,10 @@ right encoding.
However, the current uses of standard Base64 encodings are not exposed to However, the current uses of standard Base64 encodings are not exposed to
common CS API developers, and so whilst this might be slightly confusing common CS API developers, and so whilst this might be slightly confusing
for the minority of expert homeserver developers, the confusion does not for the minority of expert homeserver developers, the confusion does not
exist today for client developers. Therefore it seems safe to standardise exist today for client developers (except those implementing E2EE).
(except those implementing E2EE) on URL-safe Base64 for identifiers exposed Therefore it seems safe to standardise on URL-safe Base64 for identifiers
to the client developers, who form by far the majority of the Matrix exposed to the client developers, who form by far the majority of the
ecosystem today, and expect as simple an API as possible. Matrix ecosystem today, and expect as simple an API as possible.
A potential extension would be to change *all* Base64 encodings to be A potential extension would be to change *all* Base64 encodings to be
URL-safe. This would address the inconsistency. However, it feels like a URL-safe. This would address the inconsistency. However, it feels like a
@ -139,9 +139,9 @@ solutions to that are also possible).
There are two main questions here: There are two main questions here:
1. Whether it's worth forcing manual CS API users to juggle escaping of 1. Whether it's worth forcing CS API developers to juggle escaping of
machine-selected IDs in order to remind them to escape all variables in machine-selected IDs during manual use of the API in order to remind them
their URIs correctly. to escape all variables in their URIs correctly when writing code.
2. Whether it's a significant problem for E2EE & SS API developers to have to 2. Whether it's a significant problem for E2EE & SS API developers to have to
handle strings which are a mix of standard Base64 and URL-safe Base64 handle strings which are a mix of standard Base64 and URL-safe Base64
@ -156,10 +156,11 @@ developers test their clients against a 'torture room' full of exotic IDs and
data, or by improving warnings in the spec... rather than (ab)using data, or by improving warnings in the spec... rather than (ab)using
machine-selected IDs as a reminder. machine-selected IDs as a reminder.
Meanwhile, given we have many more CS API developers than SS or E2EE Meanwhile, given we have many more people manually invoking the CS API than
developers, and we wish to make the CS API particularly easy for developers to developing on the SS or E2EE APIs, and we wish to make the CS API particularly
manually invoke, it feels we should not prioritise consistency of encodings easy for developers to manually invoke, it feels we should not prioritise
for SS/E2EE developers over the usability of the CS API. consistency of encodings for SS/E2EE developers over the usability of the CS
API.
Therefore, on balance, it seems plausible that changing the format of event IDs Therefore, on balance, it seems plausible that changing the format of event IDs
does solve sufficient problems to make it desirable. does solve sufficient problems to make it desirable.