Clarify forking and merging workflow

[Frando]

Current state of things:

• Alice creates an island Videos. This means
  • a) she creates a new record feed which is writable for her. Let's say its key is A.
  • b) she creates a new local kappa scope kA and adds the feed A to it
  • c) she starts to swarm all feeds in kA under discoveryKey(A)
  • d) she puts some records to kA, which means they are putted into A
• Bob receives A from Alice (outside of Sonar). Bob clones the island A. This means
  • a) he creates a local kappa scope kA
  • b) he joins discoveryKey(A) to ask for feed A, downloads it and adds it to kA
  • c) he creates a new writable feed B and adds it to kA
  • d) he puts some records to kA, which means they are putted into A
• Claire does the same as Bob

Because Alice doesn't know about B her kA doesn't include B. What we currently do support is the following:

• Bob sends Alice B
• Alice adds a source record for B to her feed A. This causes B to be added for Alice's kA
  . For Bob, this changes nothing because his kA already includes B

However, Bob could also send his key to Claire. Then, the following would happen:

• Bob sends Claire B
• Claire adds a source record for B to her feed C. This causes B to be added for Claire's kA
• Because Claire syncs A in her kA, this will also add B to her kA
• For Bob, this changes nothing because his kA already includes B
• For Alice and everyone else syncing A this changes nothing because A doesn't have a record for either B or C

This model is interesting and might work out, however there's several challenges involved:

• There's no definite notion what kA is, the only shared knowledge is that it includes A and all feeds authorized by A
• At several times, we talked about making the "add a writable feed to my local kA" an explict action ("fork", "make writable", "enable edit") instead of it being automatic
• This presents a challenge to the UI - it will be mandatory to, for each island, say includes unmerged changes or something like this. Once Alice authorizes a peer, the message would change to authorized writer
• We currently wouldn't support to show an island in different states. This means that once Bob started making changes, he cannot view the island in the unchanged state (the UI could enable that, but only through manual filtering)

An alternative workflow look be more like git forking:

• Bob clones A which creates kA for him and syncs A + referenced feeds
• The island is readonly, Bob cannot make any changes
• When Bob clicks Fork this island. This creates a new feed writable feed B, adds a source record for A to this feed B, creates a new local kappa scope kB, and starts offering B and A under discoveryKey(B)
• Bob now has 2 local kappas: readonly kA and writable kB, where kB includes everything from kA
• Bob can send B to Alice, and Alice can merge B into A
• However, at least currently, if she wanted to "preview" kB, she'd first had to create kB, index it, then decide to merge, which would add B to Aand thuskB===kA`
• This has the effect that now, for Bob, kA' and kBare identical. Therefore,iAandiBare also identical, apart from their swarm address:iAis swarmed underdiscoveryKey(A), iBis swarmed underdiscoveryKey(B)`
• If he told others about iB he should likely continue swarming iA under iB.
• An alternative would be that, when clicking fork, a new kB is created, but B is set to swarm on root address discoveryKey(A). To share his changes with others, he'd send a link that looks like sonar://discoveryKey(A)?include=B (or even sonar://A?branch=B)

Maybe it makes sense for us to pick up the fork/branch terminology. Not sure yet, will have to think all this through once more.