WIPish: MSC1769: Extensible profiles as rooms #1769

ara4n · 2019-01-03T00:49:12Z

Rendered

ara4n · 2019-01-03T00:56:56Z

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

proposals/1769-extensible-profiles-as-rooms.md

ara4n · 2019-01-04T23:07:51Z

proposals/1769-extensible-profiles-as-rooms.md

@@ -0,0 +1,150 @@
+# Proposal for extensible profiles as rooms


@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).

proposals/1769-extensible-profiles-as-rooms.md

jcgruenhage · 2019-01-05T10:58:09Z

proposals/1769-extensible-profiles-as-rooms.md

@@ -14,7 +14,8 @@ leverage all the existing infrastructure we have for sending and receiving state
 events.

 Clients should construct the default alias of the profile room is constructed as
-`#_profile_userid:<server>`.
+`#@userid:<server>` (assuming aliases allow @; if not, `#_profile_userid:<server>`.
+The server in the alias is that of the user whose profile is being considered.


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

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 · 2019-01-18T02:16:00Z

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 · 2019-01-18T19:13:02Z

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 · 2019-01-18T22:55:02Z

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 · 2019-01-18T22:58:54Z

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 · 2019-01-19T12:23:48Z

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 · 2019-01-19T23:08:07Z

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 · 2019-01-20T13:48:55Z

proposals/1769-extensible-profiles-as-rooms.md

+{
+    "type": "m.profile",
+    "content": {
+        "m.profile": {


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

Half-Shot · 2019-01-29T13:04:34Z

proposals/1769-extensible-profiles-as-rooms.md

+
+### m.profile
+
+This would store a vCard-style profile of the user.


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?

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

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.

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 · 2019-01-29T13:06:14Z

proposals/1769-extensible-profiles-as-rooms.md

+rules. Again, defining this is left as a separate MSC.
+([MSC1777](https://github.com/matrix-org/matrix-doc/issues/1777))
+
+The same peeking could also be used to display message events in the user's


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.

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 · 2021-05-23T18:23:52Z

proposals/1769-extensible-profiles-as-rooms.md

@@ -0,0 +1,152 @@
+# Proposal for extensible profiles as rooms


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 · 2021-05-23T18:39:18Z

proposals/1769-extensible-profiles-as-rooms.md

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


Suggested change

"name": {

"family": "Gump",

"given": "Forrest",

"additional": "",

"prefixes": "Mr.",

"suffixes": ""

},

"name": {

"family": "Gump",

"given": "Forrest",

"additional": "",

"prefixes": "Mr.",

"suffixes": "",

"user_alias": "mrgumpforest"

},

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.

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

erkinalp · 2021-05-24T06:18:53Z

proposals/1769-extensible-profiles-as-rooms.md

+
+### m.profile
+
+This would store a vCard-style profile of the user.


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.

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.

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.

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 · 2021-07-14T16:32:19Z

@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 · 2021-07-27T15:18:02Z

proposals/1769-extensible-profiles-as-rooms.md

+events.
+
+Clients should construct the default alias of the profile room is constructed as
+`#@userid:<server>` (assuming aliases allow @; if not, `#_profile_userid:<server>`.


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 · 2022-01-01T16:09:23Z

proposals/1769-extensible-profiles-as-rooms.md

@@ -0,0 +1,152 @@
+# Proposal for extensible profiles as rooms


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 · 2022-10-06T17:01:02Z

proposals/1769-extensible-profiles-as-rooms.md

+room profile event).
+
+Internationalisation could be done using "lang" keys, as per MSC1767.
+


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.

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

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 · 2024-05-29T09:48:47Z

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!

RokeJulianLockhart · 2024-09-21T16:49:21Z

proposals/1769-extensible-profiles-as-rooms.md

+
+Profiles are currently limited to display names and avatars.  We'd like users to
+be able to publish arbitrary data about themselves instead (in a relatively
+vcard-compatible fashion).


Rather like nextcloud/contacts#3956 (comment) mentions, wouldn't an XML or JSON-based format (like jCard) be superior? Or is this merely referring to how it's key-value based?

anoadragon453 · 2024-09-25T13:35:48Z

Heads up that an MSC with similar goals (but achieved in a simpler fashion that this one) is currently making its way through the MSC process: #4133

Those interested in this feature may want to have a look.

first cut of a profiles-as-rooms MSC

2411c45

turt2live added proposal A matrix spec change proposal T-Core labels Jan 3, 2019

ara4n added 2 commits January 3, 2019 00:50

gah tabs spaces

ff1d197

backlink to MSC489

3f59758

ara4n added proposal-pr and removed proposal-in-review labels Jan 3, 2019

ara4n changed the title ~~MSC1769: Extensible profiles as rooms~~ WIPish: MSC1769: Extensible profiles as rooms Jan 3, 2019

jcgruenhage reviewed Jan 3, 2019

View reviewed changes

proposals/1769-extensible-profiles-as-rooms.md Show resolved Hide resolved

turt2live reviewed Jan 4, 2019

View reviewed changes

proposals/1769-extensible-profiles-as-rooms.md Outdated Show resolved Hide resolved

turt2live reviewed Jan 4, 2019

View reviewed changes

proposals/1769-extensible-profiles-as-rooms.md Outdated Show resolved Hide resolved

anoadragon453 removed the T-Core label Jan 4, 2019

ara4n commented Jan 4, 2019

View reviewed changes

proposals/1769-extensible-profiles-as-rooms.md Outdated Show resolved Hide resolved

switch proposed profile format & justify it

a6816ec

jcgruenhage reviewed Jan 5, 2019

View reviewed changes

spell out deps

a20a1a3

ara4n mentioned this pull request Jan 12, 2019

Extensible Profiles. (SPEC-93) #3795

Open

Half-Shot reviewed Jan 20, 2019

View reviewed changes

aaronraimist mentioned this pull request Jan 28, 2019

[Feature] Encrypted Profiles (profile picture, display name etc) element-hq/element-meta#1838

Open

Half-Shot reviewed Jan 29, 2019

View reviewed changes

erkinalp suggested changes May 23, 2021

View reviewed changes

erkinalp suggested changes May 24, 2021

View reviewed changes

turt2live added the needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. label Jun 8, 2021

ryzokuken reviewed Jul 27, 2021

View reviewed changes

turt2live force-pushed the old_master branch from e895827 to dca99ee Compare August 30, 2021 22:34

Mikaela mentioned this pull request Aug 31, 2021

Per-room/per-space profiles syphon-org/syphon#331

Open

SimonBrandner mentioned this pull request Dec 11, 2021

The ability to create custom sections in your profile element-hq/element-web#20147

Closed

MTRNord reviewed Jan 1, 2022

View reviewed changes

HarHarLinks mentioned this pull request Mar 29, 2022

[WIP] MSC3219: Space Flair #3219

Draft

gleachkr mentioned this pull request Mar 30, 2022

MSC3757: Restricting who can overwrite a state event #3757

Open

ajbura mentioned this pull request May 28, 2022

Support for custom user text statuses / bio's cinnyapp/cinny#318

Open

dklimpel mentioned this pull request Aug 12, 2022

[WIP] MSC3865: User-given attributes for users #3865

Draft

anoadragon453 reviewed Oct 6, 2022

View reviewed changes

vintprox mentioned this pull request Oct 14, 2022

Profile interop: Use public/private key/value storage provided by Matrix protocol matrix-org/thirdroom#380

Open

DMRobertson mentioned this pull request Nov 3, 2022

Howto add custom profile info in account_data and show to friends? matrix-org/synapse#14357

Closed

turt2live mentioned this pull request Dec 14, 2022

More profile customizability #3950

Closed

Half-Shot mentioned this pull request Dec 28, 2022

Embed links to third party identities with rel="me" for cross verification. matrix-org/matrix.to#298

Open

MadLittleMods mentioned this pull request Apr 17, 2023

Gitter feature parity overview issue element-hq/roadmap#26

Open

48 tasks

4www mentioned this pull request Nov 9, 2023

How to use (CRUD) arbitrary key/value data associated with a user account (public) profile matrix-org/matrix-js-sdk#3856

Closed

regalialong mentioned this pull request Feb 25, 2024

Biography / Pronouns support mautrix/discord#136

Open

Half-Shot mentioned this pull request Apr 23, 2024

MSC4133: Extending User Profile API with Key:Value Pairs #4133

Open

This was referenced May 30, 2024

MSC4145: Simple verified accounts #4145

Draft

MSC4049: Sending events as a server or room #4049

Draft

MSC4047: Send Keys #4047

Draft

andrewzhurov mentioned this pull request Jun 30, 2024

Thread sync with gossip-about-gossip and Cordial Dissemination decentralized-identity/didcomm-messaging#456

Open

RokeJulianLockhart reviewed Sep 21, 2024

View reviewed changes

		@@ -0,0 +1,150 @@
		# Proposal for extensible profiles as rooms


		### m.profile

		This would store a vCard-style profile of the user.

		@@ -0,0 +1,152 @@
		# Proposal for extensible profiles as rooms

-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.

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

		room profile event).

		Internationalisation could be done using "lang" keys, as per MSC1767.

WIPish: MSC1769: Extensible profiles as rooms #1769

Are you sure you want to change the base?

WIPish: MSC1769: Extensible profiles as rooms #1769

Conversation

ara4n commented Jan 3, 2019 • edited Loading

ara4n commented Jan 3, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gleachkr Apr 15, 2021 • edited Loading

Choose a reason for hiding this comment

Half-Shot commented Jan 18, 2019

heitorPB commented Jan 18, 2019

Half-Shot commented Jan 18, 2019

ara4n commented Jan 18, 2019

ara4n commented Jan 19, 2019

heitorPB commented Jan 19, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Half-Shot Jan 29, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

erkinalp May 24, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bmiller59 commented Jul 14, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andrewzhurov commented May 29, 2024

Choose a reason for hiding this comment

anoadragon453 commented Sep 25, 2024

ara4n commented Jan 3, 2019 •

edited

Loading

gleachkr Apr 15, 2021 •

edited

Loading

Half-Shot Jan 29, 2019 •

edited

Loading

erkinalp May 24, 2021 •

edited

Loading

bmiller59 commented Jul 14, 2021 •

edited

Loading