Meta-issue: Discordification of Matrix/Synapse/Dendrites (feature request)

[DonaldTsang]

Description

There are at least a dozen issues relating to the design of Riot being too user unfriendly, and that people are suggesting designs similar to established apps like Discord and Slack. (Please post related issues in this page for further discussion)

Issue Types:

• Better Communities (AKA Discord "servers")
• Seamless E2E with better UX
• Better "unread messages" with ping as primary type
• Tag-based user and mod/admins types (similar to Discord)
• Mumble as a default widget (instead of Jitsi as it is bad on mobile)
• (others not included in the list above)

---

I have been a Riot user for about one and a half years, and I would hope for these features to give people a better user experience (features recommended from friends in Discord)

• [ ] Room feature support
  • [ ] Custom server-based and room-based emojis
    • Have custom server emojis downloaded and be usable as a basic feature
  • [ ] Emoji collection sharing
    • Similar to Telegram, Messenger, LINE and Whatsapp, but shareable and if possible, self-hosted or user-hosted
  • [x] Emoji reaction for texts and files (useful for voting)
  • [x] Automated (non-manual) key sharing
    • Some people are sick of needing to sharing key every time someone gets in the room, they would like to have auto key sharing once in an E2E room
  • [x] Multi-room search
• [ ] Community support
  • [x] Community id generation
  • [ ] Community room mass generation
  • [x] Community room searching
  • [x] Community multi-admin multi-mod support
  • [ ] Community and sub-community sort
• [ ] Role and access support
  • [ ] Mass room invitation by role or community
    • invitation to a server once application is approved
  • [x] Mass room banning/kicking by role or community
    • for when "unfavorable" behavior by certain users happen
  • [x] Community room sub-categorization and access
    • for visitor vs club member vs club staff separation
  • [ ] Role application and removal
    • for upgrading users to automatically bring them to certain rooms
  • [ ] Announcement rooms by role
    • rooms that allows viewing but not posting unless it is staff
  • [ ] Reaction allowance by role
    • for voting by certain role but not others
• [x] audio chat support
  • [ ] self-host SIP room support (tying SIP with server)
  • [ ] self-host Mumble room support (tying Mumble with server)
  • [ ] Radio/Playlist bot support
• [ ] collaborative support
  • [ ] self-host Etherpad/Firepad support (tying *pad with server)
  • [ ] self-host Hackmd support (tying Hackmd with server)

Cross-reference: https://github.com/matrix-org/synapse/issues/4030

[ghost]

There is a repo for a Mumble web client with active development here https://github.com/Johni0702/mumble-web

Seems to work although sometimes people sound like robots due to audio problems.

Hope that's helpful (I hate using Github).

[hramrach]

Is mumble encrypted?

[natrius]

A simple google-search shows the following https://wiki.mumble.info/wiki/Features#Encryption

Is that what you are searching?

[hramrach]

There is clearly a conflict in understanding 'communities' or 'servers' vs groups of rooms.

When room belongs to exactly one 'house', 'server', or 'community' there is mapping between the room and the 'community', and you can use it to impose administration and moderation policies on multiple rooms at once.

When 'communities' are folders where anyone can freely file rooms this makes for better organization of rooms but loses this ability to group rooms for purpose of administration/moderation.

[Mathias-g]

There is clearly a conflict in understanding 'communities' or 'servers' vs groups of rooms.

When room belongs to exactly one 'house', 'server', or 'community' there is mapping between the room and the 'community', and you can use it to impose administration and moderation policies on multiple rooms at once.

When 'communities' are folders where anyone can freely file rooms this makes for better organization of rooms but loses this ability to group rooms for purpose of administration/moderation.

Yeah, it would be better to call what is currently called communities (A folder of rooms), a "List" or "Collection" instead. While the new feature on the roadmap (Rooms of Rooms) a "Group" or "Community".

[beardedlinuxgeek]

There is a repo for a Mumble web client with active development here https://github.com/Johni0702/mumble-web

Unfortunately that broke recently. There is no way to integrate Mumble with Element at this time.

As for Mumble being centralized, so is Jitsi. You need a Jitsi server or you use the central one hosted by vector.

What I would like to see is a tightly coupled integration with Mumble. Make it so Mumble rooms appear as rooms inside of Element instead of using a widget. In Element, on the left hand side, you have a list of "People" rooms and list of "Rooms" rooms. I would like to see a 3rd category which is a list of Mumble channels (or at least Mumble servers). Then you could see who is active in the voice channel and join it like Discord.

Having voice chat as a room widget system is very clunky and the way Discord does it is much nicer. Essentially, show Mumble as a widget in the side bar and not as a widget in the room.

[ShadowJonathan]

I'm not sure if this is related right here, but coming from discord, some UX is incredibly unintuitive for me:

• clicking a user's username makes a mention to their username appear in the chatbox, i expect their profile to pop up (the only way i can do that is by scrolling through the room's userlist, which is incredibly user-unfriendly)
• no way to search for existing communities anywhere
• no quickshifter anywhere like discord's ctrl-T/ctrl-K which brings up an universal searcher (which would be perfect for matrix's +, !, # and @ prefixes for objects)
• direct messages and actual rooms are loosely differentiated, and honestly i think the divide is forced, give the user a way to provide:
  • an universal room "list" with all rooms a user is in
  • a "seperated" room list, like "group chat" (room with multiple users but no local # ID), "DM" (one recipient, name isnt defined, avatar isnt defined, no local ID) and "rooms" (other)
  • user-defined "grouping" like discord server grouping, where the user can group chats under tabs without a 'community' structure

please tell me if these ideas already exist, or if i should move this to a new issue, there are currently 4.3k issues here and i dont know how to search for existing ones for my ideas

[PeterSR]

Also

• Being able to use @here and @everyone to mention everyone in the room.

[ShadowJonathan]

@PeterSR maybe @room?

[t3chguy]

clicking a user's username makes a mention to their username appear in the chatbox, i expect their profile to pop up

Click on the avatar

[ShadowJonathan]

clicking a user's username makes a mention to their username appear in the chatbox, i expect their profile to pop up

Click on the avatar

Even so, that is a discrepancy between user expectancy and actuality (coming from discord: clicking username == profile popup), plus different reactions even though you'll be clicking on the same "thing" (user avatar and username could be considered the same "thing" in my head that way), also the fact that clicking on a user's avatar has a different reaction wasn't noted anywhere, and so I assumed that "clicking on a user in chat" will produce a mention as the law of the land, that is bad UX then, if a user cannot figure out usage from contextual clues if no explicit mention or tutorial is given

[trosel]

But it should be possible, to be completely honest. There is right now a community for german rooms. He is just collecting german rooms. There can be a community for tech-rooms as well. And a german tech-room can be in both communities at the same time. I think thats really good. The thing is, a room 'can' be in multiple communities. So, why should this be messy. You guys are just not used to that. I like it.

A clan could create a community for the clan with multiple rooms. And the entry-room can be in the "GAME"-community as well, if desired.

If I try to onboard someone to the matrix ecosystem, sending them to the universal room search is the last thing I want to do. I would just give them a simple link to click and instantly join my room.

Who wants this feature? To me, the whole concept of a global registry of rooms and the ability to tag rooms as part of twitter-like "groups" is a solution looking for a problem. All it does is add complexity and there is no discernible benefit.

Unless matrix is trying to become the next google and build their own index (I wouldn't be surprised if this was a goal lol), I think it's best to keep it simple for the sake of user sanity.

And in fact, i like that and this should be kept in my opinion, because its great. You CAN use it this way, but you don't have to. Maybe add an option to make it not possible for others to add this room to a community.

The problem is, the mere existence of an option like this is added complexity and overhead for everyone. It affects everyone whether they like it or not. Now you have an additional set of options and UX that make sense to no one except the priest class of matrix users.

[acoollevel]

Should the ability to create private communities be added to this list? vector-im/element-web#12658 It's a pretty important feature in Discord, and I feel like if people see the message "Warning: any person you add to a community will be publicly visible to anyone who knows the community ID" they will be less likely to switch.

[DonaldTsang]

@acoollevel the maths on invitations needs to be reworked, but I agree, we need public invites vs private invites and vetting, and then public rooms vs moderation rooms.

[heylix]

clicking a user's username makes a mention to their username appear in the chatbox, i expect their profile to pop up

Click on the avatar

Even so, that is a discrepancy between user expectancy and actuality (coming from discord: clicking username == profile popup), plus different reactions even though you'll be clicking on the same "thing" (user avatar and username could be considered the same "thing" in my head that way), also the fact that clicking on a user's avatar has a different reaction wasn't noted anywhere, and so I assumed that "clicking on a user in chat" will produce a mention as the law of the land, that is bad UX then, if a user cannot figure out usage from contextual clues if no explicit mention or tutorial is given

So what you're really saying is that documentation and UI hints for onboarding are lacking. The problem is not that it works in a different way, but that users are accustomed to that. For me it's more intuitive that if I click on a name it appears in the chat as mention, as it worked in IRC.

For me it's logical: If you want to know more about a user, click on the representation of the user (their avatar). If you want to talk to the user, click on their name. It's analogous to conversations in real life: You recognise someone by their face or likeness and you talk to them by using their name which you might know from a name tag which is attached to the person.

I think the current behaviour is fine. If it's not, there's a possibility for someone to develop a Discord "skin" or "theme" for Riot which works differently – but I think the standard behaviour shouldn't be changed. Consistency in user experience is important and if we'd change things without thinking about the implications for current users, just because Discord or Slack are doing it differently, we'll be in a bad place.

"Good UX" is not "doing everything like other apps". If it were, we wouldn't have any evolution of UX.

[DonaldTsang]

@heylix base and experimentation would be good, and treat Discord as the "gold" standard while we try to mine for platinum.

[Kellegram]

Agreed. Copy what's good, improve on what's subpar. No need to reinvent the wheel, Discord does a lot of things good from UI standpoint, but also does many things poorly, which is unsolvable by it being closed-source, centralized and catering to the folk that are indifferent as long as it hand holds them enough.

[MyriaCore]

As a meta-issue, maybe it'd make sense to update the issue description with related issues for all of the checkboxes? It'd probably lead to much more productive discussion, as there would be a summarized single-source-of-truth, and people wouldn't need to go hunting in the comments for the current state of these topics.

I've only done a bit of searching, but here are some of my findings for existing related proposals:

• [MSC2545] proposes custom emojis (\ tags that render as emoticons), and associated functionality (such as making them room-based or community-based)
• Community support is weird, since communities in element are a bit jankey. What element calls "communities" is actually an undocumented matrix feature called "groups". The fact that they're undocumented isn't the only thing causing the jank either - the API itself has some issues. As such, the proposal I'd personally point to as the way forward is [MSC1772], which rebrands groups as "spaces", and proposes that we represent them as rooms with special properties, instead of representing them as their own custom object. This would make things easier to work with for developers. Related is the proposal here to support [MSC1772] in element.io, over the current groups API. Alongside this, IMO , [MSC2946] would also be important, as it would provide an API for gathering high level information about the organization of a space, which would be useful for performing actions on an entire space recursively, and not just on its immediate children rooms.
• Audio Chat is mentioned in matrix-org/matrix-doc#2851, but it's mentioned as an in-house thing, rather than a fuller third-party integration thing (e.g. via mumble or jitsi). I think there was also experimentation done with WebRTC, so using WebRTC is certainly something that's possible. matrix-org/matrix-doc#2903 proposes a voice / voip room, which would function more similarly to what we'd think of as a 'voice channel' in discord. A completely unrelated implementation of Voice channels can be seen over in the matrix-react-sdk project. AFAIK this uses jitsi to implement voice channels. For sure show your support over there cause I think it's one of the only recent experiments with a voice channels, as opposed to just doing a call within a room. However, because the PR is part of the react sdk, it's really just UI, and not baked into the matrix server itself. It might be wise to think about submitting a supporting MSC so voice channels could have an official API, rather than be delegated to a UI element. It's important that the api can recognize a room as a "voice room" - maybe the api would support backends for the delivery of the voice, such as WebRTC, jitsi, mumble, etc? I couldn't find any existing proposals like that, though.
• Wasn't mentioned in the issue desc but [MSC2199] proposes first-class DMs

In general, we also definitely shouldn't be relying on this issue for discussion. The way I see it, all of these topics should be given sub-issues of their own in the relevant channels so they can be implemented more quickly.

I'm super new to the matrix ecosystem, so I personally find it difficult to decide where to post proposals / issues often. For those of you who want to help write out proposals for these topics & link them back to here, here's what I've sussed out so far:

• Detailed proposals for new features that tie into matrix's SDK should probably go in matrix-doc, as most of the features that are implemented in the matrix sdk's seem to come from these MSC's.
• UI proposals that would probably need to be available to all matrix webclients should go in matrix-org/matrix-react-sdk
• Recommendations for the element.io webapp or the element.io desktop app should go here, in element-web

[MyriaCore]

@DonaldTsang would you mind changing the issue description as discussed above?

atm you have this:

> * [ ] Room feature support > * [ ] Custom server-based and room-based emojis > * Have custom server emojis downloaded and be usable as a basic feature > * [ ] Emoji collection sharing > * Similar to Telegram, Messenger, LINE and Whatsapp, but shareable and if possible, self-hosted or user-hosted > * [ ] Emoji reaction for texts and files (useful for voting) > * [ ] Automated (non-manual) key sharing > * Some people are sick of needing to sharing key every time someone gets in the room, they would like to have auto key sharing once in an E2E room > * [ ] Multi-room search > * [ ] Community support > * [x] Community id generation > * [ ] Community room mass generation > * [x] Community room searching > * [ ] Community multi-admin multi-mod support > * [ ] Community and sub-community sort > * [ ] Role and access support > * [ ] Mass room invitation by role or community > * invitation to a server once application is approved > * [ ] Mass room banning/kicking by role or community > * for when "unfavorable" behavior by certain users happen > * [ ] Community room sub-categorization and access > * for visitor vs club member vs club staff separation > * [ ] Role application and removal > * for upgrading users to automatically bring them to certain rooms > * [ ] Announcement rooms by role > * rooms that allows viewing but not posting unless it is staff > * [ ] Reaction allowance by role > * for voting by certain role but not others > * [ ] audio chat support > * [ ] self-host SIP room support (tying SIP with server) > * [ ] self-host Mumble room support (tying Mumble with server) > * [ ] Radio/Playlist bot support > * [ ] collaborative support > * [ ] self-host Etherpad/Firepad support (tying *pad with server) > * [ ] self-host Hackmd support (tying Hackmd with server)

But as of the time of writing, I feel this would be more appropriate:

* [ ] Room feature support * [ ] Custom server-based and room-based emojis * Proposed by [[MSC2545](https://github.com/matrix-org/matrix-doc/pull/2545)] * [ ] Emoji collection sharing * Similar to Telegram, Messenger, LINE and Whatsapp, but shareable and if possible, self-hosted or user-hosted * [x] Emoji reaction for texts and files (useful for voting) * [ ] Automated (non-manual) key sharing * Some people are sick of needing to sharing key every time someone gets in the room, they would like to have auto key sharing once in an E2E room * [x] Multi-room search * [ ] Community support * Element's "Communities" are actually an undocumented matrix feature called [groups](https://github.com/matrix-org/matrix-doc/issues/971), which happens to use a quite [jankey API](https://github.com/matrix-org/matrix-doc/blob/ff85e61be908f4f5f0ba846da0dd6c439147a1b0/proposals/1772-groups-as-rooms.md#appendix-problems-with-the-r0groups-api). [[MSC1772](https://github.com/matrix-org/matrix-doc/pull/1772)] proposes that the we refactor the jank a bit to make groups easier to work with. * [This issue](https://github.com/vector-im/element-web/issues/15930) proposes that element.io's client should support MSC1772, instead of using the undocumented groups API * [x] Community id generation * [ ] Community room mass generation * [x] Community room searching * [ ] Community multi-admin multi-mod support * [ ] Community and sub-community sort * [ ] Role and access support * [ ] Mass room invitation by role or community * invitation to a server once application is approved * [ ] Mass room banning/kicking by role or community * for when "unfavorable" behavior by certain users happen * [ ] Community room sub-categorization and access * for visitor vs club member vs club staff separation * [ ] Role application and removal * for upgrading users to automatically bring them to certain rooms * [ ] Announcement rooms by role * rooms that allows viewing but not posting unless it is staff * [ ] Reaction allowance by role * for voting by certain role but not others * [ ] audio chat support * See matrix-org/matrix-doc#2903 for first-class "voice/video rooms". * See [this Proof of Concept implementation](https://github.com/matrix-org/matrix-react-sdk/pull/4400) for voice room / voice channel UI in the matrix react sdk * [ ] self-host SIP room support (tying SIP with server) * [ ] self-host Mumble room support (tying Mumble with server) * [ ] Radio/Playlist bot support * [ ] collaborative support * [ ] self-host Etherpad/Firepad support (tying *pad with server) * [ ] self-host Hackmd support (tying Hackmd with server)

[ShadowJonathan]

@MyriaCore I have the feeling that @DonaldTsang has been offline for a while for some good reason, I don't think he'll have time to edit the original description anytime soon, so a member of the repo has to do that.

[DonaldTsang]

@ShadowJonathan apologies, I would not mind doing it, however if it is going to be changed often, the dev team should change it instead.

[Jieiku]

Mumble

self-host Mumble room support (tying Mumble with server)

Nothing stops you from hosting a mumble server and using the mumble web UI as a widget.

I am interested in having a voice chat room on my matrix server. It sounds as though mumble can facilitate this?

If so would it show up as a room in element?

I am not afraid of trying something a little outside of the box if the end result is being able to jump into a voice room and immediately being able to voice listen or voice talk with others, without the need to be invited into a call, etc.

I would then be able to pull some friends from discord and onto my matrix server.

I have setup a mumble server before on my linux server, i have just never tried to integrate mumble with matrix.

[SimonBrandner]

@xekon, that won't be that easy. You would need something like https://github.com/matrix-org/matrix-react-sdk/pull/4400 which is probably terribly outdated at the moment. You would essentially need to re-write that PR for Mumble and then probably maintain your fork of Element because I have my doubts about this getting merged upstream. Upstream plans Matrix-based voice/video rooms at some point, so this would be an effort that would lead to something that would get replaced eventually. Though now that I think of it, I've heard of an Element fork that already does this. I'd try asking in the Element Web/Desktop room maybe someone there can give you directions. In general this question probably should be there rather than here, since this is an issue tracker, not a support forum.

[maxwell-kalin]

msc2545 implementation would be nice

[Jieiku]

msc2545 implementation would be nice

What is msc2545?

[natrius]

I think https://github.com/matrix-org/matrix-spec-proposals/pull/2545 is meant. On the other hand, mumble is currently rewriting its core (i think) and it should be easier to implement this afterwards. https://github.com/mumble-voip/ Voice-Channels would should have priority above sticker packs :)

[prabhathc]

Hey all, is it possible to also consider the deafen feature? Deafen mutes the user's audio output and mutes all incoming audio from group calls just for the deafened user, convenient feature that should be straightforward to add.

[heyakyra]

https://github.com/vector-im/element-call/issues/223 and https://github.com/vector-im/element-call/issues/174 would be nice extensions to the now-merged https://github.com/matrix-org/matrix-spec/issues/730

[slimsag]

Could "Increase vertical density of new room list vector-im/element-web#14099" be added to this meta-issue? I think this is one big drawback compared to Discord's UX right now.

Compare the visual density of Element:

vs. a similar Discord channel organization capabilities:

[erkinalp]

Well, Discord is also adding a few ideas from Element, for example, the ability to selectively hide guild channels.

[kittykat]

Moving this issue to discussions in Element meta as we need to make a cross platform decision on how to proceed :+1:

[42Willow]

I personally prefer the way element is structured, but permissions that are for all the rooms in a space would be great.