Suggestion: using a private room as a shared data store across SchildiChat clients, to add user nickname

[NathanC]

I'm quite new to Matrix, but I've been toying with this idea a bit. It seems to me that a limiting factor with Matrix is the lack of a generic data store for a user (private to them). There are a lot of features (like being able to give someone a nickname) that don't have a way to associate a user with a nickname in the spec.

Having a name (associated with my contact book on my phone, potentially) for a user would be incredibly useful. Identity servers don't really work for privacy-- I don't want to publish my email or phone publicly associated with my account, but I'd still like my friends to identify me in the UI (after I tell them who I am).

I have a friend who uses matrix, and his name is totally unrelated to his real name. It always takes me a second of mental context switching to find him, or identify a message from him on my phone. I'd love to have a client side mapping from e.g., @strangeattractors:coolhomeserver.org -> Bob Smith (without other people knowing the full name of that user)

Ideally, something like this would be handled in the spec, and there are indeed a few issues floating around about it. However, it doesn't seem like there's a ton of momentum on them, and it'll take quite a while to be added, and still have limitations unless it's a generic client data store.

So my idea of a temporary solution (as well as potentially a proof of concept/value that could be upstreamed to a spec) is using a private room that SchildiChat would create on behalf of the user and use as a datastore. I'm not sure of the best way to structure it, but even just a simple JSON as content in a message in the room that can be edited over time, would work. More complex serializing data to a room could be implemented, of course, depending on details of the spec that I don't know enough to intelligently comment on.

At that point, within SchildiChat, the mobile and desktop app would be able to both construct the same config JSON from that well-known room (shildiChat_data_{userId} or something) once the user has gotten access to the encryption key. If the room is deleted by the user, or the key is lost-- no harm, the extra decorated config logic is lost and it fails gracefully to not using it. This should not be used for any important data, just user settings/overrides that need to persist across clients.

This wouldn't affect other clients, though they'd be able to leverage the same room if they wanted to support it. When the spec makes this hack needless, the user can be presented an option to convert away from the old pattern, or it can be done transparently. A generic adapter in the code could hide most of the complexity around it.

Some ideas for data that could be held in this simple synced data store:

• Mapping from matrix user -> nickname (UX could make both the underlying matrix display name and my nickname visible)
• Mapping from matrix user -> my phone's internal contact ID for that user, with an option to open that contact.
• Notes attached to a user (like in Discord), where I could e.g., include their personal website, or other info I want to remember when I see them again
• fallback avatars I choose for users that don't have avatars
• client ordering of spaces and subspaces in a list and pinned spaces

Honestly though, I just want to be able to make it clear my friend @strangeattractors:coolhomeserver.org is actually my friend Bob Smith when I get messages from him, in notifications and in the UX. That is the core feature request here that this simple data store could support.

This is just an experimental idea, and if this is the wrong place for it, please let me know! It seems like it would be a powerful way for a client to play with useful experimental features like naming contacts w/o any centralized data store. I'm considering doing something like this for a bot I'm creating (instead of having the bot maintain a DB), and I'm curious to hear any similar ideas that have been discussed/proposed.

[NathanC]

Alternatively to a room, a space could be used. (Something like ClientData). The description could just a YAML with some basic
mapping from userid -> nickname. The space image could be thematic.

No need for any rooms, and thus no client I've seen would give notifications on changes to the description to the user.

The user could look at the description and see a nice YAML (with comments explaining everything), and could just copy/paste that to their desktop for their own reference if they want to switch to another client that doesn't support nicknames. No lock-in. We could write a simple spec for it and other clients could use it if they chose, as it's client-side information inherently.

if the name ClientData is taken, the client can just prefix it with _ or __ until it finds one with a description that's a valid YAML or reaches some limit. Chance of realistic collisions seem very low.

edit: On second thought, I'm not sure how encryption works for spaces metadata, so perhaps rooms are much safer. The room could be assigned a space though to keep it away from the others, and made low priority with silent notifications.

[SpiritCroc]

This kind of issue is not suitable for the SchildiChat repos. I'm almost sure there's some MSCs (matrix spec change proposal) open for this kind of change (nicknames are one of the more commonly requested features).

Doing this kind of work is usually out of scope for us SchildiChat core developers. You're of course free to implement whatever you like, and we tend to be rather open for contributions. And of course it is a good idea to talk to us before implementing if you want to get it merged, if we'd be open for this. But this wall of text you wrote is inappropriate here, I'd say, it's spec thinking, not client thinking.

So ideally, you'd put your feedback on one of the existing MSCs, or write a new one, and get some feedback. Then it's enough to open an issue for SchildiChat along the lines of "Support MSC1234" (and whether you plan to work on it yourself), instead a wall of text of spec thinking :)

Content-wise feedback that comes to my mind, even though I'm no spec expert and this is the wrong place:

• Matrix recently wants to store everything as a room, such as profiles-as-rooms, so using rooms sounds natural.
• Matrix already has account-specific data store structures (see /devtools -> Account data; and room account data for room-specific data)
• Introducing another level of datastructures such as json or yaml doesn't sound useful to me, I think you could just use a custom/new event type (that you introduced in an MSC), and use the Matrix-native json-interpretation instead.

[NathanC]

@SpiritCroc sorry if it was out of place and for the wall of text, and thank you for your response.

I'll do a lot of research into the topics you mentioned before bringing this up again, but is the topic of user nickname and user notes completely off the table for SchildiChat if I made a contribution for it myself? What is the general process/delay around spec additions-- from what I saw, it looked like there were a ton of dead spec discussions, including old ones about nicknames with no movement on them. It seems like the client could implement this feature with currently available tools w/o needing a spec change, and I think a lot of people would find it very useful. But I also get not wanting to fragment the spec with client-specific standards.

[SpiritCroc]

Following approach is totally fine for adding such features to SchildiChat:

1. Pick a suitable MSC (or make one)
2. Implement it in a way that won't mess too much with other SchildiChat features, upstream merges, the SchildiChat design, ...
3. Create a PR :)

Of course generally speaking, there may also be features we wouldn't want to include if we think it doesn't fit our client, but user-defined nicknames would definitely be a welcome change in my eyes.

Re "w/o needing a spec change" - sure, this is possible, but ideally we want something that is interoperable with other clients, or at least other clients could easily add to become interoperable with us, since this feature isn't too client-specific in nature. I'm also fine if you can argue that existing MSCs have issues and you have a better idea, but only write the MSC while/after implementing the change. However, this approach increases the risk in doing bad design decisions which will hurt afterwards, especially considering you're not the first one to think about this topic and being "new" to matrix.

Maybe take MSC2867 as example. People wanted a way to mark rooms as unread, so people wrote an MSC and implemented it into FluffyChat. We wanted this feature as well, so took a look at the MSC and implemented it. Now, if you mark something as unread in SchildiChat, it will also be unread in FluffyChat, and vice-versa. (Element doesn't implement this MSC, so it doesn't work there obviously.) This MSC hasn't been accepted into the spec, but having an MSC out there still clarifies how clients may implement it nevertheless.

[NathanC]

@SpiritCroc Thank you, that was incredibly informative. I took a look at the marking rooms unread MSC.

I also enabled dev tools on Android SchildeChat (which are absolutely amazing, by the way), and I've been having a lot of fun poking around rooms and account data.

The MSC you linked mentioned the room unread feature would use com.famedly.marked_unread, but I don't see that in the room data-- was it implemented differently?

I'm also seeing lots of client-specfic data (for vector and cinny) in the account data, and some MSC prefixed keys. I feel absolutely foolish now for suggesting a yaml in the Space description-- I was under the (obviously silly in retrospect) idea that there wasn't a generic attribute store.

I know I'm getting ahead of myself with all these suggestions, seeing how I just set up my homeserver this week. I'll read up a lot more on the spec, and then I'm seriously considering either finding/contributing to a MSC on contacts or making my own, and making a PR down the road. I'll probably start in desktop just because it seems easier to work with, but I'm particularly interested in phone contacts integration.

Anyhow, thanks for your patience in explaining all this, it's appreciated.

[NathanC]

It would be good for contacts and user notes to be end-to-end encrypted. I'm going to read the e2e encryption impl details (my background is in software security), but I'm curious what level of effort it would be to have an e2e encrypted blob within account data? I'm assuming Element/SchildeChat has a generic interface for handling the complexity of key management?

[SpiritCroc]

I'm not aware of account data encryption right now (but I may miss something there), so using rooms as data store may still be a valid approach. You should be able to find some matrix rooms for client developers or matrix spec chatter which may better for discussing this, with more people who may be more knowledgeable (SchildiChat is an Element fork with focus mainly on UI aspects after all, so we usually do not play around with deeper spec changes too much).

I was linking the mark-as-unread MSC more as example how things not in the spec can end up in clients. There may be other MSCs or guides to fully get into the MSC concept though, don't know. com.famdely.marked_unread is set as room account data (both the room and account keywords are relevant here for checking from devtools). It may not be set if you never marked a room as unread.

[NathanC]

Makes sense-- it should be possible to do application layer encryption in the same way room encryption works, since the e2e encryption mechanism is still there, but if it's only applied to rooms before it would be a fair amount of work to add it. It might make sense to start out unencrypted and do that as an enhancement before the spec goes live.

and the room account data makes sense-- I was using the android app, and it shows account data and room data, but no room account data, is there a way to view it in the android dev tools?

As for desktop, is there a dev tools system similiar to mobile, where it reports unhandled/unseen events in a room, and allows you to click to view pretty json representations of account/room/room account data? I was able to pull up the chrome dev tools in Electron and see the indexeddb so I assume the data is there, but is it exposed in the interface? I can't find a setting for it.

[SpiritCroc]

When I was mentioning /devtools, I was actually thinking of the desktop ones, those are better. Just go to the room you want to inspect and "send" /devtools.
Hidden events can be enabled with ctrl+shift+h, or by going to "developer tools" using the gear icon in the left bottom corner.