<div dir="ltr"><p>Dear Tahoe-LAFS community,</p><p>Over the years, we’ve discussed various approaches to accounting and grid access control. Our team is now interested in extending the Tahoe-LAFS protocol so as to provide more granular access-control to storage server resources. There are situations in which it might be desirable to limit access to particular users -- for example, to deny access to abusive users, or to require compensation to storage server operators before access is granted -- without inconveniencing (e.g., by requiring migration to a new set of storage fURLs) other users.</p><p>In our particular case -- supporting the PrivateStorage.io Tahoe-LAFS deployment -- we are interested in providing paid access to Tahoe-LAFS storage servers.  This implies the ability to revoke access to those servers when a user chooses to end their relationship with the service. We are interested in doing this in a way that improves Tahoe-LAFS for everyone and generally fits with the project's overall goals. We would like to work with you to be able to contribute this code back to the master Tahoe-LAFS branch.</p><p>We are operating with these requirements in mind:</p><ul><li><p>Preserve Tahoe's existing privacy properties: Unlinkability a) between individual shares, and b) between shares and the users that can read/write them -- in other words, minimize server-side tracking and metadata trails</p></li><li><p>Preserve Tahoe's existing use-cases (friendnets, etc.)</p></li><li><p>Create the ability to deny share read and write access per-storage server based to certain users.</p></li></ul><p>The approach we are most actively exploring now is to expand most of the storage server APIs that involve shares, perhaps starting with the lease management APIs add_lease and renew_lease, but not necessarily being limited to these. These would change to have one or more new optional parameters giving some value that proves a right to access. </p><p>The storage server would also be extended to support pluggable interpretation of these values, allowing policy to be set by the server operator. One such policy, likely the policy we will pursue, is to have a PrivacyPass-like token (<a href="https://privacypass.github.io/protocol/">https://privacypass.github.io/protocol/</a>) which can be issued upon receipt of payment (rather than completion of a CAPTCHA as is PrivacyPass' original intended use). (Credit to Str4d for suggesting this approach to Liz.) Other policies could include signed access tokens, shared secrets, cryptocurrency systems, and other sophisticated cryptographic protocols.</p><p>This approach is inspired and informed by many past discussions within the community about economic models for Tahoe-LAFS usage, too many to link to.</p><p>The questions we have for the Tahoe-LAFS community are:</p><ul><li><p>Would you be interested in having these changes roll into Tahoe-LAFS</p></li><li><p>Are there other approaches we should discuss in the community? </p></li><li><p>If you are a storage grid operator, would you use this? If so, how would you like to bill/charge users of grids (bandwidth? bytes-stored over time? access over time? etc.)? -- in other words, how could our implementation better-support your desired use-case?</p></li></ul>Thanks!<br>Jean-Paul</div>