| | 1 | originally from https://tahoe-lafs.org/pipermail/tahoe-dev/2010-December/005748.html : |
| | 2 | |
| | 3 | Each time we cycle around this topic, we chip away at the complexity, |
| | 4 | prune back some of the loftier goals, haggle for a couple of weeks, then |
| | 5 | throw up our hands and go back to our day jobs for another couple |
| | 6 | months. |
| | 7 | |
| | 8 | This time around, here are the previous lofty goals that I [Brian] am going to |
| | 9 | move into the non-goal category: |
| | 10 | |
| | 11 | - repairer: who pays for the new share? |
| | 12 | - sub-accounts, delegation, allmydata partners |
| | 13 | - public webapi node: extending accounting beyond node and through |
| | 14 | webapi/WUI: when Bob uses a public WUI, how can his shares be |
| | 15 | counted against his quota instead of the webapi operator's? |
| | 16 | |
| | 17 | and I want to move a set of things into a "phase 2" category, to be |
| | 18 | figured out after we get the "phase 1" stuff done: |
| | 19 | |
| | 20 | - Invitations |
| | 21 | - transitive introductions |
| | 22 | - account managers |
| | 23 | - pay-for-storage |
| | 24 | - tit-for-tat |
| | 25 | |
| | 26 | Also, we have a new inspiration: we've been talking a lot about the work of |
| | 27 | [http://en.wikipedia.org/wiki/Elinor_Ostrom Elinor Ostrom], who has written a |
| | 28 | lot about communities who successfully manage common resources without suffering |
| | 29 | from the well-known "Tragedy Of The Commons". She established a set of principles |
| | 30 | that these communities had in common: |
| | 31 | |
| | 32 | 1. Clearly defined boundaries (effective exclusion of external |
| | 33 | unentitled parties); |
| | 34 | 2. Rules regarding the appropriation and provision of common |
| | 35 | resources are adapted to local conditions; |
| | 36 | 3. Collective-choice arrangements allow most resource appropriators |
| | 37 | to participate in the decision-making process; |
| | 38 | 4. Effective monitoring by monitors who are part of or accountable to |
| | 39 | the appropriators; |
| | 40 | 5. There is a scale of graduated sanctions for resource appropriators |
| | 41 | who violate community rules; |
| | 42 | 6. Mechanisms of conflict resolution are cheap and of easy access; |
| | 43 | 7. The self-determination of the community is recognized by |
| | 44 | higher-level authorities; |
| | 45 | 8. In the case of larger common-pool resources: organization in the |
| | 46 | form of multiple layers of nested enterprises, with small local |
| | 47 | CPRs at the base level. |
| | 48 | |
| | 49 | In the Tahoe context, that means that the participants of a given grid |
| | 50 | (both clients using storage and servers providing storage) should have a |
| | 51 | lot of information about who is using what on where, and should have |
| | 52 | control over that space (being able to say no). There should be some |
| | 53 | obviously public broadcast channels, so everybody knows that everybody |
| | 54 | else knows who is using what. |
| | 55 | |
| | 56 | So, in my current line of thinking, an Accounting Phase 1 is looking |
| | 57 | like this: |
| | 58 | |
| | 59 | *** tahoe.cfg:storage gets some new flags: |
| | 60 | - accounting=enabled |
| | 61 | - this turns on the lease-owner DB. Existing shares are marked |
| | 62 | 'anonymous'. New shares that arrive through the old |
| | 63 | RIStorageServer interface are labeled according to the TubID of |
| | 64 | the other end of the connection. New shares that arrive through |
| | 65 | the new RIAccountableStorageServer interface are labeled |
| | 66 | according to the account under which that interface object was |
| | 67 | created (see below). |
| | 68 | - accounting=required |
| | 69 | - this reads "storage-accounts.txt" for a list of accounts. Each |
| | 70 | contains a pubkey, a petname, and maybe some additional |
| | 71 | information (either local notes, or self-describing data sent by |
| | 72 | the privkey holder) |
| | 73 | - the RIStorageServer interface no longer accepts shares. Only |
| | 74 | RIAccountableStorageServer accepts them. |
| | 75 | |
| | 76 | *** tahoe.cfg:client gets some new flags |
| | 77 | - actually it needs to be in private/ somewhere |
| | 78 | - add a privkey. If present, clients will connect to |
| | 79 | RIStorageServer, then attempt to upgrade to |
| | 80 | RIAccountableStorageServer by sending a signed upgrade request |
| | 81 | - clients do all their storage ops through the |
| | 82 | RIAccountableStorageServer, which causes their shares to be |
| | 83 | labeled |
| | 84 | - RIAccountableStorageServer also includes get-my-total-usage |
| | 85 | methods |
| | 86 | |
| | 87 | *** the welcome page gets a new control panel |
| | 88 | - not sure if it needs to be user-private or not |
| | 89 | - storage-server panel: |
| | 90 | - contains lists of accounts that are consuming your storage |
| | 91 | - if accounting=required, add buttons to freeze/thaw the account, |
| | 92 | cautious button to delete all shares |
| | 93 | - client panel: |
| | 94 | - contains lists of servers that are holding your shares |
| | 95 | - combo "grid" panel: |
| | 96 | - contains both, correlated |
| | 97 | |
| | 98 | *** maybe broadcast channel of activity |
| | 99 | - daily, maybe at first hourly digest of aggregate usage |
| | 100 | - "Bob uploaded 62MB of data". "Alice downloaded 146MB of data" |
| | 101 | - "Bob is currently using 3.5GB of storage space" |
| | 102 | - "Alice is currently hosting 4.2GB of shares and has 0.8GB free" |
| | 103 | - also include new-server, new-client events |
| | 104 | - "Carol joined the grid, offering 3.0GB of storage space" |
| | 105 | - "Dave invited Edgar to join the grid" |
| | 106 | - and server-admin actions |
| | 107 | - "Carol froze Bob's shares: dude, you're using too much" |
| | 108 | - "David deleted Alice's shares: you unfriended me on facebook so |
| | 109 | I'm deleting all your data" |
| | 110 | - also generalized chat |
| | 111 | - "Bob says: anyone up for pizza tonight?" |
| | 112 | |
| | 113 | *** storage server needs a new crawler |
| | 114 | - or the existing LeaseCrawler needs some new features |
| | 115 | - shares contain canonical lease info, but local |
| | 116 | who-is-consuming-what and remote get-my-total-usage methods need |
| | 117 | pre-generated totals |
| | 118 | - once usage DB is complete, new shares are added at time of upload |
| | 119 | - but we must be able to generate/regenerate usage DB from just the |
| | 120 | shares (er, just shares plus table of ownerid->account data, since |
| | 121 | share.lease.ownerid field is too small) |
| | 122 | |
| | 123 | *** RIStorageServer gets new upgrade method |
| | 124 | - accepts a signed request, returns RIAccountableStorageServer facet |
| | 125 | - request needs to be scoped correctly: server1 should not be able |
| | 126 | to get Alice's facet on server2. Request should include serverid. |
| | 127 | - for transitive introductions, request may also contain |
| | 128 | recommendations / certchains / introduction path |
| | 129 | - upgrade method may fail when server doesn't like the client |
| | 130 | - might be a temporary failure: the upgrade request might get |
| | 131 | elevated to the storage server admin for approval. Might want "try |
| | 132 | again later (at time=T)" response code. |
| | 133 | - storage requests to RIAccountableStorageServer might fail if |
| | 134 | server-admin freezes or cancels the account. get-my-total-usage |
| | 135 | should keep working in many cases. |
| | 136 | |
| | 137 | The general idea is that new (accounting-aware) clients will use a new |
| | 138 | storage-server object, one which is dedicated just to a specific account |
| | 139 | (as defined by an ECDSA pubkey), which will keep track of how much |
| | 140 | they're using. To access the new object, they'll submit a signed request |
| | 141 | to some publically-visible object (either the old RIStorageServer FURL, |
| | 142 | or a new account-desk FURL published next to the old one in the #466 |
| | 143 | dict-based announcement). The new object will also have methods to query |
| | 144 | current usage. Clients ought to keep track of how much they've uploaded |
| | 145 | to servers, but since they haven't ever done this in the past, it may be |
| | 146 | hard to get an accurate count without relying upon each server. |
| | 147 | |
| | 148 | The Introducer will also need to help create the broadcast channel, |
| | 149 | either by presenting broadcast messages as Announcements, or by running |
| | 150 | a pubsub service directly. |
| | 151 | |
| | 152 | |
| | 153 | If we complete this, and we implement some small UI/tahoe.cfg for it, I |
| | 154 | think we'll have a good starting point for friend-net grids: |
| | 155 | |
| | 156 | - each client will generate a keypair at startup |
| | 157 | - all shares (well, all leases) will be associated with a specific |
| | 158 | client (with a nickname) |
| | 159 | - servers will accept shares from anybody, but they'll have a table of |
| | 160 | who is using how much. An attacker can still create thousands of |
| | 161 | throwaway accounts, but it'll be obvious that this is going on. In |
| | 162 | the non-attacker case, all participants will be able to view how |
| | 163 | space is being used by each other. |
| | 164 | |
| | 165 | Then we can start to figure out the not-so-friendly grids, where you |
| | 166 | don't accept data from just anybody. To get there, we'll need to start |
| | 167 | with explicitly-configured whitelists (a list of client pubkey |
| | 168 | identifiers who can store data, and nobody else is accepted), and then |
| | 169 | quickly move to a better (i.e. more automatic) workflow like Invitations |
| | 170 | or Account Managers or something. Eventually that may get us back to |
| | 171 | more traditional economics where a node can accept money of some sort |
| | 172 | (BTC!) to enable storage for a given client. |
