when you have close friends or family members in a group, not having an Admin is not really bad, but when the group gets larger sometimes you need ways to control some aspects of the group. right now, anyone can change the name of the group or spam everybody or …
is it possible to have restrictions in the groups?
or is it against the philosophy of Deltachat?
3 Likes
It’s not against the philosophy, but it’s difficult from a technical point of view because there is no central instance that saves information about the group. And it’s difficult to keep the member list in sync (i.e. consistent) across all members, also having a list of administrators will make things harder.
Also, e-mail isn’t really suited for large groups, anyway, because you will hit spam filter limits at some point.
If you want a large group which you can control, you will have to create a mailing list currently, e.g. with Mailman.
2 Likes
Yup, that’s a disadvantage. We could do something fancy with symmetric encryption to solve this, but that’s looooooots of work, so for now we’ll have to stay with “DC isn’t really suited for large groups”.
2 Likes
Yes, I agree with this attitude!
1 Like
As suggested by @Raiden it is interesting to look at how Threema handles this. I don’t have Threema, but their documentation suggests that they have a “creator” role that cannot be transferred to anyone, so there are no complicated questions related to granting/revoking privileges in a decentralized manner when messages can be lost.
To transfer creator privileges their FAQ recommends using “clone group” which incidentally already exists in Delta Chat: Can creator privileges be transferred or granted to multiple users in group chats? – Threema
I did not know Threema has “clone group”, I think Delta Chat came up with this idea independently, would be interesting to see how it works there.
1 Like
It is indeed not only about the implementation.
Implementing such access control may make the experience worse, I certainly don’t like such “owned groups” to be the default. Non-responsive admins who you need to reach to add someone to the group or create invite link are a more frequent problem than someone changing the name. If there is some user with an over quota mailbox or deleted account it’s easier if you can immediately delete member instead of waiting for the admin to clean up the group. Spammers can already create their own groups with known contacts and spam in 1:1 chats, so adding admin role is not likely to help. And it may be better to let the groups break apart before you get to large thousand-member groups with conflicts related to the direction it goes.
1 Like
the group can always be cloned, and a bot could be used as group admin then most of the problems are gone and the group could be used for more public setups like our community group, it doesn’t need to be in the UI, if as first step we add it only to core and bots can use it that would already be useful
1 Like
I wonder if it would be possible to have multiple admins in a group with the help of such a bot. The bot would be the admin of a group and at the same time a member of a control group. The other members of the control group can control the first one via the bot.
While the goal of having group admins and moderators might be a long way off, maybe its worth making an easy way to create mailing lists from within the app, and letting subscribers just scan a QR code to join the mailing list.
This would then give similar functionality to Signal and Telegram’s broadcast channels. Maybe a “DC broadcast” feature is the low hanging fruit here?
1 Like
I tend to agree that refining/expanding on the current (not-end-to-end encrypted btw) broadcast groups/channels is an interesting consideration but also not exactly low-hanging fruit.
(We’d probably want to introduce symmetric encryption to broadcast channels so they can scale rather arbitrarily without increase in message size, and without revealing subscriber identities. And then I guess introducing an “invite link” to broadcast channels makes sense, so you can publish a QR code / https-link for subscription.)
1 Like
I think the broadcast lists are already quite usable. The only strange thing is that the recipients can create an avatar, but not the creator of the list. Maybe it would make also more sense to rename them channels?
If I remember correctly, it was even possible to subscribe to a broadcast list via bot? In my opinion, encryption is not that important here. Telegram channels are not encrypted either.
yes, currently they work more as Telegram channels, not really as WhatsApp’s broadcast list anymore, so renaming makes sense to avoid confusion
encryption is important because with chatmail only encrypted messages are allowed, also because you don’t want random servers to read your messages, they are private channels, not public channels
1 Like
I think the most important part of “owned groups” implementation is on the “receiver side”, i.e. how to deal with messages violating privileges e.g. messages from non-admins changing the group name or members. Otherwise one can take another MUA and do what they want.
The “sender side” isn’t that important, maybe restrictions in UIs not needed at all, e.g. let’s consider the following approach:
- When the user joins the group, they receive a list of members and admins. EDIT: The list of admins may only be changed manually or by admins.
- The user themselves is always an admin (i.e. there’s no need in any conditional restrictions in UIs) and the user’s changes are only accepted locally and by others who chose the user to be an admin on their side.
If current admins become unresponsive, users can talk and agree in the group about new admins.
1 Like
This idea clearly needs some work to make it usable and not result in inconsistencies just because some users did not read the chat and did not approve the new admin.
But I like the direction, the situation where group has 5 members, group owner became unresponsive, deleted Delta Chat or left the group and now the others cannot do anything is silly.
Also without members dropping the messages from users outside the group removing spammers will not work, spammers can still technically send messages into the group and they will just appear with “~” before the name. Currently it is usually a result of some technical problem like late message or member list inconsistency that should be fixed by adding the user back into the group.
1 Like
If the old admins approve the privileges transfer, there’s no problem. Only when some members decide to change admins and the old ones are unavailable or don’t approve. But the alternative is cloning groups which doesn’t look like a solution, the chat history isn’t cloned. Further, if some members prefer to stay with the old admins, other members need to follow both groups just because of this to be aware of the discussed topic.
So, the idea is that the discussed topic is more important than the question “who is admin” even if this may lead to some inconsistency. Having two groups is also a form of inconsistency. An exception (when cloning is better) is when a group is created to e.g. discuss the group admin’s repo (smth where the admin has real power), but even then the repo may be forked 
so this makes sense rather in corporate environments.
I feel like that’s a fair enough solution, personally. It seems cleaner than a vote system where admins can be voted out, which e.g. for project-specific groups run by people involved with the project may be mismatched.
If it doesn’t require too much development effort, perhaps the content of the group could optionally be cloned as well. Users could then delete the old group.
I don’t propose to add a vote system, so existing admins can’t be voted out, they always remain admins for those who don’t change admins manually. This should only be a recovery option not too visible in UIs in case if admins become unresposive or a real network split occurs. In the worst case this may lead in a group split if a subset of users chooses new admins, but cloning a group is also a group split. Moreover, existing members continue to see each others’ messages which is better than with cloning groups where users need to follow both groups to see all messages. A member list inconsistency can happen if a user doesn’t read the group for a long time and new admins have been chosen by active members, but finally the user will read that and can “approve” the admins change.
Also i don’t propose to remove cloning groups, so it still can be used, but i’d say that cloning groups is rather for the case when the discussion actually branches out. But we can make a user cloning the group its admin (maybe add such an option). As for cloning the group content/messages, this sounds like we should add refcounting to messages so that they can be in multiple chats, this is what actually happens with “classic MUA” threads, but i think this is another story.
I think that would be too much work. But why not just copy it? Sure, that would take up more memory. But the old group could be deleted afterwards. And the admins probably wouldn’t change that often anyway.
I had once written down a simple approach how to grant administrator rights to the group owner. Perhaps it is still usefull:
1 Like