This design specification is dependent on the BACAP and Pigeonhole protocol designs from our paper Echomix: A Strong Anonymity System with Messaging, which describes

The source code and API docs for BACAP are available on pkg.go.dev.

The Pigeonhole protocol establishes anonymous cryptographic communication channels which have a readcap (read capability) and a writecap (write capability). For example, if Alice and Bob want to communicate, they can each create their own Pigeonhole/BACAP channels and exchange readcaps on those channels. Now when Bob writes to his channel, Alice can read those messages because she has Bob’s readcap. Likewise, when Alice writes to her channel, Bob can read those messages because he has Alice’s readcap. This is the most basic construction using BACAP and Pigeonhole.

Here we extend this basic design to work as a minimal group-chat protocol, without key rotation.

BACAP primitives give us two message types:

The group state consists of:

The group chat is completely decentralized. Each member must keep track of every other member.

All messages are SingleMessage if they fit in one BACAP slot, or an AllOrNothingMessage if they are too big.

// TextPayload encapsulates a normal text message.
type TextPayload struct {
    // Payload contains a normal UTF-8 text message to be displayed inline.
    Payload []byte
}

// Introduction introduces a new member to the group.
type Introduction struct {
    // DisplayName is the party's name to be displayed in chat clients.
    DisplayName string
    
    // UniversalReadCap is the BACAP UniversalReadCap
    // which lets you read all messages posted by this user.
    UniversalReadCap *bacap.UniversalReadCap
}

A FileUpload can be used for various purposes such as uploading an image to be displayed inline by the chat client. Likewise, a sound bite could be made visible in the chat along with a play-button. Beyond that, we can support arbitrary file attachments.

// FileUpload encapsulates several file types
// which result in different client behaviors.
type FileUpload struct {
    // Payload contains the file payload.
    Payload []byte
    
    // FileType is the identifier for each file type.
    // Valid file types are:
    // "image"
    // "sound"
    // "arbitrary"
    FileType string
}

The Who message type is used to query who is currently in the group.

// Who is used to query the group chat to find out the member read capabilities.
type Who struct {}

The ReplyWho message answers the Who query with an AllOrNothingMessage BACAP stream containing readcaps for all group chat members.

type ReplyWho struct {
    Payload *bacap.BacapStream
}

The GroupChatMessage message encapsulates all of the above-mentioned message types and is serialized with CBOR.

// GroupChatMessage encapsulates all chat message types.
type GroupChatMessage struct {
    // Version is used to ensure we can change this message type in the future.
    Version int

    // MembershipHash is the hash of the user's PleaseAdd message.
    MembershipHash *[32]byte
    
    TextPayload *TextPayload
    Introduction *Introduction
    FileUpload *FileUpload
    Who *Who
    ReplyWho *ReplyWho
}

The protocol flow for making a new group from scratch (using whatever authentication protocol) is essentially for everybody to exchange PleaseAdd messages.

// PleaseAdd is a message used by a client to try and gain access to a chat group.
type PleaseAdd struct {
    // DisplayName is the party's name to be displayed in chat clients.
    DisplayName string
    
    // UniversalReadCap is the BACAP UniversalReadCap
    // which lets you read all messages posted by this user.
    UniversalReadCap *bacap.UniversalReadCap
}

type SignedPleaseAdd struct {
    // PleaseAdd contains the CBOR serialized PleaseAdd struct.
    PleaseAdd []byte
    
    // Signature contains the cryptographic signature over the PleaseAdd field.
    Signature []byte
}

For introduction to an existing group over an existing channel between an introducer member and new member, an Invitation message is used.

type Invitation struct {
    GroupName string
}

The Invitation protocol flow works as follows.

GOOD QUESTION: If we are adding a lot of people at once,do we really need to upload all of the members n times?

FUTURE WORK: Forward secrecy. We can add two extensions that allow transmitting public keys + stuff encrypted under those public keys. We can also refer to the Reunion protocol which is a n-way PAKE with strong anonymity properties. Reunion is described in Communication in a world of pervasive surveillance: Sources and methods: Counter-strategies against pervasive surveillance architecture. Currently, Python and Go implementations of Reunion are available.