| 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 | |