Currently, the CROs have a pubsub group where the nodes are actively listening for a message object_update with an arbitrary field data.
In our canvas example we are passing the function that did the update and the parameters. This allows us to update our local version, but we don't account for redundant messages (will lead us to an incorrect state).
In theory, libp2p doesn't have duplicate messages, but we need to further test if that is true.
We should define a better way to do the object updates and what should go into the data field.
d-roak
commented
3 weeks ago
Currently, the CROs have a pubsub group where the nodes are actively listening for a message
object_updatewith an arbitrary fielddata.In our canvas example we are passing the function that did the update and the parameters. This allows us to update our local version, but we don't account for redundant messages (will lead us to an incorrect state). In theory, libp2p doesn't have duplicate messages, but we need to further test if that is true.
We should define a better way to do the object updates and what should go into the data field.
This will lead to the requests spec document.