waerhert

Very well done! When adding a chord on a key, I'm missing a small preview of the chords as they appear in the autocomplete list, or would be nice to be able to assemble a chord on a fretboard view. What made you start work on this app? And what is the logic behind how the chords are laid out on the keyboard?

Agreed! And also,

  Total capacitance in series is 1/C1 + 1/C2, while in parallel is C1 + C2.
  Total inductance in series is L1 + L2, while in parallel is 1/L1 + 1/L2

Nice approach! On Ubuntu 24.04 I had to loosen some AppArmor protections by creating a file:

  > cat /etc/apparmor.d/bwrap 
  #include <tunables/global>                                                       
                                                                                  
  /usr/bin/bwrap flags=(unconfined) {                                              
    userns,                                                                        
  }

Great read, thanks for sharing this. I'm also coming from software and have recently started making some hardware for personal use in my free time. The idea of selling it as an actual product has occurred to me, but the thought of dealing with all the logistics quickly makes me reconsider. Congrats on your launch!

Very cool, thanks for sharing! Any ideas of adding 2 gimbal motors to this for GOTO? MS6010v3 or something lighter would seem like a good fit.

It's not limited to WiFi networks and indeed the fingerprints you suggest would be a lot better because they would change significantly over time. The whole WiFi networks idea kinda stuck because it's an obvious an easy thing to grab from the environment using a mobile phone. An audio fingerprint would definitely be doable on mobile.

I see, this sheds some new light on your initial concerns. I'm aware an attacker can keep pretending to be inside an environment once they've seen it. I wasn't accounting for a scenario where an attacker has a huge database for queries like coords -> list of wifi networks. I was under the assumption services like Wigle only provided the reverse lookup (wifi -> coords). Indeed an attacker could potentially reverse the LSH tags if it hashed the wifi environment within very small geofences. It's bit of a needle & haystack problem but not an impossible one with enough resources. I wouldn't say it's a perfect system and I don't mind it falling apart under scrutiny, I just found it an interesting idea so I really appreciate you thinking along here.

Edit: Maybe some preshared group hash (kinda beats the point), or combining multiple modalities (eg bluetooth, shared interests) or some kind of proof of work token could help mitigate some of these issues. I guess anything to reduce the time to attack helps in this case? Or anything that really pins down environment + time, like what smath described in his comment. In essence, the core idea of minhash + lsh works and it doesn't limit you to just wifi networks. The key is being able to grab a fingerprint that is unique enough and different enough each epoch. Wifi networks are just easy enough to grab vs something more low level like an APs beacon timing interval jitter or something.

Thanks for the heads up! Good to know what's out there. Interesting that I independently arrived at something possibly similar.

Thanks for the feedback! Rainbow tables probably won't work here since the epoch (rounded to 5 minutes) salts everything, so precomputed tables would expire constantly. You would use use BSSIDs + SSID in real implementations. The MinHash part creates 128 hash values from the entire observed set, not a subset of 3, then LSH divides these into bands where similar sets collide probabilistically based on Jaccard similarity. I've tested with two phones where one saw 3-4 networks and the other saw ~10. They still found each other, and you can try it in the interactive demo yourself. You're right it's not entirely privacy preserving, really depends on your threat model as I discuss in the security section. Your idea about combining area hints with time-based salts is interesting though, feels like it could bridge geospatial indexing with this approach! The whole geospatial indexing thing was something I became aware of late in the project and didn't go into further. It's probably a much simpler approach if geolocation is important. In the current approach, geolocation doesn't matter at all, only 'the environment', whatever that may be.