Document grammar for device IDs

[jimmycuadra]

The spec is currently missing any definition of the grammar for a device ID. While it is implied that they should just be a random string of characters, at least the following should be explicit:

• Minimum and maximum character (or byte) lengths
• Allowed and disallowed characters
• Any expected patterns, such as starting with a letter followed by N digits

There needs to be some UX consideration beyond considering them opaque byte sequences, since they are displayed visually to users in some cases.

Though not specific to the grammar of the ID, the spec should also address what the scope of uniqueness is for device IDs. Do they need to be universally unique? Or only unique to the user the device belongs to? Or unique to the user's homeserver?

This may be considered part of #174.

[richvdh]

https://matrix.org/docs/spec/intro.html#devices says:

Devices are identified by a device_id, which is unique within the scope of a given user.

beyond that, I'm not sure there is anything here which isn't already covered by #174 (which explicitly mentions device ids)?

[jimmycuadra]

Perhaps this is an issue with having important information that exists only in the intro document. I'd expect the intro to explain general concepts of how Matrix works, but that any details useful to an implementer be available within the main document for that API, perhaps with an explicit link to other documents when information would otherwise be duplicated between documents. As is, I would've had to guess to go check the introduction for the information I wanted while looking at the client-server spec, which obviously wasn't something that occurred to me. :}

[joepie91]

What is the current (provisional) guidance on what a device ID should and/or can be, from an "implementing a homeserver" perspective? #174 is about 'completely opaque identifiers', but that clashes with the * wildcard character usage in some device_id fields, so evidently it can't just be any byte sequence.

Even just some practical data on what major clients currently do or allow, would be useful here.