# Group chat using mutable resources

## Private group chat channel

* Metadata about channel containing:
* participant list containing:
* each participant's public profile
* ensured mutable resource for each participant's messages in the stream, containing:
* symmetric public key for that participant's messages
* series of messages they've sent to the channel
* participant list can be updated by all participants, because everyone invited receives the channel key
* Send a new PSS packet with the full payload for each new message

## Steps for identifying shared mutable resources
* Create a shared mutable resource for a channel, probably on an ENS subdomain
* Creator would also create ENS subdomains on that subdomain for each participant
* Create custom resolver contract that allows any of the participants to edit the conversation metadata, including creating new ENS subdomains so that they can create new participants

## Reqd changes to MUT
- Make root chunk content addressed and store this in ENS
- Stops malicious root chunk replacement if it disappears from swarm
- Store write/signing key in root chunk so ENS is not even required

## Issues
### Profiles
* Finger protocol for swarm public profiles?
* https://www.diid.io/
### Forward secrecy
* storing key renewals in the stream destroys forward secrecy
* maybe you would have to ask other participants for key rotations if you need to recreate old history

## Viktor's suggested implementation

* Each participant has a mutable resource used as an append log
* Each participant maintains an access control list (an upcoming built-in feature of Swarm) (optional)
* You know the participants
* Each participant knows how many contributors there are
* Each client indexes all streams into a single view based on message timestamp

## Minimum viable application
* The creator of the chat room is the exclusive maintainer of the participant list
* Only the maintainer can add participants
* Each participant maintains an append-only stream in the form of a mutable resource
* Each client interleaves these streams and stores the hashes of each message in a chunk stream
* Each client checks them periodically for updates
* The streams are public-readable

### Potential enhancements
* Encryption
* The maintainer shares a key with all participants to encrypt the streams
* Participant management
* Other participants can send an ADD_PARTICIPANT message to the maintainer. If he/she is online, then the person is added automatically by the client.
* Indexing
* An indexer could be notified of the changes in these mutable resources and compile an interleaved index of all messages
* There could be several indexers for a popular forum
* You could even enforce indexer behavior with a staking mechanism

## Action items
* Add public key to metadata chunk (nolash)
* Background task to periodically check for stream updates (carl/shane)
* Add append method to DPA - distributed pre-image archive (carl/shane) https://github.com/ethersphere/go-ethereum/blob/swarm-network-rewrite/swarm/storage/pyramid.go#L106
* Abstraction for easy addition to and getting state of append log ()
* After each append op, call the MRU updater (Doug & nolash did a very rough version of this during a hack session.)

## Pseudo-code

Log keeps in a mutable resource the hash of the pyramid chunker. When you do this, you get back a chunk, which is the root of the top. So we want the head of the stream, and we also want.

class AppendLog
  def create() # create the MR and whatever else is needed
  def append(data) # adds chunk to MR
  def mru_root()
  def next_object(current_index)
end