librelist archives

« back to archive

Serverless Peersm and WebRTC

Serverless Peersm and WebRTC

From:
Aymeric Vitte
Date:
2014-02-20 @ 15:30
Currently Peersm is not a pure P2P system, and to correct a 
misunderstanding, it's not working like Tor, it's implementing the Tor 
protocol and extending it with P2P.

The reason is explained on our (new) site http://www.peersm.com : any 
pure P2P or WebRTC system implies necessarly that at least the sender 
and the receiver know their IP addresses, if not they can not 
communicate, so it's impossible to insure that your anonymity/privacy is 
protected.

Now the problem becomes different if we implement the Tor/Peersm nodes 
and bridges inside the browsers and use WebRTC so they can communicate 
between each other in real P2P using the Tor protocol.

Because that's not a problem that the IP addresses of the nodes are 
public and the anonymity of the users is still insured by the Tor 
protocol on top of WebRTC (solving at the same time WebRTC insecure 
self-signed certificates use for DTLS).

Technically it's already there, this is how Peersm can become serverless 
for the traffic, browsers will handle it, of course some servers are 
needed for the signaling, and... some people must be there with their 
browser open...

Issue (??) the signaling servers can try to track a connection (ie 
suspect that A connected to D via B and C) but won't know what's 
happening next since this is happening inside browsers.

Thoughts?

Regards,

Aymeric

-- 
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

Re: [webp2p] Serverless Peersm and WebRTC

From:
Feross Aboukhadijeh
Date:
2014-03-02 @ 00:54
Hey Aymeric,

Can you elaborate on WebRTC's "insecure self-signed DTLS certificates"? I'm
not aware of any such issue with the WebRTC spec and I'm curious to learn
what you mean.

Thanks,

Feross
✩ blog <http://feross.org/> | ✎ studynotes <http://www.apstudynotes.org/> |☮
webtorrent <http://webtorrent.io/>


On Thu, Feb 20, 2014 at 7:30 AM, Aymeric Vitte <vitteaymeric@gmail.com>wrote:

> Currently Peersm is not a pure P2P system, and to correct a
> misunderstanding, it's not working like Tor, it's implementing the Tor
> protocol and extending it with P2P.
>
> The reason is explained on our (new) site http://www.peersm.com : any
> pure P2P or WebRTC system implies necessarly that at least the sender
> and the receiver know their IP addresses, if not they can not
> communicate, so it's impossible to insure that your anonymity/privacy is
> protected.
>
> Now the problem becomes different if we implement the Tor/Peersm nodes
> and bridges inside the browsers and use WebRTC so they can communicate
> between each other in real P2P using the Tor protocol.
>
> Because that's not a problem that the IP addresses of the nodes are
> public and the anonymity of the users is still insured by the Tor
> protocol on top of WebRTC (solving at the same time WebRTC insecure
> self-signed certificates use for DTLS).
>
> Technically it's already there, this is how Peersm can become serverless
> for the traffic, browsers will handle it, of course some servers are
> needed for the signaling, and... some people must be there with their
> browser open...
>
> Issue (??) the signaling servers can try to track a connection (ie
> suspect that A connected to D via B and C) but won't know what's
> happening next since this is happening inside browsers.
>
> Thoughts?
>
> Regards,
>
> Aymeric
>
> --
> Peersm : http://www.peersm.com
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
>
>

Re: [webp2p] Serverless Peersm and WebRTC

From:
Sam Erb
Date:
2014-03-02 @ 04:03
Hi Feross,
Sorry to jump into this discussion, but I just spent a bunch of time
researching this myself recently. From my understanding, the current spec
is safe from an MiTM as long as the server isn't actively malicious.

When a connection is initiated, during the initial SDP exchange, each peer
will send the other a fingerprint of their self-signed cert. If the server
does not modify this (and the signaling occurs over a secure connection
(https/wss)) then each side can be guaranteed they are connecting with the
other host (that the server said it was connecting you to (ie. alice/bob)
as a fingerprint here is unique to the public key provided and you couldn't
complete the handshake/connection without the private key which matches
that public key).

However, the specification here is not finalized to my knowledge. WebRTC
hopes to provide "Identity Provider's" that each user can trust without
trusting that the signalling server(s) will not modify the SDP. This is
described here -
http://dev.w3.org/2011/webrtc/editor/webrtc.html#identitybut does not
have browser support to my knowledge.

Some relevant browser bugs I was able to find:
https://code.google.com/p/webrtc/issues/detail?id=465#c19 (mentions this
issue)
https://code.google.com/p/webrtc/issues/detail?id=2381 (open Chrome bug for
this issue?)
https://bugzilla.mozilla.org/show_bug.cgi?id=878941 (Firefox already
implemented this?)

Thanks,
Sam



On Sat, Mar 1, 2014 at 7:54 PM, Feross Aboukhadijeh <feross@feross.org>wrote:

> Hey Aymeric,
>
> Can you elaborate on WebRTC's "insecure self-signed DTLS certificates"?
> I'm not aware of any such issue with the WebRTC spec and I'm curious to
> learn what you mean.
>
> Thanks,
>
> Feross
> ✩ blog <http://feross.org/> | ✎ studynotes <http://www.apstudynotes.org/>
> | ☮ webtorrent <http://webtorrent.io/>
>
>
> On Thu, Feb 20, 2014 at 7:30 AM, Aymeric Vitte <vitteaymeric@gmail.com>wrote:
>
>> Currently Peersm is not a pure P2P system, and to correct a
>> misunderstanding, it's not working like Tor, it's implementing the Tor
>> protocol and extending it with P2P.
>>
>> The reason is explained on our (new) site http://www.peersm.com : any
>> pure P2P or WebRTC system implies necessarly that at least the sender
>> and the receiver know their IP addresses, if not they can not
>> communicate, so it's impossible to insure that your anonymity/privacy is
>> protected.
>>
>> Now the problem becomes different if we implement the Tor/Peersm nodes
>> and bridges inside the browsers and use WebRTC so they can communicate
>> between each other in real P2P using the Tor protocol.
>>
>> Because that's not a problem that the IP addresses of the nodes are
>> public and the anonymity of the users is still insured by the Tor
>> protocol on top of WebRTC (solving at the same time WebRTC insecure
>> self-signed certificates use for DTLS).
>>
>> Technically it's already there, this is how Peersm can become serverless
>> for the traffic, browsers will handle it, of course some servers are
>> needed for the signaling, and... some people must be there with their
>> browser open...
>>
>> Issue (??) the signaling servers can try to track a connection (ie
>> suspect that A connected to D via B and C) but won't know what's
>> happening next since this is happening inside browsers.
>>
>> Thoughts?
>>
>> Regards,
>>
>> Aymeric
>>
>> --
>> Peersm : http://www.peersm.com
>> node-Tor : https://www.github.com/Ayms/node-Tor
>> GitHub : https://www.github.com/Ayms
>>
>>
>

Re: [webp2p] Serverless Peersm and WebRTC

From:
Aymeric Vitte
Date:
2014-03-02 @ 09:46
Hi,

Please take a look a this thread from WebCrypto WG: 
http://lists.w3.org/Archives/Public/public-webcrypto/2013Nov/0057.html

I have not yet looked in details what's the plan to really secure this 
in the future (see the link from Richard in the last post), but as it is 
now it's not secure.

For Peersm we don't really care since the peers are not using directly 
WebRTC (see the use case on the site), the plan is for them to implement 
the servers too which will communicate using WebRTC, and then 
communications between them will be secured by the Tor protocol 
mechanism and nodes long term identity key.

Regards

Aymeric

Le 02/03/2014 05:03, Sam Erb a écrit :
> Hi Feross,
> Sorry to jump into this discussion, but I just spent a bunch of time 
> researching this myself recently. From my understanding, the current 
> spec is safe from an MiTM as long as the server isn't actively malicious.
>
> When a connection is initiated, during the initial SDP exchange, each 
> peer will send the other a fingerprint of their self-signed cert. If 
> the server does not modify this (and the signaling occurs over a 
> secure connection (https/wss)) then each side can be guaranteed they 
> are connecting with the other host (that the server said it was 
> connecting you to (ie. alice/bob) as a fingerprint here is unique to 
> the public key provided and you couldn't complete the 
> handshake/connection without the private key which matches that public 
> key).
>
> However, the specification here is not finalized to my knowledge. 
> WebRTC hopes to provide "Identity Provider's" that each user can trust 
> without trusting that the signalling server(s) will not modify the 
> SDP. This is described here - 
> http://dev.w3.org/2011/webrtc/editor/webrtc.html#identity but does not 
> have browser support to my knowledge.
>
> Some relevant browser bugs I was able to find:
> https://code.google.com/p/webrtc/issues/detail?id=465#c19 (mentions 
> this issue)
> https://code.google.com/p/webrtc/issues/detail?id=2381 (open Chrome 
> bug for this issue?)
> https://bugzilla.mozilla.org/show_bug.cgi?id=878941 (Firefox already 
> implemented this?)
>
> Thanks,
> Sam
>
>
> On Sat, Mar 1, 2014 at 7:54 PM, Feross Aboukhadijeh <feross@feross.org 
> <mailto:feross@feross.org>> wrote:
>
>     Hey Aymeric,
>
>     Can you elaborate on WebRTC's "insecure self-signed DTLS
>     certificates"? I'm not aware of any such issue with the WebRTC
>     spec and I'm curious to learn what you mean.
>
>     Thanks,
>
>     Feross
>     ✩ blog <http://feross.org/> | ✎ studynotes
>     <http://www.apstudynotes.org/> | ☮ webtorrent <http://webtorrent.io/>
>
>
>     On Thu, Feb 20, 2014 at 7:30 AM, Aymeric Vitte
>     <vitteaymeric@gmail.com <mailto:vitteaymeric@gmail.com>> wrote:
>
>         Currently Peersm is not a pure P2P system, and to correct a
>         misunderstanding, it's not working like Tor, it's implementing
>         the Tor
>         protocol and extending it with P2P.
>
>         The reason is explained on our (new) site
>         http://www.peersm.com : any
>         pure P2P or WebRTC system implies necessarly that at least the
>         sender
>         and the receiver know their IP addresses, if not they can not
>         communicate, so it's impossible to insure that your
>         anonymity/privacy is
>         protected.
>
>         Now the problem becomes different if we implement the
>         Tor/Peersm nodes
>         and bridges inside the browsers and use WebRTC so they can
>         communicate
>         between each other in real P2P using the Tor protocol.
>
>         Because that's not a problem that the IP addresses of the
>         nodes are
>         public and the anonymity of the users is still insured by the Tor
>         protocol on top of WebRTC (solving at the same time WebRTC
>         insecure
>         self-signed certificates use for DTLS).
>
>         Technically it's already there, this is how Peersm can become
>         serverless
>         for the traffic, browsers will handle it, of course some
>         servers are
>         needed for the signaling, and... some people must be there
>         with their
>         browser open...
>
>         Issue (??) the signaling servers can try to track a connection (ie
>         suspect that A connected to D via B and C) but won't know what's
>         happening next since this is happening inside browsers.
>
>         Thoughts?
>
>         Regards,
>
>         Aymeric
>
>         --
>         Peersm : http://www.peersm.com
>         node-Tor : https://www.github.com/Ayms/node-Tor
>         GitHub : https://www.github.com/Ayms
>
>
>

-- 
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

Re: [webp2p] Serverless Peersm and WebRTC

From:
Hadar Weiss
Date:
2014-03-03 @ 20:37
In any case, if you seek a more anonymous, distributed system why don't you
use p2p signalling?
http://blog.printf.net/articles/2013/05/17/webrtc-without-a-signaling-server/
(as you probably know...)




On Sun, Mar 2, 2014 at 11:46 AM, Aymeric Vitte <vitteaymeric@gmail.com>wrote:

>  Hi,
>
> Please take a look a this thread from WebCrypto WG:
> http://lists.w3.org/Archives/Public/public-webcrypto/2013Nov/0057.html
>
> I have not yet looked in details what's the plan to really secure this in
> the future (see the link from Richard in the last post), but as it is now
> it's not secure.
>
> For Peersm we don't really care since the peers are not using directly
> WebRTC (see the use case on the site), the plan is for them to implement
> the servers too which will communicate using WebRTC, and then
> communications between them will be secured by the Tor protocol mechanism
> and nodes long term identity key.
>
> Regards
>
> Aymeric
>
> Le 02/03/2014 05:03, Sam Erb a écrit :
>
> Hi Feross,
> Sorry to jump into this discussion, but I just spent a bunch of time
> researching this myself recently. From my understanding, the current spec
> is safe from an MiTM as long as the server isn't actively malicious.
>
>  When a connection is initiated, during the initial SDP exchange, each
> peer will send the other a fingerprint of their self-signed cert. If the
> server does not modify this (and the signaling occurs over a secure
> connection (https/wss)) then each side can be guaranteed they are
> connecting with the other host (that the server said it was connecting you
> to (ie. alice/bob) as a fingerprint here is unique to the public key
> provided and you couldn't complete the handshake/connection without the
> private key which matches that public key).
>
>  However, the specification here is not finalized to my knowledge. WebRTC
> hopes to provide "Identity Provider's" that each user can trust without
> trusting that the signalling server(s) will not modify the SDP. This is
> described here - 
http://dev.w3.org/2011/webrtc/editor/webrtc.html#identitybut does not have
browser support to my knowledge.
>
>  Some relevant browser bugs I was able to find:
> https://code.google.com/p/webrtc/issues/detail?id=465#c19 (mentions this
> issue)
>  https://code.google.com/p/webrtc/issues/detail?id=2381 (open Chrome bug
> for this issue?)
>  https://bugzilla.mozilla.org/show_bug.cgi?id=878941 (Firefox already
> implemented this?)
>
>  Thanks,
> Sam
>
>
>
> On Sat, Mar 1, 2014 at 7:54 PM, Feross Aboukhadijeh <feross@feross.org>wrote:
>
>> Hey Aymeric,
>>
>> Can you elaborate on WebRTC's "insecure self-signed DTLS certificates"?
>> I'm not aware of any such issue with the WebRTC spec and I'm curious to
>> learn what you mean.
>>
>> Thanks,
>>
>>  Feross
>> ✩ blog <http://feross.org/> | ✎ studynotes <http://www.apstudynotes.org/>| ☮
>> webtorrent <http://webtorrent.io/>
>>
>>
>> On Thu, Feb 20, 2014 at 7:30 AM, Aymeric Vitte <vitteaymeric@gmail.com>wrote:
>>
>>> Currently Peersm is not a pure P2P system, and to correct a
>>> misunderstanding, it's not working like Tor, it's implementing the Tor
>>> protocol and extending it with P2P.
>>>
>>> The reason is explained on our (new) site http://www.peersm.com : any
>>> pure P2P or WebRTC system implies necessarly that at least the sender
>>> and the receiver know their IP addresses, if not they can not
>>> communicate, so it's impossible to insure that your anonymity/privacy is
>>> protected.
>>>
>>> Now the problem becomes different if we implement the Tor/Peersm nodes
>>> and bridges inside the browsers and use WebRTC so they can communicate
>>> between each other in real P2P using the Tor protocol.
>>>
>>> Because that's not a problem that the IP addresses of the nodes are
>>> public and the anonymity of the users is still insured by the Tor
>>> protocol on top of WebRTC (solving at the same time WebRTC insecure
>>> self-signed certificates use for DTLS).
>>>
>>> Technically it's already there, this is how Peersm can become serverless
>>> for the traffic, browsers will handle it, of course some servers are
>>> needed for the signaling, and... some people must be there with their
>>> browser open...
>>>
>>> Issue (??) the signaling servers can try to track a connection (ie
>>> suspect that A connected to D via B and C) but won't know what's
>>> happening next since this is happening inside browsers.
>>>
>>> Thoughts?
>>>
>>> Regards,
>>>
>>> Aymeric
>>>
>>> --
>>> Peersm : http://www.peersm.com
>>> node-Tor : https://www.github.com/Ayms/node-Tor
>>> GitHub : https://www.github.com/Ayms
>>>
>>>
>>
>
> --
> Peersm : http://www.peersm.com
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
>
>

Re: [webp2p] Serverless Peersm and WebRTC

From:
piranna@gmail.com
Date:
2014-03-03 @ 21:00
The problem with that P2P signaling by human beings is that it doesn't
scale very well... :-/ I'm working WebP2P.io, a server-agnostic encrypted
signaling channel, but I don't have all the time I would like to work on
it, so development is slow.

Send from my Samsung Galaxy Note II
El 03/03/2014 21:37, "Hadar Weiss" <whadar@gmail.com> escribió:

> In any case, if you seek a more anonymous, distributed system why don't
> you use p2p signalling?
>
> http://blog.printf.net/articles/2013/05/17/webrtc-without-a-signaling-server/
> (as you probably know...)
>
>
>
>
> On Sun, Mar 2, 2014 at 11:46 AM, Aymeric Vitte <vitteaymeric@gmail.com>wrote:
>
>>  Hi,
>>
>> Please take a look a this thread from WebCrypto WG:
>> http://lists.w3.org/Archives/Public/public-webcrypto/2013Nov/0057.html
>>
>> I have not yet looked in details what's the plan to really secure this in
>> the future (see the link from Richard in the last post), but as it is now
>> it's not secure.
>>
>> For Peersm we don't really care since the peers are not using directly
>> WebRTC (see the use case on the site), the plan is for them to implement
>> the servers too which will communicate using WebRTC, and then
>> communications between them will be secured by the Tor protocol mechanism
>> and nodes long term identity key.
>>
>> Regards
>>
>> Aymeric
>>
>> Le 02/03/2014 05:03, Sam Erb a écrit :
>>
>> Hi Feross,
>> Sorry to jump into this discussion, but I just spent a bunch of time
>> researching this myself recently. From my understanding, the current spec
>> is safe from an MiTM as long as the server isn't actively malicious.
>>
>>  When a connection is initiated, during the initial SDP exchange, each
>> peer will send the other a fingerprint of their self-signed cert. If the
>> server does not modify this (and the signaling occurs over a secure
>> connection (https/wss)) then each side can be guaranteed they are
>> connecting with the other host (that the server said it was connecting you
>> to (ie. alice/bob) as a fingerprint here is unique to the public key
>> provided and you couldn't complete the handshake/connection without the
>> private key which matches that public key).
>>
>>  However, the specification here is not finalized to my knowledge.
>> WebRTC hopes to provide "Identity Provider's" that each user can trust
>> without trusting that the signalling server(s) will not modify the SDP.
>> This is described here -
>> http://dev.w3.org/2011/webrtc/editor/webrtc.html#identity but does not
>> have browser support to my knowledge.
>>
>>  Some relevant browser bugs I was able to find:
>> https://code.google.com/p/webrtc/issues/detail?id=465#c19 (mentions this
>> issue)
>>  https://code.google.com/p/webrtc/issues/detail?id=2381 (open Chrome bug
>> for this issue?)
>>  https://bugzilla.mozilla.org/show_bug.cgi?id=878941 (Firefox already
>> implemented this?)
>>
>>  Thanks,
>> Sam
>>
>>
>>
>> On Sat, Mar 1, 2014 at 7:54 PM, Feross Aboukhadijeh <feross@feross.org>wrote:
>>
>>> Hey Aymeric,
>>>
>>> Can you elaborate on WebRTC's "insecure self-signed DTLS certificates"?
>>> I'm not aware of any such issue with the WebRTC spec and I'm curious to
>>> learn what you mean.
>>>
>>> Thanks,
>>>
>>>  Feross
>>> ✩ blog <http://feross.org/> | ✎ studynotes<http://www.apstudynotes.org/>| ☮
>>> webtorrent <http://webtorrent.io/>
>>>
>>>
>>> On Thu, Feb 20, 2014 at 7:30 AM, Aymeric Vitte <vitteaymeric@gmail.com>wrote:
>>>
>>>> Currently Peersm is not a pure P2P system, and to correct a
>>>> misunderstanding, it's not working like Tor, it's implementing the Tor
>>>> protocol and extending it with P2P.
>>>>
>>>> The reason is explained on our (new) site http://www.peersm.com : any
>>>> pure P2P or WebRTC system implies necessarly that at least the sender
>>>> and the receiver know their IP addresses, if not they can not
>>>> communicate, so it's impossible to insure that your anonymity/privacy is
>>>> protected.
>>>>
>>>> Now the problem becomes different if we implement the Tor/Peersm nodes
>>>> and bridges inside the browsers and use WebRTC so they can communicate
>>>> between each other in real P2P using the Tor protocol.
>>>>
>>>> Because that's not a problem that the IP addresses of the nodes are
>>>> public and the anonymity of the users is still insured by the Tor
>>>> protocol on top of WebRTC (solving at the same time WebRTC insecure
>>>> self-signed certificates use for DTLS).
>>>>
>>>> Technically it's already there, this is how Peersm can become serverless
>>>> for the traffic, browsers will handle it, of course some servers are
>>>> needed for the signaling, and... some people must be there with their
>>>> browser open...
>>>>
>>>> Issue (??) the signaling servers can try to track a connection (ie
>>>> suspect that A connected to D via B and C) but won't know what's
>>>> happening next since this is happening inside browsers.
>>>>
>>>> Thoughts?
>>>>
>>>> Regards,
>>>>
>>>> Aymeric
>>>>
>>>> --
>>>> Peersm : http://www.peersm.com
>>>> node-Tor : https://www.github.com/Ayms/node-Tor
>>>> GitHub : https://www.github.com/Ayms
>>>>
>>>>
>>>
>>
>> --
>> Peersm : http://www.peersm.com
>> node-Tor : https://www.github.com/Ayms/node-Tor
>> GitHub : https://www.github.com/Ayms
>>
>>
>

Re: [webp2p] Serverless Peersm and WebRTC

From:
Hadar Weiss
Date:
2014-03-03 @ 21:07
Why not? It should scale better than server-based signalling.
On Mar 3, 2014 11:01 PM, "piranna@gmail.com" <piranna@gmail.com> wrote:

> The problem with that P2P signaling by human beings is that it doesn't
> scale very well... :-/ I'm working WebP2P.io, a server-agnostic encrypted
> signaling channel, but I don't have all the time I would like to work on
> it, so development is slow.
>
> Send from my Samsung Galaxy Note II
> El 03/03/2014 21:37, "Hadar Weiss" <whadar@gmail.com> escribió:
>
>> In any case, if you seek a more anonymous, distributed system why don't
>> you use p2p signalling?
>>
>> http://blog.printf.net/articles/2013/05/17/webrtc-without-a-signaling-server/
>> (as you probably know...)
>>
>>
>>
>>
>> On Sun, Mar 2, 2014 at 11:46 AM, Aymeric Vitte <vitteaymeric@gmail.com>wrote:
>>
>>>  Hi,
>>>
>>> Please take a look a this thread from WebCrypto WG:
>>> http://lists.w3.org/Archives/Public/public-webcrypto/2013Nov/0057.html
>>>
>>> I have not yet looked in details what's the plan to really secure this
>>> in the future (see the link from Richard in the last post), but as it is
>>> now it's not secure.
>>>
>>> For Peersm we don't really care since the peers are not using directly
>>> WebRTC (see the use case on the site), the plan is for them to implement
>>> the servers too which will communicate using WebRTC, and then
>>> communications between them will be secured by the Tor protocol mechanism
>>> and nodes long term identity key.
>>>
>>> Regards
>>>
>>> Aymeric
>>>
>>> Le 02/03/2014 05:03, Sam Erb a écrit :
>>>
>>> Hi Feross,
>>> Sorry to jump into this discussion, but I just spent a bunch of time
>>> researching this myself recently. From my understanding, the current spec
>>> is safe from an MiTM as long as the server isn't actively malicious.
>>>
>>>  When a connection is initiated, during the initial SDP exchange, each
>>> peer will send the other a fingerprint of their self-signed cert. If the
>>> server does not modify this (and the signaling occurs over a secure
>>> connection (https/wss)) then each side can be guaranteed they are
>>> connecting with the other host (that the server said it was connecting you
>>> to (ie. alice/bob) as a fingerprint here is unique to the public key
>>> provided and you couldn't complete the handshake/connection without the
>>> private key which matches that public key).
>>>
>>>  However, the specification here is not finalized to my knowledge.
>>> WebRTC hopes to provide "Identity Provider's" that each user can trust
>>> without trusting that the signalling server(s) will not modify the SDP.
>>> This is described here -
>>> http://dev.w3.org/2011/webrtc/editor/webrtc.html#identity but does not
>>> have browser support to my knowledge.
>>>
>>>  Some relevant browser bugs I was able to find:
>>> https://code.google.com/p/webrtc/issues/detail?id=465#c19 (mentions
>>> this issue)
>>>  https://code.google.com/p/webrtc/issues/detail?id=2381 (open Chrome
>>> bug for this issue?)
>>>  https://bugzilla.mozilla.org/show_bug.cgi?id=878941 (Firefox already
>>> implemented this?)
>>>
>>>  Thanks,
>>> Sam
>>>
>>>
>>>
>>> On Sat, Mar 1, 2014 at 7:54 PM, Feross Aboukhadijeh <feross@feross.org>wrote:
>>>
>>>> Hey Aymeric,
>>>>
>>>> Can you elaborate on WebRTC's "insecure self-signed DTLS certificates"?
>>>> I'm not aware of any such issue with the WebRTC spec and I'm curious to
>>>> learn what you mean.
>>>>
>>>> Thanks,
>>>>
>>>>  Feross
>>>> ✩ blog <http://feross.org/> | ✎ studynotes<http://www.apstudynotes.org/>| ☮
>>>> webtorrent <http://webtorrent.io/>
>>>>
>>>>
>>>> On Thu, Feb 20, 2014 at 7:30 AM, Aymeric Vitte <vitteaymeric@gmail.com>wrote:
>>>>
>>>>> Currently Peersm is not a pure P2P system, and to correct a
>>>>> misunderstanding, it's not working like Tor, it's implementing the Tor
>>>>> protocol and extending it with P2P.
>>>>>
>>>>> The reason is explained on our (new) site http://www.peersm.com : any
>>>>> pure P2P or WebRTC system implies necessarly that at least the sender
>>>>> and the receiver know their IP addresses, if not they can not
>>>>> communicate, so it's impossible to insure that your anonymity/privacy
>>>>> is
>>>>> protected.
>>>>>
>>>>> Now the problem becomes different if we implement the Tor/Peersm nodes
>>>>> and bridges inside the browsers and use WebRTC so they can communicate
>>>>> between each other in real P2P using the Tor protocol.
>>>>>
>>>>> Because that's not a problem that the IP addresses of the nodes are
>>>>> public and the anonymity of the users is still insured by the Tor
>>>>> protocol on top of WebRTC (solving at the same time WebRTC insecure
>>>>> self-signed certificates use for DTLS).
>>>>>
>>>>> Technically it's already there, this is how Peersm can become
>>>>> serverless
>>>>> for the traffic, browsers will handle it, of course some servers are
>>>>> needed for the signaling, and... some people must be there with their
>>>>> browser open...
>>>>>
>>>>> Issue (??) the signaling servers can try to track a connection (ie
>>>>> suspect that A connected to D via B and C) but won't know what's
>>>>> happening next since this is happening inside browsers.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Aymeric
>>>>>
>>>>> --
>>>>> Peersm : http://www.peersm.com
>>>>> node-Tor : https://www.github.com/Ayms/node-Tor
>>>>> GitHub : https://www.github.com/Ayms
>>>>>
>>>>>
>>>>
>>>
>>> --
>>> Peersm : http://www.peersm.com
>>> node-Tor : https://www.github.com/Ayms/node-Tor
>>> GitHub : https://www.github.com/Ayms
>>>
>>>
>>

Re: [webp2p] Serverless Peersm and WebRTC

From:
piranna@gmail.com
Date:
2014-03-03 @ 21:17
SDPs are short-living, so you can't have a list like the ones of IPs:ports
on eMule or Gnutella to do bootstrapping. You need to find to another peer
already connected to the P2P network, interchange SDPs... too much user
interaction.

A think a better aproach would be to use websocket-based proxies to the P2P
network both connecting to other already connected peers or directly
(working themselves as peers), so you can connect to them to bootstrap on
the network and later use DataChannels to look for new peers. This is the
aproach I'm doing on my signaling library.

Send from my Samsung Galaxy Note II
El 03/03/2014 22:07, "Hadar Weiss" <whadar@gmail.com> escribió:

> Why not? It should scale better than server-based signalling.
> On Mar 3, 2014 11:01 PM, "piranna@gmail.com" <piranna@gmail.com> wrote:
>
>> The problem with that P2P signaling by human beings is that it doesn't
>> scale very well... :-/ I'm working WebP2P.io, a server-agnostic encrypted
>> signaling channel, but I don't have all the time I would like to work on
>> it, so development is slow.
>>
>> Send from my Samsung Galaxy Note II
>> El 03/03/2014 21:37, "Hadar Weiss" <whadar@gmail.com> escribió:
>>
>>> In any case, if you seek a more anonymous, distributed system why don't
>>> you use p2p signalling?
>>>
>>> http://blog.printf.net/articles/2013/05/17/webrtc-without-a-signaling-server/
>>> (as you probably know...)
>>>
>>>
>>>
>>>
>>> On Sun, Mar 2, 2014 at 11:46 AM, Aymeric Vitte <vitteaymeric@gmail.com>wrote:
>>>
>>>>  Hi,
>>>>
>>>> Please take a look a this thread from WebCrypto WG:
>>>> http://lists.w3.org/Archives/Public/public-webcrypto/2013Nov/0057.html
>>>>
>>>> I have not yet looked in details what's the plan to really secure this
>>>> in the future (see the link from Richard in the last post), but as it is
>>>> now it's not secure.
>>>>
>>>> For Peersm we don't really care since the peers are not using directly
>>>> WebRTC (see the use case on the site), the plan is for them to implement
>>>> the servers too which will communicate using WebRTC, and then
>>>> communications between them will be secured by the Tor protocol mechanism
>>>> and nodes long term identity key.
>>>>
>>>> Regards
>>>>
>>>> Aymeric
>>>>
>>>> Le 02/03/2014 05:03, Sam Erb a écrit :
>>>>
>>>> Hi Feross,
>>>> Sorry to jump into this discussion, but I just spent a bunch of time
>>>> researching this myself recently. From my understanding, the current spec
>>>> is safe from an MiTM as long as the server isn't actively malicious.
>>>>
>>>>  When a connection is initiated, during the initial SDP exchange, each
>>>> peer will send the other a fingerprint of their self-signed cert. If the
>>>> server does not modify this (and the signaling occurs over a secure
>>>> connection (https/wss)) then each side can be guaranteed they are
>>>> connecting with the other host (that the server said it was connecting you
>>>> to (ie. alice/bob) as a fingerprint here is unique to the public key
>>>> provided and you couldn't complete the handshake/connection without the
>>>> private key which matches that public key).
>>>>
>>>>  However, the specification here is not finalized to my knowledge.
>>>> WebRTC hopes to provide "Identity Provider's" that each user can trust
>>>> without trusting that the signalling server(s) will not modify the SDP.
>>>> This is described here -
>>>> http://dev.w3.org/2011/webrtc/editor/webrtc.html#identity but does not
>>>> have browser support to my knowledge.
>>>>
>>>>  Some relevant browser bugs I was able to find:
>>>> https://code.google.com/p/webrtc/issues/detail?id=465#c19 (mentions
>>>> this issue)
>>>>  https://code.google.com/p/webrtc/issues/detail?id=2381 (open Chrome
>>>> bug for this issue?)
>>>>  https://bugzilla.mozilla.org/show_bug.cgi?id=878941 (Firefox already
>>>> implemented this?)
>>>>
>>>>  Thanks,
>>>> Sam
>>>>
>>>>
>>>>
>>>> On Sat, Mar 1, 2014 at 7:54 PM, Feross Aboukhadijeh <feross@feross.org>wrote:
>>>>
>>>>> Hey Aymeric,
>>>>>
>>>>> Can you elaborate on WebRTC's "insecure self-signed DTLS
>>>>> certificates"? I'm not aware of any such issue with the WebRTC spec and I'm
>>>>> curious to learn what you mean.
>>>>>
>>>>> Thanks,
>>>>>
>>>>>  Feross
>>>>> ✩ blog <http://feross.org/> | ✎ studynotes<http://www.apstudynotes.org/>| ☮
>>>>> webtorrent <http://webtorrent.io/>
>>>>>
>>>>>
>>>>> On Thu, Feb 20, 2014 at 7:30 AM, Aymeric Vitte <vitteaymeric@gmail.com
>>>>> > wrote:
>>>>>
>>>>>> Currently Peersm is not a pure P2P system, and to correct a
>>>>>> misunderstanding, it's not working like Tor, it's implementing the Tor
>>>>>> protocol and extending it with P2P.
>>>>>>
>>>>>> The reason is explained on our (new) site http://www.peersm.com : any
>>>>>> pure P2P or WebRTC system implies necessarly that at least the sender
>>>>>> and the receiver know their IP addresses, if not they can not
>>>>>> communicate, so it's impossible to insure that your anonymity/privacy
>>>>>> is
>>>>>> protected.
>>>>>>
>>>>>> Now the problem becomes different if we implement the Tor/Peersm nodes
>>>>>> and bridges inside the browsers and use WebRTC so they can communicate
>>>>>> between each other in real P2P using the Tor protocol.
>>>>>>
>>>>>> Because that's not a problem that the IP addresses of the nodes are
>>>>>> public and the anonymity of the users is still insured by the Tor
>>>>>> protocol on top of WebRTC (solving at the same time WebRTC insecure
>>>>>> self-signed certificates use for DTLS).
>>>>>>
>>>>>> Technically it's already there, this is how Peersm can become
>>>>>> serverless
>>>>>> for the traffic, browsers will handle it, of course some servers are
>>>>>> needed for the signaling, and... some people must be there with their
>>>>>> browser open...
>>>>>>
>>>>>> Issue (??) the signaling servers can try to track a connection (ie
>>>>>> suspect that A connected to D via B and C) but won't know what's
>>>>>> happening next since this is happening inside browsers.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Aymeric
>>>>>>
>>>>>> --
>>>>>> Peersm : http://www.peersm.com
>>>>>> node-Tor : https://www.github.com/Ayms/node-Tor
>>>>>> GitHub : https://www.github.com/Ayms
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Peersm : http://www.peersm.com
>>>> node-Tor : https://www.github.com/Ayms/node-Tor
>>>> GitHub : https://www.github.com/Ayms
>>>>
>>>>
>>>

Re: [webp2p] Serverless Peersm and WebRTC

From:
Will Scott
Date:
2014-03-03 @ 21:30
I've got a public matchmaking websocket server running for those who want
something to hit against:

Source: https://github.com/freedomjs/socialrouter
Running: wss://p2pbr.com/route/

Chat Client Demo: https://homes.cs.washington.edu/~wrs/demo/chat
File Transfer Client Demo:
https://homes.cs.washington.edu/~wrs/demo/filedrop/

Existing social networks are another pretty reasonable possibility. You can
do oAuth with a bunch of existing networks to help users form connections
without your own infrastructure.

--WIll


On Mon, Mar 3, 2014 at 1:17 PM, piranna@gmail.com <piranna@gmail.com> wrote:

> SDPs are short-living, so you can't have a list like the ones of IPs:ports
> on eMule or Gnutella to do bootstrapping. You need to find to another peer
> already connected to the P2P network, interchange SDPs... too much user
> interaction.
>
> A think a better aproach would be to use websocket-based proxies to the
> P2P network both connecting to other already connected peers or directly
> (working themselves as peers), so you can connect to them to bootstrap on
> the network and later use DataChannels to look for new peers. This is the
> aproach I'm doing on my signaling library.
>
> Send from my Samsung Galaxy Note II
> El 03/03/2014 22:07, "Hadar Weiss" <whadar@gmail.com> escribió:
>
> Why not? It should scale better than server-based signalling.
>> On Mar 3, 2014 11:01 PM, "piranna@gmail.com" <piranna@gmail.com> wrote:
>>
>>> The problem with that P2P signaling by human beings is that it doesn't
>>> scale very well... :-/ I'm working WebP2P.io, a server-agnostic encrypted
>>> signaling channel, but I don't have all the time I would like to work on
>>> it, so development is slow.
>>>
>>> Send from my Samsung Galaxy Note II
>>> El 03/03/2014 21:37, "Hadar Weiss" <whadar@gmail.com> escribió:
>>>
>>>> In any case, if you seek a more anonymous, distributed system why don't
>>>> you use p2p signalling?
>>>>
>>>> http://blog.printf.net/articles/2013/05/17/webrtc-without-a-signaling-server/
>>>> (as you probably know...)
>>>>
>>>>
>>>>
>>>>
>>>> On Sun, Mar 2, 2014 at 11:46 AM, Aymeric Vitte <vitteaymeric@gmail.com>wrote:
>>>>
>>>>>  Hi,
>>>>>
>>>>> Please take a look a this thread from WebCrypto WG:
>>>>> http://lists.w3.org/Archives/Public/public-webcrypto/2013Nov/0057.html
>>>>>
>>>>> I have not yet looked in details what's the plan to really secure this
>>>>> in the future (see the link from Richard in the last post), but as it is
>>>>> now it's not secure.
>>>>>
>>>>> For Peersm we don't really care since the peers are not using directly
>>>>> WebRTC (see the use case on the site), the plan is for them to implement
>>>>> the servers too which will communicate using WebRTC, and then
>>>>> communications between them will be secured by the Tor protocol mechanism
>>>>> and nodes long term identity key.
>>>>>
>>>>> Regards
>>>>>
>>>>> Aymeric
>>>>>
>>>>> Le 02/03/2014 05:03, Sam Erb a écrit :
>>>>>
>>>>> Hi Feross,
>>>>> Sorry to jump into this discussion, but I just spent a bunch of time
>>>>> researching this myself recently. From my understanding, the current spec
>>>>> is safe from an MiTM as long as the server isn't actively malicious.
>>>>>
>>>>>  When a connection is initiated, during the initial SDP exchange,
>>>>> each peer will send the other a fingerprint of their self-signed cert. If
>>>>> the server does not modify this (and the signaling occurs over a secure
>>>>> connection (https/wss)) then each side can be guaranteed they are
>>>>> connecting with the other host (that the server said it was connecting you
>>>>> to (ie. alice/bob) as a fingerprint here is unique to the public key
>>>>> provided and you couldn't complete the handshake/connection without the
>>>>> private key which matches that public key).
>>>>>
>>>>>  However, the specification here is not finalized to my knowledge.
>>>>> WebRTC hopes to provide "Identity Provider's" that each user can trust
>>>>> without trusting that the signalling server(s) will not modify the SDP.
>>>>> This is described here -
>>>>> http://dev.w3.org/2011/webrtc/editor/webrtc.html#identity but does
>>>>> not have browser support to my knowledge.
>>>>>
>>>>>  Some relevant browser bugs I was able to find:
>>>>> https://code.google.com/p/webrtc/issues/detail?id=465#c19 (mentions
>>>>> this issue)
>>>>>  https://code.google.com/p/webrtc/issues/detail?id=2381 (open Chrome
>>>>> bug for this issue?)
>>>>>  https://bugzilla.mozilla.org/show_bug.cgi?id=878941 (Firefox already
>>>>> implemented this?)
>>>>>
>>>>>  Thanks,
>>>>> Sam
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Mar 1, 2014 at 7:54 PM, Feross Aboukhadijeh <feross@feross.org
>>>>> > wrote:
>>>>>
>>>>>> Hey Aymeric,
>>>>>>
>>>>>> Can you elaborate on WebRTC's "insecure self-signed DTLS
>>>>>> certificates"? I'm not aware of any such issue with the WebRTC spec and I'm
>>>>>> curious to learn what you mean.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>  Feross
>>>>>> ✩ blog <http://feross.org/> | ✎ studynotes<http://www.apstudynotes.org/>| ☮
>>>>>> webtorrent <http://webtorrent.io/>
>>>>>>
>>>>>>
>>>>>> On Thu, Feb 20, 2014 at 7:30 AM, Aymeric Vitte <
>>>>>> vitteaymeric@gmail.com> wrote:
>>>>>>
>>>>>>> Currently Peersm is not a pure P2P system, and to correct a
>>>>>>> misunderstanding, it's not working like Tor, it's implementing the
>>>>>>> Tor
>>>>>>> protocol and extending it with P2P.
>>>>>>>
>>>>>>> The reason is explained on our (new) site http://www.peersm.com :
>>>>>>> any
>>>>>>> pure P2P or WebRTC system implies necessarly that at least the sender
>>>>>>> and the receiver know their IP addresses, if not they can not
>>>>>>> communicate, so it's impossible to insure that your
>>>>>>> anonymity/privacy is
>>>>>>> protected.
>>>>>>>
>>>>>>> Now the problem becomes different if we implement the Tor/Peersm
>>>>>>> nodes
>>>>>>> and bridges inside the browsers and use WebRTC so they can
>>>>>>> communicate
>>>>>>> between each other in real P2P using the Tor protocol.
>>>>>>>
>>>>>>> Because that's not a problem that the IP addresses of the nodes are
>>>>>>> public and the anonymity of the users is still insured by the Tor
>>>>>>> protocol on top of WebRTC (solving at the same time WebRTC insecure
>>>>>>> self-signed certificates use for DTLS).
>>>>>>>
>>>>>>> Technically it's already there, this is how Peersm can become
>>>>>>> serverless
>>>>>>> for the traffic, browsers will handle it, of course some servers are
>>>>>>> needed for the signaling, and... some people must be there with their
>>>>>>> browser open...
>>>>>>>
>>>>>>> Issue (??) the signaling servers can try to track a connection (ie
>>>>>>> suspect that A connected to D via B and C) but won't know what's
>>>>>>> happening next since this is happening inside browsers.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Aymeric
>>>>>>>
>>>>>>> --
>>>>>>> Peersm : http://www.peersm.com
>>>>>>> node-Tor : https://www.github.com/Ayms/node-Tor
>>>>>>> GitHub : https://www.github.com/Ayms
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Peersm : http://www.peersm.com
>>>>> node-Tor : https://www.github.com/Ayms/node-Tor
>>>>> GitHub : https://www.github.com/Ayms
>>>>>
>>>>>
>>>>

Re: [webp2p] Serverless Peersm and WebRTC

From:
piranna@gmail.com
Date:
2014-03-04 @ 08:10
> I've got a public matchmaking websocket server running for those who want
> something to hit against:
>
> Source: https://github.com/freedomjs/socialrouter
> Running: wss://p2pbr.com/route/
>
Lol! We got the same idea, only mine in Node.js :-P

https://github.com/piranna/Schuko

It was working at my old job three months without downtime, but AFAIK
it's still alive and kicking :-D


> Existing social networks are another pretty reasonable possibility. You can
> do oAuth with a bunch of existing networks to help users form connections
> without your own infrastructure.
>
I was thinking using Twitter to send SDPs, but it's not secure enough.
But when having a working encrypted signaling channel ready to use, it
would be interesting to investigate to use another existing Twitter or
Facebook or another messaging systems :-)


-- 
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix."
- Linus Tordvals, creador del sistema operativo Linux

Re: [webp2p] Serverless Peersm and WebRTC

From:
Shachar Zohar
Date:
2014-03-04 @ 08:23
What about https://telegram.org/ or http://www.snapchat.com/ instead of
Twitter


On Tue, Mar 4, 2014 at 10:10 AM, piranna@gmail.com <piranna@gmail.com>wrote:

> > I've got a public matchmaking websocket server running for those who want
> > something to hit against:
> >
> > Source: https://github.com/freedomjs/socialrouter
> > Running: wss://p2pbr.com/route/
> >
> Lol! We got the same idea, only mine in Node.js :-P
>
> https://github.com/piranna/Schuko
>
> It was working at my old job three months without downtime, but AFAIK
> it's still alive and kicking :-D
>
>
> > Existing social networks are another pretty reasonable possibility. You
> can
> > do oAuth with a bunch of existing networks to help users form connections
> > without your own infrastructure.
> >
> I was thinking using Twitter to send SDPs, but it's not secure enough.
> But when having a working encrypted signaling channel ready to use, it
> would be interesting to investigate to use another existing Twitter or
> Facebook or another messaging systems :-)
>
>
> --
> "Si quieres viajar alrededor del mundo y ser invitado a hablar en un
> monton de sitios diferentes, simplemente escribe un sistema operativo
> Unix."
> - Linus Tordvals, creador del sistema operativo Linux
>

Re: [webp2p] Serverless Peersm and WebRTC

From:
piranna@gmail.com
Date:
2014-03-04 @ 08:31
I was using anonimous XMPP servers, but I was only able to find one from
Jappix and they removed anonimous access last May :-( If someone know some
of them I will heartly thanks him :-)

Send from my Samsung Galaxy Note II
El 04/03/2014 09:24, "Shachar Zohar" <shacharz@gmail.com> escribió:

> What about https://telegram.org/ or http://www.snapchat.com/ instead of
> Twitter
>
>
> On Tue, Mar 4, 2014 at 10:10 AM, piranna@gmail.com <piranna@gmail.com>wrote:
>
>> > I've got a public matchmaking websocket server running for those who
>> want
>> > something to hit against:
>> >
>> > Source: https://github.com/freedomjs/socialrouter
>> > Running: wss://p2pbr.com/route/
>> >
>> Lol! We got the same idea, only mine in Node.js :-P
>>
>> https://github.com/piranna/Schuko
>>
>> It was working at my old job three months without downtime, but AFAIK
>> it's still alive and kicking :-D
>>
>>
>> > Existing social networks are another pretty reasonable possibility. You
>> can
>> > do oAuth with a bunch of existing networks to help users form
>> connections
>> > without your own infrastructure.
>> >
>> I was thinking using Twitter to send SDPs, but it's not secure enough.
>> But when having a working encrypted signaling channel ready to use, it
>> would be interesting to investigate to use another existing Twitter or
>> Facebook or another messaging systems :-)
>>
>>
>> --
>> "Si quieres viajar alrededor del mundo y ser invitado a hablar en un
>> monton de sitios diferentes, simplemente escribe un sistema operativo
>> Unix."
>> - Linus Tordvals, creador del sistema operativo Linux
>>
>
>

Re: [webp2p] Serverless Peersm and WebRTC

From:
Aymeric Vitte
Date:
2014-03-04 @ 11:03
Hi,

Interesting but:

As far as I understand to do a "serverless" WebRTC P2P, you can:

- manually exchange SDPs (chat or other)
- do the same using social networks
- use a server (ws or other) where the peers are connected to so they 
can exchange SDPs

The first two options are really serverless but it seems unlikely that 
you can scale that or make it automatic, peers have to know each other.

The third one is using at least a server, so it's not serverless.

In a large P2P system it seems impossible to have something serverless 
(again I would love to be wrong) because you need something to connect 
the peers.

And in any case no solution (except specific mechanisms like Peersm) can 
insure anonymity.

Piranna --> why is your webp2p.io project anonymous? Maybe it depends on 
your definition of anonymous, but here the peers know each other, so 
it's not anonymous, you need a server that knows what the peers are 
doing, not anonymous again, and probably you need STUN servers, not 
anonymous either... unless I am misunderstanding the project.

Regards

Aymeric

Le 04/03/2014 09:31, piranna@gmail.com a écrit :
>
> I was using anonimous XMPP servers, but I was only able to find one 
> from Jappix and they removed anonimous access last May :-( If someone 
> know some of them I will heartly thanks him :-)
>
> Send from my Samsung Galaxy Note II
>
> El 04/03/2014 09:24, "Shachar Zohar" <shacharz@gmail.com 
> <mailto:shacharz@gmail.com>> escribió:
>
>     What about https://telegram.org/ or http://www.snapchat.com/
>     instead of Twitter
>
>
>     On Tue, Mar 4, 2014 at 10:10 AM, piranna@gmail.com
>     <mailto:piranna@gmail.com> <piranna@gmail.com
>     <mailto:piranna@gmail.com>> wrote:
>
>         > I've got a public matchmaking websocket server running for
>         those who want
>         > something to hit against:
>         >
>         > Source: https://github.com/freedomjs/socialrouter
>         > Running: wss://p2pbr.com/route/ <http://p2pbr.com/route/>
>         >
>         Lol! We got the same idea, only mine in Node.js :-P
>
>         https://github.com/piranna/Schuko
>
>         It was working at my old job three months without downtime,
>         but AFAIK
>         it's still alive and kicking :-D
>
>
>         > Existing social networks are another pretty reasonable
>         possibility. You can
>         > do oAuth with a bunch of existing networks to help users
>         form connections
>         > without your own infrastructure.
>         >
>         I was thinking using Twitter to send SDPs, but it's not secure
>         enough.
>         But when having a working encrypted signaling channel ready to
>         use, it
>         would be interesting to investigate to use another existing
>         Twitter or
>         Facebook or another messaging systems :-)
>
>
>         --
>         "Si quieres viajar alrededor del mundo y ser invitado a hablar
>         en un
>         monton de sitios diferentes, simplemente escribe un sistema
>         operativo
>         Unix."
>         - Linus Tordvals, creador del sistema operativo Linux
>
>

-- 
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

Re: [webp2p] Serverless Peersm and WebRTC

From:
Feross Aboukhadijeh
Date:
2014-03-04 @ 11:21
Say I want to talk to user A. If I'm connected to B, and B is connected to
A, then it's possible without a central server. I simply ask B for an
introduction to A. B will handle exchanging our SDPs in lieu of a central
server.

The only time you need a central server is for initial bootstrapping. You
can run multiple bootstrap nodes for redundancy like bittorrent does for
the bootstrap DHT nodes. My client has 3 hardcoded DHT bootstrap nodes last
I checked. But after that you should be good.

Feross
✩ blog <http://feross.org/> | ✎ studynotes <http://www.apstudynotes.org/> |☮
webtorrent <http://webtorrent.io/>


On Tue, Mar 4, 2014 at 3:03 AM, Aymeric Vitte <vitteaymeric@gmail.com>wrote:

>  Hi,
>
> Interesting but:
>
> As far as I understand to do a "serverless" WebRTC P2P, you can:
>
> - manually exchange SDPs (chat or other)
> - do the same using social networks
> - use a server (ws or other) where the peers are connected to so they can
> exchange SDPs
>
> The first two options are really serverless but it seems unlikely that you
> can scale that or make it automatic, peers have to know each other.
>
> The third one is using at least a server, so it's not serverless.
>
> In a large P2P system it seems impossible to have something serverless
> (again I would love to be wrong) because you need something to connect the
> peers.
>
> And in any case no solution (except specific mechanisms like Peersm) can
> insure anonymity.
>
> Piranna --> why is your webp2p.io project anonymous? Maybe it depends on
> your definition of anonymous, but here the peers know each other, so it's
> not anonymous, you need a server that knows what the peers are doing, not
> anonymous again, and probably you need STUN servers, not anonymous
> either... unless I am misunderstanding the project.
>
> Regards
>
> Aymeric
>
> Le 04/03/2014 09:31, piranna@gmail.com a écrit :
>
> I was using anonimous XMPP servers, but I was only able to find one from
> Jappix and they removed anonimous access last May :-( If someone know some
> of them I will heartly thanks him :-)
>
> Send from my Samsung Galaxy Note II
> El 04/03/2014 09:24, "Shachar Zohar" <shacharz@gmail.com> escribió:
>
>> What about https://telegram.org/ or http://www.snapchat.com/ instead of
>> Twitter
>>
>>
>>  On Tue, Mar 4, 2014 at 10:10 AM, piranna@gmail.com <piranna@gmail.com>wrote:
>>
>>> > I've got a public matchmaking websocket server running for those who
>>> want
>>> > something to hit against:
>>> >
>>> > Source: https://github.com/freedomjs/socialrouter
>>> > Running: wss://p2pbr.com/route/
>>> >
>>>  Lol! We got the same idea, only mine in Node.js :-P
>>>
>>> https://github.com/piranna/Schuko
>>>
>>> It was working at my old job three months without downtime, but AFAIK
>>> it's still alive and kicking :-D
>>>
>>>
>>> > Existing social networks are another pretty reasonable possibility.
>>> You can
>>> > do oAuth with a bunch of existing networks to help users form
>>> connections
>>> > without your own infrastructure.
>>> >
>>>  I was thinking using Twitter to send SDPs, but it's not secure enough.
>>> But when having a working encrypted signaling channel ready to use, it
>>> would be interesting to investigate to use another existing Twitter or
>>> Facebook or another messaging systems :-)
>>>
>>>
>>> --
>>> "Si quieres viajar alrededor del mundo y ser invitado a hablar en un
>>> monton de sitios diferentes, simplemente escribe un sistema operativo
>>> Unix."
>>> - Linus Tordvals, creador del sistema operativo Linux
>>>
>>
>>
> --
> Peersm : http://www.peersm.com
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
>
>

Re: [webp2p] Serverless Peersm and WebRTC

From:
Aymeric Vitte
Date:
2014-03-04 @ 12:25
Yes, probably torrents (or Peersm) are a good use case for this, 
interesting again.

As far as I understand you have experimented it, would it be possible to 
have some numbers, for example for a torrent with N peers what is the 
ratio of connections established with and without the server?

Regards

Aymeric

Le 04/03/2014 12:21, Feross Aboukhadijeh a écrit :
> Say I want to talk to user A. If I'm connected to B, and B is 
> connected to A, then it's possible without a central server. I simply 
> ask B for an introduction to A. B will handle exchanging our SDPs in 
> lieu of a central server.
>
> The only time you need a central server is for initial bootstrapping. 
> You can run multiple bootstrap nodes for redundancy like bittorrent 
> does for the bootstrap DHT nodes. My client has 3 hardcoded DHT 
> bootstrap nodes last I checked. But after that you should be good.
>
> Feross
> ✩ blog <http://feross.org/> | ✎ studynotes 
> <http://www.apstudynotes.org/> | ☮ webtorrent <http://webtorrent.io/>
>
>
> On Tue, Mar 4, 2014 at 3:03 AM, Aymeric Vitte <vitteaymeric@gmail.com 
> <mailto:vitteaymeric@gmail.com>> wrote:
>
>     Hi,
>
>     Interesting but:
>
>     As far as I understand to do a "serverless" WebRTC P2P, you can:
>
>     - manually exchange SDPs (chat or other)
>     - do the same using social networks
>     - use a server (ws or other) where the peers are connected to so
>     they can exchange SDPs
>
>     The first two options are really serverless but it seems unlikely
>     that you can scale that or make it automatic, peers have to know
>     each other.
>
>     The third one is using at least a server, so it's not serverless.
>
>     In a large P2P system it seems impossible to have something
>     serverless (again I would love to be wrong) because you need
>     something to connect the peers.
>
>     And in any case no solution (except specific mechanisms like
>     Peersm) can insure anonymity.
>
>     Piranna --> why is your webp2p.io <http://webp2p.io> project
>     anonymous? Maybe it depends on your definition of anonymous, but
>     here the peers know each other, so it's not anonymous, you need a
>     server that knows what the peers are doing, not anonymous again,
>     and probably you need STUN servers, not anonymous either... unless
>     I am misunderstanding the project.
>
>     Regards
>
>     Aymeric
>
>     Le 04/03/2014 09:31, piranna@gmail.com <mailto:piranna@gmail.com>
>     a écrit :
>>
>>     I was using anonimous XMPP servers, but I was only able to find
>>     one from Jappix and they removed anonimous access last May :-( If
>>     someone know some of them I will heartly thanks him :-)
>>
>>     Send from my Samsung Galaxy Note II
>>
>>     El 04/03/2014 09:24, "Shachar Zohar" <shacharz@gmail.com
>>     <mailto:shacharz@gmail.com>> escribió:
>>
>>         What about https://telegram.org/ or http://www.snapchat.com/
>>         instead of Twitter
>>
>>
>>         On Tue, Mar 4, 2014 at 10:10 AM, piranna@gmail.com
>>         <mailto:piranna@gmail.com> <piranna@gmail.com
>>         <mailto:piranna@gmail.com>> wrote:
>>
>>             > I've got a public matchmaking websocket server running
>>             for those who want
>>             > something to hit against:
>>             >
>>             > Source: https://github.com/freedomjs/socialrouter
>>             > Running: wss://p2pbr.com/route/ <http://p2pbr.com/route/>
>>             >
>>             Lol! We got the same idea, only mine in Node.js :-P
>>
>>             https://github.com/piranna/Schuko
>>
>>             It was working at my old job three months without
>>             downtime, but AFAIK
>>             it's still alive and kicking :-D
>>
>>
>>             > Existing social networks are another pretty reasonable
>>             possibility. You can
>>             > do oAuth with a bunch of existing networks to help
>>             users form connections
>>             > without your own infrastructure.
>>             >
>>             I was thinking using Twitter to send SDPs, but it's not
>>             secure enough.
>>             But when having a working encrypted signaling channel
>>             ready to use, it
>>             would be interesting to investigate to use another
>>             existing Twitter or
>>             Facebook or another messaging systems :-)
>>
>>
>>             --
>>             "Si quieres viajar alrededor del mundo y ser invitado a
>>             hablar en un
>>             monton de sitios diferentes, simplemente escribe un
>>             sistema operativo
>>             Unix."
>>             - Linus Tordvals, creador del sistema operativo Linux
>>
>>
>
>     -- 
>     Peersm :http://www.peersm.com
>     node-Tor :https://www.github.com/Ayms/node-Tor
>     GitHub :https://www.github.com/Ayms
>
>

-- 
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

OT: Internet reloaded #cjdns

From:
Marc
Date:
2014-03-02 @ 12:47
hey folks,

has anyone heard from cjdns ?

I collected some information about cjdns , a comparision with other 
alternative (inter) networks and a video from  caleb james 
http://let.de/index.php/the-whitepaper-for-cjdns/

Its seems a pretty neat solution and achive layer2 switching and privacy 
goals, routing and even monetization would be build into the protocol. 
Any comments ?

Cheers from cologne

Marc


P.S. Book recommendation of the day 
http://www.amazon.com/Who-Owns-Future-Jaron-Lanier/dp/1451654960

-- 
Marc Manthey
50823 Köln, germany
Vogelsangerstr.97
phone : 0049-221-29891489
mobile: 0049-1577-3329231
Fingerprint: B045 9750 C2CB 06C3 3782 A264 A47F 3645 0E19 8512
Website: http://let.de
Twitter: https://twitter.com/macbroadcast
Facebook: https://www.facebook.com/opencu
Linkedin: http://www.linkedin.com/in/macbroadcast
Xing: https://www.xing.com/profile/Marc_Manthey

Re: [webp2p] OT: Internet reloaded #cjdns

From:
realcr
Date:
2014-03-03 @ 14:44
Hi Marc,
I am also very interested in the CJDNS project.

I read the whitepaper more than once. I admit that I haven't looked at the
code yet.
There are a few things that I still don't understand in the protocol. I
will list them here briefly:

1. How does the protocol makes sure that paths between nodes are short
enough? I didn't manage to think of some bound or prove one myself.
It seems to me that the protocol uses some DHT which is not related to the
actual network layout, hence paths between parties are expected to be
pretty long (I think even more than sqrt(N)).
Long paths create long latency, and also increase the probability of
meeting the adversary in the middle.

2. How does the protocol protects against Sybil attack? And I'm not talking
about a very advanced adversary here, just a simple one.
One person with one computer, claiming to be many addresses in the DHT. I
believe that this kind of attack could prevent legitimate users from
receiving their messages,
as many messages will be routed to the adversary's computer.

Besides that, I think that the programmers in the project are very
talented, and also very ambitious. Maybe I just didn't manage to understand
the protocol.

real.


On Sun, Mar 2, 2014 at 2:47 PM, Marc <marc@let.de> wrote:

> hey folks,
>
> has anyone heard from cjdns ?
>
> I collected some information about cjdns , a comparision with other
> alternative (inter) networks and a video from  caleb james
> http://let.de/index.php/the-whitepaper-for-cjdns/
>
> Its seems a pretty neat solution and achive layer2 switching and privacy
> goals, routing and even monetization would be build into the protocol.
> Any comments ?
>
> Cheers from cologne
>
> Marc
>
>
> P.S. Book recommendation of the day
> http://www.amazon.com/Who-Owns-Future-Jaron-Lanier/dp/1451654960
>
> --
> Marc Manthey
> 50823 Köln, germany
> Vogelsangerstr.97
> phone : 0049-221-29891489
> mobile: 0049-1577-3329231
> Fingerprint: B045 9750 C2CB 06C3 3782 A264 A47F 3645 0E19 8512
> Website: http://let.de
> Twitter: https://twitter.com/macbroadcast
> Facebook: https://www.facebook.com/opencu
> Linkedin: http://www.linkedin.com/in/macbroadcast
> Xing: https://www.xing.com/profile/Marc_Manthey
>
>

Re: [webp2p] OT: Internet reloaded #cjdns

From:
Marc
Date:
2014-03-04 @ 17:28
Am 03.03.2014 15:44, schrieb realcr:
> Hi Marc,
> I am also very interested in the CJDNS project.
>
> I read the whitepaper more than once. I admit that I haven't looked at 
> the code yet.
> There are a few things that I still don't understand in the protocol. 
> I will list them here briefly:
>
> 1. How does the protocol makes sure that paths between nodes are short 
> enough? I didn't manage to think of some bound or prove one myself.
> It seems to me that the protocol uses some DHT which is not related to 
> the actual network layout, hence paths between parties are expected to 
> be pretty long (I think even more than sqrt(N)).
> Long paths create long latency, and also increase the probability of 
> meeting the adversary in the middle.
>
> 2. How does the protocol protects against Sybil attack? And I'm not 
> talking about a very advanced adversary here, just a simple one.
> One person with one computer, claiming to be many addresses in the 
> DHT. I believe that this kind of attack could prevent legitimate users 
> from receiving their messages,
> as many messages will be routed to the adversary's computer.
>
> Besides that, I think that the programmers in the project are very 
> talented, and also very ambitious. Maybe I just didn't manage to 
> understand the protocol.
>
> real.

hello real,

Sorry i am not qualified to answer our questions, but maybe this thread 
on the liberation tech list

gives you a few answers. Its seems he took pieces from bitorrent, DHT 
and OSPF concepts to form neighbor relationships.

https://www.mail-archive.com/liberationtech@lists.stanford.edu/msg06030.html

There are is another Video on youtube with a live demo at the end 
http://www.youtube.com/watch?v=sCFmzGknUew

I will keep my eyes on the #cjdns project, because i have a feeling this 
could be a paradigm change in networking technologie, because i  feel a 
bit uncomftable with  stuff like  http://lisp.cisco.com/ and the power 
of future ISPs.

There is a small company  from swizerland who build in the protocol into 
there enigmabox allready ;)

http://wiki.enigmabox.net/cipherspace/cjdns

greetings


>
>
> On Sun, Mar 2, 2014 at 2:47 PM, Marc <marc@let.de 
> <mailto:marc@let.de>> wrote:
>
>     hey folks,
>
>     has anyone heard from cjdns ?
>
>     I collected some information about cjdns , a comparision with other
>     alternative (inter) networks and a video from  caleb james
>     http://let.de/index.php/the-whitepaper-for-cjdns/
>
>     Its seems a pretty neat solution and achive layer2 switching and
>     privacy
>     goals, routing and even monetization would be build into the protocol.
>     Any comments ?
>
>     Cheers from cologne
>
>     Marc
>
>
>     P.S. Book recommendation of the day
>     http://www.amazon.com/Who-Owns-Future-Jaron-Lanier/dp/1451654960
>
>     --
>     Marc Manthey
>     50823 Köln, germany
>     Vogelsangerstr.97
>     phone : 0049-221-29891489
>     mobile: 0049-1577-3329231
>     Fingerprint: B045 9750 C2CB 06C3 3782 A264 A47F 3645 0E19 8512
>     Website: http://let.de
>     Twitter: https://twitter.com/macbroadcast
>     Facebook: https://www.facebook.com/opencu
>     Linkedin: http://www.linkedin.com/in/macbroadcast
>     Xing: https://www.xing.com/profile/Marc_Manthey
>
>


-- 
Marc Manthey
50823 Köln, germany
Vogelsangerstr.97
phone : 0049-221-29891489
mobile: 0049-1577-3329231
Fingerprint: B045 9750 C2CB 06C3 3782 A264 A47F 3645 0E19 8512
Website: http://let.de
Twitter: https://twitter.com/macbroadcast
Facebook: https://www.facebook.com/opencu
Linkedin: http://www.linkedin.com/in/macbroadcast
Xing: https://www.xing.com/profile/Marc_Manthey

Re: [webp2p] OT: Internet reloaded #cjdns

From:
uɐɯɐǝS pɐɥↃ
Date:
2014-03-04 @ 17:46
Also worth checking this out.

http://hyperboria.net
On Mar 4, 2014 9:29 AM, "Marc" <marc@let.de> wrote:

>  Am 03.03.2014 15:44, schrieb realcr:
>
>     Hi Marc,
>  I am also very interested in the CJDNS project.
>
> I read the whitepaper more than once. I admit that I haven't looked at the
> code yet.
> There are a few things that I still don't understand in the protocol. I
> will list them here briefly:
>
>  1. How does the protocol makes sure that paths between nodes are short
> enough? I didn't manage to think of some bound or prove one myself.
> It seems to me that the protocol uses some DHT which is not related to the
> actual network layout, hence paths between parties are expected to be
> pretty long (I think even more than sqrt(N)).
>  Long paths create long latency, and also increase the probability of
> meeting the adversary in the middle.
>
>  2. How does the protocol protects against Sybil attack? And I'm not
> talking about a very advanced adversary here, just a simple one.
>  One person with one computer, claiming to be many addresses in the DHT. I
> believe that this kind of attack could prevent legitimate users from
> receiving their messages,
> as many messages will be routed to the adversary's computer.
>
>  Besides that, I think that the programmers in the project are very
> talented, and also very ambitious. Maybe I just didn't manage to understand
> the protocol.
>
>  real.
>
>
> hello real,
>
> Sorry i am not qualified to answer our questions, but maybe this thread on
> the liberation tech list
>
> gives you a few answers. Its seems he took pieces from bitorrent, DHT and
> OSPF concepts to form neighbor relationships.
>
>
> https://www.mail-archive.com/liberationtech@lists.stanford.edu/msg06030.html
>
> There are is another Video on youtube with a live demo at the end
> http://www.youtube.com/watch?v=sCFmzGknUew
>
> I will keep my eyes on the #cjdns project, because i have a feeling  this
> could be a paradigm change in networking technologie, because i  feel a bit
> uncomftable with  stuff like  http://lisp.cisco.com/ and the power of
> future ISPs.
>
> There is a small company  from swizerland who build in the protocol into
> there enigmabox allready ;)
>
> http://wiki.enigmabox.net/cipherspace/cjdns
>
> greetings
>
>
>
>
> On Sun, Mar 2, 2014 at 2:47 PM, Marc <marc@let.de> wrote:
>
>> hey folks,
>>
>> has anyone heard from cjdns ?
>>
>> I collected some information about cjdns , a comparision with other
>> alternative (inter) networks and a video from  caleb james
>> http://let.de/index.php/the-whitepaper-for-cjdns/
>>
>> Its seems a pretty neat solution and achive layer2 switching and privacy
>> goals, routing and even monetization would be build into the protocol.
>> Any comments ?
>>
>> Cheers from cologne
>>
>> Marc
>>
>>
>> P.S. Book recommendation of the day
>> http://www.amazon.com/Who-Owns-Future-Jaron-Lanier/dp/1451654960
>>
>> --
>> Marc Manthey
>> 50823 Köln, germany
>> Vogelsangerstr.97
>> phone : 0049-221-29891489
>> mobile: 0049-1577-3329231
>> Fingerprint: B045 9750 C2CB 06C3 3782 A264 A47F 3645 0E19 8512
>> Website: http://let.de
>> Twitter: https://twitter.com/macbroadcast
>> Facebook: https://www.facebook.com/opencu
>> Linkedin: http://www.linkedin.com/in/macbroadcast
>> Xing: https://www.xing.com/profile/Marc_Manthey
>>
>>
>
>
> --
> Marc Manthey
> 50823 Köln, germany
> Vogelsangerstr.97
> phone : 0049-221-29891489
> mobile: 0049-1577-3329231
> Fingerprint: B045 9750 C2CB 06C3 3782 A264 A47F 3645 0E19 8512
> Website: http://let.de
> Twitter: https://twitter.com/macbroadcast
> Facebook: https://www.facebook.com/opencu
> Linkedin: http://www.linkedin.com/in/macbroadcast
> Xing: https://www.xing.com/profile/Marc_Manthey
>
>

Re: [webp2p] OT: Internet reloaded #cjdns

From:
uɐɯɐǝS pɐɥↃ
Date:
2014-03-04 @ 17:49
Whoops, forgot github link to source.

https://github.com/ProjectMeshnet/Hyperboria
On Mar 4, 2014 9:46 AM, "uɐɯɐǝS pɐɥↃ" <chadillac83@gmail.com> wrote:

> Also worth checking this out.
>
> http://hyperboria.net
> On Mar 4, 2014 9:29 AM, "Marc" <marc@let.de> wrote:
>
>>  Am 03.03.2014 15:44, schrieb realcr:
>>
>>     Hi Marc,
>>  I am also very interested in the CJDNS project.
>>
>> I read the whitepaper more than once. I admit that I haven't looked at
>> the code yet.
>> There are a few things that I still don't understand in the protocol. I
>> will list them here briefly:
>>
>>  1. How does the protocol makes sure that paths between nodes are short
>> enough? I didn't manage to think of some bound or prove one myself.
>> It seems to me that the protocol uses some DHT which is not related to
>> the actual network layout, hence paths between parties are expected to be
>> pretty long (I think even more than sqrt(N)).
>>  Long paths create long latency, and also increase the probability of
>> meeting the adversary in the middle.
>>
>>  2. How does the protocol protects against Sybil attack? And I'm not
>> talking about a very advanced adversary here, just a simple one.
>>  One person with one computer, claiming to be many addresses in the DHT.
>> I believe that this kind of attack could prevent legitimate users from
>> receiving their messages,
>> as many messages will be routed to the adversary's computer.
>>
>>  Besides that, I think that the programmers in the project are very
>> talented, and also very ambitious. Maybe I just didn't manage to understand
>> the protocol.
>>
>>  real.
>>
>>
>> hello real,
>>
>> Sorry i am not qualified to answer our questions, but maybe this thread
>> on the liberation tech list
>>
>> gives you a few answers. Its seems he took pieces from bitorrent, DHT and
>> OSPF concepts to form neighbor relationships.
>>
>>
>> https://www.mail-archive.com/liberationtech@lists.stanford.edu/msg06030.html
>>
>> There are is another Video on youtube with a live demo at the end
>> http://www.youtube.com/watch?v=sCFmzGknUew
>>
>> I will keep my eyes on the #cjdns project, because i have a feeling  this
>> could be a paradigm change in networking technologie, because i  feel a bit
>> uncomftable with  stuff like  http://lisp.cisco.com/ and the power of
>> future ISPs.
>>
>> There is a small company  from swizerland who build in the protocol into
>> there enigmabox allready ;)
>>
>> http://wiki.enigmabox.net/cipherspace/cjdns
>>
>> greetings
>>
>>
>>
>>
>> On Sun, Mar 2, 2014 at 2:47 PM, Marc <marc@let.de> wrote:
>>
>>> hey folks,
>>>
>>> has anyone heard from cjdns ?
>>>
>>> I collected some information about cjdns , a comparision with other
>>> alternative (inter) networks and a video from  caleb james
>>> http://let.de/index.php/the-whitepaper-for-cjdns/
>>>
>>> Its seems a pretty neat solution and achive layer2 switching and privacy
>>> goals, routing and even monetization would be build into the protocol.
>>> Any comments ?
>>>
>>> Cheers from cologne
>>>
>>> Marc
>>>
>>>
>>> P.S. Book recommendation of the day
>>> http://www.amazon.com/Who-Owns-Future-Jaron-Lanier/dp/1451654960
>>>
>>> --
>>> Marc Manthey
>>> 50823 Köln, germany
>>> Vogelsangerstr.97
>>> phone : 0049-221-29891489
>>> mobile: 0049-1577-3329231
>>> Fingerprint: B045 9750 C2CB 06C3 3782 A264 A47F 3645 0E19 8512
>>> Website: http://let.de
>>> Twitter: https://twitter.com/macbroadcast
>>> Facebook: https://www.facebook.com/opencu
>>> Linkedin: http://www.linkedin.com/in/macbroadcast
>>> Xing: https://www.xing.com/profile/Marc_Manthey
>>>
>>>
>>
>>
>> --
>> Marc Manthey
>> 50823 Köln, germany
>> Vogelsangerstr.97
>> phone : 0049-221-29891489
>> mobile: 0049-1577-3329231
>> Fingerprint: B045 9750 C2CB 06C3 3782 A264 A47F 3645 0E19 8512
>> Website: http://let.de
>> Twitter: https://twitter.com/macbroadcast
>> Facebook: https://www.facebook.com/opencu
>> Linkedin: http://www.linkedin.com/in/macbroadcast
>> Xing: https://www.xing.com/profile/Marc_Manthey
>>
>>

Re: [webp2p] OT: Internet reloaded #cjdns

From:
uɐɯɐǝS pɐɥↃ
Date:
2014-03-04 @ 17:50
Meh, thought there was more there, sorry, will stop flooding now ;)
On Mar 4, 2014 9:49 AM, "uɐɯɐǝS pɐɥↃ" <chadillac83@gmail.com> wrote:

> Whoops, forgot github link to source.
>
> https://github.com/ProjectMeshnet/Hyperboria
> On Mar 4, 2014 9:46 AM, "uɐɯɐǝS pɐɥↃ" <chadillac83@gmail.com> wrote:
>
>> Also worth checking this out.
>>
>> http://hyperboria.net
>> On Mar 4, 2014 9:29 AM, "Marc" <marc@let.de> wrote:
>>
>>>  Am 03.03.2014 15:44, schrieb realcr:
>>>
>>>     Hi Marc,
>>>  I am also very interested in the CJDNS project.
>>>
>>> I read the whitepaper more than once. I admit that I haven't looked at
>>> the code yet.
>>> There are a few things that I still don't understand in the protocol. I
>>> will list them here briefly:
>>>
>>>  1. How does the protocol makes sure that paths between nodes are short
>>> enough? I didn't manage to think of some bound or prove one myself.
>>> It seems to me that the protocol uses some DHT which is not related to
>>> the actual network layout, hence paths between parties are expected to be
>>> pretty long (I think even more than sqrt(N)).
>>>  Long paths create long latency, and also increase the probability of
>>> meeting the adversary in the middle.
>>>
>>>  2. How does the protocol protects against Sybil attack? And I'm not
>>> talking about a very advanced adversary here, just a simple one.
>>>  One person with one computer, claiming to be many addresses in the DHT.
>>> I believe that this kind of attack could prevent legitimate users from
>>> receiving their messages,
>>> as many messages will be routed to the adversary's computer.
>>>
>>>  Besides that, I think that the programmers in the project are very
>>> talented, and also very ambitious. Maybe I just didn't manage to understand
>>> the protocol.
>>>
>>>  real.
>>>
>>>
>>> hello real,
>>>
>>> Sorry i am not qualified to answer our questions, but maybe this thread
>>> on the liberation tech list
>>>
>>> gives you a few answers. Its seems he took pieces from bitorrent, DHT
>>> and OSPF concepts to form neighbor relationships.
>>>
>>>
>>> https://www.mail-archive.com/liberationtech@lists.stanford.edu/msg06030.html
>>>
>>> There are is another Video on youtube with a live demo at the end
>>> http://www.youtube.com/watch?v=sCFmzGknUew
>>>
>>> I will keep my eyes on the #cjdns project, because i have a feeling
>>> this could be a paradigm change in networking technologie, because i  feel
>>> a bit uncomftable with  stuff like  http://lisp.cisco.com/ and the
>>> power of future ISPs.
>>>
>>> There is a small company  from swizerland who build in the protocol into
>>> there enigmabox allready ;)
>>>
>>> http://wiki.enigmabox.net/cipherspace/cjdns
>>>
>>> greetings
>>>
>>>
>>>
>>>
>>> On Sun, Mar 2, 2014 at 2:47 PM, Marc <marc@let.de> wrote:
>>>
>>>> hey folks,
>>>>
>>>> has anyone heard from cjdns ?
>>>>
>>>> I collected some information about cjdns , a comparision with other
>>>> alternative (inter) networks and a video from  caleb james
>>>> http://let.de/index.php/the-whitepaper-for-cjdns/
>>>>
>>>> Its seems a pretty neat solution and achive layer2 switching and privacy
>>>> goals, routing and even monetization would be build into the protocol.
>>>> Any comments ?
>>>>
>>>> Cheers from cologne
>>>>
>>>> Marc
>>>>
>>>>
>>>> P.S. Book recommendation of the day
>>>> http://www.amazon.com/Who-Owns-Future-Jaron-Lanier/dp/1451654960
>>>>
>>>> --
>>>> Marc Manthey
>>>> 50823 Köln, germany
>>>> Vogelsangerstr.97
>>>> phone : 0049-221-29891489
>>>> mobile: 0049-1577-3329231
>>>> Fingerprint: B045 9750 C2CB 06C3 3782 A264 A47F 3645 0E19 8512
>>>> Website: http://let.de
>>>> Twitter: https://twitter.com/macbroadcast
>>>> Facebook: https://www.facebook.com/opencu
>>>> Linkedin: http://www.linkedin.com/in/macbroadcast
>>>> Xing: https://www.xing.com/profile/Marc_Manthey
>>>>
>>>>
>>>
>>>
>>> --
>>> Marc Manthey
>>> 50823 Köln, germany
>>> Vogelsangerstr.97
>>> phone : 0049-221-29891489
>>> mobile: 0049-1577-3329231
>>> Fingerprint: B045 9750 C2CB 06C3 3782 A264 A47F 3645 0E19 8512
>>> Website: http://let.de
>>> Twitter: https://twitter.com/macbroadcast
>>> Facebook: https://www.facebook.com/opencu
>>> Linkedin: http://www.linkedin.com/in/macbroadcast
>>> Xing: https://www.xing.com/profile/Marc_Manthey
>>>
>>>

Re: [webp2p] OT: Internet reloaded #cjdns

From:
Marc
Date:
2014-03-04 @ 19:30
Am 04.03.2014 18:50, schrieb uɐɯɐǝS pɐɥↃ:
>
> Meh, thought there was more there, sorry, will stop flooding now ;)
>

are you on hyperboria ? i recently thought if it makes any sense when i 
could
install #cjdns on my ubuntu vserver, because my isp allows me to use 
virtual inferfaces,
i have 50mbit upload and about 10 mbit upload at home but just dynamic 
ip and their experimental peering policy
did not allow that  http://cjdns.ca/peers.txt

so with a static ip it would make sense to connect with some of your 
dynamic ip devices first and play around with it
before you ask to connect to the bigger nodes at http://map.randati.net/

this seems the main resource by the way

http://www.reddit.com/r/darknetplan/

cheers


> On Mar 4, 2014 9:49 AM, "uɐɯɐǝS pɐɥↃ" <chadillac83@gmail.com 
> <mailto:chadillac83@gmail.com>> wrote:
>
>     Whoops, forgot github link to source.
>
>     https://github.com/ProjectMeshnet/Hyperboria
>
>     On Mar 4, 2014 9:46 AM, "uɐɯɐǝS pɐɥↃ" <chadillac83@gmail.com
>     <mailto:chadillac83@gmail.com>> wrote:
>
>         Also worth checking this out.
>
>         http://hyperboria.net
>
>         On Mar 4, 2014 9:29 AM, "Marc" <marc@let.de
>         <mailto:marc@let.de>> wrote:
>
>             Am 03.03.2014 15:44, schrieb realcr:
>>             Hi Marc,
>>             I am also very interested in the CJDNS project.
>>
>>             I read the whitepaper more than once. I admit that I
>>             haven't looked at the code yet.
>>             There are a few things that I still don't understand in
>>             the protocol. I will list them here briefly:
>>
>>             1. How does the protocol makes sure that paths between
>>             nodes are short enough? I didn't manage to think of some
>>             bound or prove one myself.
>>             It seems to me that the protocol uses some DHT which is
>>             not related to the actual network layout, hence paths
>>             between parties are expected to be pretty long (I think
>>             even more than sqrt(N)).
>>             Long paths create long latency, and also increase the
>>             probability of meeting the adversary in the middle.
>>
>>             2. How does the protocol protects against Sybil attack?
>>             And I'm not talking about a very advanced adversary here,
>>             just a simple one.
>>             One person with one computer, claiming to be many
>>             addresses in the DHT. I believe that this kind of attack
>>             could prevent legitimate users from receiving their messages,
>>             as many messages will be routed to the adversary's computer.
>>
>>             Besides that, I think that the programmers in the project
>>             are very talented, and also very ambitious. Maybe I just
>>             didn't manage to understand the protocol.
>>
>>             real.
>
>             hello real,
>
>             Sorry i am not qualified to answer our questions, but
>             maybe this thread on the liberation tech list
>
>             gives you a few answers. Its seems he took pieces from
>             bitorrent, DHT and OSPF concepts to form neighbor
>             relationships.
>
>             
https://www.mail-archive.com/liberationtech@lists.stanford.edu/msg06030.html
>
>             There are is another Video on youtube with a live demo at
>             the end http://www.youtube.com/watch?v=sCFmzGknUew
>
>             I will keep my eyes on the #cjdns project, because i have
>             a feeling  this could be a paradigm change in networking
>             technologie, because i  feel a bit uncomftable with  stuff
>             like http://lisp.cisco.com/ and the power of future ISPs.
>
>             There is a small company  from swizerland who build in the
>             protocol into there enigmabox allready ;)
>
>             http://wiki.enigmabox.net/cipherspace/cjdns
>
>             greetings
>
>
>>
>>
>>             On Sun, Mar 2, 2014 at 2:47 PM, Marc <marc@let.de
>>             <mailto:marc@let.de>> wrote:
>>
>>                 hey folks,
>>
>>                 has anyone heard from cjdns ?
>>
>>                 I collected some information about cjdns , a
>>                 comparision with other
>>                 alternative (inter) networks and a video from  caleb
>>                 james
>>                 http://let.de/index.php/the-whitepaper-for-cjdns/
>>
>>                 Its seems a pretty neat solution and achive layer2
>>                 switching and privacy
>>                 goals, routing and even monetization would be build
>>                 into the protocol.
>>                 Any comments ?
>>
>>                 Cheers from cologne
>>
>>                 Marc
>>
>>
>>                 P.S. Book recommendation of the day
>>                 
http://www.amazon.com/Who-Owns-Future-Jaron-Lanier/dp/1451654960
>>
>>                 --
>>                 Marc Manthey
>>                 50823 Köln, germany
>>                 Vogelsangerstr.97
>>                 phone : 0049-221-29891489
>>                 mobile: 0049-1577-3329231
>>                 Fingerprint: B045 9750 C2CB 06C3 3782 A264 A47F 3645
>>                 0E19 8512
>>                 Website: http://let.de
>>                 Twitter: https://twitter.com/macbroadcast
>>                 Facebook: https://www.facebook.com/opencu
>>                 Linkedin: http://www.linkedin.com/in/macbroadcast
>>                 Xing: https://www.xing.com/profile/Marc_Manthey
>>
>>
>
>
>             -- 
>             Marc Manthey
>             50823 Köln, germany
>             Vogelsangerstr.97
>             phone : 0049-221-29891489
>             mobile: 0049-1577-3329231
>             Fingerprint: B045 9750 C2CB 06C3 3782 A264 A47F 3645 0E19 8512
>             Website:http://let.de
>             Twitter:https://twitter.com/macbroadcast
>             Facebook:https://www.facebook.com/opencu
>             Linkedin:http://www.linkedin.com/in/macbroadcast
>             Xing:https://www.xing.com/profile/Marc_Manthey
>


-- 
Marc Manthey
50823 Köln, germany
Vogelsangerstr.97
phone : 0049-221-29891489
mobile: 0049-1577-3329231
Fingerprint: B045 9750 C2CB 06C3 3782 A264 A47F 3645 0E19 8512
Website: http://let.de
Twitter: https://twitter.com/macbroadcast
Facebook: https://www.facebook.com/opencu
Linkedin: http://www.linkedin.com/in/macbroadcast
Xing: https://www.xing.com/profile/Marc_Manthey