9.7 KiB
Profiles
A description of Synapse user profile metadata support.
Overview
Internally within Synapse users are referred to by an opaque ID, which consists of some opaque localpart combined with the domain name of their home server. Obviously this does not yield a very nice user experience; users would like to see readable names for other users that are in some way meaningful to them. Additionally, users like to be able to publish "profile" details to inform other users of other information about them.
It is also conceivable that since we are attempting to provide a worldwide-applicable messaging system, that users may wish to present different subsets of information in their profile to different other people, from a privacy and permissions perspective.
A Profile consists of a display name, an (optional?) avatar picture, and a set of other metadata fields that the user may wish to publish (email address, phone numbers, website URLs, etc...). We put no requirements on the display name other than it being a valid Unicode string. Since it is likely that users will end up having multiple accounts (perhaps by necessity of being hosted in multiple places, perhaps by choice of wanting multiple distinct identifies), it would be useful that a metadata field type exists that can refer to another Synapse User ID, so that clients and HSes can make use of this information.
Metadata Fields
[[TODO(paul): Likely this list is incomplete; more fields can be defined as we think of them. At the very least, any sort of supported ID for the 3rd Party ID servers should be accounted for here.]]
- Synapse Directory Server username(s)
- Email address
- Phone number - classify "home"/"work"/"mobile"/custom?
- Twitter/Facebook/Google+/... social networks
- Location - keep this deliberately vague to allow people to choose how
granular it is
- "Bio" information - date of birth, etc...
- Synapse User ID of another account
- Web URL
- Freeform description text
Visibility Permissions
A home server implementation could offer the ability to set permissions on limited visibility of those fields. When another user requests access to the target user's profile, their own identity should form part of that request. The HS implementation can then decide which fields to make available to the requestor.
A particular detail of implementation could allow the user to create one or more ACLs; where each list is granted permission to see a given set of non-public fields (compare to Google+ Circles) and contains a set of other people allowed to use it. By giving these ACLs strong identities within the HS, they can be referenced in communications with it, granting other users who encounter these the "ACL Token" to use the details in that ACL.
If we further allow an ACL Token to be present on Room join requests or stored by 3PID servers, then users of these ACLs gain the extra convenience of not having to manually curate people in the access list; anyone in the room or with knowledge of the 3rd Party ID is automatically granted access. Every HS and client implementation would have to be aware of the existence of these ACL Token, and include them in requests if present, but not every HS implementation needs to actually provide the full permissions model. This can be used as a distinguishing feature among competing implementations. However, servers MUST NOT serve profile information from a cache if there is a chance that its limited understanding could lead to information leakage.
Client Concerns of Multiple Accounts
Because a given person may want to have multiple Synapse User accounts, client implementations should allow the use of multiple accounts simultaneously (especially in the field of mobile phone clients, which generally don't support running distinct instances of the same application). Where features like address books, presence lists or rooms are presented, the client UI should remember to make distinct with user account is in use for each.
Directory Servers
Directory Servers can provide a forward mapping from human-readable names to User IDs. These can provide a service similar to giving domain-namespaced names for Rooms; in this case they can provide a way for a user to reference their User ID in some external form (e.g. that can be printed on a business card).
The format for Synapse user name will consist of a localpart specific to the directory server, and the domain name of that directory server:
@localname:some.domain.name
The localname is separated from the domain name using a colon, so as to ensure the localname can still contain periods, as users may want this for similarity to email addresses or the like, which typically can contain them. The format is also visually quite distinct from email addresses, phone numbers, etc... so hopefully reasonably "self-describing" when written on e.g. a business card without surrounding context.
- [[TODO(paul): we might have to think about this one - too close to email?
-
Twitter? Also it suggests a format scheme for room names of #localname:domain.name, which I quite like]]
Directory server administrators should be able to make some kind of policy decision on how these are allocated. Servers within some "closed" domain (such as company-specific ones) may wish to verify the validity of a mapping using their own internal mechanisms; "public" naming servers can operate on a FCFS basis. There are overlapping concerns here with the idea of the 3rd party identity servers as well, though in this specific case we are creating a new namespace to allocate names into.
It would also be nice from a user experience perspective if the profile that a given name links to can also declare that name as part of its metadata. Furthermore as a security and consistency perspective it would be nice if each end (the directory server and the user's home server) check the validity of the mapping in some way. This needs investigation from a security perspective to ensure against spoofing.
One such model may be that the user starts by declaring their intent to use a given user name link to their home server, which then contacts the directory service. At some point later (maybe immediately for "public open FCFS servers", maybe after some kind of human intervention for verification) the DS decides to honour this link, and includes it in its served output. It should also tell the HS of this fact, so that the HS can present this as fact when requested for the profile information. For efficiency, it may further wish to provide the HS with a cryptographically-signed certificate as proof, so the HS serving the profile can provide that too when asked, avoiding requesting HSes from constantly having to contact the DS to verify this mapping. (Note: This is similar to the security model often applied in DNS to verify PTR <-> A bidirectional mappings).
Identity Servers
The identity servers should support the concept of pointing a 3PID being able to store an ACL Token as well as the main User ID. It is however, beyond scope to do any kind of verification that any third-party IDs that the profile is claiming match up to the 3PID mappings.
User Interface and Expectations Concerns
Given the weak "security" of some parts of this model as compared to what users might expect, some care should be taken on how it is presented to users, specifically in the naming or other wording of user interface components.
Most notably mere knowledge of an ACL Pointer is enough to read the information stored in it. It is possible that Home or Identity Servers could leak this information, allowing others to see it. This is a security-vs-convenience balancing choice on behalf of the user who would choose, or not, to make use of such a feature to publish their information.
Additionally, unless some form of strong end-to-end user-based encryption is used, a user of ACLs for information privacy has to trust other home servers not to lie about the identify of the user requesting access to the Profile.
API Requirements
The data model presented here puts the following requirements on the APIs:
Client-Server
Requests that a client can make to its Home Server
- get/set my Display Name This should return/take a simple "text/plain" field
- get/set my Avatar URL The avatar image data itself is not stored by this API; we'll just store a URL to let the clients fetch it. Optionally HSes could integrate this with their generic content attacmhent storage service, allowing a user to set upload their profile Avatar and update the URL to point to it.
- get/add/remove my metadata fields Also we need to actually define types of metadata
- get another user's Display Name / Avatar / metadata fields
[[TODO(paul): At some later stage we should consider the API for:
- get/set ACL permissions on my metadata fields
- manage my ACL tokens
]]
Server-Server
Requests that Home Servers make to others
- get a user's Display Name / Avatar
- get a user's full profile - name/avatar + MD fields This request must allow for specifying the User ID of the requesting user, for permissions purposes. It also needs to take into account any ACL Tokens the requestor has.
- push a change of Display Name to observers (overlaps with the presence API)
Room Event PDU Types
Events that are pushed from Home Servers to other Home Servers or clients.
- user Display Name change
- user Avatar change [[TODO(paul): should the avatar image itself be stored in all the room histories? maybe this event should just be a hint to clients that they should re-fetch the avatar image]]