Hacker News Reader

Comment by matteason | Hacker News Reader

Thanks for the great feedback!

I'm building the ability to save mixes at the moment actually - good point about being over to move them over to a new device. At the moment I'm just storing saved mixes in localstorage but people will definitely want the ability to sync at some point. I've been trying to avoid having an account system in the interests of keeping things simple but I might have to bite the bullet or come up with another clever way to keep things in sync

View on HN

You could store all state in the URL fragment. Maybe each key is a sound and each value is the volume, like /#whale=5&fire=8 or whatever. Call replaceState (better than pushState to avoid polluting the back button history with every little tweak) whenever the user changes something. On page load, read from the URL fragment using window.location.hash and then sharing is just a matter of copying the URL, which could be done entirely in browser chrome, and/or via a "share" button you provide.

These might help:

https://www.jvt.me/posts/2019/08/01/node-parse-url-fragment/

https://stackoverflow.com/a/66416539

Great recommendation for such simple state! The portability of that is just perfect!

This is exactly what I do on https://www.matteason.co.uk/scotbeats/ actually - any settings change is reflected in the URL and read back on load. When I implement sharing of individual mixes it'll probably look a lot like this

If you happen to be excited about stuff like this:

https://veilid.com/

https://news.ycombinator.com/item?id=37118124

https://www.eff.org/deeplinks/2023/12/meet-spritely-and-veil...

(Otherwise, encode-state-in-url-hash or export-to-json-and-paste aren't too bad, unless you do want "social")

You could generate some sort of hash of the selected options, encode it with something that’s short and human readable and then share that on the screen?

Something easy for a human to transfer like honey-chair-balcony or something. Store the settings in the backend against this identifier and then you can retrieve it later? So you still need a backend but no need for accounts

I feel your pain. I'm building my own local-first, no-nonsense app and need to solve the same problem. I've got proof of concepts for both a no-account server syncing scheme (app generates key, you manually enter that key in whichever instance you want to share the data with) and a web-rtc based p2p sync.

But I will say that I have a need to sync data, which is why I'm putting effort into getting that syncing working (as well as compressed and encrypted). I really doubt you would need something robust for this type of thing. I'd, personally, be perfectly happy to get a json "export" of your local storage values that I could just "import" into a new instance of the app. I'll email it to myself. No need to complicate it with automation and all of the baggage that comes along with accounts.

If nothing else, a manual import/export is a fully-featured first implementation that can be iterated into something more robust.

This is a good point. I like the safety of being able to have my own local copy of my data so json export/import would be a good first step

Reply on news.ycombinator.com