3 ms·

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

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

hunter2_ 3y ago
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://www.jvt.me/posts/2019/08/01/node-parse-url-fragment/ https://stackoverflow.com/a/66416539 https://stackoverflow.com/a/66416539
- catapart 3y ago
  Great recommendation for such simple state! The portability of that is just perfect!
- matteason 3y ago
  This is exactly what I do on https://www.matteason.co.uk/scotbeats/ 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
catapart 3y ago
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.
- matteason 3y ago
  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
jamesbooker83 3y ago
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
3np 3y ago
If you happen to be excited about stuff like this: https://veilid.com/ https://veilid.com/ https://news.ycombinator.com/item?id=37118124 https://news.ycombinator.com/item?id=37118124 https://www.eff.org/deeplinks/2023/12/meet-spritely-and-veilid 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")

hunter2_ 3y ago

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://www.jvt.me/posts/2019/08/01/node-parse-url-fragment/ https://stackoverflow.com/a/66416539 https://stackoverflow.com/a/66416539

catapart 3y ago
Great recommendation for such simple state! The portability of that is just perfect!
matteason 3y ago
This is exactly what I do on https://www.matteason.co.uk/scotbeats/ 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

catapart 3y ago

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.

matteason 3y ago
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

jamesbooker83 3y ago

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

3np 3y ago

If you happen to be excited about stuff like this: https://veilid.com/ https://veilid.com/ https://news.ycombinator.com/item?id=37118124 https://news.ycombinator.com/item?id=37118124 https://www.eff.org/deeplinks/2023/12/meet-spritely-and-veilid 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")