Skip to content
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

Merged
merged 6 commits into from
Dec 23, 2018

Conversation

richvdh
Copy link
Member

@richvdh richvdh commented Aug 29, 2018

@richvdh richvdh requested a review from a team August 29, 2018 22:38
proposals/1597-id-grammar.md Outdated Show resolved Hide resolved
proposals/1597-id-grammar.md Outdated Show resolved Hide resolved
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?)
Copy link
Member

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 :|)

Copy link
Member Author

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.

Copy link
Member

@turt2live turt2live left a 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.
Copy link
Member

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.
Copy link
Member

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.

@richvdh
Copy link
Member Author

richvdh commented Aug 31, 2018

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".

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.

@turt2live
Copy link
Member

@mscbot fcp merge

@anoadragon453
Copy link
Member

CC @matrix-org/spec-core-team

@turt2live
Copy link
Member

@mscbot fcp merge

@mscbot
Copy link
Collaborator

mscbot commented Sep 10, 2018

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.

Copy link
Member

@KitsuneRal KitsuneRal left a 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.
Copy link
Member

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 mscbot added the proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the final comment period. label Dec 17, 2018
@erikjohnston
Copy link
Member

@mscbot reviewed

(In an attempt to unwedge mscbot)

@anoadragon453
Copy link
Member

@mscbot reviewed

@mscbot mscbot added the final-comment-period This MSC has entered a final comment period in interest to approval, postpone, or delete in 5 days. label Dec 18, 2018
@mscbot
Copy link
Collaborator

mscbot commented Dec 18, 2018

🔔 This is now entering its final comment period, as per the review above. 🔔

@mscbot mscbot added finished-final-comment-period and removed proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the final comment period. final-comment-period This MSC has entered a final comment period in interest to approval, postpone, or delete in 5 days. labels Dec 18, 2018
@mscbot
Copy link
Collaborator

mscbot commented Dec 23, 2018

The final comment period, with a disposition to merge, as per the review above, is now complete.

@jplatte
Copy link
Contributor

jplatte commented Jun 9, 2020

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)

@turt2live
Copy link
Member

this, and therefore 1597, are from an older era of MSC systems. The idea was that this PR (labelled proposal-pr) is the discussion point and the issue is to hold the number. Discussion should not happen on the issue.

@jplatte
Copy link
Contributor

jplatte commented Jun 9, 2020

So what happens to that issue now? Is it considered fixed because this was merged and can be closed?

@turt2live
Copy link
Member

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.

@richvdh
Copy link
Member Author

richvdh commented Aug 19, 2020

I'm going to back out the merge of this PR, since it seems to be causing confusion.

richvdh added a commit that referenced this pull request Aug 19, 2020
…mmar"

This reverts commit d9135ef, reversing
changes made to f714aaa.

People are getting confused by the fact this has been merged.
@jplatte
Copy link
Contributor

jplatte commented Aug 19, 2020

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?

@richvdh
Copy link
Member Author

richvdh commented Aug 19, 2020

correct.

@jplatte
Copy link
Contributor

jplatte commented Aug 19, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants