<div dir="ltr">Tahoe-LAFS devchat 20-March-2018<div><br></div><div>A few topics arose but I focused my note-taking on the topic of porting Tahoe-LAFS to Python 3.  The focus of the discussion was how to deal with the Foolscap dependency.  One option is to port Foolscap to Python 3.  However, another option is to port Tahoe-LAFS to a non-Foolscap protocol which already has a Python 3 implementation.  This is the option we discussed.</div><div><br></div><div>The concerns dictating a replacement for Foolscap are:</div><div><ul><li>a Python 3 implementation</li><li><i>other</i> language implementations to encourage more alternate-language implementations</li><li>Marketing considerations ("look we use this industry standard protocol")</li><li>Firewall penetration capabilities and other network-related concerns</li><li>Bidirectionality (though Tahoe-LAFS doesn't really use this now it would be beneficial for a number of future enhancements such as improved magic-folder change notification)</li></ul><div>HTTP is an obvious choice based on these concerns.  Combined with WebSockets it should satisfy every bullet point.  Brian has a branch where he started some HTTP work.</div></div><div><br></div><div>What would an HTTP protocol look like?  Should it be ReSTful?  Should the HTTP be purely a transport for some more structured data represented with a protocol like BSON, etc?  How should authentication and integrity be handled - should requests be signed?  should requests be accepted if they result in valid share state (the write-enabler makes this trickier for mutable files - should the write enabler be removed?  or is there a way to preserve it with a new protocol?  it's derived from the storage server's TLS certificate - can the new HTTP(S) protocol re-use this certificate?)</div><div><br></div><div>What is the immutable file protocol?</div><div><ul><li>Read (offset, length)</li><li>Advise corrupt share</li><li>Allocate Buckets (storage-index, secrets, share-numbers, share-size) returning set[existing-share-indices], dict[bucket-writers]</li><li>BucketWriter - write (offset, data), close, abort</li></ul><div><br></div></div><div>How does that map to HTTP?</div><div><br></div><div>Accounting rears its head (or maybe it's scope creep wearing an accounting mask).  How can clients be limited in their storage usage?  Uploads could be signed by a key authorizing some consumption (and therefore creating accountability for storage usage for the key-holder).  Variations:</div><div><ul><li>Allocate Buckets could be signed</li><li>Close could be signed</li></ul><div>Different approaches have different consequences for upload complexity (eg in terms of number of passes over the data).</div></div><div><br></div><div>And download authorization?  Present system allows anyone with access unlimited download bandwidth.  Accounting should deal with this as well.</div><div><br></div><div>What about the other places Tahoe-LAFS uses Foolscap?  There's client<->introducer, client<->storageserver, and introducer<->storageserver.  We don't have to port all of these at once.</div><div><br></div><div>Action items:</div><div><ul><li>Complete HTTP-based spec for the immutable file interface.  Evaluate for feasibility, feature-equivalence to current API (including security, performance, extensibility).</li><li>Repeat for mutable files, pubsub (considering potential future magic folder features).</li><li>Brian will provide a reference to the already-started HTTP efforts.</li></ul><div><br></div></div><div>Also some stuff about setuptools wrt some old, hopefully obsolete cruft in Tahoe-LAFS setup.py et al and specifically relating to some problems on CI with very old setuptools.  Details too complicated to accurately record during the conversation.  Brian went ahead and did Some Stuff[tm] to try to address this shortly after the devchat.</div><div><br></div><div>Jean-Paul</div></div>