This is handled by Redis, as such, the last write will win. As the primary key is tied to the user id, there will not really be a concept of Machine A vs Machine B as the end user can only be in one place at a time.

I see. The case in question is when the user switches between two devices, each of which may be sometimes offline. This can cause older changes hitting the server later than the new ones, in which case, ideally, they should be rejected.

What happens to storage requests made while offline? Are they cached locally and propagated once online, or are they lost?

I feel like, if the answers to these questions are important, you should be using a more complex solution.

Users can have an app in multiple tabs though, and apps can read/write local storage in the background.

The funny thing is that localStorage supports that.

Judging by the title, I thought this tool actually just synced the existing localStorage instead of being its own storage. Since localStorage has onChange events it would be trivial to built, it would still be sync, it wouldn’t require any changes to the existing code, etc

Since B is offline it never sets x to 2: https://github.com/FrigadeHQ/remote-storage/blob/main/packag...

So being temporary offline is not supported? That's pretty limiting.

Based on the comments I think this is just, not yet implemented. But is one of the next steps for truly cross device storage.