Handling SINGLE account relation streams when initial stream can't be found

Devtools Ceramic SDKs
1

Hey!

How are we supposed to handle single account relation streams when the initial stream can’t be found in the network?

Let’s say i have a Profile model using the single account relation to make sure users can have only one profile per account. I create my initial profile with a node which is then disconnected from the network and try to update my profile while being connected to another node. How would that work?

cc @spencer

Thanks!

2 Likes
2

This is how I understand it:

  • There is a timeout where the event-receiving node tries to find it before creating a new stream.
  • If no conflicting stream is found, a new one gets created
  • Other nodes could refuse the event as there is a conflict, i.e., they know about the same stream beforehand and wont accept a new genesis commit.
  • Hence, this new but incorrect stream wouldn’t be included under consensus. If the first node later receives the earlier event, the latter would be trumped in that node too.
  • This work because single streams are deterministically generated from the DID and the schema, so if a DID create the same one multiple times it would get the same ID and hence this consensus conflict.

Curious to see if my understanding here is correct :slight_smile:

1 Like
3

So because of how the genesis commit is deterministically generated, even if two nodes who are disconnected both try to create the same profile, they will wind up creating identical genesis commits and wind up with the same StreamID. There is no way you ever wind up with different streams for the same model-controller pair for a model with the single account relation.

What can happen though is that you can wind up with a fork in the stream’s history. When a deterministic stream is created, the genesis commit is created with no content, and then is usually followed-up immediately with a second commit that actually sets the content appropriately. If nodes are isolated from each other in the network, they could wind up each creating their own version of this second commit that sets the content. When the network is healed and the nodes can talk to each other, this will cause a conflict in the history of the stream. The conflict resolution rules (Consensus | Ceramic documentation) will kick in, one brach will win, and the other will be discarded.

1 Like