Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC3754: Removing profile information #3754

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
62 changes: 62 additions & 0 deletions proposals/3754-removing-profile-info.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,62 @@
# MSC3754: Removing Profile Information

In the Client-Server API specification, there is currently no clear way to remove the profile information, or to know
when it has been removed.

## Proposal

On top of the current profile endpoints:

```http
GET /_matrix/client/v3/profile/{userId}/avatar_url
GET /_matrix/client/v3/profile/{userId}/displayname
PUT /_matrix/client/v3/profile/{userId}/avatar_url
PUT /_matrix/client/v3/profile/{userId}/displayname
```

This proposal adds two new endpoints for deleting the data:

```http
DELETE /_matrix/client/v3/profile/{userId}/avatar_url
DELETE /_matrix/client/v3/profile/{userId}/displayname
```

To identify the change, the `m.room.member` and `m.presence` events sent following the call to one of these two
endpoints MUST include the changed key with a `null` value. Subsequent `m.room.member` events SHOULD omit the deleted
key altogether.
Comment on lines +24 to +26
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why must the m.room.member eventsinclude null instead of omitting the values? The current spec for m.room.member and m.presence for these fields is pretty clear:

The {avatar URL|display name} for this user, if any.

My reading of this is that the new values fully replace any old values and omitted values should be cleared.

Note that I think https://spec.matrix.org/v1.10/client-server-api/#events-on-change-of-profile-information is the useful part of the spec we're talking about? Cross-linking in the MSC is very much appreciated.


To reflect those changes, omitting the `avatar_url` field in the body of the request to `PUT […]/avatar_url` or
the `displayname` field in the body of the request to `PUT […]/displayname` is now deprecated. They can be marked as
required in a future MSC.

## Potential issues

Marking the fields in the body of the `PUT` endpoints requests as required would break compatibility for existing
clients so they are only deprecated for now. This means that the servers must accept two different ways of removing
profile data for the time being.

## Alternatives

Even if it is not documented, it is currently possible to remove profile account data. The general consensus is to send
`{ avatar_url: "" }` for `avatar_url` or `{}` for `displayname`. This means that a clarification in the spec would
either be inconsistent between the `PUT` endpoints or it whould require a change in the current implementations.

The `m.room.member` event omits the changed key in `content`. This means that all the keys that are not unset should be
present every time a part of the profile is changed. This is limiting for custom keys as they might be omitted by
clients or servers that don't recognize them.
Comment on lines +44 to +46
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not really following this, maybe fewer double negatives helps?

Suggested change
The `m.room.member` event omits the changed key in `content`. This means that all the keys that are not unset should be
present every time a part of the profile is changed. This is limiting for custom keys as they might be omitted by
clients or servers that don't recognize them.
The `m.room.member` event omits the changed key in `content`. This means that all the keys that ar set should be
present every time a part of the profile is changed. This is limiting for custom keys as they might be omitted by
clients or servers that don't recognize them.


Another alternative, that is currently the behavior in some clients, is that the profile information cannot be unset
once it has been set.

## Security considerations

None that I can think of.

## Unstable prefix

When implementing this proposal, clients and servers should use the `org.matrix.msc3754` unstable prefix;

```http
DELETE /_matrix/client/unstable/org.matrix.msc3754/profile/{userId}/avatar_url
DELETE /_matrix/client/unstable/org.matrix.msc3754/profile/{userId}/displayname
```