On Mon, Oct 21, 2019 at 07:08:58AM -0400, grarpamp wrote:
See the related...
Nice! Can imagine OFFSystem, combined with even just 1- or 2-hop onion routing, where you route amongst 'friends', to be a viable low overhead (extra bandwidth) and reasonably low latency and therefore to replace existing torrent clients. Which reminds me - we must treat different streams according to the nature of the stream. - Phone call demands low latency, reasonably low bandwidth. - Bittorrent demands high throughput, is fine with utilizing excess available bandwidth (like running a coin miner in your idle process). - Text messages/ txt chat, are miniscule bandwidth, can tolerate unpredictable latency (at least, up to a few seconds if it so happens), but to achieve a systemic difference, we -must- achieve wheat in the chaff (and "via trusted friends") "disappearing act". - some txt messages can tolerate super high latency, in exchange for significantly increased anonymity and etc properties - comfort for the main stream end consumer crowd accessing MSM web sites, demands low privacy, low security, bursty, relatively low latency streams to view heavy moronic web page "CNN brain programming" - like Tor achieves Within the confines of: - packet switched altnet - with end-user node making own routing decisions - plus applied/configured meat space "friend trust metrics" I believe we can group streams into the above categories and others which make sense. Different security requires different routing - even accessing an MSM web page could be diverted to my altnet chaff fill node, if more important stuff is not being up/down-loaded via my node, but only if my node is not doing something I deem more important. With a fundamentally flexible packet switched UDP base layer, we can build appropriate stream "protocols" or "configurations" on top, to satisfy different users, uses and/ or apps - at least this is the goal - don't lock in the end users to a single stream modality, so that we don't keep rewriting the stack over and over and ...