WIPish: MSC1769: Extensible profiles as rooms

[ara4n]

Rendered

[ara4n]

(see also https://github.com/matrix-org/matrix-doc/issues/1746)

[ara4n]

@remram44 downvoted this, so i asked for clarification via Matrix on the rationale:

It probably simplifies some of the machinery but is very awkward from a API user stand point. I would have to treat that room differently anyway. It also makes it impossible to ask the server to return some of that info directly, I'd always have to peek that special room.
but the ACLs also make it too easy to break all of this. What if the room alias already exists? What if it's not readable to me? What if it's writable?
Most of the room machinery don't apply
I don't know what the situation is like for server implementors though.

To respond to this:

I would have to treat that room differently anyway

Not necessarily. If the room is used as the social feed for that user (as proposed in the Client Behaviour section below), clients could fell treat it as a real "Remram's Wall" style room - as well as it providing the additional profile state events about him. Even if that doesn't happen, it's just a simple filter to hide the room from the roomlist, and one which we are already doing trivially for things like VoIP conference rooms. There are also enough other cases where entities can be modelled elegantly as rooms without reinventing the wheel (e.g. groups; #1772) that the idea that we have rooms flying around which aren't normal chatrooms is probably inevitable. Likewise as more IOTish rooms start appearing which you may not want to see in your IM client's roomlist.

It also makes it impossible to ask the server to return some of that info directly, I'd always have to peek that special room.

This much is true. It's a trade-off between implementing a custom API specifically for querying profiles, versus (ab)using the peek API.

but the ACLs also make it too easy to break all of this

Not so sure about that. ACLs are a feature here. If you don't want someone to see your profile, then lock down who can access that room. It's very much a feature rather than a bug.

What if the room alias already exists?

We already have the ability to reserve chunks of alias namespace for stuff like that, and the spec already says that anything that begins with #_ should be preserved for magic rooms (i think/hope).

What if it's not readable to me?

Then that user has hidden their profile from you.

What if it's writable?

Then that user lets people respond to stuff written on their wall.

Most of the room machinery don't apply

I'd argue that the sync mechanisms, peeking mechanisms, ACLs, extensible key/value storage, and conversation history all apply.

I don't know what the situation is like for server implementors though.

With my server implementor hat on, i would be overjoyed that this proposal opens up a path to hosting extensible profiles without having to write a single line of server code (other than making peeking work over federation, which is desired anyway).

[jcgruenhage]

I don't like that format, it looks more like a typo IMO.

[gleachkr]

Here's another worry about the default alias scheme, from a discussion on #matrix-spec.

So, as I read this, a user with a userid @<mylocalpart>:<myserver> is supposed to have a default room profile alias of #@<mylocalpart>:<myserver> or #_profile_<mylocalpart>:<myserver>.

But userids are limited to 255 characters (in a subset of us-ascii, so assuming utf-8, 1 byte per character), while room aliases are limited to 255 bytes. So a 255 character userid, prefixed with # and utf-8 encoded will produce an invalid room profile alias.

Perhaps this could be avoided by only exposing room profiles via the profile field in m.room.member?

[Half-Shot]

What would be the plan for the existing /profile? Would it be deprecated or serve as a way to quickly set/get avatars/displaynames of users. Obviously we have a lot of code using /profile atm...

[heitorPB]

It would be nice if some of the fields (e.g. phone number, address, email, etc) would be private.

Telegram handles this in an interesting way: only my contacts can see my phone number, but anyone can send me a message with my @username.

[Half-Shot]

It would be nice if some of the fields (e.g. phone number, address, email, etc) would be private.

Telegram handles this in an interesting way: only my contacts can see my phone number, but anyone can send me a message with my @username.

I wonder if this could be achieved with multiple profile rooms, and only inviting "contacts" to a more private one.

[ara4n]

I wonder if this could be achieved with multiple profile rooms, and only inviting "contacts" to a more private one.

Yeah, this was sort-of what i had in mind - similarly for how you'd have private subsets of groups in groups-as-rooms

[ara4n]

note to self: this might also be able to replace presence lists if we sort out the "who has permission to see which profile (or presence) data" issue.

[heitorPB]

It would be nice if some of the fields (e.g. phone number, address, email, etc) would be private.
Telegram handles this in an interesting way: only my contacts can see my phone number, but anyone can send me a message with my @username.

I wonder if this could be achieved with multiple profile rooms, and only inviting "contacts" to a more private one.

I wonder how the UX will be... to be honest, I'd prefer #3795 over "profile rooms", but that might be because i'm used to simple "things"/contact-info?

[Half-Shot]

What's the need of "m.profile" inside "content"?

[ara4n]

#1767

[Half-Shot]

What is the rationale of blobbing all the profile in one state event rather than splitting out the types?

If I have a large profile, surely updating my displayname requires me to pull the whole event, change a value, then push it again which is going to be a rather large load in terms of the whole network. If the intention was to keep displayname and avatar as their own types, can that be added as an example?

[turt2live]

Tbh I thought this proposal reused existing state events where it made sense. Not really a fan of vcards-as-state.

[Half-Shot]

Given we have a rich typing system already, I am failing to see the advantage of doing a single event inside content. The only advantage I can see is a single request to pull the state, but surely the calling client knows what types it wants, and should just ask for what it needs. Alternative it can call /state and find out what types are supported.

[kevincox]

On the other hand profiles probably change relatively rarely. So bunching up a lot of data into a single event may be beneficial for memory usage and retrieval overhead. It makes the updates more expensive but the steady-state cheaper.

There is also an advantage of using a standard format that probably already has clients in numerous languages and allows interop. For example imagine that a client wants to implement "Add user to your address book" feature. Now this client is going to implement this Matrix -> vCard conversion mostly correctly for a subset of fields. If we natively support some sort of vCard, or well-known vCard conversion (like jsContact) this can be delegated to a dedicated library which hopefully has quite good support.

Furthermore if we are concerned about updates to big events maybe we can specify a general patch event in the future. However for just contact data (with the image broken out into the regular avatar) I don't think we need it anyways.

I was originally on the side of breaking it up but eventually I decided that the benefits of a standardized format is probably worth it.

[Half-Shot]

It's not clear to me if we are dropping the /profile endpoints, or simply making them helpers?

The endpoint will update all the member states in all the rooms for a user if they update their profile, so presumably that has to still be triggered when updating this room? Unless we are dropping profiles in member events, in which case I'd like to know how we plan to keep support for custom nicks per rooms as they are extremely useful for bridging things like discord.

[erkinalp]

It's not clear to me if we are dropping the /profile endpoints, or simply making them helpers?

How to make /profile work with zero or multiple profile rooms?

[erkinalp]

No. Profile rooms should be created on client request, and it should be allowed to have profile-less users (or users with multiple profile rooms).

[erkinalp]

Suggested change

	"name": {
	"family": "Gump",
	"given": "Forrest",
	"additional": "",
	"prefixes": "Mr.",
	"suffixes": ""
	},
	"name": {
	"family": "Gump",
	"given": "Forrest",
	"additional": "",
	"prefixes": "Mr.",
	"suffixes": "",
	"user_alias": "mrgumpforest"
	},

[uhoreg]

What is a user_alias? This is not defined anywhere in Matrix or in this MSC. Again, you are making a suggestion without providing sufficient context, and making us try to figure out what you're talking about.

[erkinalp]

Added the definition for user alias, as a suggested change.

[erkinalp]

Suggested change

	This would store a vCard-style profile of the user.
	This would store a vCard-style profile of the user, optionally including a user alias, as specified by
	the `user_alias` field under `name`. A user alias shall function similarly to the user display names
	we currently have and replace them, except it shall be optional, meaning each user and each profile
	shall have zero or more user aliases.

[jcgruenhage]

I do think it's reasonable to do it this way (replacing the display names from the member events), but I think we should stick to the already standardised names for vCards, which would make these nicknames, and not user aliases.

[erkinalp]

The difference lies within details. Usernames are 1:1, nicknames are 1:N, and user aliases will be M:N. Meaning, multiple (1+) users will be able to share the same profile and alias; and a user will be able to have multiple (0+) aliases.

[uhoreg]

Uhm, nicknames are not 1:N. There are multiple people who share the same nickname, and people can have more than one nickname, so nicknames are M:N.

[bmiller59]

@ara4n @turt2live Hi! Could you provide an update on the status of this from the perspective of a developer who run their own dev homeserver and would like to make use of it today? What steps would be required to start working with it?

Also, when is it anticipated that this will be implemented officially within synapse? Thank you.

[ryzokuken]

Suggested change

	`#@userid:<server>` (assuming aliases allow @; if not, `#_profile_userid:<server>`.
	`#@<userid>:<server>` (assuming aliases allow @; if not, `#_profile_<userid>:<server>`.

to better capture that userid here is not a literal.

[MTRNord]

I am not sure if I am just not finding it in the MSC or if it is missing, but what are the Powerlevels of these rooms supposed to be? Admin only for everything? Since the profile room I guess should only get changed by the creator of the room or am I wrong on that assumption?

[anoadragon453]

One potential issue with profiles as rooms is that you lose the ability to display old profile information in the timeline. No longer would a change to a field in your profile room directly correspond to a point in the timeline of another room.

Thus if you had a "job title" field in your profile room, and your client was configured to show that field's value next to messages from users in rooms, you wouldn't be able to definitely decide for a given message whether to use the old or new value.

That may not be that big a deal though. You could just make it loosely work by comparing origin_server_ts between events across rooms.

[theotheroracle]

users may also not necesarrily want old profile information in the timeline

[andrewzhurov]

Good points. They only way is to capture causality between your profile events and "interaction" (e.g., message) events.

Also, given you sign messages with a key managed in your profile, "anchoring" the message into profile is what proves it's authentic, persistent across key rotations.

[andrewzhurov]

Personally, a Room as a kind of Self-Sovereign Identifier seems like a great idea.

It could be used to manage authorized devices and their keys. With which full-fledged events could be created #4080, making users self-sovereign.
No need to have a master key (why would you want to? that's a point of failure), instead one could manage authorized devices and their keys with help of linked devices - do a 2FA, 3FA or however many, social recovery).

Users become first-class citizens in Matrix. Where Home Servers become mediators. Naturally making user's data their own, where HS can be seen as mailboxes "that's the way to reach me", which can be many, set in profile.

Profile could be seen as a generic key-value DB #4133, as CRDT, allowing to express deltas. (set name to Bob).

But how are devices managed exactly?
Say you lost a device and want to unlink it.
You create an "unlink" event, but what stops a malicious fella holding your device later on issue an event "as of the past"?
That say sets your profile's "homepage" to a "http://malicious.fella.org/".
Surely you'd not wish for it to be seen authentic.
These two event are not commutative, they require a point of order - which one happens first.
And that is possible by having a consensus algo atop your Matrix Event Graph (MEG). MEG alone is enough to have total order of events in it as a function of an event. (Devices simply gossip to each other events, we get total order of them - it is that simple (< imagine devices talk there))

So user can use his profile as a micro-ledger to manage his identity (authorized devices, their keys), profile info, as well as add authenticity to interaction he does by linking to his events. This micro-ledger can be represented as KERI's MultiSig AID, that is state of the art in SSI. Making user profile a DID, a broadly used standard. Which allows to use it for issuing and receiving Verifiable Credentials (say connect your driver license as a VC, or VC of your real name, issued by a gov, disclosing it at your discression). So profile stuff such as "phone number" "real name" can be authentic (think blue badge of Twitter, except from your gov, phone provider). May be handy for common folks as well as orgs.

And yeah, Twitter-like feed of authentic events, mentioned above!

Also could be used for defining "friends", making possible to authorize content to be readable by them. As a tangent to #3083.
(also based on VCs, e.g., chat for students of a uni)

As a crazy idea, we could try flipping chat paradigm on its head.

Instead of rooms being authoritative places where people chat, they can be seen as topics anyone can chat about.
Then it's just a matter of filtering whose contribution you want to see.
It's like tagging twitter messages. And creating your personal feeds (e.g., in this one I want to see opinions of my friends (or foaf) about politics, and in this one I want to see healthcare tips from a verified healthcare professionals)

MEG is awesome. MEG as a Profile SSI is double awesome.
Thanks to all the folks thinking on related topics across different MSCs. Good stuff!