On Mon, Oct 21, 2019 at 06:58:57PM -0300, Punk - Stasi 2.0 wrote:
courtesy of tor scum dingledine and matheson and a GCHQ guy, danezis who now works for facebook-NSA as well. Wait, facebook, nsa, gchq, university of london, etc so many aliases for the same mafia.
Have not begun to read that yet, but one of the stream covfefe will "recommend as a default for all users" is a really low bandwidth ("bw") and high latency, permanent connection. 1KiB/s is much too fat, and at 80MiB/day (2.4GiB per month) folks will complain. But let's consider just 512 bytes every 10 minutes (a single small UDP packet): 1 * 6 * 24 * 30 ~= up to 4320 separate "message sends" per month each message send can contain up to 512 / 128 = 4 "std tweets" therefore 17,280 "std tweets" at 10 minute latency at 512 * 6 * 24 * 30 ~= 2.1 MiB bandwidth per month NOW we're talking some serious chaff for high value random tweets at any time, with a maximum latency of 10 minutes, for only 2.1MiB of bandwidth per month! No doubt some folks can imagine some nice applications for this "recommended baseload" stream :) Now, if your mixing, then those 17,280 tweets need to be divided by the "mixing hop count" to work out actual payload, so let's say your actual tweets go through 10 hops, we have (up to) 1,728 high value tweets per node, per month, with possibly up to 10*10=100 minutes maximum latency (although I'm confident we can eliminate most of that with nodes cascading off one another in waves, so that maximum latency should be at most say 30 time units. If we need lower latency, say 1 minute, we're still only talking 21MiB bandwidth per month - and as a bonus we have 10 fold message capacity, for 1/10th the latency, a win win (except on the bw front of course). To repeat a key point from a previous email: by treating different types of streams for their own nature, we can not only reason about network impact and various performance metrics, but we can ensure that any design caters to include that type of stream.