[WIP] MSC3219: Space Flair #3219
Conversation
turt2live
added
client-server
Co-authored-by: Stuart Mumford <stuart@cadair.com>
There was a problem hiding this comment.
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.
| 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. |
There was a problem hiding this comment.
What is the benefit of ignoring non-space rooms?
|
|
||
| ## Alternatives | ||
|
|
||
| ### Extensible profiles ([MSC1769](https://github.com/matrix-org/matrix-doc/issues/1769)) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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"}, | ||
| ] | ||
| } | ||
| ``` |
There was a problem hiding this comment.
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
added
the
needs-implementation
|
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. |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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.
|
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 |
Rendered