-
Notifications
You must be signed in to change notification settings - Fork 383
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MSC 1597: Better spec for matrix identifiers #1598
Conversation
proposals/1597-id-grammar.md
Outdated
User IDs are | ||
[well-specified](https://matrix.org/docs/spec/appendices.html#user-identifiers), | ||
however we should consider dropping `/` from the list of allowed characters, as | ||
it interferes with URI escaping (XXX: how, specifically?) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the handwavey concern is that any HTTP layers between the client and HTTP handler in the server (e.g. proxies, load balancers, http router in the server) might get confused by a / and either change its escaping or treat it as a path separator somehow.
Another reason to consider dropping it is that mxids that begin with / get confused with slash commands, and in practice @foo/bar:example.com
in retrospect looks cosmetically quite strange - the / binds tighter than the :, so it almost looks like you are partitioning up your URL into @foo
and bar:example.com
.
Also, we've not actually ended up using it anywhere since introducing it (although that might just reflect the lack of investment on bridges :|)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another reason to consider dropping it is that mxids that begin with / get confused with slash commands
As discussed online, I'm failing to see how this is an issue that you solve by forbidding slashes in mxids, unless you also forbid slashes in displaynames.
However, the HTTP proxy argument makes more sense, on consideration. Have updated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks sensible to me as a proposal. I've commented on a few minor things, and added some points of information.
I'm also not sure how much editing you'd like to do, however there's some inconsistency between using "CS API" and "C-S API".
[Spec](https://matrix.org/docs/spec/client_server/unstable.html#post-matrix-client-r0-user-userid-filter) | ||
|
||
These are generated by the server and then used in the CS API. They are only | ||
required to be unique for a given user. `{` is already forbidden by the spec. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Specifically, {
is forbidden only at the start of the string. We should definitely forbid it throughout (which is proposed here already).
|
||
Generated by sending server. Needs to be unique for a given pair of servers. | ||
|
||
[Synapse](https://github.com/matrix-org/synapse/blob/74854a97191191b08101821753c2672efc2a65fd/synapse/federation/transaction_queue.py#L593) uses a stringified int and accepts pretty much anything. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fwiw sniffing through logs on my end I can also see [a-zA-Z0-9]+
for varying lengths. Well covered under the proposed opaque IDs - just a point of information.
given it's only a proposal I'm not too fussed about this sort of thing, but thanks. If I end up editing it anyway I'll try and clean it up. |
@mscbot fcp merge |
CC @matrix-org/spec-core-team |
@mscbot fcp merge |
Team member @turt2live has proposed to merge this. The next step is review by the rest of the tagged teams: No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm overall good with the proposal, just one-non blocking comment below.
> The total length (including sigil and domain) must not exceed 255 characters. | ||
> | ||
> This is only enforced for v2 rooms - servers and clients wishing to support | ||
> v1 rooms should be more tolerant. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"be more tolerant" probably means "accept anything possible"? Probably it's clearer to state that "Servers and clients wishing to support v1 rooms should not make assumptions on the character set and length of IDs." or just drop the part after the dash, implying that v1 is Wild West.
@mscbot reviewed (In an attempt to unwedge mscbot) |
@mscbot reviewed |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
The final comment period, with a disposition to merge, as per the review above, is now complete. |
This was supposed to resolve #1597, which has comments disabled. That should probably be unlocked or closed? (along with some of the issues it references, possibly) |
this, and therefore 1597, are from an older era of MSC systems. The idea was that this PR (labelled |
So what happens to that issue now? Is it considered fixed because this was merged and can be closed? |
the old system calls for the issue to remain open until the MSC is merged. The MSC hasn't been merged, it's just landed. "Merged" is once the spec PR has landed and thus ready for the next release. |
I'm going to back out the merge of this PR, since it seems to be causing confusion. |
So the MSC process has changed since this was originally merged, right? If this MSC was newer, it wouldn't have been merged without the necessary spec (and Synapse?) changes being implemented at all? |
correct. |
Okay, that helps put things into perspective. Thanks. Sorry if I'm being annoying, trying to juggle all of (what the spec says, what other parts of the ecosystem are doing, what makes sense to me) can be really frustrating. |
Signed-off-by: Kévin Commaille <[email protected]>
Rendered: https://github.com/matrix-org/matrix-doc/blob/rav/proposals/id_grammar/proposals/1597-id-grammar.md