You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The above mentioned issues should guarantee that a client will see it's commits when read from the same originator. This does not necessarily hold for multiple nodes in a decentralized system.
Whatever the solution is, it will have to leak to the client implementation.
We can probably expand the use of the last-seen Cursor. Or possibly the dependencies.
This has implications on the client. A write can take infinitely long to appear on another node.
What does the client do if it does not appear within a timeout (30s?).
What does the client do if the message is lost forever (due to catastrophic failure)?
This spike probably intersects with censorship resistance.
The text was updated successfully, but these errors were encountered:
This is an extension of #418 and #415.
The above mentioned issues should guarantee that a client will see it's commits when read from the same originator. This does not necessarily hold for multiple nodes in a decentralized system.
Whatever the solution is, it will have to leak to the client implementation.
We can probably expand the use of the last-seen Cursor. Or possibly the dependencies.
This has implications on the client. A write can take infinitely long to appear on another node.
What does the client do if it does not appear within a timeout (30s?).
What does the client do if the message is lost forever (due to catastrophic failure)?
This spike probably intersects with censorship resistance.
The text was updated successfully, but these errors were encountered: