Skip to content

[WIP] MSC3219: Space Flair #3219

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

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

[WIP] MSC3219: Space Flair #3219

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
8be6909
Create 3219-space-flair.md
turt2live May 27, 2021
4650dbb
Update proposals/3219-space-flair.md
turt2live May 27, 2021
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
74 changes: 74 additions & 0 deletions proposals/3219-space-flair.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,74 @@
# MSC3219: Space Flair

[Spaces](https://github.com/matrix-org/matrix-doc/pull/1772) introduced an improved way of organizing rooms into tree-like
structures in Matrix. Its predecessor, Groups, had a concept of "flair" (or "related groups" at the technical level) where
users could have a smaller version of the Group's avatar next to their name in messages they send, if they've enabled flair.
Copy link
Contributor

@HarHarLinks HarHarLinks Dec 22, 2021 •
edited
Loading

Choose a reason for hiding this comment

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

I feel like this could be much better and flexible instead of more or less copying old community flairs, in which I don't see too much benefit anyway.

Flairs should not be limited to spaces (or plain rooms):
Much more interesting things can be done with them, e.g.

  • show off my matrix projects (and their rooms) in the matrix community space
  • indicate who is an official team member (of a space/room), with access restricted badges through e.g. room power levels
  • indicate who is in a (sub)team of a room that doesn't exist
  • indicate that a user is bridged, is a bot, etc
  • misc stuff, like "5 year club", that similarly has no extra rooms

These multiple badges could be modeled completely by room state. Alternatively by flairs-as-rooms as the proposal already does. Needed to add on: a room power level that defines the required PL to use the room as avatar (-> public rooms with flair PL <= default PL means anyone can). Additional flairs are created by creating new rooms with a m.flair flag in their state to indicate not showing these rooms in the room list. Again access management by PL. The flair rooms are announced in the "owner room's" state (is it a space yet? 🤔).

I could probably go on but I hope what I mean is evident? Imo this should be done properly right away and not have these additional kinds of flair tagged on later, potentially changing flairs again to not make a mess of the spec.

This primarily only worked in public Groups.

This proposal brings in a similar mechanic for Spaces, using the space-room's avatar as the flair.

## Proposal

Rooms can list the spaces (or technically, rooms) they want to appear as flair for users through a `m.room.flair` state event
with empty state key. The `content` would look similar to:

```json5
{
"spaces": [
{"room": "!room:example.org", "via": ["matrix.org", "example.org"]},
{"room": "#alias:example.org"},
]
}
```
Copy link
Contributor

Choose a reason for hiding this comment

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

This seems somewhat odd to me. A room doesn't have flair, why are we managing it in the room. I think the better option is to control flair in the user profiles, but the room can have a list of allowed flair (possibly open).


`via` is optional but recommended for routing purposes. The `room` can be a room ID or alias. Clients would peek these rooms to
get their avatar/aesthetic state events for representation. Clients are recommended to only show flair for rooms which are actually
spaces, though this proposal doesn't impose any limitations in rooms enabling flair of other non-space rooms.
Comment on lines +25 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.

What is the benefit of ignoring non-space rooms?


This approach also allows rooms to enable flair for private spaces if the user viewing the flair is in the private space, though
this is not seen as a realistic usage scenario given users joined to the space would be able to identify the other space members
(typically).

Flair is disabled by default for all users. Individual members can set a `"m.flair": true` flag on their own membership event in
Copy link
Contributor

Choose a reason for hiding this comment

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

As kevincox pointed out in other places, this way to manage it seems odd. Instead, the membership event should contain a list of flairs to display in the respective room.

  • Would I globally want to enable my #community:archlinux.org flair to tell everybody that sees me "I use Arch BTW"?
  • Why would I enable it for rooms in the Arch space? I'm in an Arch chatroom, obviously I use Arch BTW
  • I imagine this would set a standard for rooms to disable badges by default, as nobody wants to see unrelated badges. This makes it seem better to design it the other way round: explicitly enable instead of explicitly block

the relevant space to enable visibility of their flair. Clients should ignore this flag on non-`join` membership events to prevent
inviters, moderators, etc from "enabling" flair for the user without being an active participant. Servers are expected to preserve
the flag, if present, when changing profile information for the user (displayname/avatar). When not explicitly `true`, flair should
be considered disabled.

## Alternatives

### Extensible profiles ([MSC1769](https://github.com/matrix-org/matrix-doc/issues/1769))
Copy link
Contributor

Choose a reason for hiding this comment

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

I think flair should be managed by-profile. This today can be accomplished by updating the m.room.member event and in the future by room-based-profiles. This solves the issue for a user managing which flair shows in which rooms.

Copy link
Contributor

Choose a reason for hiding this comment

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

This today can be accomplished by updating the m.room.member event and in the future by room-based-profiles.

Isn't that exactly what this MSC is proposing?

From the MSC:

Individual members can set a "m.flair": true flag on their own membership event in the relevant space to enable visibility of their flair.

Copy link
Contributor

Choose a reason for hiding this comment

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

The key difference is that (if I understand correctly) this sets the enable flag on the space. Whereas the current profiles and most if not all MSCs about profiles put the config in the room. This means that with this MSC showing flair is a global decision per-flair (which is then filtered by the per-room whitelist, but the user is not in control there) whereas the other profiles (and profile proposals) allow you to decide how you want to appear in each room.


Extensible profiles are commonly referred to as profiles-as-rooms, where each user has a personal room which represents their "profile"
(display name, avatar, etc). Because this room is, well, a room it means that it can contain arbitrary state (metadata) that user
wishes to make public, such as Flair.

Flair in a profiles-as-rooms setup could be achieved with an `m.flair` (or `m.space.flair`?) state event which lists the Spaces the
user wishes to make public. This would mean that clients "peek" into profile rooms to determine changes to flair, but could also mean
that clients have to peek spaces too for cross-referencing. [MSC1772](https://github.com/matrix-org/matrix-doc/pull/1772) had some
[prior art](https://github.com/matrix-org/matrix-doc/pull/1772/commits/cd5a8420a8849b980df14df7dcc40c69a21bbbcd) on how this could work,
such as by including membership event IDs in the flair event and having the server validate the reference itself.

However, we don't have profile rooms today. This may change before this proposal can be considered, though.

## Potential issues/dependencies

Aside from extensible profiles, this proposal largely relies on peeking over federation being functional, which is covered by
[MSC2444](https://github.com/matrix-org/matrix-doc/pull/2444). Clients might prefer a simpler (non-deprecated) peek API as well, as
covered by [MSC2753](https://github.com/matrix-org/matrix-doc/pull/2753).

## Security considerations

Most of the security considerations revolve around private, or semi-private, membership to Spaces. Because flair only works if the
link between a user and a Space can be verified, this means that the Space must either be exposed publicly for peeking or accept that
flair will not work for non-members. This effectively means disclosing either all of the members of a Space, or none. The problem of
exposing only a subset of state to non-members is considered functionality for a future/different MSC.

Clients should additionally be aware that Spaces can be peekable (history set to `world_readable`) but *not* joinable (join rules of
`invite` or similar). This can also represent how a community can create a concept of "official" members by inviting them to a peekable,
but non-public, space. Flair would be enabled for this Space to denote official community members.

## Unstable prefix

While this MSC is not considered stable, implementations should use `org.matrix.msc3219` as a namespace. This means `m.room.flair`
becomes `org.matrix.msc3219.room.flair` and `m.flair` becomes `org.matrix.msc3219.flair` for example.