Re: Tahoe Summit 2016: November 8+9, San Francisco

[Zooko Wilcox-OHearn]

I'll be there with bells on!

https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Summit2016

On Tue, Oct 18, 2016 at 11:43 PM, Brian Warner  wrote:
> We have a venue! It will be at the Mechanics Institute Library, at 57
> Post St, San Francisco, right next to the Montgomery BART station. I've
> rented the space from 9-5 each day, and there's space for about 15
> people (and wifi and a whiteboard, and we'll have a projector too).
>
> Daira and Meejah and I will be there for sure, and we'll probably have
> David and Zooko and Liz too. If you're in SF on November 8+9, come on
> by! Please add your name to the list so we can plan for food and stuff:
>
>   https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Summit2016
>
> and please add topics that you'd like to talk about to the wiki as well:
> I'm hoping to assemble an agenda of sorts before we meet.
>
> see you in november,
>  -Brian
>
>
> On 9/13/16 11:31 AM, Brian Warner wrote:
>> We're going to have a number of Tahoe developers in the San Francisco
>> area in early november, so we're going to set up another summit meeting.
>> This will be two days in a conference room where we'll talk about big
>> features like Accounting, Cloud-Backend, invitation protocols, new
>> encoding formats, and fancy new crypto things. We might even write some
>> code.
>>
>> It will be held November 8+9 (aka Election Tuesday and Aftermath
>> Wednesday). I haven't reserved space yet, but it will be somewhere in
>> San Francisco, probably SOMA or the Mission, and hopefully easy to reach
>> with public transit (worst case it will be held in my living room). Last
>> time we did this, I think we got 4-6 people together, and we were able
>> to include a few more over video.
>>
>> I'll be there, I know Daira will be in town, and I think a number of
>> LAE/ZCash folks will be in town so we might get to see some of them too
>> (maybe zooko? nathan? dawuud?).
>>
>> More details as we get closer to the date. If you think you might be
>> able to make it, please let me know soon (no committment, but I want to
>> know if I should find an 8-person conference room or a 20-person one).
> ___
> tahoe-dev mailing list
> tahoe-dev@tahoe-lafs.org
> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev



-- 
Regards,

Zooko Wilcox

Founder and Advisor
https://LeastAuthority.com — Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: new WAPI+WUI proposal

[Zooko Wilcox-OHearn]

This is a great plan! I'm delighted to see this progress happening!

+1!

On Sat, Jul 2, 2016 at 9:39 PM, meejah  wrote:
> Brian Warner  writes:
>
>> * new WAPI, listening on a new local port (so a different HTTP origin)
>> * this hosts a WebSocket at a path of "/v1"
>> * the websocket accepts CBOR[2]-encoded requests, and returns CBOR
>>   responses
>
> In a lot of ways, this sounds *very* similar to what e.g. Crossbar +
> Autobahn provide (they also support CBOR as a serialization format,
> alongside msgpack and JSON). Have you considered using this -- or
> another "RPC + PubSub framework" that supports Python + JS? (e.g. AMPQ
> or Cap'n'Proto are also similar in this regard, among others).
>
> There's a (possibly a little outdated) comparison here:
> http://wamp-proto.org/compared/
>
> --
> meejah
> ___
> tahoe-dev mailing list
> tahoe-dev@tahoe-lafs.org
> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev



-- 
Regards,

Zooko Wilcox

Founder and CEO
https://LeastAuthority.com — Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: TWN 53 Delay

[Zooko Wilcox-OHearn]

On Wed, Dec 23, 2015 at 6:43 PM, Oleksandr Drach  wrote:
>
> Is there any way we get some updates on upcoming international events in
> advance?

ACKnowledged
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: TWN 53 Delay

[Zooko Wilcox-OHearn]

Dear Patrick:

Some news is that we're planning a Hack Fest at the Tor office in
Berlin in January.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: Automatic rebalancing

[Zooko Wilcox-OHearn]

Dear Shu Lin:

That's great! Nobody else is working on that right now, and it is a
frequently-requested feature!

Regards,

Zooko
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: Tahoe-LAFS featured in “Why the command-line is not usable”

[Zooko Wilcox-OHearn]

Dear smarty ;):

Daira and Ramki have replied to your comments about the Windows build.
Please help them fix up the Windows build by reading and critiquing
the documents they pointed to!

 actually the packages from main linux versions are 1.9 and are 3 years old 
 actual release 1.10 is about 2 years old

 actual development seems quite active but with no officiel release

 what would you recommend to use ?

 2 years old 1.10 release ?
 master from github ?
 master from trac ?

Master from github should always be the same as master from trac --
they get autosynced with one another.

As for whether to use the most recent stable release or a development
revision, it depends on your goals. For *you*, since you are doing so
much good work on the Windows build, I would like you to use the
current master and contribute pull-requests back to it!

Regards,

Zooko
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: Problems uploading immutable files

[Zooko Wilcox-OHearn]

Hi David:

Thanks for writing to report your problem.

On Wed, Apr 8, 2015 at 2:15 PM, David Schneider
davidschneider.kont...@gmail.com wrote:

 The full error message is:
 ran out of shares: complete= pending=Share(sh5-on-v3otfjwi) overdue=
 unused= need 3. Last failure: [Failure instance: Traceback (failure with no
 frames): class 'allmydata.immutable.downloader.share.LayoutInvalid':
 unknown version 0 (I understand 1 and 2)

I have not seen this before in the wild, but it means that the share,
stored on disk on the storage server, has been corrupted. Since the
version number in the share is 0, when that number should have been
either 1 or 2, I wonder if the local filesystem filled the share
file with all zero bytes.

You could investigate this more by running a check operation on that
file, from the client, and by running the tahoe debug command on the
command-line on the storage server:

zooko@spark ~/playground/tahoe/tahoe-lafs/bin $ ./tahoe debug --help

Usage: tahoe debug SUBCOMMAND
Subcommands:
tahoe debug dump-share  Unpack and display the contents of a share.
tahoe debug dump-capUnpack a read-cap or write-cap.
tahoe debug find-shares Locate sharefiles in node directories.
tahoe debug catalog-shares  Describe all shares in node dirs.
tahoe debug corrupt-share   Corrupt a share by flipping a bit.
tahoe debug replOpen a Python interpreter.
tahoe debug trial   Run tests using Twisted Trial with the
right imports.
tahoe debug flogtoolUtilities to access log files.

Please run e.g. 'tahoe debug dump-share --help' for more details on each
subcommand.

You could run:

tahoe debug catalog-shares $NODE_DIRECTORY

NODE_DIRECTORY is probably ~/.tahoe/, unless you configured it to be
somewhere else.

It will print out a line of information about each share therein.

For example, on my system:

zooko@spark ~/playground/tahoe/tahoe-lafs/bin $ ./tahoe debug
catalog-shares ./test/s0/
CHK pxwh2r245lu2j55wiq46vcmiea 1/1 644734
xujcpmqedhhi54ebuierwxuy3z3tj2pzfwirzlizlrmlu6572q7a 2678304
'/home/zooko/playground/tahoe/tahoe-lafs/bin/test/s0/storage/shares/px/pxwh2r245lu2j55wiq46vcmiea/0'

You could then cut and paste the filename of the share into tahoe
debug dump-share, for example:

zooko@spark ~/playground/tahoe/tahoe-lafs/bin $ ./tahoe debug
dump-share 
/home/zooko/playground/tahoe/tahoe-lafs/bin/test/s0/storage/shares/px/pxwh2r245lu2j55wiq46vcmiea/0
share filename:
'/home/zooko/playground/tahoe/tahoe-lafs/bin/test/s0/storage/shares/px/pxwh2r245lu2j55wiq46vcmiea/0'
 version: 1
   file_size: 644734
num_segments: 5
segment_size: 131072
   needed_shares: 1
total_shares: 1

  codec_name: crs
codec_params: 131072-1-1
   tail_codec_params: 120446-1-1

  crypttext_hash: yhcii4w2dkkped4475tqtx2eu323yqxgdninsuvk7i3uth6yminq
 crypttext_root_hash: bgc3blozd4sb6465rvwkstqhpotaux7pullvgxoec7przzm7slgq
 share_root_hash: 2524tnool2py55ay4hxni2gt3xbaz7s7kr5p6m4qikaisiflun3q
UEB_hash: xujcpmqedhhi54ebuierwxuy3z3tj2pzfwirzlizlrmlu6572q7a
  verify-cap:
URI:CHK-Verifier:pxwh2r245lu2j55wiq46vcmiea:xujcpmqedhhi54ebuierwxuy3z3tj2pzfwirzlizlrmlu6572q7a:1:1:644734

 Size of data within the share:
data: 644734
   uri-extension: 323
  validation: 1474

 Lease #0: owner=0, expire in 2678245s (30 days)


You could also just use hexdump on the file to see if it is all zero bytes!



 As upload result of a immutable file I get the following message:
…
 8 - placed on [y2zlzq7z]
 9 - placed on [u64psdjj]

 It kinda seems that it just placed 2 shares instead of 10?

Yes, it does seem so. What is your shares.happy config parameter in
your tahoe.cfg file?

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com — Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: Distribute shares in another determinate way

[Zooko Wilcox-OHearn]

Good job, Shu Lin for writing this and Daira for reviewing it!

Regards,

Zooko
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: foolscap negotiation fails with unknown TubID

[Zooko Wilcox-OHearn]

On Tue, Feb 3, 2015 at 9:15 PM, Lukas Pirl tahoe-...@lukas-pirl.de wrote
 I'll also double-check if the administrators of the corresponding subnet
 do any sort of crazy firewalling.

 I tried to reproduce this bug and suddenly it worked.

 So I asked the administrator of the host and the network administrators
 if they changed anything and it turned out that a whole bunch of updates
 was applied to the FreeBSD OS. Great -.-

Oh...

Huh. From your original post:

  foolscap.tokens.BananaError: BananaError: (not right, got 'HTTP/1.1 500 
 Internal Server Error: unknown TubID eruo3ibyroMODIFIEDvkheeidhbm63vn', 
 expected 101 Switching Protocols,)

I still wish Brian (the designer and author of foolscap), or some
other foolscap experts would ponder this error message for a few
seconds.

I know, I'll just Cc: Brian on this email. :-)

--Zooko
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: how to use merkle hash tree check data

[Zooko Wilcox-OHearn]

Hello.

The Tahoe-LAFS program always validates the file when downloading the file.

The way it does this is described here:

http://eprint.iacr.org/2012/524

and implemented here:

* 
https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/src/allmydata/immutable/downloader/node.py?annotate=blamerev=99479226edc007ad174d605e63355e2e907a8acb#L252
* 
https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/src/allmydata/immutable/downloader/node.py?annotate=blamerev=99479226edc007ad174d605e63355e2e907a8acb#L365
* 
https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/src/allmydata/immutable/downloader/node.py?annotate=blamerev=99479226edc007ad174d605e63355e2e907a8acb#L405
* 
https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/src/allmydata/immutable/downloader/node.py?annotate=blamerev=99479226edc007ad174d605e63355e2e907a8acb#L476

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: Notes on installation on OSX

[Zooko Wilcox-OHearn]

Hello Francis!

Thank you for the report.

On Fri, Nov 28, 2014 at 10:35 AM, Francis Irving fran...@flourish.org wrote:

 1) Firstly, there's no section for it at all here:
 https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Installation

We're working on that! Stay tuned. ☺

 2) I started with the source code, and had little luck. In the end my
 best luck was with pip.

What happened when you followed these instructions:

https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/quickstart.rst

?

Thanks!

Regards,

Zooko
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

report from Nuts Bolts

[Zooko Wilcox-OHearn]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-

Tahoe-LAFS Nuts  Bolts, 2014-11-24
===

in attendance: Nathan (temporarily), Zooko (scribe), Daira

We started reviewing the patches that Leif and company contributed
during the recent Hack Fest:

* https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1973#comment:10

Daira looked at a newly reported regression:

* https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2329#comment:4

A user reported a bug in error reporting in the cloud backend:

* https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2341#comment:3

Zooko finally finished adding diagrams to the Servers Of Happiness
doc, and updating the text of the doc:

* https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1382#comment:77

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Nuts Bolts report from last week

[Zooko Wilcox-OHearn]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-

Tahoe-LAFS Nuts  Bolts, 2014-10-28
===

in attendance: Ramki, Zooko (scribe), Daira, Nathan

Zooko worked on `diagrams for the servers-of-happiness docs`_.

Daira worked on long pathnames on Windows (`#2235`_ and `#1674`_)

Ramki worked on a 64-bit Windows package. `#1981`_.

Nathan `reviewed`_ the Windows installer code.

.. _diagrams for the servers-of-happiness docs:
https://github.com/zooko/tahoe-lafs/blob/1382-rewrite-4/docs/specifications/example-4-matchings.svg
.. _#2235: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2235# Error
from 'tahoe cp' on Windows, due to a long path (IOError: Errno2 - no
such file or dir.)
.. _#1674: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1674#
os.path.expanduser (and therefore abspath_expanduser_unicode) fails on
Windows if username or home directory contains non-ASCII characters
.. _#1981: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1981# build
binary eggs for Windows x86 (64-bit)
.. _reviewed: 
https://github.com/tahoe-lafs/tahoe-lafs/commit/3ed844de5c7c8efdf594b30ce6f653eff3b894ec

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Nuts Bolts report from today

[Zooko Wilcox-OHearn]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-

Tahoe-LAFS Nuts  Bolts, 2014-11-04
===

in attendance: Zooko (scribe), Ramki

Ramki is working on `Windows packaging`_. He got a tahoe-lafs
executable built for Windows!

diagram for example 5Zooko is working on more diagrams for the
`servers-of-happiness docs`_. He made a `diagram for example 5`_.

.. _Windows packaging: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1981
.. _servers-of-happiness docs:
https://github.com/zooko/tahoe-lafs/blob/102d5846b53a715bd9a51aac20f325dd6f6830be/docs/specifications/servers-of-happiness.rst
.. _diagram for example 5:
https://github.com/zooko/tahoe-lafs/blob/102d5846b53a715bd9a51aac20f325dd6f6830be/docs/specifications/example-5.svg


-- 
Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Nuts Bolts Report

[Zooko Wilcox-OHearn]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-

Tahoe-LAFS Nuts  Bolts, 2014-10-14
===

in attendance: Daira, Zooko (scribe), Zancas (briefly), Dawuud (IRC only)

Zooko made a visual diagram image for the #1382 docs:

https://github.com/zooko/tahoe-lafs/blob/1382-rewrite-4/docs/specifications/example-1.svg

That's the diagram for example 1. It looks okay when rendered by
rst2html, but github doesn't inline the svg automatically when you
look at the github rendering of the doc file:
https://github.com/zooko/tahoe-lafs/blob/1382-rewrite-4/docs/specifications/servers-of-happiness.rst

Daira rebased and started reviewing #1159:

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1159# stop using .tac
files: make it possible to change appname, Python package-directory
name, perhaps other names

Zancas is eager to close some more Tahoe-LAFS tickets, but he decided
to spend this morning helping a friend of his apply for jobs, instead.

Dawuud opened a ticket about the docs about how to use Tahoe-LAFS+Tor together:

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2319# improve Tor usage
documentation



-- 
Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: Banana error?

[Zooko Wilcox-OHearn]

Here's a ticket to track the progress of fixing this so that the next
person who has this problem gets a friendly and helpful message about
it:

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2307
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Tesla Coils Corpses, 2014-09-25

[Zooko Wilcox-OHearn]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-

Tahoe-LAFS Tesla Coils  Corpses, 2014-09-25


Zooko (scribe), Daira, Lcstyle, not Maradydd

* #1382 ; 1382-rewrite-4
  (https://github.com/zooko/tahoe-lafs/tree/1382-rewrite-4) ;
  documentation-first development

* Lcstyle wants LeastAuthority to supply a whole grid, not just a
  single storage server; We talked a bit about RAIC, which led us back
  to #1382.

* #1901 ; Lcstyle has been working on it.

* Daira *wanted* to talk about Noether, effects, and formal handling
  of evidence-of-correctness (*short* of proof-of-correctness!) in
  programs. Maradydd wanted to join. Sadly, that didn't happen this
  time around. Maybe next week!

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Tesla Coils Corpses report—filecoin, secure invitations, Ice Backup

[Zooko Wilcox-OHearn]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-
.. -*- indent-tabs-mode: nil -*-

LAFS Tesla Coils  Corpses, 2014-09-05
==

in attendance: Zooko (scribe), Daira, Nathan, Brian

We looked at http://filecoin.io/filecoin.pdf . We wondered why
everyone should pay miners to store all files, instead of people who
care about specific files paying miners to store those specific files.

Brian said I'm kind of excited about filecoin because it seems like
we (the industry) are slowly circling back around to Mojo Nation. And
I'm hopeful that we've learned something in the last 20 years and will
do it better this time...

Daira asked Are any of these people referencing Mojo Nation? I don't think so.

Zooko had something on the whiteboard behind him that looked like a
capitalization table. When asked about it, he said it was very
exciting.

We wonder if the Proof-of-Work part of filecoin is there *solely* to
provide a random beacon, in order to prevent miners from stacking up
their winning result in the current mining round, plus setting up
future rounds...

We don't understand what reward filecoin miners get for satisfying a
GET transaction.

Zooko says that Andrew Miller says that Bitcoin has a mechanism design
flaw, which is that one miner gets a reward for adding a UTXO, thus
obligating all future miners to store the UTXO if they want their
reward. Eventually, says Nathan, the cost of storing those will rise
to exceed the mining reward.

We want to organize a videocall chat session with all the distributed
storage folks: Tahoe-LAFS, Filecoin, Permacoin, StorJ, Ethereum, and
MaidSafe.

We talked about documenting and advocating the Tahoe-LAFS format (the
process of getting from a piece of plaintext to an immutable file read
cap). Zooko believes that the presence of erasure-coding in Tahoe-LAFS
excludes it from a lot of use-cases where people don't need
erasure-coding and don't want the added baggage of it being defined in
the format. Nathan argues that we could offer a simplified version in
which the erasure-coding is still in the format but is hard-coded to
k=1, n=1. Nathan suggests that libraries/APIs could be re-used instead
of or in addition to specifications.

What will we talk about at the next Tesla Coils and Corpses? Maybe
secure invitations, which Brian has been experimenting with in
PetMailV2, and might want to bring back into Tahoe-LAFS. A
user-experience-oriented approach: I'm a user. I have this vague idea
that I want to use Tahoe-LAFS. What does that mean?

The user experience flow would be a lot like the current flow, in
which you get an email that says Alice wants to share something with
you on blahblah, except instead of Alice introducing you to a
centralized service in order to share something with you, she's
introducing you to a decentralized network.

Brian has an experiment of a more transparent, visible backup process,
named Ice Backup in which it shows all the files on your system in a
sunburst display, and a dotted line is sweeping around like a clock
hand showing how many files it has already hashed in order to find out
if they have changed and need to be backed up, and another clock hand
is sweeping around showing which ones have been backed up.


-- 
Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Tesla Coils Corpses report, 2014-08-30, hash-based digital signatures

[Zooko Wilcox-OHearn]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-
.. -*- indent-tabs-mode: nil -*-

LAFS Tesla Coils  Corpses, 2014-08-30
==

in attendance: Zooko (scribe), Daira, Andreas Hülsing, Arthur, Taylor, Christian

We talked about improved hash-based digital signatures. The question
is if we can strengthen the security even more than our previous
designs.

The goal is for the security to rest only on very conservative
assumptions about the properties of the underlying secure hash
function. We've already gone quite a long way on this, but we'd like
to even further strengthen it. If possible, we could define a
signature scheme so that *any* successful forgery attack against the
signature scheme necessarily implies a violation of the Target
Collision Resistance property of the hash function. (This is what
they call provable security, but might be more usefully called
using security reductions.)

We would, of course still require the stateless property of the final design.

Along the way, we're also exploring a few more tweaks that might help
in optimizing the performance.

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Tesla Coils Corpses, 2014-08-22 — cryptocurrency 2.0 storage, Ethereum

[Zooko Wilcox-OHearn]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-
.. -*- indent-tabs-mode: nil -*-

LAFS Tesla Coils  Corpses, 2014-08-22
==

in attendance: Zooko (scribe), Andrew, Daira, Nathan

Zooko has been noticing all these distributed-storage projects coming
out of the cryptocurrency world: Permacoin
(https://www.cs.umd.edu/~elaine/docs/permacoin.pdf), StorJ
(http://storj.io/), MaidSafe (http://maidsafe.net/), a recent blog
post from Vitalik Buterin
(https://blog.ethereum.org/2014/08/16/secret-sharing-erasure-coding-guide-aspiring-dropbox-decentralizer/),
and IPFS/FileCoin (http://filecoin.io/). Zooko is saddened that none
of these projects are building on Tahoe-LAFS, nor even studying
Tahoe-LAFS and learning from its successes and its mistakes.

Andrew says they all have broken incentives, will eventually get
exploited, but none of them come with a good model or formalism with
which to succinctly show that it is broken.

Zooko suggests Mechanism Design as that formalism
(https://en.wikipedia.org/wiki/Mechanism_design ).

Then we switched gears:

Andrew showed us an Ethereum script which sets a mutable variable to a
value then does some stuff, and surprisingly that variable has the
wrong value after. If you try to fix this by adding locking, then the
locking may prevent an otherwise useful and desirable use case.
https://gist.github.com/amiller/cdc42df919a9b1dcf7df#file-concurrency_example-py

Zooko pointed out that this is the same pattern of examples shown by
Mark S. Miller in his PhD dissertation
(http://www.erights.org/talks/thesis/index.html), which is there
called Plan Interference.

Andrew proposes an Ethereum message-queue dispatcher (implementing an
eventual-send).

Nathan: There's a proposal for an Ethereum thing called alarm. That
could be used for the eventual-send message.

Daira: Where's the best documentation for the Ethereum language?
Andrew: the yellow paper.

Daira finds these systems difficult to think about because they are
*almost* capabilities-as-data systems except that the mailbox
addresses are not secret.

Andrew wonders if you could layer capabilities on top by having a
little table of which contract is allowed to send messages to which
contract.

Zooko says that would be a C-list, implementing a capabilities-as-access system.

So Andrew went and implemented one right at that moment:
https://gist.github.com/amiller/dab7b9d2aece26f5bf20

Zooko noticed that it had a flaw — it allowed Alice to give a
Bob-reference to Carol even if Alice didn't have a reference to Carol.

Caps-as-access can implement the *-property, and confinement in
general, Caps-as-data can't.

Daira says I think I've been convinced that it is possible to
implement an obj-caps system in Ethereum.

Andrew wants to be able to connect two objects within the ocap graph
even if neither created the other, and there is no path through the
ocap graph that connects them. Why? Because Andrew might already own
some Ether, and there could be an Capthereum-based club, like a
lottery, and Andrew might want to play their lottery.

We proposed a hybrid in which some sorts of things in Ethereum-world [
* ], which have private keys, can register themselves with the
Introducer in order to linked in to the ocap graph, but other sorts of
things, that created by contracts, through the cap-manager, can't do
that and so they can be confined.

[* Zooko doesn't understand Ethereum well enough to understand what
sorts of things Andrew and Nathan were talking about.]


-- 
Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

report from the Nuts Bolts party, 2014-08-19 — lots of nuts, lots of bolts

[Zooko Wilcox-OHearn]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-
.. -*- indent-tabs-mode: nil -*-

LAFS Nuts And Bolts Party, 2014-08-12
=

in attendance: Zooko (scribe), Meskio (IRC), Daira, Zancas, Nathan,
dstufft (IRC), Riastradh (IRC), cypher (IRC)

We're reviewing the second version of meskio's branch
(https://github.com/tahoe-lafs/tahoe-lafs/pull/99) for
(https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2045).

We made a lot of progress on
(https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2235)! See
https://github.com/tahoe-lafs/tahoe-lafs/pull/103.

We need more and better-oiled Windows buildbots. Currently
(https://tahoe-lafs.org/buildbot-tahoe-lafs/waterfall?show_events=true)
we have Dcoder's Win7-64 py2.6 and Marcus's Cygwin WinXP, but they
are usually not turned on and connected to the buildmaster. Also,
Zooko says WinXP is obsolete and we should probably not try to support
it at all. Daira disagrees and wants to continue supporting WinXP.

Zooko asked Daira (who is one of the administrators of the
https://Tahoe-LAFS.org mailing lists) to make a new mailing list for
buildbot operators.

Daira wrote a test called test_create_long_filename in test_util.py
that exercises (https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2235).

Zooko wrote several iterations of new entry-level documentation
explaining the `tahoe backup` command, iterating with Riastradh and
cypher: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2280

Meskio commented that `tahoe backup` was too slow, for him, because he
had many small files and it take a bit of time for each file, and he
switched duplicity↔Tahoe (using duplicity's builtin support for a
Tahoe backend, *not* using FUSE and/or SFTP) and it worked well.

We worked on some packaging/build problems, with dstufft's help:
* https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2249
* https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2283

Zooko is really glad that as part of his job at LeastAuthority.com, he
gets to take a break from “CEO stuff” once a week and muck about with
Python packaging bugs and Tahoe documentation tweaks. ☺

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Nuts and Bolts, 2014-08-12

[Zooko Wilcox-OHearn]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-
.. -*- indent-tabs-mode: nil -*-

LAFS Nuts And Bolts Party, 2014-08-12
=

in attendance: Daira, Zooko (scribe), Zancas

interesting bug that's just been filed:
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2276

It is a special case of https://tahoe-lafs.org/trac/tahoe-lafs/ticket/731

We closed http://foolscap.lothar.com/trac/ticket/224 , which Brian has
already fixed in Foolscap trunk, and linked to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755339 .

Zooko reported a bug on the foolscap trac by emailing Brian.

Zooko reported a bug against buildbot (mentioned in a previous Nuts 
Bolts report): http://trac.buildbot.net/ticket/2870

Daira attempted to run the tests for meskio's branch on Windows and
failed because of the details of Windows being rubbish.

We reviewed some more patches on meskio's branch.
https://github.com/tahoe-lafs/tahoe-lafs/pull/79

Zooko read the changelog of buildbot-0.8.9 to see if we need to
upgrade from buildbot-0.8.8
http://docs.buildbot.net/0.8.9/relnotes/index.html

Opened tickets:

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2278
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/592
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2277

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Nuts and Bolts, 2014-08-05 — making a Debian-compatible config, how to run tests

[Zooko Wilcox-OHearn]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-
.. -*- indent-tabs-mode: nil -*-

LAFS Nuts And Bolts Party, 2014-08-05
=

in attendance: Daira, Nathan, Zooko (scribe), Meskio, Cypher (lurker)

theme: make Tahoe-LAFS be a proper daemon instead of a user-app from Debian's
perspective

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2045# Make the paths of the
different folders configurable

Meskio already has a branch with a lot of patches, which has already gotten
some review and iteration with Leif:

https://github.com/tahoe-lafs/tahoe-lafs/pull/79

Daira and Nathan and Zooko started reviewing the patches and posting
comments.

Meskio started writing a new branch with patches that address the review
comments.

Nathan tried to run the tests, and encountered some problems:

1. He grepped for instructions for how to run tests in the docs/ subdir and
   didn't find any such instructions.

   (He didn't notice the part of
   
https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/quickstart.rst?rev=82579cec966c3b8b0c2161c1946be01b6953f610
   that said to run python setup.py trial.)

2. He got confused when he learned that there were two different commands
   that you could pass to python setup.py to run tests. You can run python
   setup.py trial or python setup.py test. He began to wonder how these
   behaved differently from one another and whether one or the other was a
   convention shared with other software projects beyond Tahoe-LAFS.

3. He was further nonplussed when I told him that there was also a Makefile
   so that you could use make $MAKECOMMAND instead of python setup.py
   $SETUPCOMMAND.

4. He was further nonplussed when I told him that there were at least two
   commands defined in the Makefile for running tests.

5. He was further nonplussed when I told him that the documentation that he
   failed to find in the docs/ directory was in fact hosted on the wiki:
   https://tahoe-lafs.org/trac/tahoe-lafs/wiki/HowToWriteTests (which,. while
   it is about how to *write* tests, also includes instructions on how to
   *run* tests).

6. He was further nonplussed when it turned out that the instructions on that
   wiki page do not tell you to use any of the four ways of running tests
   mentioned above, but instead instroduce a *fifth* way of running tests::

  ./bin/tahoe @coverage run --branch --include='src/allmydata/*'
@tahoe debug trial allmydata.test.test_fname

At this point, Nathan disconnected from the videoconference. I'm not sure if
it was due to a network outage at the San Francisco coffeeshop that he was
sitting in, or if his head exploded.

How could we improve this situation? First of all we should start with the
docs. We need a doc that is discoverable when someone looks for how do I run
tests?.


Then the scribe (Zooko) had to leave, after only 1 hour and 23 minutes of
Nuts and Bolts Party goodness, so this missive here ends.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Tesla Coils and Corpses, 2014-08-01 — Ripple/Stellar/etc.

[Zooko Wilcox-OHearn]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-
.. -*- indent-tabs-mode: nil -*-

LAFS Tesla Coils  Corpses, 2014-08-08
==

in attendance: Taylor, Zooko (scribe), Nathan

Ripple consensus mechanism: ??? Zooko has heard second-hand that there
has never been documentation of the consensus mechanism. Zooko assumes
that it is effectively a simple federated-centralized mechanism, where
there are a small number of special organizations, and everyone relies
on that set of organizations for double-spend-protection. So it isn't
really decentralized in the Bitcoin sense. (But it isn't a bad
architecture, in Zooko's opinion! (Zooko got most of his opinions
about Ripple from Andrew Miller.))

Nathan wants to back off from Bitcoin-style distributed consensus and
consider whether there are other paths through the design space. So
here's a nice narrowly-scoped section of the design space: there is a
cryptoledger system in which people control private keys and can sign
over some of their assets to other public keys, and there's only one
ledger server. And we assume that it is partially corrupt in that
would engage in rollback/replay/double-spend attack if it were
profitable. Now, can we make it unprofitable?

Nathan was frustrated with Ripple.com. There's a note that says It
will be open-sourced soon.. Nathan can't find actual protocol docs,
etc. etc.

Zooko says I have a suggestion for you: stop looking at ripple.com;
look at stellar.org.. Nathan looked at stellar.org and saw a github
link at the top of the front page. He felt better. Then he found an
actual API doc, and felt much better.

I think there might have been a lot more discussion in this session,
but I stopped taking notes and a week later when I looked back at it,
I couldn't remember. Sorry!
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Tesla Coils and Corpses report, 2014-08-01

[Zooko Wilcox-OHearn]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-
.. -*- indent-tabs-mode: nil -*-

LAFS Tesla Coils  Corpses, 2014-08-01
==

in attendance: Zooko (scribe), Taylor, Nathan, Brian

Example of servers with disjoint sets. If the reader uses union on
read, then each server (or coalition thereof) gets to choose whether
their uniquely-held elements will be included or excluded from the
reader's view. This bothers Zooko. Because editorial or filtering
and selection power is close to *write* power in Zooko's mind. (ref.
The Library of Babel, Daniel Dennett's version)

Taylor suggested biggest set instead of union, unanimity, majority,
etc. Zooko likes the idea!!

Brian suggested that good adders who like to limit the freedom of the
servers could be expected to download the previous set or remember the
previous set in their local state.

Brian suggested that the servers could enforce upon the adders that
they don't send add commands without a proof of knowledge of the
current version. But we decided against that because the lob an
element into the set, even though I don't know anything about the set
is a valid use case. (Example: a write-intensive workload like secure
distributed logging, where the performance and availability
consequences of requiring read-before-every-write would be
intolerable.)

The protocol for uploading has to require adders to provide the
transitive closure of elephants in case the server doesn't already
have them. Should that be an interactive protocol or…?

We talked about Two-Phase-Commit. It can eliminate (assuming correct
implementation) a single server entering a broken state due to a
partially-applied update. It can *reduce*, but not eliminate version
skew between servers, where some of the servers have (atomically)
updated to the new version and others have (atomically) rolled-back to
the current version.

We talked about building distributed ledgers on top of add-only sets.
Nathan is keen on this idea of using add-only sets as a primitive
building-block for Bitcoin-like distributed ledger systems.

Then we started talking about our plans for a cryptocurrency startup…

-- 
Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Nuts and Bolts report, 2014-07-22

[Zooko Wilcox-OHearn]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-
.. -*- indent-tabs-mode: nil -*-

LAFS Nuts And Bolts Party, 2014-07-22
=

in attendance: Zooko (scribe), Daira, Zancas

theme: disable assembly optimizations in pycryptopp

In the history of pycryptopp, about 1/2 of the bugs have been due to
the asm optimizations in Crypto++. And, the C++ implementation is
already fast enough.

In order to make changes to the pycryptopp build system, we first need
to write a unit test of the configuration interface described in
https://github.com/zooko/pycryptopp/commit/5c2e0f729a25eee8f374ff79a9299a818c378bc2#commitcomment-3005081
.

In order to write such a unit test, we need to set up automated
running of unit tests of packaging, as described in here:

* https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2050# Expand
HowToWriteTests to packaging and distribution tests
* https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2049# Decide where
packaging tests should live.

Daira argued that maybe we should disable asm optimizations
unilaterally instead of supporting an optional build with asm
optimizations feature, but we decided that other packagers (e.g.
Debian) are certainly going to want that and we might as well support
it ourselves instead of making them patch it in.

Then we switched topics, because Daira is discouraged about packaging
issues of all sorts. So we asked: what does Daira like? What would be
fun? The answer is: harden the WUI!

So Daira and Zancas started working on:

* https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2136# Use
Content-Security-Policy to harden the WUI
* https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1797# WUI: view
content in an HTML5 sandboxed iframe

(Zooko kept poking at the pycryptopp/assembly-optimizations/packaging
stuff on the side for the rest of Nuts and Bolts, because he — for
whatever reason — is *not* currently despairing about software
packaging.)

Daira looked through our ticket garden
(https://tahoe-lafs.org/trac/tahoe-lafs/wiki/ViewTickets) for other
headers that we should send to harden security. She decided that
preventing content-type sniffing
(https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1455) was too complex
and put it aside for now. She decided to include the option to prevent
frame-busting. The reason we're doing both at once is that CSP sandbox
and frame-busting-prevention are complementary to one another.


Zancas admired the buildbot's console page:
https://tahoe-lafs.org/buildbot-tahoe-lafs/console but it appears to
have a bug. The top row is about a git commit fac1f0d55a7c..., but
the cell showing the result of the build for the FreeStorm
CentOS6-amd64 builder shows this build:
https://tahoe-lafs.org/buildbot-tahoe-lafs/builders/FreeStorm%20CentOS6-amd64/builds/0
which describes git commit 4889129f3732219cb9cedb1eb27dec3da3f22db2.
That seems inconsistent. Those two git commits should be the same as
one another, but are different. Is this a bug in buildbot?


Zooko wrote a catalog of all pycryptopp bugs ever and classified
whether they were security-relevant or not and whether they would have
been avoided by disabling assembly:

https://tahoe-lafs.org/pipermail/tahoe-dev/2014-July/009134.html





-- 
Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Tesla Coils and Corpses report, 2014-07-25

[Zooko Wilcox-OHearn]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-
.. -*- indent-tabs-mode: nil -*-

LAFS Tesla Coils  Corpses, 2014-07-25
==

in attendance: Zooko (scribe), Daira, Andrew, Nathan, Brian (last minute)


topic: add-only sets!

Nathan points out that the Tahoe-LAFS concept of add-only sets has much in
common with open topics in crypto-consensus algorithms (e.g. Bitcoin).

We looked at our current best design for add-only sets
(https://tahoe-lafs.org/trac/tahoe-lafs/ticket/795#comment:13 ), which is
known as The Elephant Circus Design.

Daira wanted to know: what does the reader do? The design described in
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/795#comment:13 is silent on
that critical question. We had some discussion of the weird way in which a
simple union-read might somehow allow servers, authorized-adders, or a
collusion of those two, to exercise what Zooko calls editorial control.

What should the Diminish-Relations be between caps? The description at the
top of https://tahoe-lafs.org/trac/tahoe-lafs/ticket/795 has write-cap
diminishable to append-only cap, but Zooko doesn't think there should *exist*
a write-cap, since a write-cap is a thing that can violate the add-only
property.

Brian has an idea about a write-cap being used for a sort of
compacting/garbage-collection process that could occasionally rewrite the
state for efficiency, but Zooko (at least half the time) thinks that we can
get away with not having that, and instead having a stronger security
property. The stronger security property is that *nobody* *ever* has the
authority to violate the add-only property.

Note that if we do the can't-be-rewritten version, so that add-only sets
inevitably get more and more heavyweight as they get bigger, then
applications written on top might choose to emulate the rewritable version by
having all readers switch to a new add-only set once the old add-only set
gets too heavy.

We decided that this is actually a multiset, not just a set.

Nathan suggested that for some uses cases an add-only multiset API is the
right API, but for other uses the underlying partial order might be
important.

We talked about the use case of building append-only files of records on
top of the add-only multiset. That is definitely a use where having access to
the underlying partial order can be valuable, because without it you have to
sort the entire set of records, but with it you can sort only those subsets
which are still ambiguous after applying the underlying partial order.

We talked about the use case of building append-only log files on top of
append-only files of records. Zooko is enthusiastic about append-only log
files.

Daira asked if the elephants should be size-limited. Brian argued that
accounting and consistency would be easier if the net were wrapped around the
entire elephant, instead of the net being wrapped just around the elephant's
trunk and you can go find the right elephant if you need it.

Does the append-only-file-of-records protocol need to *prevent* an authorized
appender from appending a record without proving knowledge of the previous
record? Without proving knowledge of the previous record *from* them? No, the
protocol does not need to prevent those things. Appenders are not constrained
in these ways. The goal of append-only is just that all readers will see the
same total order as one another.

Daira says they should be called add-only DAGs instead of add-only multisets.

Nathan started writing the Python API for append-only files of records in
the branch named 795-add-only-sets_0. Brian pointed out that the current
Python API to mutable files has much in common with the new API for
append-only files.

Use case: secure logging

Use case: chatroom, elephants are messages from different people

Use case: the OS 10 Dropbox/Publc Box thing which people can use to give me
files but they can't see what files have been given to me.

Use case: announcements on a shared grid

Use case: secure backups, defense against ransomware


-- 
Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

a catalog of bugs, or Why to disable assembly optimization

[Zooko Wilcox-OHearn]

Folks:

We had already agreed to disable assembly optimizations in pycryptopp,
because there seem to have been a lot of bugs in the optimized
assembly code in the past, and because the added speed really makes no
difference to our uses, as far as I know.

However, in order to explain and justify to other people (e.g. Debian
packagers) why we are doing this, and why they should consider doing
the same thing themselves, I just read through the entire history of
issues in pycryptopp and classified whether they were runtime errors
(and therefore potential security bugs) or build-time errors
(therefore probably not), and whether they would have been avoided if
we had been disabling assembly optimizations all along. Here are the
results. They clearly show that we should disable the optimized
assembly! About half of all the security-threatening bugs we've had
would never have been an issue if we'd avoided assembly from the
beginning.

By the way, in my opinion the author of Crypto++, Wei Dai, is an
*exceptionally* skilled, careful, and experienced coder, and I would
assume that if Crypto++ has had this many security-threatening bugs in
its optimized assembly code, then other crypto libraries that also use
optimized assembly code also have at least as many.

Here's the ticket to track this issue:

https://tahoe-lafs.org/trac/pycryptopp/ticket/85

bugs that cause run-time failures
=

(These bugs are potential security issues.)

* would have been avoided by DISABLE_ASM:
  - https://tahoe-lafs.org/trac/pycryptopp/ticket/24
  - https://tahoe-lafs.org/trac/pycryptopp/ticket/31
  - https://tahoe-lafs.org/trac/pycryptopp/ticket/45 (three
*different* bugs in the assembly implementation)
  - https://tahoe-lafs.org/trac/pycryptopp/ticket/67
  - https://tahoe-lafs.org/trac/pycryptopp/ticket/84
  - https://tahoe-lafs.org/trac/pycryptopp/ticket/86

* unclear if it would have been avoided if we'd used DISABLE_ASM:
  - https://tahoe-lafs.org/trac/pycryptopp/ticket/65

* would not have been avoided by DISABLE_ASM:
  - https://tahoe-lafs.org/trac/pycryptopp/ticket/17
  - https://tahoe-lafs.org/trac/pycryptopp/ticket/44
  - https://tahoe-lafs.org/trac/pycryptopp/ticket/83

* would not have been avoided by DISABLE_ASM (but would have been
avoided by using cffi instead of CPython API)
  - https://tahoe-lafs.org/trac/pycryptopp/ticket/19
  - https://tahoe-lafs.org/trac/pycryptopp/ticket/70
  - https://tahoe-lafs.org/trac/pycryptopp/ticket/80

* would have been avoided if we *didn't* use DISABLE_ASM! (A bug only
in the non-ASM version!)
  - https://tahoe-lafs.org/trac/pycryptopp/ticket/66


bugs that cause deterministic build or compilation failures
===

(These bugs are *typically* not potential security issues but they can
be, and in any case they are engineering/deployment issues.)

* would have been avoided by DISABLE_ASM:
  - https://tahoe-lafs.org/trac/pycryptopp/ticket/37
  - https://tahoe-lafs.org/trac/pycryptopp/ticket/96

* would not have been avoided by DISABLE_ASM:
  - https://tahoe-lafs.org/trac/pycryptopp/ticket/22
  - https://tahoe-lafs.org/trac/pycryptopp/ticket/23
  - https://tahoe-lafs.org/trac/pycryptopp/ticket/32
  - https://tahoe-lafs.org/trac/pycryptopp/ticket/39
  - https://tahoe-lafs.org/trac/pycryptopp/ticket/62
  - https://tahoe-lafs.org/trac/pycryptopp/ticket/77
  - https://tahoe-lafs.org/trac/pycryptopp/ticket/78


-- 
Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: unsubscribe from list serve please

[Zooko Wilcox-OHearn]

On Mon, Jul 14, 2014 at 8:06 AM, Jimmy Tang jcft...@gmail.com wrote:
 I missed this but ...

 https://github.com/jcftang/homebrew-jcftang/blob/master/allmydata-tahoe.rb

 Assuming you use homebrew you can use the above formula to install it on OSX

Well that's pretty sweet! Although I'm guessing that it won't help
fanona grace, because she probably doesn't use homebrew either.
fanona grace?

Jimmy, and anyone else: where should the existence of this homebrew
recipe be documented? Here:
https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Installation or here:
https://tahoe-lafs.org/trac/tahoe-lafs/wiki/RelatedProjects or
somewhere else?

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Nuts And Bolts report, 2014-07-08

[Zooko Wilcox-OHearn]

in attendance: Brian, Nathan, Zooko (scribe)

topic: packaging! automated testing! automated testing of packaging!

We got the pycryptopp buildmaster running again:

https://tahoe-lafs.org/buildbot-pycryptopp/waterfall

FreeStorm fixed up the passwords on his buildslaves so they would
reconnect. The buildmaster now uses publicly visible config:

https://github.com/tahoe-lafs/buildbot-config-tahoe

That way people can fork and pull-request in order to improve the
buildmaster config.

We've finished moving from darcs to git.

* https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1644# move to git
* https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2049# Decide where
packaging tests should live.
* https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2051# Publish the
buildbot configuration in a public repository  define where to track
its issues
* https://tahoe-lafs.org/trac/tahoe-lafs/ticket/570# buildbot trac integration
* https://tahoe-lafs.org/trac/tahoe-lafs/ticket/630# automated tests
of debian compatibility: run-from-source and run-from-.deb-package

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

HOPE-X!

[Zooko Wilcox-OHearn]

Folks:

I'm going to attend the HOPE-X conference (https://hope.net/), July
18–20 in New York. I intend to hang out with the anti-censorship
community at the Noisy Square
(https://wiki.hope.net/w/index.php/NoisySquare). I'm hoping to make
more progress on integrating Tor, Tails, and Tahoe-LAFS. If you are
there, say Hi to me!

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Tesla Coils And Corpses report, 2014-06-19

[Zooko Wilcox-OHearn]

In attendance: Zooko (scribe), Glenn Willen, Dcoder, Brian

Zooko says that Bitcoin is doomed to mining centralization. He claims
that any pure-PoW system is so doomed, even with non-outsourceable
mining (a la Amiller's recent paper and Emin Gun Sirer's recent blog
post), because capital costs of mining are high and marginal operating
costs (power and cooling) are low. Glenn says, in support of that
claim, that ghash.io has about 25% of Bitcoin's mining power in its
own physical control. Zooko says, yeah, even if Bitcoin had been
non-outsourceable from the beginning, Ghash.io would still be halfway
to Dominant Miner by now, so non-outsourceable only *slows* the
process of centralization.

Hypothesis: low or no capital cost and high marginal operating costs
would solve the problem of mining centralization. Why? Zooko has
trouble articulating why he thinks this. It has to do with the idea
that you can't establish an *incumbent position* that gives you an
advantage over a newcomer. There's no barrier to entry. Does that slow
or even prevent the process of mining centralization?

Glenn pointed out that with the current Bitcoin Proof-of-Work system
expected returns on mining are being pushed close to or even below 0.
So, shouldn't *that* have the same effect as Zooko's claimed effect of
high marginal operating costs? Zooko thinks it doesn't have the same
effect, but has trouble articulating why. Something about the
investment and commitment of buying/building hardware for PoW mining.

Zooko's Pay-To-Mine idea is a way to make marginal operating costs
high and capital investment costs 0. It is similar to or perhaps
identical to some variants of Proof-of-Stake (but Proof-of-Stake
is an inaccurate name for it), and Zooko hasn't been able to figure
out how to make it actually secure. He brought some proposals to
Amiller, who explained challenge scenarios that Zooko's proposals
couldn't handle.

We talked for a bit about the problems of Pay-To-Mine. Basically, if
some miners controlling an aggregate amount of resource, X, attest
that you can rely on a given transaction because they bless it as
being the first/only transaction that spends the money, then how can
you know whether, after you decide to rely on that, that a new, bigger
coalition controlling a greater amount of resource, Y, will arrive and
reverse it, saying that the transaction is the loser in a
double-spend?

Zooko claims that Proof-of-Work systems have an analogous problem, as
Ben Laurie has argued
(http://www.links.org/files/decentralised-currencies.pdf ). (I.e. that
the word resource in the previous description could mean either
hash-power or pay-to-mine money.) Zooko uses the example of The Alien
Miner, who appears, wielding vastly more hashpower than all of
humanity combined.

Then we went back to the topic of whether Pay-To-Mine, if it *could*
be made secure, would achieve anti-centralization. Here's the argument
for why it could:

Because of The Sybil Problem, our system can't distinguish between a
giant miner who controls 51% of all the resource (whether that
resource is proof-of-work-power or money with which to pay-to-mine,
either way), and millions of small players who collectively control
51%. The Sybil Problem is the problem that no open system can
distinguish between those two situations — a big player can, if it is
advantageous to them, choose to appear as a lot of small players, or
else to appear as a single big player, or any combination thereof.

So, our approach is that we aren't going to attempt to distinguish
between big players and lots of small players, but we're going to
offer a mining operation which is *unattractive* to the big player but
attractive to the small player. There are two ways that we can
financially engineer an offering to be attractive to small players but
not big players.

One is that the reward from mining could be low expected return and
extremely low or no variance. Suppose you have to invest your money
for 28 days in order to mine, and at the end of it you get 1.2X
your investment back, with no variance. (Zooko got this number by
looking at the most recent auction price of 28-day T-bills.)

Then, according to this theory, people who have only a little money,
like $1000 worth, might *store* it into cryptocurrency mining because
it is safe, and getting $1000.02 back is better than what your local
bank would give you. Whereas people who have a lot of money might find
a more attractive investment that has a higher expected return.

Brian said, what would we have to do to *guarantee* that there is a
better use of money for the rich people? What characteristic of the
economy is this, that you can find more profitable uses for your
money? Zooko said, well I had been assuming that the economy will
provide it for us. But, now that you ask, what *would* we have to do…
Then Zooko remembered another of Amiller's crazy ideas: lotteries!

So, the idea is, we can have two kinds of mining, one that has
extremely low 

Re: Need help w the program please

[Zooko Wilcox-OHearn]

Hello fanona grace:

I'm sorry you've been having trouble installing the software. Could
you give me the hyperlink to the instructions or documentation that
you've been following?

According to the Frequently Asked Questions page on the wiki
(https://tahoe-lafs.org/trac/tahoe-lafs/wiki/FAQ#Q7_mac_os_x) it is
possible to install Tahoe-LAFS on Mac OS X by following these
instructions: https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/quickstart.rst

Are those the instructions that you were attempting to follow when you
got stuck?

Thanks!

Regards,

Zooko
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: [Tails-dev] Tahoe-LAFS persistence

[Zooko Wilcox-OHearn]

Hi, I'm a Tahoe-LAFS core dev. I'm excited about the possibility of
Tahoe-LAFS becoming really useful to Tails users, and I'm grateful to
others, especially David Stainton, for moving this forward.


On Sun, Jun 1, 2014 at 12:46 PM, David Stainton dstainton...@gmail.com wrote:
 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
 to mention install Tahoe-LAFS using the Debian package.

Well, hold on, if people start by going to the Tahoe-LAFS home page
(https://Tahoe-LAFS.org), then they see a prominent big blue button
labeled Download Tahoe-LAFS. If they click that button, it takes
them to https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Installation ,
which prominently advertises Debian (as well as Ubuntu, Arch Linux,
NetBSD, Slackware, SmartOS, and NixOS), and which *less* prominently
offers a hyperlink named Run this release from source. which takes
them to the quickstart.rst.

So, it seems like if they got to the quickstart.rst from that path,
then they don't really need an added link or text on quickstart.rst
pointing them back the way they came!

What if they got to the quickstart.rst from a different path? Well, my
first suggestion would be to find the thing that pointed them to
quickstart.rst, and have it point them to
https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Installation instead.


 2. Tails persistent volume assistant feature additions:

 It's good to have a concrete integration proposition! Looks good to me
 (understandable and usable), but i'm curious about other people's
 opinions. And... would that not be better to have, like you propose, 3
 columns, but the third being Tahoe, so users can choose to persist
 localy, OR on Tahoe, OR both - by selecting one column, the other, or
 both. But... Tahoe column should be grey if Tahoe has not been configured.

I'd like to raise a warning flag here to indicate that it might be a
mistake to categorize Tahoe-LAFS as being a persistence solution. It
does *not* function super well when used as a local filesystem. Think
of it instead as an alternative to SFTP. Or as an alternative to
Bittorrent, which offers an *upload* action in addition to a download
action.

Here is my write-up for how Tails users could potentially use
Tahoe-LAFS instead of SFTP:

https://labs.riseup.net/code/issues/6227#note-20

On the other hand, as that write-up suggests, Tahoe-LAFS *might* be
okay as an alternative to a (local) persistence solution, as long as
the user doesn't mind the long lags on every action, doesn't mind that
it breaks if it can't connect to the Internet, and doesn't use an app
that tries to do a lot of small writes to disk, and doesn't use an app
that times-out and gives up if its reads or writes take more than a
few seconds to complete.

So, I don't want to say Stop! Do not go forward and experiment with
Tahoe-LAFS as a persistence tool., because it *might* work. But I do
want to say Why don't we use it for what we know it is good at, and
we can also do an experiment in using it as a persistence tool, and
let it be okay if that experiment fails..

So my question for Tails devs (this is where my ignorance begins):
does Tails come with an SFTP client? Does it come with a Bittorrent
client? Can we make Tahoe-LAFS be the third thing next to those two
things?


 4. Tahoe-LAFS backup GUI applet

 I'll be opening a Tahoe-LAFS trac ticket about this one soon.
 Of course it will have to be written for the same desktop environment
 that Tails uses.
 I agree that this is lower priority than hacking the persistent volume 
 assistant
 and writing a Tahoe-LAFS client configuration assistant. I will work
 on those first.

I agree that Tahoe-LAFS is good for backup.


By the way, I'm the founder of a company trying to commercialize
Tahoe-LAFS, and we'd like to offer some free storage service as a way
to help this effort along. I haven't figured out how to make it useful
to Tails users (and devs) while limiting the amount of expense it
would cost us to maintain it. One idea I just had is to hack our
backend servers to reject any uploads of ciphertext files that are
larger than about 100KB. I am guessing that this might make it still
usable for config files, text documents, HTML pages, etc., but not
usable for the photo, music, and movie files that might otherwise
quickly start costing us too much to maintain. Any thoughts about
that?

(Obviously, someone could work-around that limitation by breaking
their large files into many pieces, but I assume that wouldn't happen,
at least not soon, because anyone who understands the system well
enough to do that understands that doing that would force us to
shutdown the free service, simply by ramping up our costs. If that's
their goal, they could accomplish it just as well by writing a script
to upload an infinite stream of files read from /dev/urandom.)


Regards,

Zooko 

Re: [Tails-dev] Tahoe-LAFS persistence

[Zooko Wilcox-OHearn]

On Sun, Jun 1, 2014 at 3:11 PM, Greg Troxel g...@ir.bbn.com wrote:

 This can be viewed as a bug in tahoe :-)
 But seriously, fixing the FUSE interface would be a great contribution.
 It's not clear to me how efficient the FUSE interface has to be before
 it isn't the limiting issue; tahoe is not a fast filesystem.

Like Leif mentioned in reply, there *is* the SFTPd that comes with
Tahoe-LAFS, and that is supported by the current Tahoe-LAFS core devs.
Like gdt, I also don't know whether its performance would satisfy for
this use case.


 Are you proposing to store the capabilities to access the persistent
 data on the local media (removable flash, I'm assuming)?   I've come
 into this thread somewhat late, but the security and usability
 properties are not entirely clear to me.

This is a key question (so to speak). How is the cap stored? The cap
is basically just the encryption key plus the URL to reach the remote
server. (The remote server stores only ciphertext, remember.) So, the
cap needs to be protected exactly like a symmetric encryption key
needs to be protected: if it is copied, the copier can read your
files, and if it is lost, then *you* can never again read your files.

I usually advise people to print the cap out on paper.


   (resident old-school unix crank on the tahoe list)

We love you, gdt. Never change.


Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: [Tails-dev] Tahoe-LAFS persistence

[Zooko Wilcox-OHearn]

On Sun, Jun 1, 2014 at 10:14 PM, Leif Ryge l...@synthesize.us wrote:

… many interesting things, including his sketch for a successor to, or
extension of, Tahoe-LAFS (chisel) …

  ***
  *** BACK TO THE NEAR FUTURE ***
  ***
…
 I look forward to seeing Tahoe integrated with Tails, but I am a little bit
 concerned about a potential pitfall which I think should be communicated to
 users somehow: there is no way to delete the ciphertext of immutable files
…
 This is rather different from a typical access control based system where one
 can simply change their password and/or ask the server to delete everything
 quickly.

We could implement this: add a feature that allows you to ask a server
to quickly delete a ciphertext. This would be analogous to having a
way to contact the owner of your SFTP server and ask her to delete a
ciphertext that you earlier uploaded into the write-only incoming/
directory on that SFTP server. There are two or three practical
engineering reasons that we haven't implement this, but the one I want
to emphasize here is that we haven't implemented it because it doesn't
provide good assurance of safety!

If you contact the owner of the SFTP server and ask her to remove the
ciphertext that you previously uploaded, and she writes back Okay, I
removed it., then how do you know she actually deleted it?

So, it isn't so much that Tahoe-LAFS is *less safe* than other
alternatives in this way, as that we think those other alternatives
are equally unsafe, and indeed it would offer a false sense of safety
to add this feature.

(Actually, Tahoe-LAFS is probably *more* safe than most alternatives,
because every file and directory has an independent encryption key, so
if a key of yours leaks or gets compromised, the exposure might be
limited, and objects that are protected by other keys may remain
safe.)

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: report from this week's Nuts And Bolts party

[Zooko Wilcox-OHearn]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-
.. -*- indent-tabs-mode: nil -*-

===
 LAFS Nuts And Bolts Party, 2014-06-02
===

in attendance: Zooko (scribe), Daira, dreid (sort of present)

topic: the Heartbleed Detection Patch (#2215 and #)

https://github.com/tahoe-lafs/tahoe-lafs/blob/b521ff0b33aaa3aff0431ff1944bc3fad4923101/src/allmydata/util/check_pyopenssl.py

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2215

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2215#comment:14

Daira doesn't agree with Zooko that Tahoe-LAFS should ignore OpenSSL
version numbers and do solely the active test. She doesn't agree because
she doesn't trust the active test to be accurate in both
no-false-positives and no-false-negatives directions. In particular, the
current test code, run against the current OpenSSL (v1.0.1g) from her
Debian-derived Linux distro, finds that OpenSSL emits *no* heartbeat
responses at all, even in response to well-formed (non-attacking)
heartbeat queries. What gives? Did Debian compile heartbeat support out
of OpenSSL?

Here's some text that Zooko wrote into a potential new README.rst file
for the potential new heartbleed-detector tool. This text is not (yet‽)
true.


heartbleed-detector -- see if your pyOpenSSL comes with the heartbleed
vulnerability


heartbleed-detector uses pyOpenSSL to test its openssl implementation for
heartbleed. It does this by actually attempting to exploit the heartbleed bug
(i.e., it sends 1-byte heartbeat message along with a bogus payload length =
4096), so we do not expect it to give false negatives nor false alarms.

That is: if it prints out THIS OPENSSL LIBRARY IS VULNERABLE TO HEARTBLEED.
then we are pretty confident that the vulnerability really is present in that
particular OpenSSL library (i.e., the OpenSSL library returns a buffer
containing more than one byte of data in the payload). If it prints out This
OpenSSL library is not vulnerable to heartbleed., then we are pretty
confident that the vulnerability really is absent from that particular
OpenSSL library (i.e. either it ignores the heartbeat request, or it returns
a buffer containing exactly one byte of data in the payload).

If it doesn't print out either of those things, then there is a different
bug, either in heartbleed-detector, in pyOpenSSL, or in OpenSSL, so please
open a bug report and paste in whatever traceback or other output it
produced.

heartbleed-detector has been tested with pyOpenSSL v0.13 and v0.14.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

report from Tesla Coils and Corpses meeting

[Zooko Wilcox-OHearn]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-
.. -*- indent-tabs-mode: nil -*-


 LAFS Tesla Coils  Corpses, 2014-05-29


in attendance: Zooko (scribe), Daira

Zooko is dreaming about launching a new cryptocurrency. It has two main
features. The first feature is SNARK-based unlinkable transactions, a la
ZeroCash ¹, which is the strongest kind of privacy yet invented for
cryptocurrencies.

¹ http://zerocash-project.org/media/pdf/zerocash-oakland2014.pdf

The second feature is all about marketing: we are willing to stand up and
say that privacy is a social good! We're creating this strongly private
cryptocurrency for good, not for evil. We believe that privacy makes
individuals, nations, and our planet-wide society stronger, safer, and
more prosperous. We believe that a decentralized protocol for private
execution of these sorts of transactions (e.g. money and domain names) is
necessary for planet-wide, borderless commerce.

Then we started talking about economics. Actually Zooko did most of the
talking. Zooko has recently had a shift in perspective, to thinking that
in a cryptocurrency *there is no inflation or deflation*.

Zooko thinks this because in a cryptocurrency there is no *uncertainty*
about future changes to the monetary base, or about what changes to the
monetary base have already happened, and therefore there is no inflation
or deflation as commonly understood from traditional economics. The
reward given to Bitcoin miners is a wealth transfer from all holders of
Bitcoin to the miner beneficiaries, but that transfer should *not* change
anyone's opinion about the overall value of Bitcoin vs. goods and
services, because everyone *knew* that it was going to happen.

One way to understand this perspective is to pretend you live in an
alternate universe where Bitcoin is exactly the same as in our universe,
except that the user-interface displays *only* the percentage of all
Bitcoin that you own. It never displayed the absolute number of Bitcoin
units. That would demonstrate to everyone that the reward given to miners
is a wealth transfer, causing the Bitcoin-percentage balances of everyone
else in the world to fall a tiny fraction of a percent and causing the
balance of the lucky miner to increase by exactly the sum of the amount
that everyone else's balances decreased. (It always adds up to exactly 0
because it is all transfer — there is no creation or destruction of
Bitcoin-percentage).

This would make it very clear to everyone that if, for example, you
engage in a long-term debt contract obligating you to pay 0.01% of
the world's Bitcoin to someone at some time in the future, that this will
be slightly harder for you amount to pay 0.1% of the world's Bitcoin
today. It would be slightly harder for you to pay in the future for the
simple reason that the percentage of Bitcoin that you own decreases a
tiny little bit every time a new block is mined.

We ended the meeting early because Daira was tired and because
LeastAuthority is in the middle of launching an upgrade to our secure
storage service.

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: report from Tesla Coils and Corpses meeting

[Zooko Wilcox-OHearn]

[following-up to my own post to correct an error and to give credit-where-due]

On Thu, May 29, 2014 at 11:41 PM, Zooko Wilcox-OHearn
zo...@leastauthority.com wrote:

 This would make it very clear to everyone that if, for example, you
 engage in a long-term debt contract obligating you to pay 0.01% of
 the world's Bitcoin to someone at some time in the future, that this will
 be slightly harder for you amount to pay 0.1% of the world's Bitcoin
 today. It would be slightly harder for you to pay in the future for the
 simple reason that the percentage of Bitcoin that you own decreases a
 tiny little bit every time a new block is mined.

Argh. I totally edit-o'ed that paragraph to death. I apologize to
everyone who wasted time trying to decode this. It should have said:

This would make it very clear to everyone that if, for example, you
engage in a long-term debt contract obligating you to pay 0.0001% of
the world's Bitcoin to someone at some time in the future, that this
will be slightly harder than to pay 0.0001% of the world's Bitcoin
today, for the simple reason that the percentage of Bitcoin that you
own decreases a tiny little bit every time a new block is mined.

On the credit-where-due front, having a recent private conversation
with Mark maaku Friedenbach, and listening to some not-so-recent
podcasts from econtalk.org (¹, ², ³) inspired this thinking. This
doesn't mean maaku or any of those economists agree with me, of
course.

¹ http://www.econtalk.org/archives/2013/03/sumner_on_money_1.html

² http://www.econtalk.org/archives/2012/10/garett_jones_on_2.html

³ http://www.econtalk.org/archives/2010/10/irwin_on_the_gr.html

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

report from this week's and last week's Nuts And Bolts

[Zooko Wilcox-OHearn]

===
 LAFS Nuts And Bolts Party, 2014-05-19
===

in attendance: Zooko (scribe), Aaron, Daira

Accumulo is a nosql db invented by Aaron that has fine-grained access
control. Each row-column pair in the table has its own access control
rules which are a set of boolean equations in a simple DSL that can be
satisfied with tokens provided by the queries.

Aaron invented it while working at NSA, for the purpose of being able
to store information with various classification levels or
compartmentalization tags in a single DB, instead of having a separate
DB for every such compartment. Nowadays it is the only nosql db that
you can get your boss to approve if you are working in the US
military/intelligence world and dealing with
classified/sensitive/secret data.

Aaron has successfully connected it to LAFS in place of its native
HDFS storage layer, and we talked about how to make sure the
write-ahead-log was durably synced, and whether Tahoe-LAFS mutable
file update performance would be acceptable, and stuff like that.

Aaron and Zooko talked about how they were going to demo Accumulo+LAFS
at the Pentagon later that week.

===
 LAFS Nuts And Bolts Party, 2014-05-26
===

in attendance: Zooko (scribe), PRab

Tahoe-LAFS v1.11.0 Milestone is shown as having been due to be
released back in Sept 2013. We should update that, but we don't know
to what new date to set it.

It shows 42 closed tickets in the 1.11.0 Milestone, and 24 active.
PRab asked if that means we're 2/3 of the way to the next release.
Zooko replied that almost all of those 24 open tickets we're *not*
actually planning to block the 1.11.0 release for. See the tag
blocks-release:
https://tahoe-lafs.org/trac/tahoe-lafs/query?status=!closedkeywords=~blocks-release
There are only 4 such tickets currently.

We talked about the work to integrate Tahoe-LAFS into Tails, and
specifically the intended use cases for why anyone would want that:
https://labs.riseup.net/code/issues/6227#note-20 . It seems like the
current blocker is that the Tails developers are waiting to hear from
some Tails users who say Yes! I used Tahoe-LAFS and it was even
better than SFTP!.

The public test grid was down due to the dynamic DNS service that
points to the introducer being down. PRab added the introducer's IP
address to his node and restarted it and it connected. PRab updated
https://tahoe-lafs.org/trac/tahoe-lafs/wiki/TestGrid

PRab uses Windows, and will test
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2235 .

Zooko had to leave early, so this was only 1/3 as long as a normal
Nuts and Bolts party.

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

looking for beta testers for S4-improved

[Zooko Wilcox-OHearn]

Folks:

S4 is LeastAuthority.com's commercially-supported Tahoe-LAFS storage
service. It currently uses Amazon S3 as a backend store. (From now on,
whenever you hear S3 you should think to yourself S3? Hm, something
seems to be missing… oh yeah! Security!)

https://leastauthority.com/product_s4

We are in the process of rolling out an upgrade to S4, and we would
love your help. The upgrade is that we've deployed the cloud backend
code ¹, which allows arbitrarily large files, is efficient has good
error handling, and which comes with connectors for Amazon S3,
Openstack Swift (e.g. Rackspace Cloud Files), Microsoft Azure Blob
Storage, and Google Cloud Storage. So this upgrade to S4 is the first
step in rolling out what will eventually become RAIC — Redundant
Array of Inexpensive Clouds!

https://leastauthority.com/products

☺

We're also going to reduce the price of our S4 service once this
upgrade to it has been tested and deployed.

So if you want to help test this then *don't* just go sign up for the
S4 product, linked above, but instead send us email to
supp...@leastauthority.com so that we can direct you to try out the
new improved version of S4 and get your feedback about it.

Thank you!

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.

¹ https://tahoe-lafs.org/pipermail/tahoe-dev/2013-July/008610.html
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: pycryptopp setup.py test gives ImportError with ostream_insert on CentOS5 i386

[Zooko Wilcox-OHearn]

On Thu, May 22, 2014 at 5:02 PM, Andy Cress acr...@unitrends.com wrote:

 With pycryptopp-0.5.29 and 
 pycryptopp-0.6.0.1206569328141510525648634803928199668821045408958

 I get an ImportError with ostream_insert during the 'test' on CentOS5 i386.

Did you build pycryptopp yourself or did you let the Tahoe-LAFS
setup.py download a pycryptopp binary?

If you let the Tahoe-LAFS setup.py fetch one, it might have fetched
the Python 2.7 linux-x86 pycryptopp from here:
https://tahoe-lafs.org/source/tahoe-lafs/deps/tahoe-lafs-dep-eggs/README.html
.

I think it is probably a mistake on our part to try to host those
binaries for Linux, because the egg format doesn't convey enough
information for us to build binaries that will work on all linux-x86
systems. If you could confirm whether that was the package that caused
this trouble for you, I'll go ahead and take it down and stop hosting
it.

If you built the pycryptopp binary yourself and then go that error,
please tell us more so we can help debug it.

By the way, it looks like you work for this company:
http://www.unitrends.com/ . It would be great if a company like yours
started using Tahoe-LAFS to protect your own data and/or your
customers' data! Let us know how we can help.

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: Accepted tahoe-lafs 1.10.0-2 (source all)

[Zooko Wilcox-OHearn]

On Sat, May 3, 2014 at 12:51 AM, David Stainton dstainton...@gmail.com wrote:
 Sweet! Does this help Tahoe-LAFS get into the next release of TAILS?

Well, according to https://labs.riseup.net/code/issues/6227#note-39 ,
Tails developer intrigeri wrote Anyone interested in pushing this
further, see comment 20 on this very ticket :). Comment 20 is
https://labs.riseup.net/code/issues/6227#note-20 , which is my
description of how Tahoe-LAFS could be useful for Tails users.

So I think that means that the next step is for some Tails users to
install Tahoe-LAFS and attempt to use it in the ways described in
Comment 20, and then post a comment on
https://labs.riseup.net/code/issues/6227 saying that they used it and
whether it worked for them.

Any volunteers?

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

report from today's Nuts and Bolts Party

[Zooko Wilcox-OHearn]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-
.. -*- indent-tabs-mode: nil -*-

===
 LAFS Nuts And Bolts Party, 2014-05-12
===

in attendance: Zooko (scribe), Daira

We merged a patch to print out more useful information about versions of
dependencies and tools, when building `pull/91`_.

We looked at `ticket #2193`_ and decided that it depended on `ticket
#2215`_. Zooko added `a comment on ticket #2193`_ objecting to a proposal in
an earlier comment on the ticket.

We talked about the Heartbleed detection patch (`ticket #2215`_) and Zooko
suggested that we should start with a minimal version of the patch that does
not look at the ostensible version numbers of OpenSSL at all and that does
not try to account for any other vulnerabilities besides Heartbleed. Daira
agreed.

We agreed to package up the Heartbleed-detector code as a separate Python
package and publish it and ask everyone to run it.

.. _pull/91: https://github.com/tahoe-lafs/tahoe-lafs/pull/91

.. _ticket #2193: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2193

.. _a comment on ticket #2193:
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2193#comment:35

.. _ticket #2215: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2215


-- 
Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: Tahoe LAFS + cryptocurrency compensation system

[Zooko Wilcox-OHearn]

On Mon, Apr 28, 2014 at 9:58 AM,  bin.e...@gmail.com wrote:

 Are the erasure blocks world readable in LAFS?  I don't know what
 assumptions LAFS was built with. I'm still getting up to speed on what
 the foundation is here. Hopefully Eve has no easy way to clone blocks
 from Bob.

I would start by reading this:

https://code.google.com/p/nilestore/wiki/TahoeLAFSBasics

And then read this:

https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/architecture.rst

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: Tahoe LAFS + cryptocurrency compensation system

[Zooko Wilcox-OHearn]

On Mon, Apr 28, 2014 at 8:25 PM, Lionel Bouton
lionel-subscript...@bouton.name wrote:

 I've not read every one of them as I should really begin by reviving an
 old private grid (down for nearly 2 years) on which I had a nasty bug to
 try to reproduce it with the latest code (it seems it may have been
 fixed since then: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1791 )...

That issue — #1791 — is not fixed yet in the current stable release,
nor even in the master branch of git. If you want to try out the fix
and report back, to help us have confidence in merging the fix into
master, then please try this git branch:

https://github.com/zooko/tahoe-lafs/commits/1382-rewrite-3

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1791#
UploadUnhappinessError with available storage nodes  shares.happy

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Seattle 3rd Monday

[Zooko Wilcox-OHearn]

Is anyone reading this going to be in Seattle on the 3rd Monday of a
month? The organizers of the Seattle TA3M asked me if I knew of anyone
who could present about Tahoe-LAFS there.

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: announcement/call for testing ansible role for tahoe-lafs

[Zooko Wilcox-OHearn]

Dear David:

Very cool! Thank you so much for sharing this work.

Regards,

Zooko
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: announcement/call for testing ansible role for tahoe-lafs

[Zooko Wilcox-OHearn]

On Thu, Apr 17, 2014 at 6:49 AM, David Stainton dstainton...@gmail.com wrote:

 
 15:42  sickness I really *HATE* how tahoe can automagically pull
 things from the net without notice, I'd like that if I have a .zip to
 build the *same* way every time
   I build it instead of rotting over time :(
…
 However, right now I do not set allowed hosts to None (perhaps I
 should?)... but instead set an invalid proxy host like wiretapped
 suggested:
 https://github.com/david415/ansible-tahoe-lafs/blob/master/tasks/install.yml#L89

This is ticket #1220.

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1220# build/install
should be able to refrain from getting dependencies

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

using LAFS as a key-value store

[Zooko Wilcox-OHearn]

Someone asked me in private mail about using LAFS as a key-value store
instead of as a filesystem, and specifically about performance. I
wrote this reply, which I also think may deserve to live in the docs
subdirectory of Tahoe-LAFS or maybe on the wiki.

There are several ways you could use Tahoe-LAFS as a key-value store.

Looking only at things that are *already implemented*, there are three options:

1. immutable files

   API:

* key ← put(value)

  This is spelled `PUT /uri`_ in the API.

  Note: the user of this API (i.e. the client code that invokes
this API) does not get to choose the key! (The key is determined
programmatically using secure hash functions and encryption of the
value and of the optional added convergence secret.)

* value ← get(key)

  This is spelled `GET /uri/$FILECAP`_ in the API. $FILECAP is the key.

   For details, see immutable files in `performance.rst`_, but in
summary: the performance is not great but not bad.

   Oh! That document doesn't mention that if the size of the A-byte
mutable file is less than or equal to `55 bytes`_ then the performance
cost is much smaller (because the values gets packed into the key).
Added a ticket: `#2226`_.

2. mutable files

   API:

* key ← create()

  This is spelled `PUT /uri?format=mdmf`_.

  Note: again, the key cannot be chosen by the user! (The key is
determined programmatically using secure hash functions and RSA public
key pair generation.)

* set(key, value)

* value ← get(key)

  This is spelled `GET /uri/$FILECAP`_. Again, the $FILECAP is
the key. This is the same API as for getting the value from an
immutable, above. Whether the value you get this way is immutable
(i.e. it will always be the same value) or mutable (i.e. an authorized
person can change what value you get when you read) depends on the
type of the key.

   Again, for details, see mutable files in the performance.rst (and
`these tickets`_ about how that doc is incomplete), but in summary,
the performance of the create() operation is *terrible*! (Because it
involves generating a 2048-bit RSA key pair.) The performance of the
set and get operations are probably merely not great but not bad.

3. directories

   API:

* directory ← create()

  This is spelled `POST /uri?t=mkdir`_.

  performance.rst does not mention directories (`#2228`_), but in
order to understand the performance of directories you have to
understand how they are implemented. Mkdir creates a new mutable file,
exactly the same, and with exactly the same performance, as the
create() mutable above.

* set(directory, key, value)

  This is spelled `PUT /uri/$DIRCAP/[SUBDIRS../]FILENAME`_.
$DIRCAP is the directory, FILENAME is the key. The value is the
body of the HTTP PUT request. The part about [SUBDIRS../] in there
is for optional nesting which you can ignore for the purposes of this
key-value store.

  This way, you *do* get to choose the key to be whatever you want
(an arbitrary unicode string).

  To understand the performance of ``PUT /uri/$directory/$key``,
understand that this proceeds in two steps: first it uploads the value
as an immutable file, exactly the same as the put(value) API from
the immutable API above. So right there you've already paid exactly
the same cost as if you had used that API. Then after it has finished
uploading that, and it has the immutable file cap from that operation
in hand, it downloads the entire current directory, changes it to
include the mapping from key to the immutable file cap, and re-uploads
the entire directory. So that has a cost which is easy to understand:
you have to download and re-upload the entire directory, which is the
entire set of mappings from user-chosen keys (unicode strings) to
immutable file caps. Each entry in the directory occupies something on
the order of 300 bytes.

  So the set() call from this directory-based API has obviously
much worse performance than the the equivalent set() calls from the
immutable-file-based API or the mutable-file-based API. Although it is
not necessarily worse than the performance of the mutable-file-based
API if you take into account the cost of the necessary create() calls.

* value ← get(directory, key)

  This is spelled `GET /uri/$DIRCAP/[SUBDIRS../]FILENAME`_. As
above, $DIRCAP is the directory, FILENAME is the key.

  The performance of this is determined by the fact that it first
downloads the entire directory, then finds the immutable filecap for
the given key, then does a GET on that immutable filecap. So again,
strictly worse than using the immutable file API (about twice as bad,
if the directory size is similar to the value size).


What about ways to use LAFS as a key-value store that are not yet
implemented? Well, I have lots of ideas about ways to extend
Tahoe-LAFS to support different kinds of storage APIs or better
performance. One that I think is pretty promising is just the Keep It
Simple, Stupid idea 

Re: using LAFS as a key-value store

[Zooko Wilcox-OHearn]

I uploaded a slightly edited version of this to github so that you can
see the rendered version of it with hyperlinks:

https://github.com/zooko/tahoe-lafs/blob/3c13c138cf09e83d2f8001888e2a7de85564d406/docs/frontends/key-value-store.rst

There's also a pull-request to add it to the docs directory:

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2229

Regards,

Zooko
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

report from Nuts And Bolts Party, 2014-04-21

[Zooko Wilcox-OHearn]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-
.. -*- indent-tabs-mode: nil -*-

LAFS Twice-Weekly Hack, 2014-04-17
==

“Nuts And Bolts Party”

in attendance: Zooko (scribe), Daira, tsygrl

Zooko reviewed `a work-in-progress patch`_ for `#2215 (mitigate
heartbleed vulnerability)`_

.. _a work-in-progress patch:
https://github.com/tahoe-lafs/tahoe-lafs/commit/9393f1ea2d6bf9d555ac29d4658efde73b334c45

.. _#2215 (mitigate heartbleed vulnerability):
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2215


Daira is *finally* feeling comfortable with git. It took a *long* time.

Daira finished merging and fixing unit tests for a
clean-up/refactoring patch `#1847 (Ugly shadowing of
Client.DEFAULT_ENCODING_PARAMETERS)`_.

.. _#1847 (Ugly shadowing of Client.DEFAULT_ENCODING_PARAMETERS):
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1847


Zooko, Daira, and tsygrl looked at `#2208 (excluded from Debian
because of no-source-code-included files)`_, which is a blocker for
Tahoe-LAFS v1.10 being included in the new Debian stable, and *that*
is a blocker for Tahoe-LAFS being included as a standard tool in
Tails. Here is `a note Zooko wrote about how Tahoe-LAFS could be
useful to Tails users`_.

.. _#2208 (excluded from Debian because of no-source-code-included
files): https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2208

.. _a note Zooko wrote about how Tahoe-LAFS could be useful to Tails
users: https://labs.riseup.net/code/issues/6227#note-20

Using the non-minified versions of all Javascript files would
eliminate questions about the source-availability of those files, and
Zooko and Daira agree that we shouldn't try to turn on minification,
or other such performance optimizations, without quantitative evidence
of how much (if any) it actually helps performance. So henceforth we
will have a policy of no minification unless it is quantitatively
justified.

A sufficiently new version of D3 appears to be packaged in Debian.


This coming Thursday's Tesla Coils and Corpses Party will be about
hash-based signatures!


-- 
Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

invitation to weekly Nuts and Bolts party

[Zooko Wilcox-OHearn]

Folks:

Every Monday we have a get-together to work on the Nuts and Bolts of
Tahoe-LAFS. This means things like reviewing patches, writing docs,
planning upcoming releases, updating the wiki pages, etc. etc.

It is fun! And you are invited. We need people to do all of the above:
write docs, test new features and give feedback, etc. etc.

Email me if you are interested.

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

report from Tesla Coils and Corpses, 2014-04-17

[Zooko Wilcox-OHearn]

(N.B., the following doesn't really have almost anything to do with
Tahoe-LAFS, other than that Daira and Zooko are the two primary
maintainers of Tahoe-LAFS.)

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-
.. -*- indent-tabs-mode: nil -*-

LAFS Twice-Weekly Hack, 2014-04-17
==

Thursdays are always Tesla Coils and Corpses from now on. If you want to
attend on Thursdays, please contact Zooko to sign up. The topic for next week
will be either Noether, ZeroCoin, or a crypto idea for
no-added-round-trips-transitive-directory-lookup. (Which is a kind of
encrypted search.)

Mondays are always Nuts and Bolts, likewise, please let Zooko know you want
to join Nuts and Bolts!


in attendance: Zooko (scribe), Daira


topic: Noether!

https://github.com/daira/noether/blob/master/doc/presentations/StrangeLoop/noetherj.pdf?raw=true


Noether-C. Might already be a consistent logic. The main reason it is
not is that it includes failure. Shouldn't be too hard to define it as
a consistent logic except that it can fail. If Noether-C is, or can be
made to be, a consistent logic, then it would be more convenient to
use Noether-C as a proof-system for Noether code than it is to use
Agda as a proof-system for Haskell code.

*All* function calls are atomic in Noether (all side-effects are
rolled back if the function raises an exception).

This is related to Software Transactional Memory, although STM is more
for concurrency than for error-handling.

E-like separation between immediate and eventual send (function call).

… plus Erlang-style blocking-receive

Zooko: When do you want to use blocking-receive for anything *other*
than to implement an E-like event loop and then never see
blocking-receive again?

Daira: to implement things like: try a turn, if it fails then repeat
it but with logging turned up to the max

difference between yield and blocking-receive

Zooko was concerned that this could yank the rug out from under the
programmmer if they were reasoning about the runtime state, while
looking at the code, and then at runtime a blocking-receive ends up
letting unpredictable *other* code run which alters the runtime state.
See MarkM's and Glyph's rants on the topic:

http://www.eros-os.org/pipermail/e-lang/2001-July/005418.html

https://glyph.twistedmatrix.com/2014/02/unyielding.html

Parties (both Nuts and Bolts parties and Tesla Coils and Corpses
parties) should be 1.5 hours instead of 1.0 hours. Daira and Zooko
never want to stop after just 1 hour!

Rust's disjoint heaps, borrowed-pointers and unique pointers

In Rust, the idea of having unique heaps was the motivation of having
unique pointers and borrowed-pointers. In Noether there is a different
motivation: you can use it to separate the language into more layers.
You can do things that look like mutating state within the
pure-functional subsets. There's another language that does this:
Clean.

possible next Tesla Coils and Corpses: Noether, ZeroCoin,
constant-time (no extra server-round-trips) directory-lookup


-- 
Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

report from Nuts and Bolts party 2014-04-14

[Zooko Wilcox-OHearn]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-
.. -*- indent-tabs-mode: nil -*-

LAFS Twice-Weekly Hack Hour, 2014-04-14
=

in attendance: Zooko (scribe), Daira

from now on Monday LAFS Hack is Nuts and Bolts and Thursday LAFS Hack
is Tesla Coils and Corpses!

today's agenda: release engineering (1.11.0)

We merged the patch for #1847.

We looked at a few new tickets to decide whether to put them in the
1.11.0 Milestone or not:

* #2217 (): yes
* #2220 (): no
* #1431 (): no, we're past feature-freeze
* #2218 (): no, depends on #1431
* #2208 (excluded from Debian because of no-source-code-included files): yes
* #2214 (DOS defect concerning forged shares): no. It is a bug, but it
doesn't seem to be a critical bug in terms of impact.
* #2213 (Make SFTP generate its own key): no; It is a feature-request.
* #1759 (cloud backend: debug command to dump a listing of objects in
a cloud container); no (new feature)
* #1906 (constant-time directory lookup): no, because it is awesome
science-fiction stuff that is probably impossible in lots of otherwise
perfectly normal-seeming universes ☺
* #1784 (add happiness count to check and repair reports): yes,
already fixed and in trunk
* #2149 (tahoe start emits an error message when tahoe is already
running): no; It is a feature. [Zooko is sad because git-annex↔LAFS
wants this. Oh well—let 1.12 come soon!] Opened
https://twistedmatrix.com/trac/ticket/7146
* #2210 ('sudo pip install .' fails if tests have been run):
undecided; Hopefully this is someone else's (pip's) problem.

* #2193 (pyOpenSSL 0.14 pulls in a bunch of new dependencies): yes
* #2215 (mitigate heartbleed vulnerability): yes (critical, ugh)
* #2217 (SandboxViolation:
mkdir('/usr/lib/python2.7/site-packages/cryptography/hazmat/bindings/__pycache__',
511) {}): yes

pyOpenSSL packaging—argh! We considered shipping our own binaries of
pyOpenSSL with a version number that we made up, called 0.13.post1, and
making Tahoe-LAFS depend on pyOpenSSL == 0.13.post1. We considered shipping
a fork of pyOpenSSL which has packaging-metadata name flyOpenSSL but still
still installs a package (which is the Python word for a .py file or a
directory containing .py files) named OpenSSL. We considered shipping a
fork name flyOpenSSL that installs package (directory) named
flyOpenSSL. At this point Zooko got really frustrated and suggested
rewriting everything in Rust in order to get away from the hideous mess that
is Python packaging.

Then we came up with a relatively reasonable-sounding proposal, which is
something that the pyOpenSSL devs could do:: make new releases of pyOpenSSL,
named 0.14.1 and (for people like us who can't upgrade to the cffi-based
build system yet) 0.13.1. The .1's in these version numbers are being
used as a *signal*, visible within the Python packaging metadata, that this
particular package was built by someone who is aware of heartbleed and they
intended to avoid putting the heartbleed vuln into this package. Then
Tahoe-LAFS (and Foolscap, and Twisted, etc.) can depend on pyOpenSSL ==
0.13.1, = 0.14.1, to indicate their desire to listen to this signal.

Then the pyOpenSSL setup.py can help the builder of the package send the
correct signal, by checking the version number of OpenSSL and refusing to
build if it is one of the version numbers that had (in the upstream OpenSSL
release) the heartbleed vuln.

Now, Debian and Ubuntu ship OpenSSL libraries which have a patch to fix the
vuln but which still report the original upstream OpenSSL version numbers. No
problem! When they build pyOpenSSL v0.13.1 and v0.14.1 packages, they will
patch out that check that pyOpenSSL's setup.py does (or perhaps pyOpenSSL
will offer a --affirm-heartbleed-fix-is-present build-time option for
this), in order for them to correctly send the signal that their
Debian/Ubuntu python-openssl 0.13.1 or python-openssl 0.14.1 package does
*not* have the vuln.

So, we'll open a ticket suggesting this to the pyOpenSSL team. Zooko is not
going to hold his breath, though. Instead he's going to start rewriting
everything in Rust. ☹ Just kidding. I think.

Also, Daira added a comment to an earlier discussion, in order to affirm the
pyOpenSSL/cryptography.io developers and let them know that we don't think
they are dumb: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2193#comment:26
;-)

* #2212 (tahoe renew)
* #1377 (tahoe start claims to have started when it didn't (due to
port number conflict)): no; We don't have a patch for it.
* #2147 (web.port can conflict): no; See above.
* #2135 (Add --print-uri option to tahoe backup to dump resulting
backup URI): maybe; It is a new feature, but it has a patch. however
the tests currently fail. it can be included if the tests are fixed,
but is not a high priority.
* 2122 (Update jQuery to address CVE-2011-4969): yes, because we need
to fix #2208 anyway for 1.11
* 2202 (ERROR: UnrecoverableFileError(no recoverable versions)): needs
further 

report from LAFS Hack 2014-04-10

[Zooko Wilcox-OHearn]

Daira and I were the only attendees. We worked on a way for Tahoe-LAFS
to blacklist known-vulnerable-to-heartbleed versions of OpenSSL.

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2215

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

report from Twice-Weekly Hack Session, 2014-04-10

[Zooko Wilcox-OHearn]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-
.. -*- indent-tabs-mode: nil -*-

LAFS Twice-Weekly Hack Hour, 2014-04-07
=

in attendance: Zooko (scribe), Daira, Zancas

We worked on `#2208`_, because we want Tahoe-LAFS to be included in Debian
and in Tails.

.. _#2208: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2208

It turned out that Debian doesn't have a sufficiently new version of
d3 to include the d3.time feature. Also we can't tell (ironically!)
what upstream version of d3 Debian has packaged.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735940#52



-- 
Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

LAFS Twice-Weekly Hack Hour, 2014-04-03

[Zooko Wilcox-OHearn]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-
.. -*- indent-tabs-mode: nil -*-

LAFS Twice-Weekly Hack Hour, 2014-04-03
=

in attendance: Zooko (scribe), Aaron, Daira

(Note that Freenode was unreachable, at least to Zooko, so that might have
prevented some people from joining the meeting.)

Pre-meeting chit-chat: Bitcoin is fatally flawed.

1.a. A Dominant Miner is an existential threat to the currency.

1.b. There is a smooth path of making more and more profit, at the end of
  which you are a Dominant Miner.

2. Having a complete transaction history indelibly stamped on every coin will
   lead to non-fungibility. The IRS just tried to give it a big push in that
   direction, but even if they roll that back, says Zooko, Bitcoin will still
   inevitably lose fungibility in practice.

Once the meeting officially started, Aaron demoed his Javascript (Bootstrap)
WUI, which is called Simple Secure File Browser ¹. It is read-only. It looks
very clean. The major functional difference between it and the builtin
Tahoe-LAFS WUI is that when you click on subdirectories in the Simple Secure
File Browser it updates a breadcrumb trail showing the path of
subdirectories that you've taken, from the root.

This means that if you share the URL, you're sharing access to the root, not
to the current subdir.

We had a good discussion about sharing, UX, and security. The consensus among
the three of us was that a good user action to initiate sharing would be:

* If you want to share read-only access to the thing you are looking at, you
  just copy the URL from the URL bar and send that.

* If you want to share write-access to a page that you have write access to
  and which you are looking at, you push the button on the page labeled
  Share Write Access To This. This pops up a text field next to the button
  containing the write-cap, already selected. This is similar to how web apps
  such as Google Maps implement the share a link to this feature.

Aaron said that when he suggests LAFS-style crypto-caps, he commonly
gets pushback about tracing delegation, prohibiting delegation, and
revoking access. Zooko sighed heavily and agreed that this is an
extremely common reason for people to decide not to use crypto-caps,
but that it is a *mistaken* reason. The difficulties of tracing
delegation, prohibiting delegation, and revoking access are made
*obvious* by crypto-caps, but they aren't *caused* by crypto-caps,
they are inherent problems that also bedevil conventional access
control solutions. Zooko ranted about how you can't prevent your users
from sharing credentials, you can't prevent them from proxying for one
another, and you can't prevent the people who control your centralized
access control server from abusing *their* access, either.

We discussed how there were possible improvements within the
crypto-cap model to ameliorate these problems. Many such improvements
are already described in tickets on our trac, but one that is not yet
described is to create independent caps pointing to the same resource,
so that you can revoke one of them and not the others.

We talked about if and how to integrate a newer and better WUI into
Tahoe-LAFS. Incremental improvement of the current WUI, or a fresh start? We
would want to support non-JS-capable browsers in any case, so we would end up
with two WUIs — one for JS-incapable and one for JS-capable browsers.

All such work is blocked on releasing Tahoe-LAFS v1.11!

Daira and I agreed to work together on Tahoe-LAFS v1.11 at the next
Twice-Weekly Meeting.

future meeting agenda: David's Clojurescript-based WUI

¹ https://github.com/acordova/lafs-simpleui


-- 
Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

notes from Hack Session Monday, 2014-03-31

[Zooko Wilcox-OHearn]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-
.. -*- indent-tabs-mode: nil -*-

LAFS Twice-Weekly Hack Hour, 2014-03-31
=

in attendance: Zooko (scribe), Nathan, Daira

Nathan opened a ticket about an issue installing Tahoe-LAFS using pip.
It *might* have been #2209. #2209 is now fixed.

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2209# Missing
`allmydata/web/static/img` subdirectory when installed from `pip`.

We showed Nathan a tour of buildbot:

1. Go to https://Tahoe-LAFS.org

2. Click on buildbot button in the button-bar at the top. That takes
you to https://tahoe-lafs.org/buildbot-tahoe-lafs/

3. Click on All Builders. That takes you to
https://tahoe-lafs.org/buildbot-tahoe-lafs/waterfall?show_events=true

4. Click on Kyle OpenBSD amd64. That takes you to
https://tahoe-lafs.org/buildbot-tahoe-lafs/builders/Kyle%20OpenBSD%20amd64

5. Click on #263. That takes you to
https://tahoe-lafs.org/buildbot-tahoe-lafs/builders/Kyle%20OpenBSD%20amd64/builds/263

Now, let's work on https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2051 ! ☺

We merged a pull request:
https://github.com/tahoe-lafs/buildbot-config-tahoe/commit/027e2fe1646863df46c15977cb3ed9badde100bf

Now we're deploying this new version of our buildbot config onto
https://tahoe-lafs.org/buildbot-tahoe-lafs/

Okay, we got it running, but haven't imported the histories of old
builds. We're leaving it shut down until we can do that (hopefully
tomorrow).


-- 
Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

cryptic notes from Twice-Weekly Hack Hour, 2014-03-24

[Zooko Wilcox-OHearn]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-
.. -*- indent-tabs-mode: nil -*-

LAFS Twice-Weekly Hack Hour, 2014-03-24
=

in attendance (or at least innocently bystanding on IRC): Zooko (scribe),
str4d, dreid, Riastradh, daira (LAST MINUTE, TIMEBOX-BUSTING, MEETING
PARATROOPER)

not in attendance although we wished he were: Brian, author and maintainer of
foolscap, author of half of Tahoe-LAFS, and much else besides

Topic: How to make foolscap work best over Tor/I2P/IPv6/etc.

str4d thinks the next step is to make foolscap (optionally?) use NaCl instead
of SSL for encryption. He's opening a ticket on the foolscap trac about that.

http://foolscap.lothar.com/trac/ticket/219

dreid pointed out that the Python libraries that implement NaCl also have a
cffi dependency, like his (dreid's) cryptography.io library that has
recently been the subject of Zooko's angst because of
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2193#comment:6

Zooko replied that well, that reminds him of how much he would like instead
upgrading foolscap, to eliminate the dependency on foolscap in favor of a
custom protocol embedded into HTTP:
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/510

dreid said everyone should use endpoints for everything.

Zooko replied that in a #510 world, Tahoe-LAFS would be delegating that to
Twisted, using whatever the state of the art is for HTTP client and HTTP
server in Twisted.

dreid suggest that it might almost be time to consider jumping straight
to HTTP/2. Zooko had never thought of that before, and said maybe that
*would* be a good idea. Two of the best things about switching from
Foolscap to HTTP are that it could encourage implementations of LAFS in
Javascript in-browser [*] and that it could encourage implementation of
LAFS in different programming languages. Possibly jumping straight to
HTTP/2 could achieve both of those, while also offering performance and
perhaps sanity benefits compared to HTTP/1.

str4d said he had no qualms with it — I2P will take whatever protocol you
can throw at it. :P

Next meeting will be Monday the 31st (unless someone other than Zooko
organizes one for this Thursday the 27th). Aaron Cordova wants to show us
a new frontend something something written in Javascript. Aaron is
awesome because he invented Accumulo and
https://docs.google.com/file/d/0B9iCsXQ_HuEpN2NlNDgwMTMtNWRjOC00YzMwLWExYjMtYzVmM2FiZGRhNjA4/edit?pli=1hl=en
so Zooko is interested!

Daira arrived at the end of the first hour, and the meeting was
overflowing into the second hour when Zooko (scribe) had to leave to do
chores in preparation for flying to the Princeton Cryptocurrency Workshop
tomorrow, so these notes end here. ☺

[*] Yes, I know that makes no sense until someone (else?) solves a
different unsolvable problem. We try to solve one unsolvable problem
at a time!


-- 
Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

notes from Twice-Weekly Dev Chat, 2014-03-20

[Zooko Wilcox-OHearn]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73;
indent-tabs-mode: nil -*-

notes from LAFS Weekly Dev Chat 2014-03-20
==

in attendance: Zooko (scribe), Nathan, Remy (voiceless), Oleksandr
(lurker), Daira

looking for Zooko's #1382 patches…

Nathan is looking at tickets for 1.11.0 release blockers.

#2105 is one of them. It is owned by Remy.

Remy is blocked by the trac anti-spam features. AGAIN. Zooko tweaked
the anti-spam config to let more posts through and block posts less.

Oleksandr is still alive.

Zooko is confused by git histories with different patch-contents
having the same commit-logs as each other, and applied in different
order, on different branches. Also he himself is the author of most of
the conflicting and confusing patches. ☹ Nathan is helping him
untangle the history.

We're wondering what to call the measure formerly named Happiness
Count, per Remy's review of #2015. We settled on Happiness Level.

Zooko refactored his branch ¹ for #1382, the refactored version fails
many unit tests, he found and fixed two inadvertent semantic changes
that had been introduced in the refactoring, and also realized that
there was a lot more simplification and refactoring that could go into
it, such as changing a lot of methods of HappinessUpload class into
module-scoped functions instead, and started doing that …

Daira replied to Remy's reviews on the Trac.

¹ https://github.com/zooko/tahoe-lafs/commits/1382-rewrite-3


-- 
Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

unexpanded notes from Twice-Weekly Hack Hour, 2014-03-06

[Zooko Wilcox-OHearn]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73;
indent-tabs-mode: nil -*-

notes from LAFS Weekly Dev Chat 2014-03-06
==

in attendance: Zooko (scribe), Oleksandr (lurker), Brian, Daira

* bitcoin-sorcerers, Bitcoin-onlyists vs. altcoinists

* Oleksandr is in Kyiv; He is safe.

* posters with pictures of eyeballs make people behave better (from
Dragnet Nation); non-eyeball-shaped cameras are the worst of both
worlds ; googleglass triggers the eyeball-response ; Facebook early-on
put images of the reader's faces (and eyes) right next to the
text-entry form.

* Ars Technica is claiming that Newsweek has found out who Satoshi
Nakamoto is: Satoshi Nakamoto!

* Brian's FireFoxTahoeThing→PetMail2
  - frontend: FireFox extension written in Javascript, installable to
desktop with Web RT -- Web Run Time
  - backend: same backend code could run in node.js or in browser

* identity within Mozilla
  - Persona is in limbo, Firefox Accounts is the new thing
  - Firefox Accounts is not federated, just centralized (to Mozilla.org)

* Brian's FireFoxTahoeThing→PetMail2
  - erasure coding

TANGENT: erasure coding, transparency, better-is-better ; vs.
replication or 1-server, worse-is-better

TANGENT from TANGENT: Tahoe-LAFS needs to set K=H=N=1 for the default!
(says Zooko)

* Brian's FireFoxTahoeThing→PetMail2
  - de-emphasize erasure coding and separate the DHT from the layer
above it that tracks what files/directories/things you care about
  - it is easier to think about deploying small numbers of servers in
a fixed configuration rather than make that thing dynamic

Separating DHT from other layers in LAFS would allow LAFS to use other
DHT tech, and would also help the community of DHT researchers to
learn and use LAFS. E.g. they can get another publication saying we
adopted LAFS to our DHT.


* Brian's FireFoxTahoeThing→PetMail2
  - Tahoe-LAFS immutable filecap is equivalent to a PetMail2 BlobCap
  - A PetMail2 FileCap is filename, metadata, BlobCap, maybe an icon
or a thumbnail
  - the DHT layer gives immutable BlobCaps and mutable channels
  - the only mutable things are channels, and channels are special ;
not a general-purpose filesystem tool
  - channels are unidirectional, one-writer, one-reader
  - if you want to back something up, then you create a channel for
which you have the writecap, and you persist the readcap and store it
somewhere where you can get back to it later
  - if you want to send data to someone else, then you have the
writecap and they have the readcap
  - one of the UI operations may be to tell your agent: here's a local
OS directory tree that I want to send through this channel ; your
affordance for that is to drag that folder into your agent and drop it
into the box that represents that channel ; really an Instant
Messaging type metaphor, so there's a scrolling window and you can
type text in there and you can drop folders in there
  - you can set up automatic repeated updates
  - there are no network-side or DHT-side directory caps in this approach
  - so when you want to send a directory to somebody, what your agent
does is scan through the directory locally, upload all of the files
that are in there and upload them, and get back a BlobCap for each
one, then build a local database of filepaths and BlobCaps and
metadata
  - then serialize that...
  - This design is pretty equivalent to the Virtual CDs idea for
LAFS (insert ticket # here)

Daira: This is why Noether adds channels before it adds mutable state.
In the expressiveness vs. tractability, channels are more tractable
and slightly less expressive.

* Brian's FireFoxTahoeThing→PetMail2
  - Precise GC by having at most two roots for each thing. Atomic
operation can acquire leases on new stuff and drop leases on old
stuff.

In theory garbage collection ranges from trivial to difficult, and
in practice that range is like difficult to impossible. ☺

Somebody please make a googly-eyes version of the Google (tm) logo!

* update on https://LeastAuthority.com: Unnamed Potential Business
Partner Company, needs accounting
  - accounting needs leasedb
  - leasedb needs 1.10 released
  - 1.10 released needs #1832
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: If the machine run the introducer down,what can i do

[Zooko Wilcox-OHearn]

Hey dstainton415 and str4d:

Is there an hour per week we could all get together on IRC and/or a
videoconferencing and/or screen-sharing tool and work on this? Str4d
and I had previously agreed on Monday 22:00Z, but that hasn't really
come together yet, and also I'm not sure if DST [*] changes Str4d's
availability for that.

Regards,

Zooko

[*] Fuck DST!
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: If the machine run the introducer down,what can i do

[Zooko Wilcox-OHearn]

That's right. If you have a backup of the introducer's private keys
then you could set up a new introducer that would have the same FURL.
If not, then you'll have to put in the new introducer's FURL to each
storage server and each client.

The multi-introducer ticket that str4d mentioned is ticket #68:

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/68# implement
distributed introduction, remove Introducer as a single point of
failure

The state of that ticket is: test-needed — it is waiting for someone
to write unit tests that test the code changed by the patch.

Regards,

Zooko
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: apparent serious integrity problem in build system - setuptools bug?

[Zooko Wilcox-OHearn]

Sigh.

Thanks for the issue report, gdt.

Here's what I know so far:

1. The Tahoe-LAFS build system (which is based on setuptools) will
download and execute any package which pypi.python.org says is the
foo package, if any part of Tahoe-LAFS transitively depends on a
package named foo. To change it so that it *doesn't* automatically
download packages over the Net is ticket #1220.

2. pyOpenSSL just updated from 0.13 to 0.14, and newly depends on a
new project named cryptography.io: https://cryptography.io . To deal
with this is ticket #2193.

My current plan for #2193 is to pin Tahoe-LAFS's dependency on
pyOpenSSL ¹ to pyOpenSSL == 0.13.

I have a question for you: how did cryptography and six get into
the dependencies that setuptools is trying to satisfy (in your
transcript above)? I would guess that cryptography got in there
because of pyOpenSSL, and that six got in there because of
cryptography, but why didn't your build use the pyOpenSSL package
that was already installed!?

I have a suggestion for you: go ahead and patch Tahoe-LAFS's
src/allmydata/_auto_deps.py to specify pyOpenSSL == 0.13 instead of
just pyOpenSSL if it helps.

Please let us know what you learn.

See also relevant tickets #1582, #2055, and #2077.

Regards,

Zooko

¹ 
https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/src/allmydata/_auto_deps.py?annotate=blamerev=7bb07fb5e28756fa13ba5190e6c39003c84d3e1e#L41

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1220# build/install
should be able to refrain from getting dependencies
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1582# setuptools delenda est
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2055# Building tahoe
safely is non-trivial
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2077# pip packaging plan
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2193# pyOpenSSL 0.14
pulls in a bunch of new dependencies
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

report^H^H^H^H^H^Hcryptic notes from Twice-Weekly LAFS Chat, Monday 2014-02-17

[Zooko Wilcox-OHearn]

in attendance: Zooko (scribe), Brian, Zancas (lurker), Daira

Zooko is trying to simplify and/or understand the implementation of
the core algorithm of servers-of-happiness in happiness_upload.py and
documented in docs/specifications/servers-of-happiness.rst

Then we took a hard left turn into Cryptocurrency Land.

trapdoor free accumulators, RSA-UFOs, SNARKs, NIZKs

ZeroCoin, ZeroCash

bonds to penalize multispenders, Nikita and Zooko

pure-proof-of-stake, positive-expected-value mining (a simple solution
to the “I have googol-googol-googol-votes” attack)

51% attack

ordering sold separately from transaction-vetting

bootstrap by granting newcoin to Bitcoin holders

“Zookoin” — you heard it here first!


Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

report from Twice-Weekly LAFS Dev Chat, Thu 2014-02-30

[Zooko Wilcox-OHearn]

in attendance: Zooko, Daira

Zooko was distracted by trying to get publicity for his startup
(https://LeastAuthority.com) from this news:

https://spideroak.com/blog/20140220090004-responsibly-bringing-new-cryptography-product-market

https://news.ycombinator.com/item?id=7271030

http://www.reddit.com/r/programming/comments/1yg0ow/responsibly_bringing_a_new_cryptography_product/

Daira and Zooko tried to find a paper that they both vaguely
remembered reading, which claimed to be a more intuitive,
understandable explanation of Bleichenbacher and Maurer's scheme for
asymptotically-better hash-based one-time digital signatures. They
didn't find it, but they did find a paper by C. Dods, N.P. Smart, and
M. Stam that claimed to improve on it.



-- 
Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

report from LAFS Hack Hour 2014-02-13

[Zooko Wilcox-OHearn]

Folks:

I was the only one who showed up at LAFS Hack Hour today. I started
working on #1382, and saw that generate_upload_plan() ¹ seems to be
computing some local variables from other local variables (peers and
shares) from other local variables (map), and then passing all three
as arguments to _calculate_mappings() ². Why, I wondered, does it just
pass that third one to _calculate_mappings() and let
_calculate_mappings() generate the other two from the third one?

Investigating that, I saw what seemed to be another redundancy, that
_calculate_mappings() invokes _reindex() ³ to generate a mapping
between things and small integers, and then invokes
_servermap_flow_graph() ⁴, which then invokes _reindex() again,
itself. Are these two invocations of _reindex() supposed to be
generating the same result as each other?

Then I got tired of working on this all by myself and switched to
editing a note I've written about the historical tendency of secure
hash functions to succumb to collision attacks but not to
(second-)pre-image attacks. I hope to publish that note soon. Please
contact me if you're an expert in secure hash functions and want to
help me review it for errors before I publish it.

The next LAFS Hack Hour will be Monday, the 17th, at 22:00Z!

Regards,

Zooko

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1382# immutable peer
selection refactoring and enhancements

¹ 
https://github.com/zooko/tahoe-lafs/blob/6fd9d90e9fc667a8f21028a4c73bef5265e3facd/src/allmydata/immutable/happiness_upload.py#L30

² 
https://github.com/zooko/tahoe-lafs/blob/6fd9d90e9fc667a8f21028a4c73bef5265e3facd/src/allmydata/immutable/happiness_upload.py#L90

³ 
https://github.com/zooko/tahoe-lafs/blob/6fd9d90e9fc667a8f21028a4c73bef5265e3facd/src/allmydata/immutable/happiness_upload.py#L282

⁴ 
https://github.com/zooko/tahoe-lafs/blob/6fd9d90e9fc667a8f21028a4c73bef5265e3facd/src/allmydata/immutable/happiness_upload.py#L256
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Avi and Zooko chat about near-future LAFS features

[Zooko Wilcox-OHearn]

-- Forwarded message --
From: Zooko Wilcox-OHearn zo...@leastauthority.com
Date: Wed, Feb 12, 2014 at 1:41 PM
Subject: Re: report from Weekly Hack Hour, 2014-02-12
To: Avi Freedman freed...@freedman.net


- making it easy and bulletproof to install

I don't know if I told you about this, but we got a grant from
OpenITP to improve installation! I'll be happy to share the
proposal/spec doc with you if you want.

- ensuring diversity of chunk spreading (maybe done or almost done I think)

Yes, almost done. Feels like it has taken forever and I'm sick of
dealing with it, but at least once it is done it should be a very
well-reviewed, high-quality feature!!

- verification and rebuild of data by proxy for the client without
having to give up the ability to recover to plaintext

I agree this is important, but we don't currently have anyone working on it:

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/568

I wonder if we should try a bounty program! #568 doesn't sound *too*
complicated to implement…

- accounting

I agree this is important, and I think it is stuck right now because
Brian Warner isn't actively working on it and we were depending on
him. I think only super-experts like Brian and Daira could do it right
at this point, so it isn't amenable to a bug bounty program.

- multiple introducers

Several people have worked on this, and I think they have working
patches! Maybe we just need unit-testing and review in order to land
it into trunk?

- a few other things I'm forgetting

:-)

Nice hearing from you!


Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: implementation of GUI frontend to tahoe

[Zooko Wilcox-OHearn]

Hello freelab xavier:

Welcome.

On Wed, Feb 12, 2014 at 10:07 AM, freelab xavier freelab...@gmail.com wrote:

 so that i can reuse it as a basis to create a tahoe driver for pydio

Great! I hope it works. Pydio sounds great!

Maybe:

* https://github.com/joepie91/pytahoe/blob/master/pytahoe/__init__.py

Or:

* 
http://code.google.com/p/pyfilesystem/source/browse/#svn%2Ftrunk%2Ffs%2Fcontrib%2Ftahoelafs

Would help you? Is pydio written in Python?

Another idea would be to see how the SFTP driver works:

https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/src/allmydata/frontends/sftpd.py

github mirror of that file:

https://github.com/tahoe-lafs/tahoe-lafs/blob/master/src/allmydata/frontends/sftpd.py

Anyway, you might find it easier to use the LAFS web API than to use
any wrapper code:

https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/frontends/webapi.rst

github mirror of the same document:

https://github.com/tahoe-lafs/tahoe-lafs/blob/master/docs/frontends/webapi.rst

Let us know how it goes!

Regards,

Zooko
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

report from Weekly Hack Hour, 2014-02-12

[Zooko Wilcox-OHearn]

In attendance: Zooko, Marlowe, Andrew, Daira, Str4d

Andrew was doing tech support for his colleagues for part of it, Daira
had technical difficulties with the video-conferencing part, str4d
accidentally left behind his notes from RWC, Marlowe was distracted by
his day job and Zooko had to leave early to help a 12-year-old with
his homework. Also:

#2128 - Andrew has a patch; Updating it to apply the no #'s rule to
any config value whose key ends with .furl ; Daira concurs with the
design.

#1382 - Zooko is reviewing generate_upload_plan() and
_calculate_mappings(); _calculate_mappings() seems to have two
separate uses -- if servermap is provided then it identifies a subset
of the mapping therein which is the mapping to be preserved, or if
servermap is None then it generates a new mapping from the other
arguments. It might be clearer to have two separately-named functions.
Zooko is examining all code that invokes _calculate_mappings(). Zooko
rewrote _calculate_mappings() to be two separate functions for those
two uses and it did indeed make generate_upload_plan() easier to
follow.

Next week we'll try the same time: Tuesday at 23:00Z, despite the
mixed success of this time around. We're also doing Thursday at
16:00Z, but there are some people who can never make that slot so
we're going to continue experimenting with additional other slots.

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: Meeting place to discuss 'the decentralised internet' projects

[Zooko Wilcox-OHearn]

Hi David Irvine:

You might also want to post about
http://www.reddit.com/r/decentralisedinternet/ on the p2p-hackers
mailing list: http://lists.zooko.com/mailman/listinfo/p2p-hackers

I had a quick look at
http://www.maidsafe.net/maidsafe-network-platform-libraries ,
http://www.maidsafe.net/blog/surefile/ , and
http://www.maidsafe.net/network-platform-licensing .

It seems like your tech has much in common with Tahoe-LAFS, and I
wondered if you considered using Tahoe-LAFS as part of your toolset,
and I wondered if you had any documentation of differences between
your architecture and Tahoe-LAFS.

Regards,

Zooko
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

[tahoe-dev] report from Tahoe-LAFS Weekly Dev Chat 2013-08-29

[Zooko Wilcox-OHearn]

In attendance: Zooko (scribe), Mark, Arturo, Daira, Nathan, Oleksandr, Brian

There is a video recording of this meeting!

http://www.youtube.com/watch?v=0fAbv9EzHiw

We decided what tickets would be considered blockers for Tahoe-LAFS v1.11.0:

https://tahoe-lafs.org/trac/tahoe-lafs/milestone/1.11.0

Please help by reviewing a ticket from that set! (See How To Review Patches ¹.)

We removed more than one hundred open tickets that had been in the
1.11 Milestone and moved them into the Soon Milestone.

Nathan volunteered to be Release Manager for this release! But Brian
wants to think about it first before accepting Nathan's offer. Nathan
asked what's the next step in that job, and our answers were that
there are two next steps: (a) cat herding, poking people and reminding
them to fix bugs, (b) writing the NEWS file ².

¹ https://tahoe-lafs.org/trac/tahoe-lafs/wiki/PatchReviewProcess

² https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/NEWS.rst

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

[tahoe-dev] join us for the Tahoe-LAFS v.11 planning meeting tomorrow

[Zooko Wilcox-OHearn]

Folks:

Everyone is invited to participate in a video conference using Google
Hangouts tomorrow, Wednesday the 28th, at 15:00Z, for 1 hour.

Here is more detail:

https://tahoe-lafs.org/trac/tahoe-lafs/wiki/WeeklyMeeting

The video conference will be recorded and posted to the public on
youtube (if we can figure out how to make it do that).

The topic will be: What is coming in Tahoe-LAFS v1.11! ☺

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

[tahoe-dev] weekly dev chat notes from 2013-08-21

[Zooko Wilcox-OHearn]

notes Tahoe-LAFS Weekly Dev Chat 2013-08-21

in attendance: Zooko (scribe), Jeff psi2, Mark, zab, Brian


Agenda Item 1: next week's Dev Chat

for the next Weekly Dev Chat meeting, we're going to do an experiment:

* invite people more widely (everyone who reads tahoe-dev, everyone
who follows me (zooko) on twitter, etc.)
* upload a recording of the dev chat to youtube
* try to finish reviewing #1382 *before* the meeting so that we can
focus the meeting on:
* planning Tahoe-LAFS v1.11!


Agenda Item 2: I2P patches

Jeff and zab from the I2P project joined Tahoe-LAFS Weekly Dev Chat
for the first time to help us integrate the patches that I2P needs in
order to use an unmodified LAFS on I2P. Jeff tagged the specific
tickets that are blocking the I2P people on that:

https://tahoe-lafs.org/trac/tahoe-lafs/query?status=assignedstatus=closedstatus=newstatus=reopenedkeywords=~i2p-collaborder=priority

We dug into #1010. We agreed to make a [node]anonymize, which means
On startup, verify that all configuration options are compatible with
anonymity. If any aren't, stop the process with a useful error message
about the configuration option that is dangerous to anonymity..

Action item for me: add a comment to that proposing a configuration UI
that I would like, then email Brian about it. Action item for Jeff:
update the patch on #1010.

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1010# use only 127.0.0.1
as local address


Agenda Item 3: Tahoe-LAFS v1.11.0

I don't want to release Tahoe-LAFS v1.11 with regressions that make it
worse than Tahoe-LAFS v1.10. Currently, there are seven such
regressions!

https://tahoe-lafs.org/trac/tahoe-lafs/query?status=assignedstatus=newstatus=reopenedkeywords=~regressionmilestone=1.11.0order=priority

The next step in the process of releasing v1.11 is to elect a
Release Manager. And by elect we mean that someone somehow gets
appointed to that role, and if they don't want to do it they have to
fight a bear.


Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

[tahoe-dev] press release: LeastAuthority.com announces Spy-Proof Backup

[Zooko Wilcox-OHearn]

Folks:

We're really happy to be offering our LAFS-based ciphertext storage
service to the public! Please spread the word. Thank you very much to
everyone in our little community for making things like this possible.

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep

https://LeastAuthority.com
Title: LeastAuthority.com Announces A Spy-Proof Storage Service






LeastAuthority.com Announces A Spy-Proof Storage Service

Wednesday, July 31, 2013
LeastAuthority.com today announced “Simple Secure Storage Service (S4)”, a backup service that encrypts your files to protect them from the prying eyes of spies and criminals.
“People deserve privacy and security in the digital data that make up our daily lives.” said the company's founder and CEO, Zooko Wilcox-O'Hearn. “As an individual or a business, you shouldn't have to give up control over your data in order to get the benefits of cloud storage.”

verifiable end-to-end security
The Simple Secure Storage Service offers verifiable end-to-end security.
It offers “end-to-end security” because all of the customer's data is encrypted locally — on the customer's own personal computer — before it is uploaded to the cloud. During its stay in the cloud, it cannot be decrypted by LeastAuthority.com, nor by anyone else, without the decryption key which is held only by the customer.
S4 offers “verifiable end-to-end security” because all of the source code that makes up the Simple Secure Storage Service is published for everyone to see. Not only is the source code publicly visible, but it also comes with Free (Libre) and Open Source rights granted to the public allowing anyone to inspect the source code, experiment on it, alter it, and even to distribute their own version of it and to sell commercial services.
Wilcox-O'Hearn says “If you rely on closed-source, proprietary software, then you're just taking the vendor's word for it that it actually provides the end-to-end security that they claim. As the PRISM scandal shows, that claim is sometimes a lie.”
The web site of LeastAuthority.com proudly states “We can never see your data, and you can always see our code.”.


trusted by experts
The Simple Secure Storage Service is built on a technology named “Least-Authority File System (LAFS)”. LAFS has been studied and used by computer scientists, hackers, Free and Open Source software developers, activists, the U.S. Defense Advanced Research Projects Agency, and the U.S. National Security Agency.
The design has been published in a peer-reviewed scientific workshop: Wilcox-O'Hearn, Zooko, and Brian Warner. “Tahoe: the least-authority filesystem.” Proceedings of the 4th ACM international workshop on Storage security and survivability. ACM, 2008. http://eprint.iacr.org/2012/524.pdf
It has been cited in more than 50 scientific research papers, and has received plaudits from the U.S. Comprehensive National Cybersecurity Initiative, which stated: “Systems like Least-Authority File System are making these methods immediately usable for securely and availably storing files at rest; we propose that the methods be further reviewed, written up, and strongly evangelized as best practices in both government and industry.”
Dr. Richard Stallman, President of the Free Software Foundation (https://fsf.org/) said “Free/Libre software is software that the users control. If you use only free/libre software, you control your local computing — but using the Internet raises other issues of freedom and privacy, which many network services don't respect. The Simple Secure Storage Service (S4) is an example of a network service that does respect your freedom and privacy.”
Jacob Appelbaum, Tor project developer (https://www.torproject.org/) and WikiLeaks volunteer (http://wikileaks.org/), said “LAFS's design acknowledges the importance of verifiable end-to-end security through cryptography, Free/Libre release of software and transparent peer-reviewed system design.”
The LAFS software is already packaged in several widely-used operating systems such as Debian GNU/Linux and Ubuntu.
https://LeastAuthority.com




___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

[tahoe-dev] report from Tahoe-LAFS Weekly Dev Chat 2013-07-04

[Zooko Wilcox-OHearn]

in attendance: Oleksandr, Zooko (scribe), Mark_B, Amber

First we looked at the last remaining test failure that happens on
Mark's #1382 branch. The test failure is in test_each_byte ¹, when it
is supposed to be corrupting the ciphertext hash tree. Mark_B's
changes changed the corrupted share from share-num 0 to share-num 2,
although this test really shouldn't be sensitive to *which* sharenum
was being corrupted. We began to suspect that the offsets in
need_4th_victims might be incorrect with respect to the layout
specified in src/allmydata/immutable/layout.py ², but we stopped
before confirming that. Mark is going to email Brian (the primary
author of that test) and ask for help.

I drew

Then we talked about what else Mark should work on, since he is mostly
done with his original GSoC project (☺!). I asked what he was
interested in. He suggested


¹ 
https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/src/allmydata/test/test_download.py?annotate=blamerev=3d771132a843a85578dc23a6cac55b4fae09fc64#L945

² 
https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/src/allmydata/immutable/layout.py?annotate=blamerev=3668cb3d068b7f3a56cc88e7c45d4f81c0b4f499#L27

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1382# immutable peer
selection refactoring and enhancements

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep

https://LeastAuthority.com
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

[tahoe-dev] FSF suggests Tahoe-LAFS

[Zooko Wilcox-OHearn]

Folks:

In response to the recent revelations of massive, intrusive spying by
the US Government, the Free Software Foundation made a statement
which, among other things, recommended the use of Tahoe-LAFS!

http://www.fsf.org/news/free-software-foundation-statement-on-prism-revelations

 Free software projects like GNU MediaGoblin, StatusNet, Diaspora,
pump.io, Tahoe-LAFS, FreedomBox and SparkleShare are hard at work
creating a less centralized world where users retain control over both
their media and the software used to access it, while still getting
the social and convenience benefits of the giant centralized -- and
compromised -- services. 

So, we should get ready to receive an influx of new users trying it
out because they've heard about it from the FSF! ☺ Batten the hatches!
Polish up the FAQ!

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep

https://LeastAuthority.com
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

[tahoe-dev] report from Weekly Dev Chat of 2013-05-30

[Zooko Wilcox-OHearn]

Weekly Dev Chat of 2013-05-30

This was a Nuts And Bolts meeting.

in attendance: Zooko, Nathan, Mark_B, Daira

Mark_B got some practice using git to rebase his branch for #740. This
skill will be important once his Google Summer of Code project
officially starts (approximately 2013-06-14).

We updated ticket #1818 to tell anyone who is looking for code to
review that they should go review #1819.

We discussed a tiny patch which will hopefully make it a teeny tiny
bit easier for people to learn the backupdb schema and maybe even an
infintesimal amount faster: #1864.

See the whole timeline:

https://tahoe-lafs.org/trac/tahoe-lafs/timeline

We aren't meeting next week or the next, due to Daira, Nathan, and me
traveling (Berlin!). The next meeting will therefore be 2013-06-20,
and the agenda will be to help Mark_B get going on his GSoC project! ☺

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep

https://LeastAuthority.com
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

[tahoe-dev] weekly dev chat report from 2013-04-25

[Zooko Wilcox-OHearn]

2013-04-25

in attendance: Tariq, Oleksandr, Andrew, Daira, Brian, Zooko (scribe), Mark

The topic was all about the Google Summer of Code project proposed by
Mark. We advised Mark that a good first goal for the summer would be to
finish Kevan's patch that implements Upload Strategy of Happiness.

There are a bunch of other related tickets that it would be cool to
fix, including a big refactoring to make immutable and mutable files
use the same or most of the same upload and download code. Hopefully
MarkB will make quick work of the initial Upload Strategy of
Happiness task and then take on other tasks afterward.

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep

https://LeastAuthority.com
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: [tahoe-dev] GSoC Share Rebalancing and Repair Proposal

[Zooko Wilcox-OHearn]

Thanks for the feedback, Kevan! We've integrated it into MarkB's GSoC proposal.

--Zooko
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

[tahoe-dev] weekly dev chat report for 2013-05-02

[Zooko Wilcox-OHearn]

(This may be confusing, because it is  cryptic and telegraphic and
also doesn't have anything to do with Tahoe-LAFS.)

In attendance: Brian, Zooko (scribe), Andrew, Amber, Daira

Brian says:

Bitcoin 1.0 is a specific implementation of a more general concept.

Actors

Secure Distributed ECMA Script

Purses

Verification doesn't necessarily have to be proof-of-work based.

Ben Laurie's cabal idea.

Maybe split up the jobs of sequencing and verification.

Ask everyone to commit to a statement of fact, and then after everyone
has committed, reveal.

This is an algorithm for reifying Schelling Points.

Zooko thinks this is vulnerable to manipulation for profit.

You might want to use this only for a few specific things.

Make a monster movie in which an alien gorilla attacks one of the
participants of the video chat.

The rules of the game get to change according to the votes of the
people playing the game.

You can submit patches to the code that runs the game board.

* full-scale actors in the block chain

* separating out the sequencing from the verification

* vote in patches

* could have lower super-majority requirements for unit-test-matching patches

* meetings, actors, secretaries, actors can be put into storage, ...

* you have to pay for CPU and RAM

* meetings can have predictable bounds, enforced

* use cases:
   + simple 1-in-1-out payment
   + multi-in-multi-out payment
   + ripped certificate
   + options contract of some kind

* transaction fees can be generalized into the notion of a tax

* if primary sequencer is detected cheating, he gets ejected and
replaced by one (random?) sequences from the pool of backup sequencers

Daira says:

next week's Weekly Dev Chat agenda: Noether

Amiller says:

* Scarcity is dead ; long live scarcity. ; Amiller doesn't like
gold-like scarcity, and likes credit networks like Ripple. ; Cites
alternative crypto-currencies as evidence against scarcity.

* When is it not in your best interest to mine on the longest chain?
When there is an exceptionally large transaction. What you should if
you win is take only a small slice and redistribute the rest to the
next miner... The coinbase maturity rule prevents that, so that rule
is an important design flaw.


Brian says:

* can vote in new rules changing money supply

Zooko says:

inputs to crypto-currency value: monetary base scarcity, gold-rush
effect, demand for crypto-currency as opposed to other currency ; The
latter is potentially far bigger than the first two, by at least
several orders of magnitude.


Amiller: i submit to the record my notes about the rational mining
behavior and coinbase maturity
https://gist.github.com/amiller/cf9af3fbc23a629d3084


--
Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep

https://LeastAuthority.com
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

[tahoe-dev] Weekly Dev Chat report, 2013-04-18

[Zooko Wilcox-OHearn]

2013-04-18

in attendance: Zooko, Oleg, Iraklis, CodesInChaos, Brian, Andrew, Daira, Amber

The topic was Andrew's mind-boggling PhD research project. It is a
type-driven compiler to generate authenticated data structures. So, if
I understand correctly, you write some code in a nice functional
language like Haskell that implements a data structure, and then you
apply these crazy type annotations to it that explain to Andrew's
compiler what it would mean for that thing to be an authenticated data
structure (i.e. soundness — the server can't forge the structure —
and correctness — whenever the server delivers an unforged answer,
the data structure produces the correct output). Then Andrew's
compiler generates a cryptographically-enforced version of the data
structure. This works for Merklizing arbitrary pointer-based data
structures (by using collision-resistant hashes as adjuncts to
pointers). Andrew has a demonstration of it which is an authenticated
Red-Black tree.

Watching this presentation melted my brain and I had to lie down
afterward. Daira bounced and clapped. She loved it. It all made
perfect sense to her.

Then, having got back up, I got on IRC and said a few things:

1. I'm interested in Red-Black trees as the basis of Large Distributed
Mutable Files.

2. I think relying on collision-resistance is iffy but relying on
2nd-pre-image-resistance is very safe. Here is an incomplete write-up
about that: 
https://zooko.com/uri/URI%3ADIR2-RO%3Ajztduk4og4p6meikidbxfkoeia%3Ayjx7niqa7czmtz6qn7calxpgr3nhjrdcnoxiz4t5pg7r4mwd5rvq/preimage-attacks.rst
 . The bottom line is that most of the real-world secure hash
functions ever created have turned out to be vulnerable to collisions,
but only one (Snefru, designed by Merkle in 1989) has ever turned out
to be vulnerable to 2nd-pre-images. So I actually care about the
difference between If this protocol is unsound then here is a hash
collision. and the more complicated If this protocol is unsound then
here is a second pre-image that hashes to the same image that the
pre-image you told me hashes to..

3. Down with K=2! Binary trees suck. I'm a fan of fanout. Hopefully
this is the sort of thing that is trivially covered by Andrew's
generalized system.

next meeting: starting at 15:30Z (8:30 AM Pacific) instead of 16:00Z
(9:00 AM Pacific), like this one did.

Possible agenda items:

* Could Amiller's generalized authenticated data structures be useful
for Tahoe-LAFS?
* 1.10
* share placement for 1.11
* GSoC students ?

I think we'll have time for only about two of those agenda items...

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep

https://LeastAuthority.com
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: [tahoe-dev] Weekly Dev Chat report, 2013-04-18

[Zooko Wilcox-OHearn]

corrections:

On Fri, Apr 19, 2013 at 4:24 PM, Zooko Wilcox-OHearn
zo...@leastauthority.com wrote:

 in attendance: Zooko, Oleg, Iraklis, CodesInChaos, Brian, Andrew, Daira, Amber

^-- and Tariq, and when I wrote Oleg, I mean Oleksandr.

Regards,

Zooko
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

[tahoe-dev] notes from weekly dev chat 2013-04-04

[Zooko Wilcox-OHearn]

Hi folks! Here is your regularly scheduled incomplete, cryptic notes
from the Weekly Dev Chat!

in attendance: Zooko, Daira, Andrew, Brian, Amber, Samuel

All tickets were either moved out of the 1.10 Milestone or assigned to
someone. They are all in the state of reviewing and fixing -- no new
code needs to be written.

Brian will cut an RC1 release of v1.10.0 within a week.

Next week's meeting will be a Nuts And Bolts meeting, but it will be
*post-1.10* Nuts and *post-1.10* Bolts! That will be fun!

proposed theme for 1.11 cycle: New automation to lower the friction of
the release process, so we can have more frequent releases. Buildbot
is chugging along, but needs oiling, new robot arms.

LeastAuthority.com submitted a second DARPA proposal. We'll find out
in about two weeks if it got accepted.

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep

https://LeastAuthority.com
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

[tahoe-dev] Tahoe-LAFS Users Group Meeting, San Francisco, Tuesday 2013-03-19

[Zooko Wilcox-OHearn]

You are invited to the Tahoe-LAFS Users Group Meeting!

Tahoe-LAFS is a secure, fault-tolerant, scalable storage system. It is
a Free/Open Source Software project. It is also an idea: we want to
see a World Wide Web that can't be censored or surveilled; a Web with
no master.

when and where:

Tuesday, March 19, 2013, 6 PM to 9 PM

Rackspace, 620 Folsom, Suite 100, San Francisco, CA

There will be pizza, from Goat Hill Pizza. Thanks to Rackspace for the
location and food!

Agenda:

1. Announcing Tahoe-LAFS v1.10

Whoo!

2. Tahoe-LAFS For Engineers Who Don't Care About Security

A 20-minute demo of installing the Tahoe-LAFS software, deploying a
grid of storage servers, using them to upload, download and browse
files. Then the punch line: did you notice what we *didn't* do during
this demo? Screw around with certificates, keys, encryption, or
decryption! You don't have to spend your time messing with that stuff
in order to use Tahoe-LAFS.

3. What Should We Put Into Tahoe-LAFS v1.11?

Who is using Tahoe-LAFS, what are you using it for, and what would it
make it more useful for you?

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep

https://LeastAuthority.com
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

[tahoe-dev] Weekly Dev Chat notes from 2013-03-07

[Zooko Wilcox-OHearn]

Sheesh, it takes a lot longer to write these notes up for the list
than it does to actually attend the dev chat.



in attendance: Oleksandr, Zooko (scribe), David-Sarah, Randall
ClashTheBunny Mason, Brian (late—one lash), Tony (late—one lash)

not in attendance: Andrew (ABSENT—two lashes)

sort-of-in-attendance (on the IRC channel): a lot of folks

Agenda: Tahoe-LAFS v1.10 (Nuts and Bolts)

SUMMARY:

This was awesome. We got lots of tickets closed, or at least pushed forward a
step or two. This was the most productive hour of ticket-closing work
ever. We're going to do it again next week! If you like doing code-review and
writing unit tests, you should join us.


DETAILS:

You can see also use the Trac Timeline:

https://tahoe-lafs.org/trac/tahoe-lafs/timeline


ClashTheBunny has some patches for IPv6 for Tahoe-LAFS and Foolscap (#867),
and has some tests of them but needs more thorough tests. However, we didn't
look at that this time, because we focused on tickets for Tahoe-LAFS v1.10.

Nejucomo said on IRC that he wasn't going to get around to manually verifying
that the bug we fixed in ticket #1679 was the same as the bug he reported. I
decided to just close the ticket for the following reasons: there *is* a bug
that we understand, there is a fix which is clear, there is a unit test that
exercises the bug that is red without the fix and green with the fix, and The
Dod manually verified that it fixed the problem in practice for him. The only
reason we've left the ticket open waiting for Nejucomo to test is in case
Nathan actually has a *different* bug than this one. But we don't need to
keep the ticket open for that eventuality.

ClashTheBunny did design review on #1732. He approved the design and made
good comments that showed that he actually had thought about it. Subsequently
Zooko added another design question and assigned it to Brian for design
re-re-re-review.

We looked at #1926. It is a blocker because it makes the SFTP frontend
incompatible with the current stable release of Twisted. However it is closed
as a duplicate of #1525 because the improvement in #1525 would remove the
incompatibility. We briefly considered kludging it by requiring people to
install an older Twisted, but instead decided to fix it the good
way. David-Sarah had already implemented the fix to #1525 but there was
something wrong with the unit test.

NEWFLASH! This just in! As we were going to press, David-Sarah posted on
#1525 a comment that they are currently working on it.

We discussed #1767. David-Sarah had an idea for how to make the
implementation simple, by incrementing the server-wide counter once for each
service. Brian will work on it. It and #1732 are the two blockers that
require new code to be written before we release Tahoe-LAFS v1.10.

We closed #1484 as fixed. Yay!

#1746 is finished, reviewed, and ought to go into Tahoe-LAFS v1.10, but I
can't figure out how to merge it into master using git. I don't understand
how to use git very well, since I've only been using it on a daily basis for
a little more than two years now...

#1812 was already applied, but there was something wrong with it according to
Brian. Do we need to fix that as a blocker for 1.10 release?

We agreed to drop support for Python 2.5 and therefore for CentOS 5.

In the last few minutes of the hangout, we agreed that next week's hangout
will be another Nuts And Bolts like this one, hopefully bringing Tahoe-LAFS
v1.10 close to completion. Brian will work on #1767. Someone (maybe Zooko??)
will work on #1732.

Then we briefly mentioned the possibility of switching from a semantic
versioning style version number, to a YEAR.RELEASE_COUNT version number like
Twisted does. So instead of Tahoe-LAFS v1.10, this might be Tahoe-LAFS
v13.0. Then if there is another release in 2013, that would be Tahoe-LAFS
v13.1. We also considered leaving it alone for the v1.10 release, and
switching styles for the next release.

Currently we use the 1. in Tahoe-LAFS v1.10 to mean that it has
backward-compatibility with all of the stable Tahoe-LAFS releases since v1.0
(released March 25, 2008:
https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Doc#TheParadeofReleaseNotes
). I'm not sure that's accurate. While we have never deliberately violated
that goal, and we are not aware of any change that we've made which would
break that compatibility, on the other hand we don't have automated or manual
testing of backwards compatibility. Anyway, I suspect that there aren't any
users of Tahoe-LAFS versions older than 1.9.2:
https://tahoe-lafs.org/trac/tahoe-lafs/wiki/OSPackages

tickets mentioned in this letter:

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/867# use ipv6
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1484# CLI: overzealous
quoting of error messages
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1525# SFTP: handle
download failures correctly; remove use of IFinishableConsumer
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1679# Nondeterministic
NoSharesError for direct 

Re: [tahoe-dev] Newbie problems

[Zooko Wilcox-OHearn]

Hello Owen Thomas. Welcome!

I'm sorry you had this trouble when experimenting with Tahoe-LAFS.

On Sun, Feb 3, 2013 at 2:55 PM, Owen Thomas
owen.tho...@redoakconsulting.co.uk wrote:

 Unfortunately when I opened the web client it states that it is not connected 
 to the introducer.

Could it be that the Test Grid introducer is down? I do not know who
is responsible for the Test Grid introducer. Let's see...

docs/running.rst ¹ points to wiki:TestGrid ² which has this introducer
furl: pb://u7w4hdwgw5lfsuw7cnovh4jcoyvlne7o@128.59.153.44:51644/introducer

nc tells me that nothing is accepting TCP connections on that host and port:

$ nc -v 128.59.153.44 51644
nc: connect to 128.59.153.44 port 51644 (tcp) failed: Connection refused

The furl was put there by David-Sarah in this edit:

https://tahoe-lafs.org/trac/tahoe-lafs/wiki/TestGrid?action=diffversion=73old_version=72

host 128.59.153.44 tells me tyler.cul.columbia.edu, which is running
a default Mac OS X Server page on port 80.

So, how about we do one of the following:

option a) Someone volunteers to become the Official Tahoe-LAFS.org
Test Grid Wrangler, and make sure there is a reliable introducer. That
person's name and email address appears next to the introducer furl on
the wiki.

option b) We edit running.rst to remove any mention of the existence
of a Public Test Grid and instead have it instruct people in how to
set up their own test grid.

Regards,

Zooko

¹ https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/running.rst

² https://tahoe-lafs.org/trac/tahoe-lafs/wiki/TestGrid



 I am (obviously?) doing something stupid but can’t work out what it is. I’ve
 tried Google, but nothing turns up.

 (I also tried setting up my own test introducer – on the Windows box – which
 did connect ok. However I hadn’t set up any storage so couldn’t play.)

 I am sitting behind a NAT. I have checked my firewall settings and can go
 out on all ports. I can ping the introducer host (128.59.153.44) and a trace
 route looks sensible.

 Any ideas?

 Owen



 __
 This email has been scanned by the Symantec Email Security.cloud service.
 For more information please visit http://www.symanteccloud.com
 __

 ___
 tahoe-dev mailing list
 tahoe-dev@tahoe-lafs.org
 https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev




-- 
Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep

https://LeastAuthority.com
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Re: [tahoe-dev] which net protocol(s)

[Zooko Wilcox-OHearn]

Hi Tom!

It goes through foolscap, which is a Python-specific remote object
protocol layered on top of TLS. So: foolscap over TLS (which is
implemented by pyOpenSSL) over TCP over IP.

There are a few resources that might be interesting for performance
analysis. The first one is the timeline on the Recent Uploads and
Downloads page. The timeline shows the time it took, in seconds, for
the various stages of a download of an immutable file. It shows a
different row for each storage server. It can be panned back and forth
and zoomed in and out with the mouse.

There is a status page about each specific upload or download, and
that page shows timings for how much time was spent in encryption, in
network send/recv, etc.

Regards,

Zooko
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

[tahoe-dev] Tahoe-LAFS Weekly Dev Chat, 2012-10-02

[Zooko Wilcox-OHearn]

Tahoe-LAFS Weely Dev Chat, 2012-10-02

in attendance: Zooko (scribe), David-Sarah, Andrew

CAVEAT LECTOR; Some of this was added by Zooko after the chat ended.

Andrew Miller has found three bugs in #1240: 1. There's a bug. 2. A
different code path partially compensates for it sometimes
(David-Sarah calls this a masking bug). 3. The tests aren't smart
enough to realize that that the task has been done wrong and masked
rather than done right. Unclear if Andrew will fix #1240 before
David-Sarah stops accepting patches into Tahoe-LAFS v1.10.

Andrew: Dynamic Merkle Tree -- a Red-Black Merkle Tree

deterministic balancing, good asymptotic cost even in the worst case,
good small constant

Any data structure can be Merklized by replacing the links with hashes.

Take MDMF and replace the Merkle Tree with a Red-Black Merkle Tree.
Now you have an LDMF! (Except the backend needs to be able to store,
find, and insert data blocks efficiently. Fortunately
LeastAuthority.com's new Cloud Backend can do that! Well actually
maybe it can't because it currently identifies the blocks by their
*block number*. But it is a lot closer than the current disk backend,
which stores the each block under its offset in a single share file.)

Andrew is trying to work out how to do the physical storage and
addressing, apart from the logical -- Merkle-Tree-authenticated
integrity-checking. He's looking at B trees or B+ trees. Zooko thinks
this may be closely related to tickets #1543, #1687.

Zooko is excited because of the history here. Brian and he thoughtof
the design of LDMF, then thought it was too hard and thought of the
design of MDMF, then thought that was too hard and invented SDMF,
which was stupid enough that they could implement it. Much later,
Kevan came along and, not realizing how hard MDMF was, decided to do
it for a summer project (Google Summer of Code) and worked really hard
and well on it for about two years, which is why we now have MDMF. So
why is Zooko excited? Because hopefully Andrew doesn't realize how
hard LDMF is!

Zooko recommended N. Askitis's dissertation on cache-oriented data structures.

Andrew has at least two other ideas, and is talking about putting all
three of them into his dissertation. Zooko thinks that's three
dissertations. Maybe Andrew should get three PhD's.

If you add access control at the sub-file level of granularity, so
that you can grant access to only *part* of an LDMF, then what's the
difference between a directory structure and an LDMF? You could store
a deep directory structure in an LDMF. The question is how do you
identify sub-parts of an LDMF in order to talk about them with someone
else and grant someone else access to them. You don't want to grant
them access to a byte span! Like, here's read access to bytes 1000
through 3000 of this file, because then you could no longer safely
insert and delete things in that file.

Brian once suggested packing the share data of multiple files and
directories together for more efficient download and storage -- a
Virtual CD -- #204, #1029.

Once we finish the next RAIC Milestone, David-Sarah will focus on
Tahoe-LAFS v1.10 release. Zooko may not be able to focus on that much
due to ongoing LeastAuthority.com work. LeastAuthority.com is bidding
for another contract.

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/204# virtual CDs
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1029# download a subtree
as an archive
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1240# remove
ResponseCache in favour of MDMFSlotReadProxy's cache
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1543# rearrange share
format to make downloads faster
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1687# store copy of
block-hash-chain with each block


Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep

https://LeastAuthority.com
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

[tahoe-dev] introducing Least Authority Enterprises

[Zooko Wilcox-OHearn]

Dear people of the tahoe-dev mailing list:

David-Sarah Hopwood, Zancas Wilcox, and I are working on a startup to
commercialize Tahoe-LAFS, named Least Authority Enterprises.

https://leastauthority.com

We're simply selling Tahoe-LAFS storage service backed on Amazon S3.
Tahoe-LAFS storage service means, of course, storage of your
ciphertext. Neither your plaintext nor your keys ever get anywhere
near us.

Since this, as far as I remember, the first time I've mentioned Least
Authority Enterprises on this mailing list, let me quickly state a few
things about governance, intellectual property, and our relationship
to the open source project:

* We employ myself, David-Sarah Hopwood and Zancas Wilcox. We don't
employ any of the other major contributors to the Tahoe-LAFS project
so far. I am the CEO of Least Authority Enterprises.

* So far, we contribute all of the Tahoe-LAFS code we write to the
Tahoe-LAFS project under the terms of its open source licences. This
is the best thing to do for our customers, because it is good for the
quality of our code, it allows the customers to have a thorough
understanding of what happens to their ciphertext on the backend, and
it gives our customers the best chance of continuity and support (even
if our company were to go out of business).

* The non-profit Tahoe-LAFS Software Foundation (Peter Secor,
President and Treasurer) holds the rights to relicense the Tahoe-LAFS
source code under different licensing terms. Whenever new contributors
offer substantial patches to Tahoe-LAFS, the developers ask them if
they would agree to give the Tahoe-LAFS Software Foundation the right
to relicense their contributions under terms of its choice, and so far
they've always unhesitatingly agreed. Least Authority Enterprises
doesn't own any special privileges to the Tahoe-LAFS source code -- we
at the company don't have any rights to do anything with it that you
don't also have.

* In the future, when LAE creates some new derived work of Tahoe-LAFS,
we might exercise the right to withhold the source code of our derived
work for up to 12 months. This is the same right that you, and
everyone, also has, under the terms of the Transitive Grace Period
Public Licence:
https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/about.rst .
We're not currently planning on doing that, but we could change our
minds.

* We haven't applied for any patents. We're not planning to. We could
change our minds. If we ever offer any contributions to the Tahoe-LAFS
project which are covered by any patent that we've applied for then as
employees of Least Authority Enterprises we'll make that clear to the
other developers and to you, the community of users. (Also, as members
of the open source community, we wouldn't accept such contributions,
unless possibly if there were some sort of licence which permitted all
users of the open source software to exercise the patent freely or
something.)

* We welcome feedback from the community on our technology and
business decisions. For anything topical to Tahoe-LAFS itself, you can
post to this list and we'll reply, or for private matters you can
write to zo...@leastauthority.com or to i...@leastauthority.com.

* The in-development versions of our work are available to the public
under the open source licences even before they are accepted into
Tahoe-LAFS trunk, for example here:
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1569 . Patches and
code-review welcome!

* The service itself is currently open to all customers who are
willing to alpha-test it. Just sign up on the web site and be prepared
to tolerate a few rough edges and to chat with us about how you like
it, what you use it for, and what you want out of future versions of
the product. The price is $1.00/GB/month. You pay only for what you
use. (Discounts are available for full-time students, educational
institutions, libraries, non-profits, and open source projects.)

Thank you very much! I'm excited about having hitched our wagon to
the Tahoe-LAFS project, both because of its technical excellence and
because of the vibrant open source community around it. Thank you for
being part of that!

Regards,

Zooko Wilcox-O'Hearn

CEO, Least Authority Enterprises

https://leastauthority.com
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev