DRAFT

The vision for hybrid groups is to allow groups to determine their own infrastructure - whether that is an always-on bot, an untrusted server, or a fully p2p shared experience.

As a bridge between pervasive hybrid groups and the current legacy groups setup we propose a roadmap towards "Managed Groups".

Goal 1: Prototype Bot Group Management

High level: A Bot that is responsible for maintainence of a group. This includes managing a member list (adding, removing members) and pushing out new keys to members when those members change (or at predetermined points). This has the follow benefits over existing legacy groups:

forward secrecy
member management

This does introduce a trust concentration in the bot operator as they do have the power to send different keys to different members, and thus could artificially split the group. This can be counteracted using the existing protections in legacy groups where messages reference the group id which is bound to the current group key and hosting server.

In its most basic form this could just be a bot that sent a new group invite to a set of members periodically. However as a first cut I propose the followng work that can mostly take place outside of Cwtch and only requires a few small integrations to be usable as an initial experiment, namely:

a new overlay message group update to allow clients to automatically process messages from a bot (gated by an experiment)
a way to hide bots from the contact list
additional data recorded in the group invite and in the group database entry that associates a bot with the permissions to update certain attributes (like the key)

Questions intended to be answered by this phase:

What strategies should we preset to group managers for maintaining group security (e.g. reset period limits)
How should we deal with members that are mostly offline and who may not have received the most recent keys (e.g. allow them to fetch past keys from the bot? Only allow them to fetch the most recent key?)
How can we best integrate the flow between key management and offline storage (e.g. if a key rotation happens prior to a profile fetching the most recent messages from a server how can we structure the flow in cwtch to ensure they don't have to refetch every message again once they learn of a new key).

Goal 2: Integrated Group Management

Once Goal 1 has been tested we should have a fairly good idea of the UX necessary to bring an integrated experience to group management. This would involve bringing the bot inside of Cwtch and allowing access to its management functions from within the UI. This UI likely needs:

new group creation screen that explains and allows addition of a "manager"
new group management screen to allow viewing, adding and removing memebers
new group management screen to allocate fine-grained permissions to members (read / write)
(optional) APIs for moving the group to a different server

This work takes place mostly inside of Cwtch UI building out interfaces for interacting the the flows realized by Goal 1, and integrating the bot code (or reimplementing it in Cwtch itself).

Goal 3: Bot Hosted Groups

In between or alongside Goal 1 and Goal 2 we also have the option of allowing the entity doing group management to also host the group. This would effectively be a merger of the server code and the group management code - extending the trust of the bot over an entire server.

This server could be permissioned to allow the bot to only store messages from given members (or only show messages to certain members) - allowing for some groups to opt for greater efficiency.

This also necessitates building APIs to realize the ultimate goal of hybrid groups - peer-hosted groups e.g.:

FetchNewMessagesForGroup
RelayMessageToGroup

In designing those APIs we should ensure that they are also suitable for direct p2p interaction with group members, allowing for the next step.

Goal 4: Shared Peer Hosting

Once the APIs from Goal 3 is in place, there is little reason why the bot should shoulder the complete burden for hosting a group. Peers themselves can take part in relaying messages when they are online.

At some point the line between bot and peer merges and we are left with a large part of hybrid groups.