Notes from Matt Hour episode 1
=======

## Multi-device feed: Identity as a tangle

> (cft: I suggest to call this a "feed group" - and to avoid references to tangles (=implementation detail) or identity (=which would wrongfully hint at "feed groups" being a 1:1 replacement for single-identity logs)) or devices (any set of log owners may wish to form a "feed group" as a distribution list for encrypted content, for example)

`-==-==-==-===-==-=-=-=-==-===-==-=-=-===--=-==--==-==-===--=-==--==-==-==--=`

### Device Key (per app)

The secret file, public and private key
- per-device and per-app

### Identity

The message ID of a root post with type "identity"

### Messaging Key

A key pair, public key posted to identity thread, private key shared between all devices (encrypted with all device keys)

----

current feeds have message order, as each message directly links to the previous message, thanks to strong consistency.

we could combine multiple feeds and maintain message order, if we combine all messages from the various feeds into a tangle, as tangles maintain causallity even with eventual consistent.

we introduce an identity tangle:

- identity_root
- identity_branch

The Tangles (causalities)
- identity
- thread
- revisions

---

## Tangle permissions spec:

we need a generalized way to manage author / admin permissions within a tangle

- identity permissions
- thread permissions
- revision permissions

many possible admin strategies:

- first-come first-served
- 2-factor
- N/M
- majority-rules

---

Open questions

- how do we grandfather in our existing content?
- how do we handle key revocation?
- can you have multiple identities per device key?
- how do we handle lost keys?
- is this mutually exclusive with the shared identity spec?
- does this require less or more coordination than the shared identity spec?

---

Versus 'shared identity spec'

- we learned that shared identity spec required every app to opt-in before it became viable, so actually needs a good amount of consensus
- this might need even less coordination: no agreement on config formats, no agreement on flume database, only agreement on a message protocol
- tangle identities allow apps to opt-out of the ~/.ssb folder
- where do we store the crap? https://github.com/sindresorhus/env-paths
- maybe when you boot up Patchwork (Next with this feature), it mints a new identity and asks if you want to point to your old identity
- apps will still need to run on their own separate port
- using port 8008 only matters if you're a pub
- shouldn't break anything if apps each run on a random port

## Hendrik's comments:

I need to butt out. got other meetings on my end.<br/>Thanks for the walk-through and the interesting thoughts on this.<br/><br/>My biggest wins for this thought process would be:<br/>- keeping only parts of tangles on lower end devices and being able to fetch them from other online people.<br/>- Being able to read private messages on different devices. I can from my current phone identity still access most of the things written to me publicly, but i can't open my private macbook inbox on the fly from the phone.<br/><br/>But anyway, thanks for today!

## cft:

I learned a lot, thanks for the office hour! Topics we touched:
- see my critique point that the "virtual feed" (aka "tangle as an identity") has not the strict log property, which means that some transactional applications (having side effects in the real world) will not be happy about it
- id-group-mgmt (still need to find a good terminology for these new concepts) is critical. Who "owns" that tangle, and how to prevent an attacker who got access to the key used to create to root message, to kick out everybody else (Hendrik brought up this scenario)
- the "tangle as an id" implements "encrypted rooms, but without encryption", because it handles group membership - would be interesting to compare with the recent "private SSB groups" proposals
- can such tangles/identities be useful for Wiki style media? I'm still hesitant that Wiki and SSB go well together
- recursive tangles as a spec goal: forces to separate the levels (e.g. membership mgmt). Matt using the word "rings" makes sense ("the ring 0 tangle", which is host to several "ring 1 tangles" etc)
- one-feed-per-app (chess, chat etc): conceptually nice, becomes very close to a (secured, persistent) TCP stream. One downside though: the replication layer will have to maintain awful lot of state (follow graph)