438 karma · joined August 31, 2018
But even with an llm backbone you’d still need some setup to detect when to query the llm. And then you already have a low-false-negative pigeon detector that may be sufficient for your use case.
My setup also had its occasional false positives but that’s not a problem if all you do is spray a bit of water around. I also looked into yolo, but I couldn’t find any good datasets of pigeons. Nowadays that’s no problem anymore as you can just use models like meta’s segment anything that do zero-shot bounding boxes… if you have the GPU to run it.
As of 2025 the pigeons are back and version 2 with aiming and a microphone array for target acquisition is still work-in-progress. I’m heading to bed now, but I’ll happily answer any questions tomorrow.
> this seems to just be a SQLite database with values in fields?
Sqlite is used as a storage format ("SQLite competes with fopen()"). The key-value pairs are stored as a modified Append-Only CRDT. The LUB-Operation (to merge to states while syncing) is implemented here: https://github.com/maxmunzel/kvass/blob/e32fdabdc86b039f716c...
> anyone with access to the file would be able to see all data stored?
Yes, attackers with access to your fs are not part of my attacker model. I rely on disk encryption for that matter.
> Do the clients cache data locally? It looks like you're basically syncing from the server for every request. You're already making a round trip to the server for a request anyway, so why not keep state only on the server? I can understand an offline-only mode, but this would require a significantly more robust sync mechanism. If this was the goal, I'd love to see this discussed more in the README too.
The sync mechanism is actually pretty solid, as its based on CRDTs. One of the applications of kvass is central management of config files, so automatic syncing and offline fallback are important.
> What is the purpose of the ProcessID?
The Counter Variable implements a rudimentary implementation of Lamport clocks. To get a total order from Lamport clocks, you need ordered, distinct process ids. The process id's don't really need to mean anything and the Lamport clock is itself just a fallback for the case that the wall-clock timestamps collide (see the Max() function), so it's practical to just draw them randomly.
> I didn't see any authn/authz in the requests. You're also unmarshalling random data from the request w/o confirming that it is valid first. This seems risky to me and could potentially crash the server if I were to send it random data.
Authentication is provided by the GCM mode of AES. As I decrypt (and thereby verify) early, I can assume to work on trustworthy payloads. GCM is also non-malleable unlike for example CBC or CTR.
As suggested by losfair, I'll switch to PSK TLS as soon as it's available or just put HTTPS in front of the end-points. But that's not high-priority right now.
On the other hand, using redis (/skate) for storing files was the inspiration for creating kvass.
This is by no means meant to replace the backend of your app. It's more of an alternative to usb-sticks and google drive.
Especially self-hosting kvass is even simpler than skate, and I had issues linking/syncing skate in the past.
It would probably be a nice weekend project to port the url/qr features to skate.
On the other hand, I didn't anticipate replay attacks in the design and thanks to your comment, I'll keep them in mind should I ever find myself in a scenario where they are undesirable...
Prior, I had to deal with ephemeral http servers, which I didn't like from an ergonomic perspective.
Ergonomically, I find redis nice. The problem is, that it is in-memory and that encryption is cumbersome. Also, kvass is able to be used offline, as the kv-store is implemented as a CRDT.
I’m thinking about a auto-aiming gun for the next iteration, though.
Feel free to ask any questions :)
So I bought a cheap electric water gun from Amazon, built in WiFi using an ESP8266 and a relay shield; 3D printed a window mount for my old iPhone (running a webcam app) and hacked together some openCV code in python.
After all this was working on my desk, I had the pleasure to discover that the PCB Antenna of the ESP is to weak to receive WiFi on my balcony so I connected the ESP to my (current) iPhone hotspot and wrote a small go relay for my server so that my laptop can send the shooting commands to the water gun ~~over the internet~~. Oh and while I was at it, I added a Siri Shortcut, so it’s voice controllable, too. (They are surprisingly hacker-friendly)
The surprising thing is, that this Ruben Goldberg machine actually works really well and without much fiddling.
As a long time i3 user that switched to Mac, it gives me almost all the benefits while still integrating nicely with the general UI. It's also not nearly as steep of a learning curve and does not get in your way at all.
As the implementation is block-based it is also faster than the naive approach of just zipping your data files.
A feature like this (properly implemented) could actually be great for those countries.
The slippery slope argument still applies of course.