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.

Sign up for GitHub

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

Jump to bottom

WIPish: MSC1769: Extensible profiles as rooms #1769

Draft
wants to merge 5 commits into
base: old_master
Choose a base branch
from
Draft

WIPish: MSC1769: Extensible profiles as rooms #1769

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
2411c45
first cut of a profiles-as-rooms MSC
ara4n Jan 3, 2019
ff1d197
gah tabs spaces
ara4n Jan 3, 2019
3f59758
backlink to MSC489
ara4n Jan 3, 2019
a6816ec
switch proposed profile format & justify it
ara4n Jan 4, 2019
a20a1a3
spell out deps
ara4n Jan 6, 2019
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
5 changes: 3 additions & 2 deletions proposals/1769-extensible-profiles-as-rooms.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,8 @@ leverage all the existing infrastructure we have for sending and receiving state
events.

Clients should construct the default alias of the profile room is constructed as
Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure this sentence came out the way it was supposed to

Copy link
Member

Choose a reason for hiding this comment

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

indeed

Suggested change
Clients should construct the default alias of the profile room is constructed as
Clients should construct the default alias of the profile room as

`#_profile_userid:<server>`.
`#@userid:<server>` (assuming aliases allow @; if not, `#_profile_userid:<server>`.
Copy link

Choose a reason for hiding this comment

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

Suggested change
`#@userid:<server>` (assuming aliases allow @; if not, `#_profile_userid:<server>`.
`#@<userid>:<server>` (assuming aliases allow @; if not, `#_profile_<userid>:<server>`.

to better capture that userid here is not a literal.

The server in the alias is that of the user whose profile is being considered.
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't like that format, it looks more like a typo IMO.

Copy link

@gleachkr gleachkr Apr 15, 2021 •
edited
Loading

Choose a reason for hiding this comment

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

Here's another worry about the default alias scheme, from a discussion on #matrix-spec.

So, as I read this, a user with a userid @<mylocalpart>:<myserver> is supposed to have a default room profile alias of #@<mylocalpart>:<myserver> or #_profile_<mylocalpart>:<myserver>.

But userids are limited to 255 characters (in a subset of us-ascii, so assuming utf-8, 1 byte per character), while room aliases are limited to 255 bytes. So a 255 character userid, prefixed with # and utf-8 encoded will produce an invalid room profile alias.

Perhaps this could be avoided by only exposing room profiles via the profile field in m.room.member?


This may be overridden per-room by setting a `profile` field in the
`m.room.member` for the user. (Once we remove MXIDs from rooms in
Expand All @@ -26,7 +27,7 @@ the same underlying profile room).
This does not replace the current `displayname` and `avatar_url` field behaviour
on `m.room.membership` events which we have today.

This is an alternative to [MSC489](https://github.com/matrix-org/matrix-doc/issues/489).
This proposal is an alternative to [MSC489](https://github.com/matrix-org/matrix-doc/issues/489).

## Client behaviour

Expand Down