[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[p2p-hackers] The next gen P2P secure email solution

On Fri, Jan 31, 2014 at 11:39 PM, Bill Broadley <[email protected]> wrote:
> 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.

Why these 'social launches' work for crappy apps is becuase the windows
writers cater to and know the forum using, bling ridden, pop, idiot-sphere.

While cpunk writers / good apps such as might be found below have
historically shied away from that catering/knowing, there is no reason
they cannot engage it, or that they cannot partner with people that do
to enable their own social launch.


> 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 don't agree. If you do not design for say 2bn users upfront
(as is the general subject of this thread re: nexgen global p2p solutions)
and instead target 200k or less, you will hit major roadblocks that
are very difficult to rip out and cure becuase your entire mindset
from day one was only scaling to a dreamy 200k. Mindset and failure
to think big traps projects like these, and if they somehow capture
and grow users they'll get overloaded to the point of unusability.
The best case they then embarrasingly have is to take a year
basically rewriting from scratch, or they fail and users move on.
And once a project hits unusability issues, that is a hard image to
shake... fool me once. This is a classic issue in systems history,
where better upfront design would have prevented it. The examples
are plenty, there's really no excuse anymore.

>> 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.

The p2p pooled anon secure model is interesting. I think MaidSecure
was the most recent thing making the rounds in this area. Maybe
FreeNet is also similar.

> _______________________________________________
> p2p-hackers mailing list
> [email protected]
> http://lists.zooko.com/mailman/listinfo/p2p-hackers