| | 55 | |
| | 56 | == Design Overview == |
| | 57 | |
| | 58 | As touched upon in source:docs/proposed/accounts-pubkey.txt (and |
| | 59 | source:docs/proposed/accounts-introducer.txt), each share on a storage server |
| | 60 | is kept alive (in a garbage-collection sense) by one or more "leases", and |
| | 61 | each lease is assigned to a given "account"/"user"/"owner". The server has an |
| | 62 | imaginary "lease table" (imaginary in the snese that it is not actually |
| | 63 | implemented as a giant table: instead the data is broken up into more |
| | 64 | efficient/robust pieces). This two-dimensional lease table has Storage Index |
| | 65 | along one axis, and Account on the other, and each cell of the table |
| | 66 | represents a potential lease. |
| | 67 | |
| | 68 | Each account-owner gets control over their column of the table: they can add |
| | 69 | leases to existing shares, upload new shares (which immediately acquire new |
| | 70 | leases), cancel their lease on a share (possibly causing the share to be |
| | 71 | garbage-collected), or get a list of all of their leases (for |
| | 72 | reconcilliation). |
| | 73 | |
| | 74 | Some clients may be "super-powered", meaning that they may have the authority |
| | 75 | to affect more than one row of the table. It may be necessary to give a |
| | 76 | Repairer this sort of authority to let it keep files alive when the original |
| | 77 | uploading client is not participating in the maintenance process. POLA |
| | 78 | dictates that we try to avoid needing this sort of authority inflation, so |
| | 79 | superpower delegation is just a fallback plan. |
| | 80 | |
| | 81 | The admin of each storage server decides their own policy by configuring |
| | 82 | their server with various certificates and public keys: fundamentally, |
| | 83 | storage authority originates with the server, and is delegated outwards to |
| | 84 | the clients. Clients are configured with certificates and private keys that |
| | 85 | allow them to use some portion of the server's authority. |
| | 86 | |
| | 87 | Each time a client uploads a file (or otherwise makes use of storage |
| | 88 | authority), they must demonstrate their authority to each server, through a |
| | 89 | negotiation protocol. The {{{client.upload()}}} API will be modified to |
| | 90 | accept a new argument, tenatively named "cred=", that represents this |
| | 91 | authority. The webapi will also acquire such an argument, allowing the HTTP |
| | 92 | client to pass its authority to the webapi server so the server can perform |
| | 93 | the upload. |
| | 94 | |
| | 95 | = Design Pieces = |
| | 96 | |
| | 97 | * Add cred= to upload API |
| | 98 | * client.upload() needs a cred= argument |
| | 99 | * the webapi PUT/POST commands need a cred= argument |
| | 100 | * the javascript-based webfront program (used by allmydata.com) needs cred |
| | 101 | * the human-oriented "wui" needs a way (cookies? sessions?) to express |
| | 102 | storage authority |
| | 103 | |
| | 104 | * Define how to configure clients with their storage authority |
| | 105 | |
| | 106 | * define how to create these credentials |
| | 107 | * certificate-signing tools |
| | 108 | * "tahoe sign" subcommand |
| | 109 | |
| | 110 | * define how to configure servers with their certificates |
| | 111 | * changes to Introduction |
| | 112 | * advertise accepted pubkeys in the storage-v2 announcements? |
| | 113 | * changes to peer selection |
| | 114 | * furlification process, persistence/optimization |
| | 115 | * label format: how should leases be labeled |
| | 116 | * usage-table management: databases, size totals, what to store in each lease |
| | 117 | * Usage/Aggregator service |
| | 118 | * web interface |
| | 119 | * petname database / display |
| | 120 | |
