feat: add TodoMVC example with identity contracts and KV store

[akhileshthite]

todomvc.mp4

[corrideat]

This looks like a good start. I left some accessibility-related comments that, while they are issues in the code this is based on (i.e., the other TODO MVC examples), there's maybe little reason to replicate here.

I think that to simplify things, up to you, it's fine to use a CDN for importing sbp and @chelonia/lib here, since this isn't supposed to be a security-sensitive app.

I see that you're adding login functionality. This part will likely be the most complex aspect of this MVC, since login currently takes several steps, but it'll also be a good opportunity to see how simple we can make it.

[akhileshthite]

The TodoMVC uses SBP (@sbp/sbp@2.4.1) and Chelonia (@chelonia/lib@1.2.2) libraries loaded from CDN with localStorage as the storage backend for browser compatibility. Also, the custom todomvc/* selectors and KV operations are used while following SBP selector patterns and Chelonia architecture.

Chelonia's KV store (chelonia.db/set, chelonia.db/get) fails in browsers due to cryptographic key validation that expects Node.js-style hash-based keys, not simple strings like "identity_asdads:todos". The library loads successfully but throws "bad key" errors.

We still benefit by loading Chelonia because it validates our architecture patterns match real Chelonia (same contractID:key structure), provides learning value for developers.

Q: How should I approach this? Any guidance on the recommended path forward would be greatly appreciated!

[corrideat]

I've taken a look at this again, and these are some thoughts:

1. It's fine if you don't use any frameworks (and I'd say the same if you were using a framework), but the current app.js file is already too complicated. The point of this PR is to serve as a starting point / example / demo for Chelonia, so ideally we'd want the Chelonia-relevant parts to be self-contained and defined separately from the UI. In other words, the audience would be application developers who probably already know how to implement a web app, so they could gloss over the non-Chelonia parts and focus on the Chelonia parts.
2. I don't see this PR using any contracts whatsoever (right now, anyhow), which it should, since that's a fundamental aspect of Chelonia. That also means that state will need to be loaded from a contract.

chelonia.db/set and chelonia.db/get should in fact work on simple strings, but colons have a special meaning. However, you probably shouldn't be using these selectors (directly) on this app.

ETA: On this same note, I can see why maybe things got confused, but chelonia.db/set and chelonia.db/get are a KV store but they're not the KV store that this PR should be using, which are chelonia/kv/get and 'chelonia/kv/set'.

[corrideat]

We still benefit by loading Chelonia because it validates our architecture patterns match real Chelonia (same contractID:key structure), provides learning value for developers.

Somehow, I missed this. I'm not sure what you mean here by 'contractID:key structure', however I don't think that this demo / PR should just match 'architecture patterns'; it should use real contracts with real Chelonia. Perhaps the bit that you could skip is needing a server by using browser storage and / or some fancy SW, but otherwise a Chelonia-like experience isn't sufficient.