4 ms·

I wish there was some browser solution for apps like this where you could save and share your app state between your own devices, and push/share that state with

I wish there was some browser solution for apps like this where you could save and share your app state between your own devices, and push/share that state with others, all without any server backend involvement e.g. so you could have a Kanban board shared with others and the state would be stored locally and/or in bring-your-own cloud storage. There's so many apps like this that could be simple, but for robust state saving involve setting up and maintaining a backend (e.g. with security patches, backups, performance monitoring). There's also the privacy implications on your data being store on someone's server, and the risk of data leaks. It's like there's a key part of the internet that's missing. Something like this could be a browser extension? This exists?

staticfish 2y ago
You can already do this using things like the Chrome Storage APIs (obviously chrome only, and you need to be signed in, and bundle an extension) https://developer.chrome.com/docs/extensions/reference/api/storage https://developer.chrome.com/docs/extensions/reference/api/s...
- seanwilson 2y ago
  Yeah, seen this but the storage quota is tiny: > If syncing is enabled, the data is synced to any Chrome browser that the user is logged into. If disabled, it behaves like storage.local. Chrome stores the data locally when the browser is offline and resumes syncing when it's back online. The quota limitation is approximately 100 KB, 8 KB per item.
  - msephton 2y ago
    8KB is a lot! You just have to be mindful of the constraint. I made an entire video game in 39 KB.
WorldMaker 2y ago
`roamingStorage` as a relative to `localStorage` sort of like Windows' "Local App Data" versus "Roaming App Data' would be nice to have in theory. Of course even if you kept it to the simple KV store interface like `localStorage` you'd need to define sync semantics and conflict resolution mechanics. Then you'd have to solve all the security concerns of which pages get access to `roamingStorage` and how it determines "same app" and "same user" to avoid rogue apps exfiltrating data from other apps and users. It would be neat to find an architecture to solve such things and see it added as a web standard.
- seanwilson 2y ago
  > Of course even if you kept it to the simple KV store interface like `localStorage` you'd need to define sync semantics and conflict resolution mechanics. It would be great to have this standardized. Custom two way syncing is a nightmare to implement correctly, and it doesn't make sense for apps to have to keep reinventing the wheel here.
  - WorldMaker 2y ago
    It is a factor in why CRDT/OT posts and libraries get regularly upvoted on HN. A lot of us want a good, easy to use baseline. A lot of us are searching for that and/or thinking we can build that. Part of why there's always some reinventing the wheel in this space, unfortunately is that this also seems to be one of the harder problems to generalize. There's always going to be domain specifics to your models or your users or users' idea of your models that is going to need some custom sync and conflict resolution work. Sync has a lot more application specifics than most of us want. That said, yeah, if there was a good simple building block "base line" to start with that met a nice 80/20 rule plateau, it would be great for giving apps an easy place to start and the tools to build application and domain specifics as they grow/learn their domain. (One such 80/20 place to start if the idea was just a simple KV store might be a basic "Last Write Wins" approach and a simple API to read older versions when necessary. You can build a lot of the cool CRDT/OT stuff on top of a store that simple. Many starting apps LWW is generally a good place to start for the basics. It doesn't solve all the syncing/conflict resolution problems, you'll still need to write app-specific code at some point, but that could be a place to start. It's basically the place most of the simplest NoSQL databases started.)
    - seanwilson 2y ago
      > It is a factor in why CRDT/OT posts and libraries get regularly upvoted on HN. A lot of us want a good, easy to use baseline. A lot of us are searching for that and/or thinking we can build that. Do you have any views on the easiest way to do two-way syncing for a web app if you want to avoid relying on propriety services, or a complex niche framework? This comes up for me every few years and I'm always disappointed there isn't a no-brainer way yet to get a 80% good enough solution.

staticfish 2y ago

You can already do this using things like the Chrome Storage APIs (obviously chrome only, and you need to be signed in, and bundle an extension) https://developer.chrome.com/docs/extensions/reference/api/storage https://developer.chrome.com/docs/extensions/reference/api/s...

seanwilson 2y ago
Yeah, seen this but the storage quota is tiny: > If syncing is enabled, the data is synced to any Chrome browser that the user is logged into. If disabled, it behaves like storage.local. Chrome stores the data locally when the browser is offline and resumes syncing when it's back online. The quota limitation is approximately 100 KB, 8 KB per item.
- msephton 2y ago
  8KB is a lot! You just have to be mindful of the constraint. I made an entire video game in 39 KB.

WorldMaker 2y ago

`roamingStorage` as a relative to `localStorage` sort of like Windows' "Local App Data" versus "Roaming App Data' would be nice to have in theory. Of course even if you kept it to the simple KV store interface like `localStorage` you'd need to define sync semantics and conflict resolution mechanics. Then you'd have to solve all the security concerns of which pages get access to `roamingStorage` and how it determines "same app" and "same user" to avoid rogue apps exfiltrating data from other apps and users. It would be neat to find an architecture to solve such things and see it added as a web standard.

seanwilson 2y ago
> Of course even if you kept it to the simple KV store interface like `localStorage` you'd need to define sync semantics and conflict resolution mechanics. It would be great to have this standardized. Custom two way syncing is a nightmare to implement correctly, and it doesn't make sense for apps to have to keep reinventing the wheel here.
- WorldMaker 2y ago
  It is a factor in why CRDT/OT posts and libraries get regularly upvoted on HN. A lot of us want a good, easy to use baseline. A lot of us are searching for that and/or thinking we can build that. Part of why there's always some reinventing the wheel in this space, unfortunately is that this also seems to be one of the harder problems to generalize. There's always going to be domain specifics to your models or your users or users' idea of your models that is going to need some custom sync and conflict resolution work. Sync has a lot more application specifics than most of us want. That said, yeah, if there was a good simple building block "base line" to start with that met a nice 80/20 rule plateau, it would be great for giving apps an easy place to start and the tools to build application and domain specifics as they grow/learn their domain. (One such 80/20 place to start if the idea was just a simple KV store might be a basic "Last Write Wins" approach and a simple API to read older versions when necessary. You can build a lot of the cool CRDT/OT stuff on top of a store that simple. Many starting apps LWW is generally a good place to start for the basics. It doesn't solve all the syncing/conflict resolution problems, you'll still need to write app-specific code at some point, but that could be a place to start. It's basically the place most of the simplest NoSQL databases started.)
  - seanwilson 2y ago
    > It is a factor in why CRDT/OT posts and libraries get regularly upvoted on HN. A lot of us want a good, easy to use baseline. A lot of us are searching for that and/or thinking we can build that. Do you have any views on the easiest way to do two-way syncing for a web app if you want to avoid relying on propriety services, or a complex niche framework? This comes up for me every few years and I'm always disappointed there isn't a no-brainer way yet to get a 80% good enough solution.