[Discussion] Speccing a namespace for user tags

[elinorbgr]

This is a RFC/Discussion regarding tags that users can set to rooms.

This RFC does not imply any change of the APIs nor any adaptation is required from the homeserver implementation, but simply asks for some convention be integrated into the spec, as guidelines for the matrix clients.

Background

Matrix client can currently associate tags with matrix rooms. The specification currently specifies m.favourite and m.lowpriority as tag names that are specially recognized by clients (notably Riot), but it is possible for any tag to be set to a room, the interpretation of them being currently unspecified.

It is apparently generally accepted that every application should use tag namespaces according to their domain name (for example im.riot.* for riot-specific tags) for storing tags related to internal functionality of this client.

Proposition

Specify how tag namespaces should be interpreted by the clients like so:

• The m.* namespace only contains tags specified by the matrix spec
• The u.* namespace is reserved for user tags. These tags can be set by the user to order their rooms as they please. As such, the clients should only interpret them as "a label the user has set to this room". The exact way this is reflected on the UI is up to the client to decide. (Possible examples could be: displaying categories regrouping rooms with the same tags, or using tags to offer a filtering mechanism to the user...)
• The tld.domainname.* namespace associated to the client name is free for the client to use as they please
• Any tag not matching these namespaces should be ignored (so that client won't try to interpret tags internals to other clients/apps)

These are guidelines for matrix client, to ensure a good cohabitation in the room tag namespace, but they cannot (and should not) be enforced by the protocol.

Motivation

The initial motivation is for the reservation of the u. namespace. Allowing users to tag their room in order to organize them is a useful feature clients can provide to their users. (I personally use it to order my ~100 rooms, using the undocumented-but-kinda-existing support for these tags in riot-web.)

Thankfully, the matrix protocol already supports this via the room tags mechanism. Reserving now this namespace and advertising it as such now, before clients actually try to implement these functionality ensures a good interoperability with clients in the future, while requiring a very low effort from the matrix specification.

Unresolved questions

What should be done if a user wants to put special UTF8 characters in their tag names? I see two options:

• Treat the u. as a special prefix to the tag name, but the rest is just an UTF8 string and should only be treated as such, with no attempt of parsing it further
• Encode the UTF8 room name using the same encoding as used for usernames, or base64, or any other to be decided, and store u.<encoded room name> as the tag name.

[GuillaumeDIDIER]

Namespacing client-specific tag is quite important for future maintenance and evolution of all clients.
And +1 on a namespace for user defined tags.

[richvdh]

@vberger are you happy for this to be closed?

[elinorbgr]

Absolutely 👍