yes eventually they'll get merged. hopefully... meanwhile i port
foolscap to twisted endpoints.
i'll post a message when all the unit tests pass ;-)
On Tue, Mar 11, 2014 at 2:06 AM, str4d wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> This is exactly why the I2P version of Tahoe-L
Hi Zooko,
Yes... a once a week meeting sounds good and doable.
I reside in Berlin... and I am usually awake during CET daylight hours.
I would like to suggest we meet at 17:00 UTC because it would be
convenient for me as I would simply stay
in my office a bit longer and chat with you two.
22:00
Greetings,
I recently wrote a Tahoe-LAFS Ansible role.
https://github.com/david415/ansible-tahoe-lafs
It can be used to write many different kinds of Ansible playbooks for
dealing with Tahoe-LAFS
component servers such as Introducers, Storage nodes and clients...
for instance the readme
shows an
Greetings,
I wrote a simple IStreamClientEndpointStringParser for using the
SOCKS5ClientEndpoint with Tor:
https://gist.github.com/david415/26a4ed59078d2e27376f
I modified a txsocksx code example for testing the new endpoint descriptor:
https://gist.github.com/david415/7c6040117319cc3b0230
...bu
Greetings,
Today I wrote an endpoint parser for Meejah's txtorcon Tor Hidden
Service endpoint.
Now that we have foolscap ported to twisted endpoints (branch needs
review but I should probably rebase first) we'd like to be able to
simply specify an "onion" endpoint descriptor in Tahoe-LAFS
configu
id415/txsocksx.git
On Wed, Apr 30, 2014 at 1:42 PM, David Stainton wrote:
> Greetings,
>
> I wrote a simple IStreamClientEndpointStringParser for using the
> SOCKS5ClientEndpoint with Tor:
> https://gist.github.com/david415/26a4ed59078d2e27376f
>
> I modified a txsocksx code e
descriptors from the user and
passes them to foolscap.
On Fri, May 2, 2014 at 2:20 PM, Tristan Seligmann
wrote:
> On 2 May 2014 15:59, David Stainton wrote:
>> This will work fine for the txsocksx tor client endpoint parser I
>> wrote... However the txtorcon Tor Hidden Service
Ah ha! Of course it is so obvious now that you point it out to me.
The onion endpoint parser can do this setup work in it's `listen`
method which returns a `Deferred`.
Thanks for your observation/advice!
Cheers!
David
On Fri, May 2, 2014 at 3:01 PM, wrote:
> On 02:53 pm, dstainton...@gmail.co
>> Ah ha! Of course it is so obvious now that you point it out to me.
>> The onion endpoint parser can do this setup work in it's `listen`
>> method which returns a `Deferred`.
>> Thanks for your observation/advice!
>
> Cool! Thanks for doing this. Can I pull it into txtorcon when it's
> finished?
Ah yeah... twisted endpoints that support udp...
Perhaps when Yawning Angel finishes Lightweight Obfuscated Datagram
Protocol (LODP) there will be interesting things we can do with
this... and a more immediate perceived need for twisted datagram
endpoint interfaces.
On Fri, May 2, 2014 at 9:16 PM
ch this
soon. For now my hacky development/testing flow works OK.
On Fri, May 2, 2014 at 9:18 PM, Glyph Lefkowitz wrote:
>
> On May 2, 2014, at 6:59 AM, David Stainton wrote:
>
> Today I wrote an endpoint parser for Meejah's txtorcon Tor Hidden
> Service endpoint.
>
>
> This i
Sweet! Does this help Tahoe-LAFS get into the next release of TAILS?
On Fri, May 2, 2014 at 10:11 PM, Daira Hopwood wrote:
> Woo!
>
> Original Message
> From: Ramakrishnan Muthukrishnan
> To: debian-devel-chan...@lists.debian.org
> Subject: Accepted tahoe-lafs 1.10.0-2 (source
OK... I decided that txtorcon's endpoint constructor should only take
string arguments besides the reactor arg...
because serverFromString passes only str args to the endpoint constructor.
I wrote the endpoint parser to be as simple as possible.
The endpoint's `listen` method now handles the tor c
> The endpoint constructor should do _construction_. The endpoint parser
> should do _parsing_. The task of parsing is of taking strings and producing
> meaningful values.
Ah yeah I see what you mean. OK... I changed it:
https://github.com/david415/txtorcon/commit/1e96d550c40bef1be1b45c3c975c0da
Greetings,
I believe the Foolscap-endpoints-port is at least ready for code review.
pull request: https://github.com/warner/foolscap/pull/18/files
So... after code review and perhaps code cleanup... I can
squash/rebase if needed to clean up the git history a bit: Str4d's
server side foolscap endp
I talked with Leif today.
Now I am going to work on making my foolscap branch fully compatible
with the current release of Tahoe.
All the Foolscap and Tahoe unit tests should pass at that point...
Cheers,
David
On Fri, May 9, 2014 at 9:19 AM, David Stainton wrote:
> Greetings,
>
>
Greetings,
My Foolscap branch is now backwards compatible with Foolscap 0.6.4...
What I mean is: all of the Tahoe-LAFS unit tests pass when using my
branch of Foolscap. All of the Foolscap unit tests pass too.
I was hanging out with Leif working on Foolscap today... and when I
was thinking about
Dear Meejah,
I'm replying by e-mail because it might be better than a conversation
inside a github pull request.
Excellent idea about not launching tor all the time! We were just
talking about that. My friend Leif Ryge and I were discussing possible
designs for this tor hidden service endpoint...
Hi Meejah,
Briefly changing subject to the IListeningPort interface:
http://foolscap.lothar.com/trac/ticket/203
please read trac comment #19 --->
http://foolscap.lothar.com/trac/ticket/203#comment:19
Reading Foolscap trac ticket 203 caused me to think about the exact
object implementing IListen
> I also don't mind doing a 0.9.x release with this in it as a "preview"
> feature, even if it's not completely-fully-baked -- especially if having
> a version of this on PyPI helps your Tahoe dev. Is this something you
> need?
Thanks! That's very nice of you to offer swift code merges.
The Tahoe
I volunteer!
On Tue, May 20, 2014 at 6:36 PM, Zooko Wilcox-OHearn
wrote:
> On Sat, May 3, 2014 at 12:51 AM, David Stainton
> wrote:
>> Sweet! Does this help Tahoe-LAFS get into the next release of TAILS?
>
> Well, according to https://labs.riseup.net/code/issues/6227
Hey Michael,
This reminds me of a conversation that came up a few days ago.
If you are going to write the client AND the server then why use SMTP at all?
Why not just use pond (https://pond.imperialviolet.org/)?
David
On Wed, May 28, 2014 at 11:50 PM, Michael Samuel wrote:
> Hi,
>
> I've draw
Hi,
In the interest of completing the Tails + Tahoe-LAFS integration
(see https://labs.riseup.net/code/issues/6227),
I propose a Tahoe-LAFS backup scheduler daemon. Leif and I discussed
it the other day and I want to know what others think of it.
I hope Leif or others will correct me if I say anyt
-- Forwarded message --
From: BitingBird
Date: Fri, May 30, 2014 at 2:06 AM
Subject: Re: [Tails-dev] Tahoe-LAFS persistence
To: The Tails public development discussion list
David Stainton:
> Hi,
> [...]
> 1. the Tahoe-LAFS debian package:
>
> This part
>> 1. the Tahoe-LAFS debian package:
>>
>> This part is done. Great!
>>
> Congratulation :)
> Tahoe documentation could mention this:
> https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/quickstart.rst
OK... I volunteer to update
https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/quickstart.rst
Hi Daira,
Thanks for all the info!
> +1. There are two existing tickets about scheduled backups:
=-)
> https://tahoe-lafs.org/trac/tahoe-lafs/ticket/643
I reviewed this ticket and thought about it too.
It doesn't seem appropriate for what I had in mind...
and there may be problem/solution conf
Hi!
If I understand correctly, then your question might be rephrased as:
How do I access a TCP service on localhost from outside of my NAT device?
I suggest investigating ssh port forwarding. (i don't think the
question or answer are specific to tahoe... but maybe someone else on
the list knows s
> Additionally, on any relevant Debian system, the command-line sftp
> client is shipped as part of the openssh-client package, that is
> installed in Tails.
>
>> Does it come with a Bittorrent client?
>
> No: https://tails.boum.org/support/faq/#index22h2
>
>> Can we make Tahoe-LAFS be the third th
-- Forwarded message --
From: intrigeri
Date: Thu, Jun 5, 2014 at 12:23 AM
Subject: Re: [Tails-dev] Tahoe-LAFS persistence
To: The Tails public development discussion list
Cc: tahoe-dev@tahoe-lafs.org, David Stainton
Hi,
[Snipping large chunks of discussion about how various
-- Forwarded message --
From: intrigeri
Date: Thu, Jun 5, 2014 at 3:03 PM
Subject: Re: [Tails-dev] Tahoe-LAFS persistence
To: David Stainton
Cc: The Tails public development discussion list ,
tahoe-dev
Hi,
(Disclaimer: I still have not read this full thread.)
David Stainton
> (Disclaimer: I still have not read this full thread.)
OK...
>> is there any reason not to?
>
> If someone properly integrates Tahoe-LAFS withing Tails (including
> patching tails-persistence-setup, design doc, and whatever nobody has
> thought of yet), then I'm happy.
Since you didn't read the
-- Forwarded message --
From: intrigeri
Date: Thu, Jun 5, 2014 at 6:07 PM
Subject: Re: [Tails-dev] Tahoe-LAFS persistence
To: David Stainton
Cc: The Tails public development discussion list ,
tahoe-dev
Hi,
David Stainton wrote (05 Jun 2014 16:58:52 GMT) :
> Since you did
> Looks good. Still, will need to persist the Tahoe-LAFS configuration.
> Hence my proposal.
Ahhh OK! I understand.
> Have you actually tried installing Tahoe-LAFS on Tails, in a way that
> it's re-installed automatically on every boot, and you don't have to
> reconfigure it every time you start
I too am interested but I unfortunately will not be back in SF in time for this.
On Thu, Jun 19, 2014 at 10:03 PM, Zancas Dearana
wrote:
> Interested! Don't know if I can make it.
>
>
> On Tue, Jun 17, 2014 at 5:43 PM, Brian Warner wrote:
>>
>> We're trying to assemble a small Tahoe Summit fo
post it on a
new twisted trac ticket...
-- Forwarded message --
From: David Stainton
Date: Thu, Jul 3, 2014 at 8:16 AM
Subject: "serialization" of ListeningPort
To: twisted-pyt...@twistedmatrix.com
Greetings,
I wanted to see what people think of this before attempting
Dear Warner,
I have without much trouble broken out the Foolscap client side
endpoint code into it's own branch:
https://github.com/david415/foolscap/tree/endpoint_client1
All Tahoe-LAFS and Foolscap unit tests pass.
Is this OK? Is this commit a small enough unit of code?
This is definitely not
to be TCP.
https://github.com/david415/foolscap/tree/endpoint_server1
On Sun, Aug 31, 2014 at 6:19 PM, David Stainton wrote:
> Dear Warner,
>
> I have without much trouble broken out the Foolscap client side
> endpoint code into it's own branch:
>
> https://github.com/david4
this event yet.
Cheers,
David Stainton
contact info → https://www.lumiere.net/~mrdavid/contact.txt
signature.asc
Description: Digital signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
.
>
> On Sat, Sep 6, 2014 at 12:10 PM, David Stainton
> wrote:
>>
>>
>> Dear Tahoe-LAFS enthusiasts,
>>
>> I am organizing a Tahoe-LAFS cryptoparty at Noisebridge in the next coming
>> weeks
>> and I'd be delighted if some of you woul
https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/configuration.rst#overall-node-configuration
tub.port must be set to something like: tcp:interface=127.0.0.1:7789
On Sat, Sep 13, 2014 at 9:22 PM, Roland Haeder wrote:
> Hello together,
>
> I run Tahoe-LAFS on my local network on all my compute
Greetings!
You. Must. Read!!!
http://www.laser.dist.unige.it/Repository/IPI-1011/FileSystems/TahoeDFS.pdf
What does "simulating a Peer-to-Peer network?" mean?
I have a feeling if you read the above paper it would help you understand
Tahoe-LAFS.
I2P AND Tor (as in Tor hidden services) can pene
e not discouraged from using Tahoe-LAFS!
Please continue to ask your questions and I will help you...
however I think for the time being your problem is solved! Enjoy!
Cheers,
David
On Sun, Sep 14, 2014 at 11:28 AM, Roland Haeder wrote:
> On 09/13/2014 11:36 PM, David Stainton wrote:
>>
oopsy... sorry for my hasty reply.
I'm glad it worked out or you! yay!
Cheers!
David
On Tue, Sep 16, 2014 at 8:35 PM, Roland Haeder wrote:
> On 09/13/2014 11:36 PM, David Stainton wrote:
>> https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/configuration.rst#overall-node
Dear Lukas,
I dare say this does not belong in the Tahoe-LAFS trac ticket system.
You can write all sorts of applications that use Tahoe-LAFS... good
luck with your software project!
David
On Sat, Nov 1, 2014 at 12:12 PM, Lukas Pirl wrote:
> Hi everyone!
>
> I just tried to create a ticket tha
sebridge!
https://www.cryptoparty.in/sanfrancisco
Cheers,
David Stainton
On Fri, Dec 19, 2014 at 3:21 AM, Sameer Verma wrote:
> Hi,
>
> I'm trying to set up a system of 1 introducer and 10 storage nodes on
> AWS, plus one client on my laptop. The introducer sets up, but when
ities. I think we should also create a development roadmap for
"censorship resistance" or also referred to as "denial of service
attack resistance".
Would you be interested in collaborating with me?
What kind of things do you want to use Tahoe-LAFS for?
Cheers,
David Stainton
Tor hidden services get you NAT whole punching for free... so just use
Tor hidden services!!! =-|
On Sun, Dec 21, 2014 at 11:13 AM, Lukas Pirl wrote:
> On 12/20/2014 08:15 PM, Shu Lin wrote:
>> if Tahoe team has any intention to put effort in this area
>
> Well, I am not the team but I'd apprecia
Hi Lukas,
I'm very interested to see what the tahoe-devs say to this idea of
participating in GSoC.
With regards to NAT... it seems that they decided a while back that
this problem was outside the scope of what Tahoe-LAFS should solve...
but maybe they are interested? I can tell you that there ar
ey want to
review and merge my foolscap Twisted endpoints branch which would
allow the use arbitrary network transports (transports that have
Twisted client and server endpoints).
On Wed, Feb 25, 2015 at 4:52 PM, Lukas Pirl wrote:
> On 02/25/2015 04:51 PM, David Stainton wrote:
>> With r
Yes... me too. Unfortunately large patches like mine probably seem
like a daunting code review task that nobody has had time for.
On Wed, Feb 25, 2015 at 5:13 PM, Lukas Pirl wrote:
> On 02/25/2015 05:28 PM, David Stainton wrote:
>> I don't know much about IPv6 but the core Tahoe
per-helper-nodes" would also help, albeit with increased
> bandwidth costs.
>
>
>
> On Wednesday 25 Feb 2015 15:51:14 David Stainton wrote:
>
>> Hi Lukas,
>
>>
>
>> I'm very interested to see what the tahoe-devs say to this idea of
>
>> parti
> Perhaps I did not express myself very well. I want to store several TB on
> Tahoe-LAFS nodes behind NATs. This is not a super-expensive high-tech exascale
> project; just a few Raspberry Pis with external hard drives, distributed
> around my friends' houses, total cost well under US$1000.
> Your
I think this just means that for the people who do not know or like
command line tools, they will use the easier to use interface for
Tahoe-LAFS (which doesn't exist yet).
On Wed, Apr 8, 2015 at 5:14 PM, John wrote:
> Long time lurker on this project and I'm hoping it succeeds.
>
> Hmm, sorry, ho
What would happen if the foolscap transport plugin state directory was
removed but the tahoe.cfg config file remained intact?
In that error case when the Tor-Foolscap plugin is used, the correct
behavior would be to exit with an error telling the user that the
Tahoe-LAFS configuration file express
yay! i'm excited for this native Tor integration project.
The default Tahoe-LAFS+Txtorcon behavior will persist hidden service
key material to a private client config directory... however I'm sure
that ephemeral storage nodes would easily be possible as well;
I envision ephemeral Tahoe-LAFS onion
Yes the "direct onion services" are a very good feature for the Tahoe
+ Tor combo... especially with regards to how most people would like
to use tools like Tahoe-LAFS to transfer largish amounts of data.
Furthermore if/when we release Tahoe+Tor integration I'd like to write
a short little release
Dear Meejah,
I appreciate all the work you've put into the txtorcon project. I am
very excited about this Tahoe-LAFS integration.
> Cool, tahoe via Tor :)
free NAT penetration via Tor onions means Tahoe-LAFS will be *much*
more useable... and we can possibly change our thinking of all
Tahoe-LAFS
>> * It could be desirable to connect to a grid (possibly of non-onion
>>storage servers) using Tor to reach all of the servers *except* the
>>user's own servers, which are reachable via their LAN or VPN.
>
> How would a client know which ones are "mine" vs someone else's?
How would we pr
> I think per-server connection preferences should be exposed via the
> introducerless mode which you (Brian) mostly implemented long ago but left
> commented out and which David made work in the truckee branch[1]. Speaking of
> which, I really need to bring that up to date with the last 6 months o
working... then it might be interesting to discuss
making Tahoe-LAFS more denial-of-service resistant.
On Mon, Jun 29, 2015 at 5:43 PM, David Stainton wrote:
>> I think per-server connection preferences should be exposed via the
>> introducerless mode which you (Brian) mostly implemente
Dear Roland,
I'm sorry to hear about your data loss. It is my understanding that if
you do not possess a cryptographic capability for either ReadOnly or
ReadWrite access to a file, you will NOT be able to recover it. That
is... not with some sort of cryptographic attack.
You might check if any of
NO. You cannot try all possibilities. It would defeat the point of
using cryptographic capabilities.
Your data is lost forever unless you possess the cryptographic capability.
I'm sorry for your loss but if you continue to insist you can recover
it then that's like saying you don't believe in crypt
Dear Roland,
Don't have the caps? Sorry for your lose. Continue to insist it's
possible to recover? Trolling.
Furthermore... you really must have a low opinion of our security
model if you think you can so easily recover a file without it's
capability. ;-p
Cheers,
David
On Fri, Jul 10, 2015
Why is a question about rsync sent to a list about Tahoe-LAFS?
Seriously, I fail to see the connection between Tahoe-LAFS and
rsync... except for the file paradigm... they both deal with file like
objects... and that's cool and all but what exactly do you want?
Do you want to use Tahoe-LAFS with r
the end is very slow
>
>
> maybe there is another way to achieve what you want to do
>
> 2015-07-27 21:46 GMT+02:00 David Stainton :
>>
>> Why is a question about rsync sent to a list about Tahoe-LAFS?
>> Seriously, I fail to see the connection between Tahoe-LAFS a
Hi Brian Warner and everyone else too,
There's some really good examples of how to use the txtorcon's Tor
hidden service endpoints... that also demonstrate how to properly
determine the generated .onion address from the fired IListeningPort:
https://github.com/meejah/txtorcon/blob/master/examples/
First of all, we had several meetings, they take a long time, we talk
about a lot of stuff... it's work. Therefore it seems really unfair to
hear more quasi design discussion/complaining talk from people who
didn't attend the meeting; it disregards our efforts. Perhaps come to
the meetings? Offer s
Dear Paul Rabahy,
Thanks for running the public grid so users can test out Tahoe-LAFS...
Btw both you and Zooko misunderstood Brian Warner's e-mail; he doesn't
want to take away the autodetect feature... he just wants it to not be
the default if no listening address is specified... keyword AUTO w
Agreed; If possible we'd like to first hear Daira's solution before we
send Leif's.
I'm also curious to hear Zooko's solution.
I've written a proposal document explaining Leif's solution.
Hopefully later today Leif will apply more corrections to this document
which is almost ready to be reviewed.
; 2 clients on same file is fair enough
>
> we shall grab the last github to build to test this.
> or we shall take any other build/repo ?
>
>
> thanks
>
> xavier
>
>
> Le dimanche 8 novembre 2015, David Stainton a écrit
> :
>>
>> Agreed; If possi
yes we can make a git-like design... although we only have to preserve
the history of a single file... not the history of the whole directory
hierarchy.
the other property i think a new design might *need* is to preserve
the identity of the client that created the "snapshot object". the
only notio
feeling sick today with a cold and so i'm hoping to rest up and
recover tomorrow hopefully.
On Sat, Jan 2, 2016 at 9:06 AM, Daira Hopwood wrote:
> Frederik Braun wrote:
>
>> > Gottschedstraße 4, [Aufgang] 4
>> > 13357 Berlin
>>
>> When, though? :-)
>
> Today and the next few days. The morning sta
Dear Brian Warner,
Would you have time to help us figure out the most suitable
development roadmap for the Tahoe-LAFS Magic-Folder project?
I believe that at this time we need your senior developer experience
to help us make some decisions. Without this kind of leadership we
will continue to be s
73 matches
Mail list logo
