1.9.2 Released

David-Sarah announced the release of Tahoe-LAFS 1.9.2. Tahoe-LAFS 1.9.2 is primarily a bugfix release which fixes regressions in mutable file support. Take a look at NEWS to see all the fixes.

On the limits of the use cases for authenticated encryption

Zooko announced Tahoe-LAFS's use case was discussed at Directions in Authenticated Ciphers workshop. Zooko decided "authenticated encryption" is not useless for Tahoe-LAFS use cases. He believes Tahoe-LAFS needs "public key authenticated encryption" instead of "symmetric key".

p2p or client/server (Introducers to gossip)

Discussion continues on the introducers to gossip thread. The discussion centers on whether to continue with the client/server architecture or move to a p2p style architecture. Users of client/server most likely want:

Which services? Each node operates, by default, only the services that the operator manually configured it to run. Even better you can install the software sufficient to run a specific kind of node, e.g. a storage server, without installing the software that would let it run other servers, such as introducers or storage clients (#1694).

Which IP addresses? Nodes do not automatically detect their own IP addresses, but instead use only the IP address that their sysadmin manually told them to use. This is especially important for tor and i2p people where any auto-discovered IP address threatens the user's safety (#517).

Which connections? You try to establish the prescribed TCP connection(s) to your server. If that fails, you log/announce failure. In the future you might even be able to configure it to run exclusively over HTTP(S) and then pass all of its connections through your HTTP proxies and Web Services tools (#510, #1007).

(Although sysadmins may actually like the "try to connect to multiple IP/DNS addresses at once" feature, if it is sufficiently understandable and controllable to them. It would ease some headaches provided by the Amazon Web Services EC2 TCP/DNS infrastructure, for example.)

How to handle NAT/firewall/inconveniently-behaving-router? If you can't establish a TCP connection to your prescribed target, then obviously you should not talk to it. Either some wise sysadmin doesn't want you to (firewall) or some stupid sysadmin has screwed up the network config and needs to fix it. In either case you should log failure and give up immediately.

Reverse connections? Clients connect to servers. Servers do not connect to clients, clients do not connect to other clients, and servers do not connect to other servers (#344). To violate this principle means you will receive a visit from your keen-eyed sysadmin who will want to know what the hell you are doing.

Users of the p2p model probably want:

Which services? Each node operates, by default, only the services that the operator manually configured it to run. Even better you can install the software sufficient to run a specific kind of node, e.g. a storage server, without installing the software that would let it run other servers, such as introducers or storage clients (#1694).

Which IP addresses? Nodes do not automatically detect their own IP addresses, but instead use only the IP address that their sysadmin manually told them to use. This is especially important for tor and i2p people where any auto-discovered IP address threatens the user's safety (#517).

Which connections? You try to establish the prescribed TCP connection(s) to your server. If that fails, you log/announce failure. In the future you might even be able to configure it to run exclusively over HTTP(S) and then pass all of its connections through your HTTP proxies and Web Services tools (#510, #1007).

(Although sysadmins may actually like the "try to connect to multiple IP/DNS addresses at once" feature, if it is sufficiently understandable and controllable to them. It would ease some headaches provided by the Amazon Web Services EC2 TCP/DNS infrastructure, for example.)

How to handle NAT/firewall/inconveniently-behaving-router? If you can't establish a TCP connection to your prescribed target, then obviously you should not talk to it. Either some wise sysadmin doesn't want you to (firewall) or some stupid sysadmin has screwed up the network config and needs to fix it. In either case you should log failure and give up immediately.

Reverse connections? Clients connect to servers. Servers do not connect to clients, clients do not connect to other clients, and servers do not connect to other servers (#344). To violate this principle means you will receive a visit from your keen-eyed sysadmin who will want to know what the hell you are doing .

Users of a p2p model probably want:

Which services? Each node operates, by default, multiple services -- storage server, storage client == web gateway, introducer/gossiper, and in the future other services like relay server (to help get around incomplete connectivity of the underlying network -- #445).

Which IP addresses? Nodes automatically detect their own IP addresses, such as by inspecting the output of "/sbin/ifconfig" or "route.exe", or opening a TCP connection to some helpful STUNT/ICE server and asking that server what IP address your packets appear to be coming from (#50).

Which connections? Nodes advertise multiple IP addresses / DNS names (possibly including those auto-discovered as above, plus any that were manually entered by the user (#754), plus 127.0.0.1 or any globally-non-routeable IP addresses revealed by ifconfig, and possibly in the future including indirection through a relay server), peers attempt to connect to nodes on all advertised IP addresses / DNS names in parallel, then use whichever connections succeeded.

How to handle NAT/firewall/inconveniently-behaving-router? Nodes utilize the latest and greatest Romulan packet technology, such as UPnP (#49), "NAT hole punching" techniques (#169) or even µTP (#1179) or relay service (#445) to breeze through such impediments as though they weren't even there.

Reverse connections? If a TCP connection is established from node A to node B, then B can use that in the "reverse direction" to make requests of A, just as well as A can use it to make requests of B. This means that if A is behind a firewall which allows outgoing but not incoming connections to be established, and A established an outgoing connection to B, then B can use A as a server, but C, which for some reason didn't get a connection from A, cannot use A as a server. (#1086)