# Consento Permissions System

## Main Goal:

- Consistent Hypercore Feed
- Mutable set of writers
- Resist compromised devices forking history

## Core Structures / Datatypes / Transports / Terms

- Sign Vectors
- Stream of encrypted content that's verifiable (without decryption)
- Members generate a new keypair for each block
- Throws out old key so that being compromised can avoid forking
- Channels
- A single receivier can get encrypted messages from any number of writers
- Group Hypercore
- Multiple writers can add to this using shamir's secret sharing
- Private Key gets split across members of group
- each written block has additional verification via signatures from other writers
- Shamir's Secret Sharing
- When a new member gets added or removed, the private key is split into shards and shared among all the peers
- This makes it harder to compromise the group if you compromise a single device
- Member Hypercore
- Used to store requests?
- no shards!
- Receipt when the member receives a request?
- Extension Messages?
- Maybe authentication for member hypercore sync
- When a memeber replicates member feeds with another member, they will use extensions to

## Verifying the Group Hypercore

- Before we can validate the group list, we need to iterate through the blocks from the start
- Each block will have an add or remove operation
- Each operation will be signed by a quorum of the members
- Each block should contain the public keys writers will use for the next block's signatures
- Keep a set of known group members while iterating
- Each `member` is identified by <SignVector + Channel Writer + HyperCoreKey>
- On each operation add or remove from the set
- Once you've caught up you can disregard everything but the latest block, but keep the data for replication

## Adding a new member

1. New member wants to be added to a known group (member knows group off-band)
1. New member generates a Channel, a SignVector, and a member hypercore to identify themselves
2. New member sends information off-band to known Requestee (aka. QR Code on device of linking)
- Requestee puts a request in their member hypercore
- Request contains new member info, the block number, and a UUID for the request
- Other members are periodically syncing all other member feeds
- When members sync member feeds they will also gossip shard info for requests via hypercore extensions messages in the group hypercore
- When a member sees another has done a new request
a. their app will prompt the user to accept or deny it.
b. their app will automatically accept it.
- If enough members deny such that there cannot be a quorum, the request is considered "denied"
- If the Requestee decides to cancel the request it is considered "aborted"
- If a member accepts a request
- they will encrypt their fragment of the shamir's secret such that it can only be read by the members and add it to the gossip info
- Sign it with their sign vector and gossip it to other members
- add a response to their member hypercore with their signature for the request
- Members will track response counts and if they detect that the response has quorum, they will perform the addition
- They will combine all the signatures of the members responses, re-generate the secret key for the group feed using the shards they got from gossip, and put together a new block / append it to the feed.
- They will also generate a new shard for the new member and send an encrypted message to them
- The new member will see that a new block has been created with them being added as a writer.
- They will then decrypt their shamir secret shard and persist it locally for future use
- We should consider whether the shamir secret needs to be re-generated here

## Removing a member

- Similar to process when adding a member
- The removed member may not accept or deny the request
- Once enough peers have accepted the request a new block will be added which omits this group member from the list
- We should consider whether the shamir secret needs to be re-generated and distributed here

## Concurrent requests

- When a member detects that there are concurrent requests happening they will combine the two into a new - request and sign it
- This merge should yield the same result on every member even if they generate it in dependently.
- Instead of waiting for quorum on the original requests, memebers will now wait for quorum on the merged request

## Q's

- Is it safe to be putting shamir's secrets into the member feeds?
- How should we re-generate the shamir's secrets when a peer is added / removed?

### Breaking quorum

A creates 3a
B signs 3a via A
C signs 3a via A
Now 3a only needs one sig

E creates 3e
B denies 3e via E
C

Now it is signed...
D signs 3a via A - quorum reached

A create 3a
B sign 3a
C sign 3a
D sign 3f
E sign 3f
F create 3f

E connect B - knows about deadlock - signs 3af
D connect C - knows about deadlock - signs 3af

A sign 3a
B sign 3a + 3af
C sign 3a + 3af
D sign 3f + 3af
E sign 3f + 3af
F sign 3f

state = {
    lastSigned: null,
    lastRequest: null
}
function mergeRequests (requestA, requestB) {
    if (isInConflict(requestA, requestB)) {
        return { cancel: [requestA, requestB] }
    }
    return { merge: [requestA, requestB].sort(sortUnambiguosly) }
}
function sign (request) {
    if (state.lastSigned === null) {
       state.lastSigned = doSign(request)
       state.lastRequest = request
    } else {
       merged = mergeRequests(request, state.lastRequest)
       state.lastSigned = doSign(merged)
       state.lastRequest = merged
    }
    if (hasQuorum(state)) {
       write()
    }
}

### Does n/2 + 1 work?

A - Req
B - sign Req via A

--

D - get Req via B => Disconnect from B and sign
C - get Req via B => Disconnect from B and sign

Both sides will thing they made quorum