Admin/mod roles, and prevent people from removing others from group

Expected behavior

When creating a group chat, the person who created the chat should be assigned the role of owner and admin. They should then also be able to assign mod role to other members. Any member should NOT be able to kick another member without admin/mod roles.

Actual behavior

No hierarchy exists. Anyone in the group can kick anyone else. This is bad if the group wants to be public and have non-friendly users join.

Please add owner/admin/mod roles to secure groups that want to be public from being abused.

this is known, and at some point we will probably iterate over that, so that huge, untrusted group get better support. there are lots of ideas and internal discussions about that.

however, already today, twhen using Delta Chat as it is supposed to, in small, known circles you trust (family, friends…), in practise, this is far less of an issue than one may expect

Yes it is great in small group chat with trusted friends. Let me know where I can provide potential ideas for admin/mod capabilities. Have you tried Keet messenger? It’s P2P but has good admin/mod support in groups.

lots of ideas usually pile up in the real-life meetings with devs and users, eg. soon on DIFF in Freiburg/Germany (invitation), but surely also here in the forum.

in general, there is no lack of ideas.

it is more that resources are missing :wink:

It’s going to be a very cool conference, so many new things are planned, great. I admire Delta Chat, the best secure messenger in the world, and I’m not kidding.

Related:

I fully understand your point — the current mechanism may work well in small, trusted circles, but there are two critical flaws in this view, and it does not align with how users actually choose to use Delta Chat:

1. The idea that “problems won’t happen among people you know” is not true
Even with friends, family, or acquaintances, conflicts, misunderstandings, or bad actors can still exist. A far more common issue arises when the circle expands: Person A invites B, B invites C, C invites D… Eventually, D has no meaningful connection to the original creator, or is merely a “friend of a friend of a friend” who may dislike something and decide to destroy the group or wipe all data in a single click. The creator has no way to stop or reverse such actions.

In such cases, the group is gone forever — the consequence is just as serious as, or even worse than, having a group shut down or deleted maliciously on centralized platforms. At least on centralized platforms, there are established rules and you have a channel to appeal; moreover, even if you file a report, it may still be rejected for various reasons. Here, however, once something goes wrong, it is completely irreversible, and you cannot even trace who was responsible.

2. The “use case” you mentioned is exactly where users almost never choose Delta Chat
In reality, families, friends, and stable, trusted groups mostly prefer more mature tools like WhatsApp, Signal, or Telegram — which have well‑developed management features. The reason is simple: these platforms have admins, formal rules, and control mechanisms to maintain order, and people are already accustomed to this kind of “regulated safety.”

On the contrary, users who do choose Delta Chat are usually those building public groups, interest communities, cross‑platform teams, or collaborating with strangers. They value decentralization and freedom from platform control. These are precisely the scenarios you referred to: large‑scale groups, relationships without pre‑established trust, and settings that require stronger functional support — and currently, these are exactly where the most severe problems occur.

This creates a contradiction: you claim “the current system works well for trusted circles,” yet those groups rarely use Delta Chat at all. People turn to Delta Chat exactly for the scenarios where the current mechanism fails.

:white_check_mark: Detailed Solution: Dual‑Mode System + Signature Verification

This approach preserves all existing logic, requires no changes to the underlying protocol, and never compromises decentralization. It simply adds an optional set of rules that can be implemented immediately:

Step 1: Separate two independent group modes

1. Basic Group (Current mode — default, unchanged)

  • Functions exactly as it does today: anyone can join, modify group information, remove members, or wipe data;
  • No data verification, no permission controls; fully compatible with all older versions and all third‑party clients;
  • Intended use: small circles prioritizing absolute freedom and equality, identical to how you use it now.
    2. Managed Group (New optional mode)
  • Core rule: Only operations signed with the Creator’s Key or an Authorized Admin Key will be accepted and applied by all clients;
  • Upon creation, the group automatically binds the creator’s public key as the Root Key, which is written into the group configuration. The Root Key can only be modified by the creator using their private key;
  • The creator may issue Admin Credentials signed with their private key. Anyone holding such a credential obtains management rights;
  • Intended use: public groups, large communities, cross‑platform teams — environments that require order, protection against abuse, and manageability. Completely independent from Basic Groups — no interference between the two.

:white_check_mark: Key point
The only difference between the two modes lies in how clients interpret data. Under the hood, all content remains standard email messages — no server control is involved. It stays 100% decentralized.

Step 2: Signature verification logic (implemented client‑side, easy to adopt)

1. Data format: Every change (renaming, updating avatar, removing members, wiping history) includes the operator’s digital signature plus a flag: verification required / no verification required.
2. Verification rules:

  • Basic Group: All signatures are ignored; every change takes effect immediately — exactly as it works today.
  • Managed Group: Upon receiving a change, the client automatically verifies: Is this signed by the creator or an authorized admin? Has it been tampered with? Is it expired?
  • :cross_mark: Invalid operations: Rejected, hidden, not executed, and not synced to other devices. To everyone else in the group, they effectively never happened.
    3. Third‑party client compatibility:
  • Option 1 — No support: You can still create or join Basic Groups. When entering a Managed Group, you will see a notice: “This group mode is not supported by your client.” You can read messages, but cannot make modifications.
  • Option 2 — Full support: Simply add the standard verification logic — the rules are fully open and documented. Once implemented, your client offers exactly the same functionality as the official one.
  • :cross_mark: Want to cause disruption? — Modify data, kick everyone out, or wipe history? Without a valid signature, every client in the group will automatically disregard your actions. You literally cannot affect the group in any way.

Step 3: Permissions & security boundaries

1. Creator rights: Issue or revoke admin status, dissolve the group, transfer the Root Key. All actions require signing with the private key — impossible to forge.
2. Admin rights: Remove members, moderate content, edit group information. Cannot transfer the Root Key; rights may be revoked instantly by the creator.
3. Recovery & backup: Keys are stored exclusively by the user and can be exported or backed up. Authority derives from your own key, not from any platform — fully aligned with Delta Chat’s core philosophy.
4. No enforcement — purely consensual: Managed Groups are not about “official control.” They represent a social contract agreed upon by everyone in the group. Disagree with the rules? Do not join, create a Basic Group instead, or keep using an older client. No one forces you to comply — but equally, no one is obligated to accept your actions.

:bullseye: Final outcome

  • For existing users: Zero impact. Basic Groups operate exactly as before — total freedom remains intact.
  • For those needing governance: Instant security. Create a Managed Group with one click. No more erased groups, arbitrary removals, or third‑party abuse.
  • For third‑party developers: Full freedom. Implement the rules to unlock complete functionality; skip them, and you still work perfectly with Basic Groups. This is not a “restriction” — it is simply the choice to follow community‑agreed standards.
  • For decentralization: Strengthened, never weakened. Rules are defined, chosen, and enforced by users, not by servers or central authorities. That is true decentralization.

To put it simply: “We do not block you from modifying data — but in this group, we have agreed to trust only signed changes. Want unlimited freedom? Use Basic Groups — no one is stopping you.”

Every problem described here can be resolved immediately. There is no need to wait for “future iterations.”