Super Steward role for de-MLS and modular de-MLS

This post is for discussion on super steward role for de-MLS.

Firstly, recap that; de-MLS provides two layers of decentralization:

  1. Architectural: every user is a node in a P2P network, no central server.
  2. Governmental: no single trusted actor exists. Group changes go through voting, and stewards are transparent.

So, we cannot compromise on architecture decentralization but for governmental administration, conventional group chat apps have an admin role who governs the group without voting overhead. In de-MLS, we have already single steward mode but it still follows voting outcomes. Super steward fills the remaining gap: a fully trusted admin over P2P transport, no central server and no governance overhead. Shortly, nothing interesting in here this would be just MLS over P2P.

Still, I want to bring up a discussion here about what the super steward role could look like. So, I reduced three initial questions that may shape this role.

Why do we need it?
As we discussed earlier, achieving conventional app compatibility by replacing voting with a trusted admin-style governance.

What is the member’s role in super steward groups?
Members do not vote. Instead, they only run a lightweight commit validation (e.g., broken commit checks) since only the super steward has the right to add or remove users.

Super steward life-time and evolution?
Groups must be initiated as either super steward or decentralized governance (current de-MLS) and never switch between modes. Ownership can be transferred to another member upon request or automatically via the anti-deadlock inactivity timer. Multi super steward support may be defined later.

After these, we can have more questions, such as should we have peer scoring, or sort of voting such as an emergency criteria proposal in super steward groups etc. At first glance, it looks like we don’t need peer scoring since the super steward (ss) is trusted so there is no enforcement over them but what if we can have more super steward (ss).

Eventually, these bring us (thanks for @seemenkina here) to some term of modular de-MLS which each feature can be chosen separately over the group e.g. type of steward, peer scoring and voting. We can have 2 questions here:

  • First one, we can have so many combinations of features in modular de-MLS that we cannot define each of them well. We can mitigate this by allowing only a few at first, then expanding them.
  • The second one: Is there a demand for modular de-MLS according to its effort? So this may not make sense, such as this effort. If not, we can continue with a trivial super steward, which is relatively simple to deliver by just removing some feature of the transparent steward.

Happy to discuss super steward role and further.