On 01/30/2014 08:51 PM, grarpamp wrote: > Other than for latency issues in our protocols, there's enough > fiber to generally ignore our global traffic impact... torrent, video > and cloud are dominating that, not messaging anymore.
Indeed. Even the "3rd world" of home internet connections the USA (ranked 14th) has an average speed of 7mbit/sec. Any reasonable multiple of Email/IM traffic is basically zero. Not particularly worth discussing. The hardest part of the problem is the feature set and social aspect of launching a new messaging network. Clearly it's still happening with Mxit, WhatsApp, WeChat, Line, Viber, MessageMe, Voxer, etc. I think WhisperPush's approach with TextSecure is interesting: * they partnered with cyanogen to because the default on a substantial number of phones * It "just works" with any SMS user, granted no security/encryption * It "just works" securely with any other TextSecure user * It also "just works" on IOS, granted a user has to track it down and install it. As far as I know Cyanogen does not have a secure IM app yet. >On Sun, Jan 12, 2014 at 3:29 PM, Christian Huitema >> I believe this is actually an issue. The number of pings per host scales as >> O(log N), which means the amount of maintenance traffic scales as O(N log N) >> -- more than linearly with the size of the network. Given the nature of the >> DHT, the addresses to be pinged So yes, per node bandwidth scales with O(log N). System bandwidth with O(N log N). But it's so small that it's mostly irrelevant. Sure some phone users will be power limited or have a very low data cap, in those cases they should install a raspberry pi at home or share a node with more resources. Don't worry about 2 billion users before you get 2000. > I think the question is, can we do what we want to do within > the bandwidth that our target users have available to them... > such as say a 56k channel, 128k, 512k, etc. If we're using > 32 of 56k for maintenance, that may leave little left for the > signal you want to send through. 10M users DHTs work today with minimal bandwidth overhead (kbit/sec) while maintaining MByte/sec (factor of 8000 different). The huge majority of node bandwidth goes to actually downloading torrents. So basically I don't see any particularly big technical hurdles. Not that there aren't others. The network effect and social issues being the big ones. ChatSecure looks pretty reasonable. In a perfect world I'd hope for a client that: * fully decentralized, only has find the bit-torrent mainline DHT to be able to find peers. Why not use the existing 10M peers to help find compatible peers. * IPv6 capable, clearly the easiest way to directly connect other peers in the future. Comcast is already over 25% and IPv6 seems to be gathering steam. * Simple tit-for-tat bandwidth and storage trading between owners. Reputation based on direct observation (no 3rd parties). * support for 2 tiers of peers, those with long connection times bandwidth and power to burn and those with intermittent connections and are power/bandwidth limited. * allowing people to have a home node that trades bandwidth/storage with peers and then a mobile node with the same crypto identify that can leverage the home node and any of it's peers. Ideally I could have a 2TB disk ($100) at hosting my more important files (200GB) and earning the good will of it's peers by hosting encrypted blobs for them. Leave it connected to a raspberry pi/beagle board black for $40. Then as needed I can use the goodwill of those peers to record for whatever bandwidth/storage needs I have. So basically my node and it's friends could act collectively as my IM/Mail/File server. _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
