Thoughts on profile rooms

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 (#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?

Start by reading the related issues #489 and #913 and the existing /send, /initialSync, and /sync behavior. Investigate how profile rooms could address federation and client peeking, per-room visibility, room versions, and canonical ownership. Done would require resolved protocol designs for these concerns, including subscription behavior and profile-room identification.