Update events break if one node's clock is ahead
Opened this issue · 10 comments
Two nodes: A and B
B's clock is ahead of A's
When A deletes a value added by B it doesn't include it in the update event, thus there is no notification that the value is removed. The value does get removed from node A though.
yes. what is needed is a way to provided adjusted clocks.
probably by pinging back and forth, and deciding on a compromise time.
that can be a separate streaming protocol...
I've been aware of this problem a while, but I've been waiting for someone to have this problem to fix it.
A quick fix is to only check the timestamp if the source of the new update is the same as the source of the one in the history.
that would mean that only the original author can update the items they create.
If that is what you need... sure, but it breaks the idea of collaborative software.
Sorry if I was confusing. What I was saying is to allow the update if the source if different or the timestamp is larger.
Sorry this is still confusing.
Can you explain this in terms of a concrete example, of some thing that you are intending to use r-array for? Explain how the problem arises, and what the effects are on the user.
Explaining a problem interms of an actual use-case is very helpful, because I can also apply what I know about that usecase, which may reveal new approaches to the problem...
I'm using it for a chat. I have a bot that deletes messages, when it deletes a message (coming from a source which's clock is ahead) none of the clients react to it. Also I have a clear button, when I click it deletes the messages from the clients r-array but since it doesn't include the update in the update event it doesn't remove the elements from the page, also the messages still exist on all other clients (and the server).
oh, okay.
does the bot delete old messages? or is it just offensive, etc? messages?
the bot's update needs to be ahead of the message it is deleting.
if it's just deleting old messages it would be better to have each client delete the messages,
then there is no extra IO to be sent.
If you need a centralized deleter, but are having clock problems, you could delete make a delete message that has a newer timestamp...
you could just make your own localUpdate to set a timestamp that is ahead on the message you are deleting.
https://github.com/dominictarr/scuttlebutt/blob/master/index.js#L58
to solve this problem more generally, the scuttlebutt's clock should probably be exposed, or passed in some way...
I guess really what I need is an authority system, give all scuttlebutts full authority over themselves and on the server regulate it so everything but setting non-existent keys is blocked for most scuttlebutts and then trust other ones somehow.
there is this module https://github.com/juliangruber/authoritee
also, it maybe of interest to read through this issue dominictarr/scuttlebutt#6