[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Tor and P2P



Thus spake Nathan Freitas (nathan@xxxxxxxxxxx):

> On 09/26/2012 10:08 AM, meh. wrote:
> > 
> > After implementing the torchat protocol and seeing how bad it is,
> > but how nice the idea is, I started thinking it would be cool to
> > have a more general protocol for P2P use through hidden services.
> 
> This is something we have definitely been considering as a feature or
> add-on to Orbot - essentially mobile-to-mobile file sharing,
> messaging/voice messaging via hidden services.
> 
> While we don't need a very complex p2p design (in short, we are mostly
> just talking about simple HTTP servers running on each device, behind
> a hidden service .onion), I am concerned in the long run about
> scalability and reliability of this. It is not unheard of for apps
> that work well and do something cool to suddently have 1M+ users, and
> already are nearing half that with Orbot.

This is a great point, and I wish I could reply to it and Robert's
comments about DoSing the hsdirs in the same mail.

It would seem that "simple" solutions might end up destroying the Tor
network. Based on Robert's comments, it sounds like the properties we
need are:

1. Persistent hidserv connections. Reconnecting for each message via an
HTTP POST is right out. Way too many circuits+onionskins to scale.

2. Avoid the situation where a single user is creating multiple hidden
services for all their crazy P2P apps.


For 1: It would seem to me that a system that ships a local torified
XMPP server would satisfy this. XMPP is fully decentralized, and
maintains persistent connections between servers. Each user would run
their own server over .onion.

For 2: The resource identifiers of XMPP mean we can connect multiple
XMPP clients to a single local XMPP server, and have them provide
multiple (admittedly linkable) P2P services over XMPP 'streams' without
spinning up additional hidden services for each client app.


XMPP has some obvious downsides... We'd need to audit the whole beast to
make sure the federation+decentralization properties can't be
manipulated to connect to things over non-tor.

It also appears to have the property that social networks where
everybody wants presence notifications for everybody else end up
requiring O(n^2) persistent hidserv connections between the n XMPP
servers... Not sure how serious this is, or if there are any workable
decentralized alternatives.

However, unlike torchat, the XMPP protocol itself is well documented,
widely used, and seems to be designed for a superset of the things we
want. I was able to spend just 10 minutes reviewing the XMPP specs to
fact-check before composing this email:
http://xmpp.org/xmpp-protocols/rfcs/

I was unable to determine if torchat even has property 1 in that time...


-- 
Mike Perry

Attachment: signature.asc
Description: Digital signature

_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk