ActorsActor groups

Actor groups

A participant in Condensation — a user, service, or other entity — is an actor group encompassing one or more devices:

User A Smartphone Actor 929c... Laptop Actor 7e9e... Backup Actor 35bc... Actor group Service Z Server 1 Actor adc4... Server 2 Actor e211... Actor group Backup Actor 1657...

An actor group behaves like a single, consistent entity. Actors within the same group unconditionally trust each other, share (synchronize) their private data, and read each other's messages. Each actor thereby uses its own key pair.

A group may evolve over time. New actors may be added, obsolete members removed, and stolen keys revoked.

All actors in the group are equal. There is no group leader or main actor — unless the application designates such roles.

Group members may use different stores.

Group announcement

Every actor publishes a list of group members on its public card. Conceptually, these cards form a directed graph of actors and their relationships:

A B C D "is with me" Group member Other actor

If two actors mutually claim to belong together, they are in the same group. In the above example, A, B, and C form a group.

A group's active members should be fully connected. However, when joining an actor, some links may be missing temporarily. A, for example, may just have joined the group through B, and C does not yet know about it.

Unidirectional links may also exist while a new actor (D) is joining the group.

Member status

Group members have one of the following status:

Note that the distinction between active and idle is based on the member's intent, and not on its actual behavior. An active member may be sleeping for days (or even disappear), and an idle member may suddenly become active again.

Every actor publishes the status of each group member on its public card. This information may not be consistent, and is therefore most-recent merged on a revision timestamp:

Public card of A A active 2018-01-18 B active 2018-01-21 C active 2018-01-19 Public card of B A active 2018-01-18 B active 2018-01-21 C idle 2018-01-20 Public card of C B active 2018-01-20 C active 2018-01-19 A B C active 2018-01-18 active 2018-01-20 active 2018-01-21 active 2018-01-19 idle 2018-01-20 active member idle member

In the above example, B set the status of C to idle, and thereby overwrote C's own status declaration.

Note that public cards of idle and revoked members may not be read during group discovery. As a consequence, an active member may switch itself to idle, but an idle member cannot reactivate itself.

Group discovery

Given an actor, its group can be discovered by reading its public card, and that of all associated group members. Often, only the subgroup of active members is of interest.

Starting with A, the above group is discovered as follows:

Reading the public card of A.B and C are potential members. Reading the public card of B.B is a member.C is a potential idle member. A B C A B C

The resulting active subgroup is [A, B]. Since C is marked idle by B, its public card is ignored.

The origin actor is always considered active to start with, but may may switch to idle (or revoked) throughout the discovery process. This occurs, for instance, when starting the discovery process with C:

B C A B C A B C Reading the public card of C.B is a potential member. Reading the public card of B.A is a potential member.B is a member.C is idle. Reading the public card of A.A is a member.

Adding a new member

To attach a new actor D to the group, D sends a join request message to the group, and announces its (one-sided) membership on the public card:

B D join request message is with me 1. B D is with me 2.

An active member of the group (B) validates the request. If approved, it announces D on its public card, and discloses the current private data to the new member.

The content of a join request is specific to the application and its validation procedure. New actors may be validated through a shared group secret, a temporary pin code, or through any other appropriate means.

Removing a member

A member is removed by changing its status to idle (or revoked). This may be done by any active member of the group, including the member to be removed itself.

Sending messages

To send a message to a group, an actor discovers the group, encrypts the message for all active group members, and places the envelope into the message box of an active member. Usually, the most recent active member is chosen.

Messages specific to an actor can still be sent to the specific actor rather than to its group.