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

[WIP] MSC3219: Space Flair #3219

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

Conversation

turt2live
Copy link
Member

@turt2live turt2live changed the title [WIP] MSC0000: Space Flair [WIP] MSC3219 Space Flair May 27, 2021
@turt2live turt2live added client-server Client-Server API kind:feature MSC for not-core and not-maintenance stuff proposal A matrix spec change proposal labels May 27, 2021
@turt2live turt2live changed the title [WIP] MSC3219 Space Flair [WIP] MSC3219: Space Flair May 27, 2021
Co-authored-by: Stuart Mumford <stuart@cadair.com>
Copy link

@kevincox kevincox left a comment

Choose a reason for hiding this comment

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

I don't like this. It seems like a quick hack to get it working but it seems like it will need to be redone as we get some required changes in.

  • We need good profile support for users to manage what flair they show where. Putting the enable/disable in spaces forces this to be global.
  • This has no way to allow arbitrary flair, the allowlist is set in the room.

TL;DR I see fair as a profile feature, the room/space can add some lists of allowed flair if they want.

Comment on lines +25 to +26
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.

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?


## Alternatives

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

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.

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.

{"room": "#alias:example.org"},
]
}
```

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).

@turt2live turt2live added the needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. label Jun 8, 2021
@marcusmueller
Copy link

Just a user/element renter's feedback: This feature was valuable for conference organizing in with Communities in the past, and it would be very cool to see it for spaces in the future.

Copy link
Contributor

@HarHarLinks HarHarLinks left a comment

Choose a reason for hiding this comment

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

oops, can't seem to delete this

Copy link
Contributor

@HarHarLinks HarHarLinks left a comment

Choose a reason for hiding this comment

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

Apparently I don't know how to review, here I try again.

I feel like flairs should be designed more general and flexible. This MSC seems to try to mirror the old community flairs. Essentially, it enables you to stick a couple badges on your belt to advertise for the spaces you're joined to where ever you go, unless you happen to go into a room that asks you to show only certain badges.

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


[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

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.

@HarHarLinks
Copy link
Contributor

since this is closely related, instead of adding its own spec for flairs, simply put flairs into per-room/space extensible profiles and which for example are attached to the respective rooms like this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client-server Client-Server API kind:feature MSC for not-core and not-maintenance stuff needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants