forked-synapse/docs/model/profiles.rst

========
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]]