On Sun, Jun 1, 2014 at 9:45 PM, Cathal (phone)
wrote:
> What about streaming, which is increasingly used to hold power to account in
> real time? Or other rich, necessarily large media which needs to *get out
> fast*? Big media isn't always frivolous. Even frivolity is important, and a
> mixnet wi
I think frivolous stuff could wait some more ... but you can always bundle
several connections by means of bonding interfaces.
I know it is not the best approach, but let's suppose you need to command a
robot or conduct a surgery over p2p. Bonding a few openvpn connections together
would do the
> Message du 01/06/14 20:37
> De : "grarpamp"
>
> In May 2014 someone wrote:
> >> > p2p is no panacea, it doesn't scale
> >>
> >> I believe it could. Even if requiring super aggregating
> >> nodes of some sort. Layers of service of the whole
> >> DHT space. More research is surely required.
>
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 01/06/14 20:54, pira...@gmail.com wrote:
>>> There is no way to hide metadata because you need a destination
>>> for your messages to arrive ... has to find its destinations to
>>> deliver its contents.
>
>> Yes of course... the minimum necessary
On Fri, May 16, 2014 at 6:01 AM, wrote:
>> >> pesky to/from/subject/etc headers.
>> > Those are hidden by use of TLS.
>> weaknesses intrinsic to SMTP discussions?
>> Yes, they are hidden in TLS transport on the wire.
>> No, they are not hidden in core or on disk at
>> the intermediate and final
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 01/06/14 19:30, grarpamp wrote:
> It would be nice to check some numbers on this for the list. Is
> there a wiki or paper repository that discusses plausibly reachable
> DHT sizes, time needed for DHT ops to resolve, and management
> schemes for s
In May 2014 someone wrote:
>> > p2p is no panacea, it doesn't scale
>>
>> I believe it could. Even if requiring super aggregating
>> nodes of some sort. Layers of service of the whole
>> DHT space. More research is surely required.
> It is not possible to have fast p2p unless:
> - Cable networks c
