It's probably a good idea too to offer these ingredients through your service as an upcharge. "Buy your kitchen starter pack".
For meal kit customers who may not have the time or knowledge to stock the basics, this could be a win-win.
https://www.goodeggs.com/sfbay/dinner-kits
We use produce and groceries we were already selling as parts of our kits, as well as partially prepared food we prep/cook in-house. 80% of what we sell is made within 200 miles of SF.
We also assume you have things like olive oil. Hah.
Also worth mentioning is that we hold onto produce for usually less than 24 hours from the farm to your door.
http://www.sfchronicle.com/food/article/Good-Eggs-hatches-ne...
Let me know if you'd like a beta invite to try the kits out. (Or to talk Operations Engineering (my team), it's fascinating and full of classic compsci problems)
Could you explain that using different words?
This is a variant of "should you compress or encrypt first?"
Compression relies on pattern matching, and compressed size will leak details about what you compressed, even if that result is encrypted. (Unless you then pad the encrypted size, but then what was the point of compressing? I can see some more or less secure ways to do this like establishing a compression ratio/bandwidth/entropy limit, then padding and achieving that constraint so each encrypted payload looks more or less the same, but latency sensitivity makes this difficult)
In the case of VOIP, the codec uses a lookup table for distinct parts of speech (tch, sp, buh, etc). Then "all it has to send" is table cell numbers around (certainly not all). On the receiving side, you just look in your speech table and reconstruct.
These values have distinct output patterns, particularly when compressed. If you can guess better than 70% of the time (I forget the exact number they achieved) what table value was used, then reconstruct it, you can listen in on what they're saying, without having to break the underlying encryption.
Voice codecs are also awful at encoding music which may explain why when you're on hold, the hold music may just be dropped and replaced with white noise because it's reached some bandwidth cap. C.f. video encoding and falling snow.
It also reminded me of a recent article talking about how you can break audio codecs by guessing which quantizer was used by the packet, then using it in reverse to produce speech! Which I suppose is obvious in retrospect, that lossy codecs are trying to compress data by making it perceptually similar, whatever the domain.
I also appreciated the ties to video game networking. Gaffer on Games has had a long-running series on designing multiplayer networking protocols with UDP and you two approach bit-shaving very similarly (unsurprisingly I suppose - it's a very specific process with its own tools).
Anyway, thank you! I learned a lot.