Nullboard: Kanban board in a single HTML file

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?

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/s...

`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.

> 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.

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.

8KB is a lot! You just have to be mindful of the constraint. I made an entire video game in 39 KB.

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.)

> 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.

For a couple years I thought PouchDB might give us a strong relatively standardized 80% solution, but then the CouchDB ecosystem kind of exploded (IBM bought Cloudant and pivoted it to a much worse IBM product; Couchbase continued to pivot away from CouchDB compatibility; Apache's politics got real confused real quickly about what the next version of CouchDB should even be and tried to rewrite it in six different languages).

I still think the multi-version document database approach is probably the easiest 80% solution baseline to work with for many projects, especially with a mixture of developer skill levels and document types. It doesn't save you from needing to solve conflicts, of course, but the default behavior (newest version wins) is a predictable one and generally just works until it doesn't work anymore by which point you should have a better idea of your application's specific domains and which conflicts are more important to resolve than others.

It's unfortunate that "Mongo-compatible" better won the marketplace, because CouchDB had a better focus on standardizing the sync experience between DBs and "Couch-compatible" was nice while it lasted (not nearly long enough).

I think the CRDT/OT library builders got a little bit too lost for too many years thinking that the "conflict-free" initial "C" in CRDT was fate or manifest destiny rather than hopes and dreams (to see dashed against the hard rocks of reality). As someone whose introduction to CRDT/OT was specifically from the lens of source control, I know that I was a skeptic that they'd ever truly achieve "conflict-free". Conflict resolution in source control will almost always be a human-in-the-loop touch point. I don't think you can solve for "conflict-free", I think you just try for more and more ways to sweep conflicts under the rug and I think that's a pretty good summary for part of why we've seen a lot of increasingly complex frameworks in the space that feel like they need increasingly more PhDs in the room to build apps on top of.

I think we're finally starting to see the other side of that mountain, as more (not all, but a lot more) of the developers working in that space do start to realize that you can't eliminate conflicts entirely in a general way for every application domain, you can just offer better tools for how to manage them when they naturally occur. The last few libraries that I've seen on HN have given me hope that we are starting to see more pragmatic and fewer dogmatic projects in that space and maybe soon one will feel like a real 80% good enough contender for general application development.

Amusingly, or perhaps predictively, I think the ones that are going to get there to feeling like an 80% good enough are going to be the ones that most look like a multi-version JSON document database at the high-level API and maybe also in the low level storage mechanics (to run anywhere localStorage does and/or any Mongo-compatible NoSQL store). In theory though, maybe that CRDT/OT-based version gives you a lot of knobs under the hood in between storage and high level specifics to help push individual applications from 80% to 90%+ if you learn how to configure it. That would be better than just an 80% if that happened, and is a reason to stay excited about the CRDT/OT space.

I think the other side of the wishlist is also hoping for better peer-to-peer/device-to-device solutions for the web and web browsers. There was a flurry of work that happened there during the cryptocoin boom that never quite built the 80% good enough solutions for general applications or that weren't too heavily tied to cryptocoin projects that added proprietary complexity. I'm afraid that as the cryptocoin boom has faded a lot of those projects are already abandoned and we are going to see another spike in interest in such tools again for a while. (Unfortunately AI doesn't need peer-to-peer, it needs big pipes to large central datacenters again.)