Messaging apps like Discord and Slack have the ability for the user to create groupchats with large amounts of people, where the messages can be organized into “channels” and moderators can delete messages, mute or kick groupchat members, create “roles” that can be assigned to groupchat members giving them the ability to speak, to moderate, or to view private channels, and to invite others. The implementation of things like private channels might be difficult, but creation of public channels within the groupchat could be done by simply “tagging” each message with a header specifying the channel that the message was sent in. Moderation might also be difficult to implement. Finally, scaling to large amounts of users sending large amounts of messages might be difficult, and cause performance issues. However, I think these features will allow Delta Chat to compete in a segment (groupchats exceeding 50 people) where most existing applications, like Discord, Slack, Matrix, and Telegram, have weak security.
I am not affiliated with DC and I do not know what they plan to do.
But I would think it would not be in DC’s best interest to really chase a “conference protocol” vibe. It’s more of an Instant Messenger.
Since the earliest days of the internet, “instant messengers” and “conference protocols” have been two distinct and separate concepts with differing design goals.
As I understand it, supporting very large communities in the conference protocol fashion would be challenging for DC.
So perhaps it’s best for DC to focus on being an excellent Instant Messenger.
Discord has been doing both large-group chatting and small-group/2-person interactions for quite a while. Additionally, I’d say that things like “Discord” are really more “instant messaging” than “conference” – people use them to chat with friends about random topics, organize events, etc. Also, a lot of DeltaChat’s features would be useful in a large-group setting – e2ee and authentication, webxdc apps (for example to plan events), anonymous chatmail, easy creation of Jitsi meetings, etc. Also, anyone who wants to set up a secured large groupchat would find DeltaChat’s invite interface easy.
My rough thoughts on this:
Moderation is too hard without servers. See the existing discussions on different group types. Though with the chatmail servers we might be able to add a protocol so that you can directly create and manage bigger groups based on mailing lists right from inside the delta chat interface. Those mailing lists are basically the server, so moderation and enforcing different roles is easier again.
Providing a separate mode to exchange the bubbles for a more compact discord / slack / rocket chat layout would be rather easy in comparison.
Also you can already look at the multi account feature as a way to have multiple contexts like discord’s guilds/servers.
About different conversations in groups, I think we should explore doing something similar to telegrams threading feature Threads in Group Chats - #10 by Simon.
Discord guilds/servers have the same people in all channels, so it’s not directly similar to the multi-group system. Also, people often want to chat with people they’ve already gotten keys for, and each account has a different key.
Yes, conference protocols have always supported direct messages and sometimes small groups, but it’s not necessarily optimized for this.
I brought up this point to underline that these are two different concepts- and although discord does provide a “good enough” IM experience, we shouldn’t also expect IMs to start providing conference experiences.
Some projects will provide both, some will specialize into just one or the other. I just want to underline that as end users, we should not hold the expectation that all projects specialize in both.
How does deltachat deal with encryption in group chats?
does each sender need to encrypt for all the group participants?
(sorry if this a FAQ that i missed somewhere)
does each sender need to encrypt for all the group participants?
yes.
in detail, the message itself is encrypted by a temporary key, and only the temporary key is then encrypted to each group participants. this avoids encrypted messages getting too big (eg. an image of 1 megabyte sent to 10 participants does not result in 10 megabyte data, but only slightly more than 1 megabyte). this is the standard PGP behaviour