Folks: We had another Tahoe-LAFS Weekly Call. Here are my notes, which are patchy and could be inaccurate. You could check this publicly editable notepad for updates from the other attendees of the call. http://titanpad.com/qnudyEsEoR In attendance: Brian, David-Sarah, Zooko About leasedb schema and Python code: b" Use ascii-encoded or binary blobs in the leasedb (sqlite db)? b" Use ascii-encoded or binary strings to hold things like shareids inside the Python interpreter? About accounting: Server admin should be able to see aggregate usage per account. We have read-only admin WUIs because we don't yet have a good technology to authorize the administrator to access a WUI without exposing the same access to CSRF attacks. (Brian has a prototype solution in his "toolbed" project.) Use cases of sharing: b" Club b" For-profit service (e.g. Least Authority) Individual pairwise storage relationships: b" Social (as long as there is visibility and control, Bob doesn't need to feel like he needs something explicit specific in exchange) b" Money b" Tit for Tat b" 3-way: Bob is running a server, Alice is running a client. She is also, separately running a server (or hiring someone else to run a server that Bob can use). So, Bob wants to let Alice's client use his server because he knows that she is responsible for that other server that he can use. Somewhere along the line there is going to be a graph of who likes whom -- who has accepted storage obligations for whom. Eventually Brian wants to provide tools at *least* to visualize, and ideally to manage, this network of social relationships. People could, perhaps configure their node to give anybody storage space as long as that person is giving you at least X% as much storage space (Tit for Tat). The three messages are: 1. I will accept shares from this other person. 2. I'm willing to send shares to this other person. 3. I'm working for this other person (as a storage server). Next week: b" Try some alternate tech such as Google Hangouts or Skype? POTS quality is bad enough to interfere with communication. b" More about accounting relationship management -- present the higher-altitude picture of the roadmap from Brian's mind. The short-term decision that we have to make is whether to have one key or two keys -- a separate key for the client and for the server. After David-Sarah rang off for dinner, Zooko made the following proposal to Brian as a "baby step". Zooko's motivation is that this would be simple to understand (especially for non-Brian people), and useful (e.g. to volunteergrid2 folks), and hopefully forward-compatible with the better "invitation protocol" design that Brian has in mind. Baby Step Proposal: There is a file named "clients.txt" which is edited by a human and is treated as read-only by the Tahoe-LAFS storage server (and is ignored entirely by Tahoe-LAFS the storage client). It is a text file with one record per line. Each record is a complete ascii-encoded public key followed by an optional whitespace and pet name. If your client's public key appears in the server's "clients.txt" file, then your storage usage gets accounted for and displayed to the storage server owner with his petname for you. If your client's public key does not appear in that clients.txt, then your storage usage goes into the "open, anonymous" accounting bucket (or else maybe gets tracked under your public key?). Or, the storage server operator can turn on the mode where if your client's public key does not appear in his "clients.txt" file, then it refuses to let you store data there at all. There is an analogous file named "servers.txt" which is read but not written by Tahoe-LAFS storage clients and is ignored entirely by Tahoe-LAFS storage servers. This file contains a list of public keys and optional petnames for storage servers. In "backwards compatibility mode", it tracks which of those servers you store how much data with. In "strict mode", it refuses to store data with storage servers that don't have public keys in that file. _______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE