Tahoe-LAFS dev-chat notes 2018-05-22

flupke flupke.tahoe-dev at liminal-space-agency.org
Tue May 22 19:26:49 UTC 2018

Dear reader,

here are the minutes of todays dev-chat:

dev-chat notes 2018-05-22

Tahoe-LAFS devchat 2018-05-22

attendees: flupke, exarkun, meejah

1. Release
	* There is a branch now: https://github.com/tahoe-lafs/tahoe-lafs/pull/497
	* news file updated
	* meejah went through checklist and did some things
	* exarkun will review

1.1 branch cleanup
	* meejah will write a script to extract ticket numbers
	* if ticket is close, branch will get nucked

2. Great Black Swamp
	* new protocol to talk to storage servers
	* review
		* are desired security properties there?
		* functional properties there?
		* convey enough information to talk to storage servers?
		* exarkun will open PR for discussion: https://github.com/tahoe-lafs/tahoe-lafs/pull/499
		* http://cbor.io/ CBOR encoding since it is simple enough
		* JSON as fallback (+ base64 for binary) and for testing
		* other encodings dismissed as too complex/powerful
		* Haskell implementation as soon as spec is blessed by community

3. grid manager
	* meejah implemented some things over the weekend
	* https://github.com/tahoe-lafs/tahoe-lafs/pull/498
	* enable adding storage server by name to grid
	* some certificate handling and distribution
	* gridmanager code is really complex in some spots
	* node.pubkey is only written, never read in tahoe -> different indentity mechanism used?
		* still tied to identity in foolscap
		* preserved in great black swamp
	* --config to get configuration from somewhere (disk, other storage server ...)
	* TODO: write a transition story (un-managed to managed grid)
	* should we download from storage-servers not blessed by a grid-manager?
		* it's safe
		* one reason not to: the tahoe code is complex, and might be easier to audit if we just never connect to "not blessed" storage servers
		* migration: uploading to non-blessed storage servers might make transition easier?
		* if you have non-managed grid, the steps to get to a managed grid are:
			* create a grid-manager
			* add all storage-servers to the grid manager
			* make certificates for all of them
			* distribute certificates to all storage-servers
			* (can now confirm they're all publishing)
			* distribute grid-manager pubkey to all clients
	* there are other tickets in the tracker about related features (of various ways to "discriminate" against which storage servers you use)
		* makes sense to unify all these concepts (or at least discuss how they relate)
		* maybe it makes sense to implement grid-manager things as a "plugin"-style thing so future stuff can use it too
		* (we don't have to write the first implementation as a future-proof-plugin-all-singing-all-dancing API)
	* gridmananger to remove introducer as single point of failure -> more gossipy protocol?
	* anyone with access to the grid can be storage server
		* can't stop anyone from providing storage services
		* all legit clients don't (want to) unblessed storage server
		* limit clients on which storage servers they can talk to (requires complitaed YAML file in private directory)
	* singed certs to tell storage servers apart (clients already have identities)
	* encoding parameters on per file basis (via API in the future)?
	* every client gets an identity, but clients can change it as often as they want (for anonymity)
	* there are some notes on all this "client identity" and grid-manager adjacent topics in the last Tahoe-LAFS Summit (SFO) on the wiki

4. magic-folder hypothesis tests
	* session on thursday with exarkun and meejah


More information about the tahoe-dev mailing list