I am assuming we want to build group chats, but if that is still a pending question please discuss.
To start with we should decide which features we want to include in a potential MVP.
Some I take we are quite certain of:
Users should be able to communicate in groups > 2.
A user should be able to initiate a group chat.
Other might be open questions:
Do we want to have an “admin” of the chat responsible for certain tasks, such as adding/removing members / content moderation etc, or we want to have everyone on the same level of privileges.
What kind of privacy guarantees we want to make for group chats (that’s also been discussed elsewhere)
And probably more.
Once there’s some agreement on the problem we are trying to solve, we can move the discussion about potential technical solutions.
This is a very interesting topic.
First of all we must distinct this type of group chat to “private”, because users need to be invited to participate on the group.
P2P one to many message encryption
This type of group is special because the messages are encrypted from one to many.
I see the best way to have this is an shared key, when someone is added or removed from a group this key should change to a new unique one. There exists other options and we can explore them if this simple technique does not attend requirements. What are other options we have?
Governance models
The difference from a public chat governance is that the participants are limited and the messages private to participants - so we cannot use the governance model of public chats - because they use Topic Democracy, which is meant to control Status Software code and contracts.
We can build a specific Topic Democracy for controlling each group, that would come with also with a Subscription Fee Token contract, which would able to mint a token to users that were invited (or invited themselfs depending in the group configs) and accepted the invitation by paying the fee (that can be 0) at every again n days (can be zero, if only need to pay once).
Subscription Fee is Individuality as Influence
groups can be started with predefined multiple addresses and initial quorums % and subscription fee per time
a default quorum is set for root setup, and specific actions can be configured to have smaller quorum - for example add an user can be easier than remove.
if initial quorum for adding an user is 0, the user willing to participate can subscribe itself automatically
each address is considered individual and have 1 point of influence in vote, as long as they paid the subscription fee.
users that didn’t paid the fee can be kicked out automatically after a period of time.
to add or remove an participant we need a voting (commands and cool UI)
fee destination is controlled by voting quorum, by default a contract can be set to automatically release funds to determined addresses each month, or a custom contract, or keep them locked (no funds release contract defined)
should be possible to set delegation of influence to other user in the group.
who delegated can vote for itself or the delegate can use this influence
delegation can be circular, this means that Alice can delegate to Bob and Bob to Alice, if Alice voted and Bob didn’t, Alice can use 2 points (from itself and from Bob) and vice-versa. If both voted, than each one uses its own influence for the vote them decided.
Its important that or a good quorum is needed to add a new user, or a good fee is required - otherwise could lead takeover of the group, to avoid this mistake we can enforce some rules in contract config setter. Otherwise the group becomes like a public group, but with a really bad governance security.
Custom governance system
Custom governance models could also be supported, only needing the DAO to control a contract with a specific ABI for managing the users in group.