I sympathize with the author, I've had similar thoughts about snacks. We need more non-sweet snacks. Ideally something that tastes good, is not too salty, is healthy and satisfies your cravings.
Nuts (in the culinary sense) and cheese are good for that - a mini-cheeseboard with a couple of different bits of cheese (maybe 20-30g of each), a handful of cashews and walnuts, and maybe a dab of fig jam or membrillo on the side.
Tasty, nutrient-dense, surprisingly filling. Great as a mid-afternoon snack, or add some fruit and a bit of bread or some oatcakes to make it into a decent lunch.
South African food actually has this in abundance, biltong is like beef jerky but better in almost every conceivable way - not to mention all the other variants of it for example dry stix, droevors, etc.
Not to say we don't also have other sweet snacks, but compared to other places I've been nowhere quite has the same level of "savory" snacks
In terms of beverages alcohol-free beer gained popularity in recent years because it's not sweet, has half the calories of juice/soda yet actually carries some taste.
If I were to imagine something fitting this description, it would have to be something you have to chew for extended periods of time.
Still: Using a line based protocol and base64 encoding the audio data? Not my first choice.
The README doesn't mention it, but I assume both parties have to be online at the same time?
Regarding encryption - what's the point? When communicating with a tor hidden service, the data is already encrypted.
Only starting the sending audio data after the speaker has stopped talking means much longer delays than necessary. Imagine someone talking for a minute.
To receive a call, you either need to be online and actively listening for calls, or optionally, you can enable auto listening. When another user calls you it will automatically put you in the call. On end call you will be put back in listening mode. I'm not really sure a great way to get around this without overly complicating it.
I believe because of the small overhead that's added there is just no reason not to layer encryption. At the end of the day I just wanted to see the bits I'm sending over the wire with my own eyes for assurance it's protected regardless of the fact that tor is protecting the data.
The streaming would be a nice improvement for latency. I would have to look into how this would work for the optional audio processing. Having one set file for transport also simplifys the some of the flow with encryption like salting and optional hmac authentication as these are derived from the sum of the entire file, not a portion of it.
The base64 encoding adds about 30% overhead. It's not ideal but it was a limitation of bash. Passing raw binary does not work in bash (or I couldn't get it to work).
I was also curious about the base64 encoding in the stack. I'm not knowledgeable in this area though so it was more for my own education than questioning the choices.
Its a product of me troubleshooting why my audio pipe wasn't working in early prototyping. I tried quite a few things and the first time I got the successful loopback on a remote device I had implemented the base64 and it solved the piping errors I was getting.
Turns out bash totally can pipe raw binary you just need to appropriately wrap the blob with the correct command.
By the time I had the working pipe I was in feature building mode.
your right it's not a problem. This has been implemented since v1 and I haven't really been focused to much this. Trying to decide if I should remove this step for future versions. It's a clear optimization but Im thinking it should at least be backwards compatible with old versions.
It's not really a latency saver but it definitely reduces load on the network.
Wow, the enshittification over at Dropbox has reached a terrible level. They make it super hard to just download a file in a browser, something that is supposed to be their core function. Why even use Dropbox these days?
I'm still happy about FUZIX on the RP2040 (last discussed here two month ago https://news.ycombinator.com/item?id=46271115 ). A capable SoC that costs around $1.
Only via (USB) serial so far, but that works for me.
reply