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

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

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

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

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

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