owned this note
owned this note
Published
Linked with GitHub
# ThreadParticipant Protocol
This protocol coordinates the management of the participants within a single message.
DIDComm itself only transfers messages from one party to one other party. Disclosure of other participants is voluntary and not cryptograhically verifiable. This protocol is another voluntary participation protocol among it's participants.
This protocol works well alongside the ThreadSync Protocol, allowing for missed message discovery and sync: https://hackmd.io/dxoXK4I-TGehMuFRoz1O8g
The following protocol messages allow participants to communicate about adding and removing participants on the thread. Participation is completely voluntary with all interactions.
Each add or remove message uses a new thread, with a parent thread of the thread under subject for modifying participants.
For the listed message examples, the id of the main thread is represented by `[mainthread]`
##### Add Participant
- did: 'did'
- share-history: boolean
- reason (optional): '' //optional
A `share_history` of true indicates that previous messages are expected to be sent to the newly added participant. A value of false indicates that old messages should not be shared. The method of prior message sharing is out of scope for this protocol.
the `reason` is an optional human readable explanation of why the participant is being added.
```json
{
"@type": "https://didcomm.org/thread-participant/1.0/add",
"@id": "1",
"pthid": "[mainthread]",
"did": "",
"share-history": "false",
"reason": "Might be able to help us resolve issues."
}
```
##### Remove Participant
- did: 'did'
- reason (optional): '' //optional
Signals the suggestion of a removal.
```json
{
"@type": "https://didcomm.org/thread-participant/1.0/remove",
"@id": "1",
"pthid": "[mainthread]",
"did": "",
"reason": "Might be able to help us resolve issues."
}
```
##### ParticipantList
- participants: [`<did>`]
Publishes who the sender believes is a participant within the thread. Upon receiving this message, the recipient should compare it to their own list of participants within the thread.
```json
{
"@type": "https://didcomm.org/thread-participant/1.0/list",
"@id": "1",
"pthid": "[mainthread]",
"participants": ["did:example:alice", "did:example:bob"]
}
```
## Open Questions
- do we need a way to ask for a participant list?
- Should we support adding and removing multiples at a time?
## Future Ideas
- more nuance in what to share when adding a participant
- options for consensus about what is shared.
### Typical flow
Alice and Bob are exchanging messages. Alice suggests adding Carol, and Bob signals his agreement by returning a ParticipantList which includes both Alice and Carol.
Bob sends a message to both, and then Carols sends a message to both.`[Message]` has been used to indicate a message of any type.
```sequence
Participant Alice
Participant Bob
Participant Carol
Bob -> Alice: [Message]
Alice -> Bob: [Message]
Alice -> Bob: thread-participant/1.0/add (Carol)
Bob -> Alice: thread-participant/1.0/list (Alice,Bob,Carol)
Bob -> Carol: [Message]
Bob -> Alice: [Message]
Alice -> Carol: [Message]
Alice -> Bob: [Message]
```