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

we could do with a grammar for tags #364

Open
richvdh opened this issue Aug 31, 2018 · 2 comments
Open

we could do with a grammar for tags #364

richvdh opened this issue Aug 31, 2018 · 2 comments
Labels
A-Client-Server Issues affecting the CS API enhancement A suggestion for a relatively simple improvement to the protocol

Comments

@richvdh
Copy link
Member

richvdh commented Aug 31, 2018

The spec says 'The name of a tag MUST not exceed 255 bytes', but doesn't specify an encoding, so that doesn't make much sense as it stands.

Should we allow non-ascii? (they are used as display names, so potentially) Spaces? Are they case-sensitive?

They are specific to users so homograph attacks aren't too much of a worry.

@richvdh richvdh added the enhancement A suggestion for a relatively simple improvement to the protocol label Aug 31, 2018
@uhoreg
Copy link
Member

uhoreg commented Aug 31, 2018

Since it's created by users for their own use, it seems like just saying that it's a UTF-8 string should be fine. I would hope that clients would present users with a list of tags to select, rather than requiring them to type it in every time, so I don't know if it matters much if we say that they're case sensitive or not. Maybe we can say that clients MAY fold case, and consider different character sequences that render identically (e.g. combining characters vs. single codepoints) to be the same, so that clients that care can implement that, but we don't force clients to have to deal with it.

@turt2live turt2live added the A-Client-Server Issues affecting the CS API label Sep 5, 2018
@KitsuneRal
Copy link
Member

KitsuneRal commented Oct 18, 2018

For the record, here's how Quaternion works. You're allowed to choose any tag that Quaternion knows from other rooms, or to enter new tags. Quaternion doesn't fold case; it only converts between m.favourite/m.lowpriority and human-friendly captions, and strips/adds u. prefix with user-defined tags.
Attempts to make any kind of unification lead to undesired results: for example, shortly after adding support of u. prefixes, and trying to unify legacy non-prefixed tags with prefixed ones in UI, I've had a report that Riot shows duplicate tags (both prefixed and non-prefixed) because Quaternion was only adding prefixed tags while non-prefixed ones were still used on other rooms. I believe it's better to leave users to their own devices (pun intended) and let them clean up their own mess they may produce with homographs etc.

@turt2live turt2live mentioned this issue Mar 1, 2022
12 tasks
@richvdh richvdh transferred this issue from matrix-org/matrix-spec-proposals Mar 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Client-Server Issues affecting the CS API enhancement A suggestion for a relatively simple improvement to the protocol
Projects
None yet
Development

No branches or pull requests

4 participants