> On Oct 23, 2018, at 2:14 PM, Nathan Freitas wrote:
>
> On Tue, Oct 23, 2018, at 1:55 AM, Roger Dingledine wrote:
>> On Mon, Oct 22, 2018 at 05:13:39PM +0100, Iain Learmonth wrote:
>>> It might also be that half-duplex communication (even if implemented
>>> with humans saying "over") could
On Tue, Oct 23, 2018, at 1:55 AM, Roger Dingledine wrote:
> On Mon, Oct 22, 2018 at 05:13:39PM +0100, Iain Learmonth wrote:
> > It might also be that half-duplex communication (even if implemented
> > with humans saying "over") could bring benefits as this would allow you
> > to increase the
> On Oct 23, 2018, at 7:49 AM, Iain Learmonth wrote:
>
> Signed PGP part
> Hi,
>
> On 23/10/18 01:27, grarpamp wrote:
>
>> Yes, one cannot rationally overload all 128 bits for that without colliding
>> upon allocated IPv6 space that may appear in one's host stack.
>> However the 1:1 key
Hi,
On 23/10/18 01:27, grarpamp wrote:
> Bittorrent users don't need lifetime / PQC level authentication
> between peers, they just need enough to prevent nuisance
> collisions from degrading operations. Today even the less
> than 32 bits of IPv4 (reality: users don't typically brute the ISPs)
>
Hi,
On 23/10/18 13:18, Conrad Rockenhaus wrote:
> If it were to be offered as a non-hidden service, what about the UDP portion
> of the VoIP services, or do we just force everything to be TCP?
You still have 3-hops to the rendezvous point that are going through Tor
so it all still has to be
Iain,
If it were to be offered as a non-hidden service, what about the UDP portion of
the VoIP services, or do we just force everything to be TCP?
Thanks,
Conrad
> On Oct 22, 2018, at 11:13 AM, Iain Learmonth wrote:
>
> Signed PGP part
> Hi Conrad,
>
> On 20/10/18 06:07, Conrad Rockenhaus
On Mon, Oct 22, 2018 at 05:13:39PM +0100, Iain Learmonth wrote:
> It might also be that half-duplex communication (even if implemented
> with humans saying "over") could bring benefits as this would allow you
> to increase the buffer sizes without having people talking over each other.
Reminds me
> Tor Metrics has some data on average latencies for client to Onion
> service. This is your absolute minimum latency, with the only way to
> reduce this being to have latency-aware path selection
Apps like VoIP, IRC, shell could all benefit from that selection.
Tor doesn't proffer path selection
Hi Conrad,
On 20/10/18 06:07, Conrad Rockenhaus wrote:
> 4)Results of a test were conducted and one second round trip latency was
> noticed from PSTN to a soft phone connected via Tor (via OpenVPN). Hopefully
> performance improvement will be noticed with OnionCat.
Tor Metrics has some
> architecture to Tor <—> OnionCat <—> Asterisk
> test ... one second round trip latency ... PSTN to a soft phone connected via
> Tor (via OpenVPN).
> Hopefully performance improvement will be noticed with OnionCat.
OnionCat can provide access to using UDP and IPv6
over Tor without the extra
Hello All,
We had a discussion on IRC regarding this and the following suggestions were
made:
1) Change the architecture to FreeBSD box<—> Tor <—> OnionCat <—>
Asterisk, or even drop the FreeBSD box completely if the Asterisk box is able
to handle the load.
2) Traumschule is
Hello All,
So prior to opening up the service for beta, Iain suggested that we have a
discussion regarding my proposed service and my planned architecture to see
if there’s any room for improvements in the design or any vulnerabilities
that can take away someone’s anonymity.
So the design is
12 matches
Mail list logo
