Add creator/admin permissions for groups, with optional independent section separation

[AKM2498K146]

📢 Proposal: Add Creator & Admin Permissions — Stop Instant Wipeout, Save Everything You Built

✅ Expected Behavior

Clear role separation: Only Creator/Admins manage settings, members & rules; ordinary members can only chat & view — NO right to alter, remove, or destroy anything.

Independent section separation: 100% optional. Sort groups freely, no forced rules — fully user-controlled, pure organization freedom.

Flexible hierarchy: Creator holds full authority; admins handle daily work; supports "admin-only posting" — fits every use case perfectly.

⚠️ Actual Behavior

EVERY member has absolute, unrestricted power — NO exceptions. Anyone — even someone you just added or fully trust — can kick all members, erase all history, rewrite all data, or seize total control in seconds.

Worse: this can be fully automated. With basic skills, one can run a script that completely wipes out or destroys an entire group in LESS THAN 30 SECONDS — no warning, no chance to stop it, zero recovery possible.

This is NOT a bug — it is a catastrophic design flaw. Trust means nothing here; even the safest, closest group is one click or one script away from total extinction. NO defense, NO undo, NO safety net whatsoever. Groups today are not just fragile — they are practically self-destructive and unusable.

📌 Reasons

1. Risk is not just human — it is automated and instant.
Mistakes or bad intentions are bad enough; automated destruction makes it 100x worse. One small script = total loss in half a minute. NO permission limits = NO way to block or stop this ever. Safety is not about distrust — it is about surviving modern risks.

2. Only choice, NO compulsion.
Fully optional mode: keep full equality if you prefer; turn on protection if you need it. Hurts no one, blocks nothing — stops only total destruction.

3. Your value is irreplaceable — but currently disposable.
Groups carry years of trust, work, memories, and connections. Right now ONE person or ONE script can erase it ALL instantly. Permissions = the ONLY barrier between your work and total loss. Without this, groups are just temporary shells that vanish in seconds.

4. Decentralization ≠ no rules ≠ open door to total wipeout.
Decentralization = NO central control, NOT "leave the front door wide open for automated destruction". Rules run 100% LOCALLY on your device — servers stay simple, dumb, and unchanged. Perfect fit, zero burden. We add protection, NOT control.

5. This is NOT a feature — it is fixing a life-threatening flaw.
Some want freedom; everyone NEEDS safety from instant wipeout. Optional design = satisfies all users, saves the core function. Without this, group feature is effectively DEAD — too dangerous to use at all.

Final conclusion: This is NOT a small improvement — it changes groups from "easily destroyed in seconds" to "stable and safe". Stopping instant, automated wipeout is the ONLY way groups have any real value at all.

[ian]

This is a duplicate of:

Bug and suggestion regarding the group

This issue duplicates the following: TL;DR The scenario DC aims to solve at the moment is to only create small private groups with friends & family who you trust and where everyone can be held accountable for their actions in person. Anything else would require major architectural changes. Blocking is a completely local action for your own account, not targeting a given channel or group.

[Low]

@AKM2498K146

Even small, close-knit groups with people you trust can still have bad actors

Yes, and that’s quite unfortunate! But it’s literally how life works. If you set up strict permissions to protect yourself, you’re never really “trusting” anyone, which hinders your ability to truly make friends.

@AKM2498K146

Adding creator and admin permissions does NOT require major architectural changes; it is simply adding a small rule option: only the creator or designated admins can modify group settings, add or remove members.

Who will enforce those rules? The chatmail relay servers? Those servers are quite dumb and we like it that way.

[AKM2498K146]

First, in my proposal, this is fully optional, not mandatory at all. You can absolutely turn off the “admin permission” feature for people you fully trust. Second, some may see rules as a sign of distrust, but think the other way around: it actually stops many bad actors from doing harm, while letting trusted groups stay as they are. This logic doesn’t need to be enforced or processed by servers at all — it’s just a local rule set inside the app itself. Servers only keep relaying messages as usual, no extra work or complexity added. The simplicity you value stays completely untouched. We’re not changing how servers work at all, just adding a small optional switch in the client.

[Low]

@AKM2498K146

This logic doesn’t need to be enforced or processed by servers at all — it’s just a local rule set inside the app itself.

Can you explain this a bit more? I’ve worked in the decentralized space quite a bit and AFAIK the only way to achieve what you want is smart servers enforcing the rules.

[AKM2498K146]

all permission checks and rule judgments happen inside the client app, not on the server. When someone tries to change group settings or manage members, their own app first checks if they have the right to do so — if not, the action gets blocked right there, and no request is even sent to the server. Servers only pass messages and data exactly as they are, without understanding or filtering anything. This way, servers stay simple and unchanged, while we get the control we need purely through client-side logic. It works just like how your app decides which messages to show you or how to format text — all done locally, no server involvement needed.

And

Delta Chat already supports a recall feature for your own messages — you can delete them for everyone in the chat. However, when it comes to content posted by others, you have no permission to delete it at all. This alone perfectly proves that such permission-based logic is entirely feasible and works just fine.

[ian]

I have listed almost a dozen topics where many people have requested the same thing that you have, sometimes with similar wording, at other times, using a different solution. It is best to not fragment or repeat discussions and instead comment on existing issues in such cases.

I have not done this because I disagree with you or that we don’t understand what you want from the first few repetitions - they were loud and clear.

[AKM2498K146]

As far as I know, among the “related topics” you listed, there is one from 2019 — more than 6 years ago.

People have been asking for this year after year, and nothing changed. Telling us “don’t repeat” doesn’t solve the problem; it just buries it. If old requests got done, nobody would post new ones.

[Low]

@AKM2498K146

When someone tries to change group settings or manage members, their own app first checks if they have the right to do so — if not, the action gets blocked right there, and no request is even sent to the server.

Yes, so it’s not a real permission system. It’s a system based on trust that the user doesn’t run a non-standard client. They can easily get around these “permissions” by using an API or different client.

What you want is just some UI that pretends to be permissions.

In which case, what’s the point? If you’re trusting this person enough in that regard, why do you even need the theater?

[AKM2498K146]

First: This is an OPTIONAL, SEPARATE mode. Old groups work exactly as before — no changes, no force.

Let me explain clearly:

1. Owner = Single Source of Truth

The creator holds the ONE official master copy of all data: members, roles, settings, rules.

Rule: Only commands that MATCH the Owner’s data are valid.

Simple: Owner has the “original”; everything else is a copy — different = wrong/fake.

2. Admins = Only Copies

​

- Appointed ONLY by Owner.

​

- They have exact copies only, no independent rules or power.

Rule: Claimed Admin but not in Owner’s list? → FAKE, ignored instantly.

3. How verification works

Everyone stores a full copy + checksum.

​

- Owner changes → all check together → OK → sync.

​

- Any other change → compare to Owner + most members → mismatch = REJECTED automatically.

4. “Modded clients bypass it?” — NO

You can hack your own app → only YOU see it work.

Everyone else: “Doesn’t match Owner → IGNORE.”

Result: You only fooled yourself. Zero real effect.

5. “It’s just theater?” — WRONG

​

- Centralized: Server controls everything.

​

- OURS: Owner defines + Everyone verifies = real order, no central server needed.

Summary:

Optional → Owner = master → Admins = mirrors → All verify → Wrong = rejected → Modded = useless.

This is real decentralized security, not fake.

[Low]

I changed my mind. I’m against AI slop now lol.

I understand the idea though. It is a client-enforced social contract, like I said.

“Privileged groups” would use keys that already exist, just with clients applying stricter rules about whose signature makes a group state change valid.

This should really be the final word on this topic for now

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

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

[AKM2498K146]

我说白了，我不用AI翻译你看啥(这里的你看啥指的是一个设问反问连用句)，看方块字发懵吗？再说了在你眼里AI翻译就只有人工智能垃圾吗？那你接触的人工智能创作圈子很好了(这句话的语气是阴阳怪气，防止你的AI看不懂)

我就想问你了(设问句)哪句话不是有用的？除了你发的。

对，说到你我还要再说，请问了你告诉我什么叫去中心化专家不知道这个功能可以在去中心化中实现

而且目前我能追溯到的关于类似的消息已经是公元2019年2月了，距今公年2026年5月(五月末即将来到六月初)已经足足隔了7年4个月

而上文引用的内容也已经是整整一年的内容了

(2025年五月-2026年5月)

而且说咱俩发的这个内容，你发的和我发的有什么本质性的区别吗？

[r10s]

closing as duplicate of Admin/mod roles, and prevent people from removing others from group - it does not matter, how old a feature proposal is, they’re still duplicates. note that there are more than 1000 feature proposals here, nearly one new per day. so, there is lots of triage, considerations not that easy to grep. everyone has its own priorities, and of course wants to get the handled as such. anyway, posting duplicates does not make things faster - it just keeps the team unnecessarily busy with moderation