Thoughts on profile rooms

[turt2live]

In an effort to solve extensible profiles (#489) and also not maintain a bunch of ways to synchronize data to clients, "profiles as rooms" (or just "profile rooms") could be used. This takes the form of a room where the user's profile lives and any other data they might want to advertise, such as an m.bio or m.website.

Each user would have 1 room for their profile, and they would be the only allowed member. The room's state would be the various parts of the user's profile, such as the name being the user's display name. Similarly, custom state events can be used to define stuff like social media links, bios, locations, etc.

In order to have this work effectively though, there's some concerns that need to be addressed:

• Peeking over federation (Clarify access to listing members by guest users #913) would have to work
  • Can we solve this by re-using the existing /send route? It would be a shame to have peeking be appended as another way to sync data between servers. Would need some form of subscribe/unsubscribe though.
• Peeking in clients could be improved. Currently clients have to use /initialSync which is deprecated. We should re-use /sync where possible to avoid having billions of people in profile rooms and to avoid a billion initial syncs flying around.
• How do per-room profiles work?
  • How do we safely ensure that people not in those rooms can't see the user's per-room profile for that room? There's a valid case for someone being in #company and #afterdark, but not necessarily wanting members of #company to know that they like to be called something different in #afterdark.
• Do we need a custom room version? Stuff like bans, invites, ACLs, etc might not make sense in a profile room.
• How do we indicate that a room is a profile room? Do we need to prove that the room is the canonical place for the user's profile?

[turt2live]

Note that a proof of concept of this exists in the form of a special-case experimental feature: https://github.com/matrix-org/matrix-react-sdk/blob/experimental2/src/MergedUsers.js

It handles joining a bit differently, and doesn't follow the model fully, but does prove it is a viable solution if we cut back the barrier to entry.

[ara4n]

Some thoughts i've had on this in the past include:

• Could the profile room also be the public 'wall' for that user? I.e. let users join it and scribble/respond on it if the owner allows?
• Could it also (in a groups-as-rooms world) act as the root for the user's personal group? (i.e. that user's set of personal rooms, including any they might choose to publicly publish?)