| | 1 | = Goals for new filecaps = |
| | 2 | |
| | 3 | This is a place to record desiderata for the next version of our |
| | 4 | mutable/immutable filecaps. Many of the design requirements are spread out |
| | 5 | across separate tickets: this page is here to consolidate them. We should not |
| | 6 | release a new filecap format without checking it against everything on this |
| | 7 | list. |
| | 8 | |
| | 9 | Ticket #432 was the starting point: it contained a list of features. |
| | 10 | |
| | 11 | == make them real URIs == |
| | 12 | |
| | 13 | Kevin Reid points out that the Tahoe calls URIs are not actually URIs (in the |
| | 14 | established sense). To make them real, we need to: |
| | 15 | |
| | 16 | * make then start with {{{x-tahoe:}}} or {{{tahoe:}}}, register {{{tahoe:}}} |
| | 17 | with IANA (#418) |
| | 18 | * understand how URI/URL/URNs are built, decide about hierarchical segments |
| | 19 | vs non-hierarchical segments. What's magical about a leading double-slash? |
| | 20 | Do we need one? |
| | 21 | |
| | 22 | == other features == |
| | 23 | |
| | 24 | * Enable convenient cut-and-paste. If caps are too long they'll wrap in |
| | 25 | email. If they contain lots of word-breaking characters then you have to |
| | 26 | drag after you've double clicked (this is probably ok). If the word-broken |
| | 27 | sections are small and at the beginning or end then you have to be very |
| | 28 | precise about that drag. The best design would be a single short |
| | 29 | non-word-breaking string. The next best will be to have a large |
| | 30 | non-word-breaking string at the start and end, with smaller segments (if |
| | 31 | necessary) in the middle. |
| | 32 | * Usable in a browser. Specifically, it should be easy to actually use a |
| | 33 | filecap that you get in email or IM, and many email/IM clients will look |
| | 34 | for http URLs and make them clickable. If tahoe filecaps start with |
| | 35 | {{{http:}}}, then they'll be made clickable. This is at odds with the |
| | 36 | IANA-friendly {{{tahoe:}}} prefix. Clients may make {{{tahoe:}}} URIs |
| | 37 | clickable too (I've seen them make other letters-than-colon strings |
| | 38 | clickable, even when the letters are not "http"), so perhaps a reasonable |
| | 39 | solution is to provide an OS-level URI handler for the {{{tahoe:}}} |
| | 40 | scheme, which could embed the filecap in an http URL and submit it to a |
| | 41 | webbrowser (i.e. when you click on {{{tahoe:foo}}}, a helper program is |
| | 42 | launched with {{{tahoe:foo}}}, and that in turn launches your web browser |
| | 43 | with {{{http://localhost:8123/foo}}}). (#52) |
| | 44 | * Self-identifying. It should be visually clear what sort of filecap the |
| | 45 | string represents: read-write or read-only, mutable-or-immutable, |
| | 46 | file-or-directory. This is especially important when sharing tahoe objects |
| | 47 | over out-of-band channels like IM and email: it should be easy for the |
| | 48 | user to tell whether they're giving away readonly access or read-write |
| | 49 | access. We've considered prefixes like {{{DWM..}}} for "Directory |
| | 50 | Writeable Mutable" and {{{FRI..}}} for "File Readonly Immutable". If these |
| | 51 | are jammed against the (base62) crypto bits it may be difficult to tell |
| | 52 | where the prefix ends and the crypto bits begin ({{{FRIDWM...}}}). |
| | 53 | * in addition, tahoe URIs should be distinguishable from local filenames by |
| | 54 | a CLI tool, so that {{{tahoe cp $CAP local/foo.txt}}} is unambiguous. |
| | 55 | (unfortunately, the current practice of using "tahoe:" as a default alias |
| | 56 | name collides with this badly, but perhaps if the new URIs include the |
| | 57 | double-slash, this won't be a problem: |
| | 58 | {{{tahoe cp tahoe://CAP local/foo.txt}}} copies from a specific URI, |
| | 59 | while {{{tahoe cp tahoe:blah local/foo.txt}}} copies from a child of |
| | 60 | the "tahoe:" alias). |
| | 61 | * I'd like to make it easy to layer uses on top of one another: since |
| | 62 | directories are just a specific way of interpreting the contents of a |
| | 63 | (mutable) file, let's make the directory cap be closely related to the |
| | 64 | underlying filecap. For example, if we end up using |
| | 65 | {{{tahoe://MR/cryptobits}}} to describe a read-only mutable file |
| | 66 | referenced by "cryptobits", then we could use |
| | 67 | {{{tahoe://D/MR/cryptobits}}} for the directory that uses it as a backing |
| | 68 | store. The rule would be that {{{tahoe://D/$A}}} would be handled by |
| | 69 | fetching {{{tahoe://$A}}} and then interpreting its contents as a |
| | 70 | directory structure. Then reading immutable-dirnodes (#607) would be |
| | 71 | trivial. Another way to think about this is that if our filecaps were |
| | 72 | verbose s-expressions, these caps could be expressed as "(readonly |
| | 73 | (mutable cryptobits))" and "(directory (readonly (mutable cryptobits)))". |
| | 74 | * provide for verifycaps, repaircaps, and traversalcaps. Repaircaps in |
| | 75 | particular may require a grant of storage authority, which might entail a |
| | 76 | cap format that can accept arbitrary extra non-hierarchical fields. |
| | 77 | Appendcaps or "drop-box" writecaps might fall into this same space. |
| | 78 | * provide ciphertext access. Reading from a verifycap should give you |
| | 79 | ciphertext. It should be possible to upload ciphertext directly. |
| | 80 | * provide for a grid-identifier, possibly on the MSB end, e.g. |
| | 81 | {{{tahoe://grid1234/IR/cryptobits}}}. Perhaps let some contexts define a |
| | 82 | "default grid id", such that {{{tahoe://IR/cryptobits}}} is expanded to |
| | 83 | mean {{{tahoe://grid1234/IR/cryptobits}}}. Something like |
| | 84 | {{{tahoe://grid1234/D/MR/cryptobits}}} should reference |
| | 85 | {{{tahoe://grid1234/MR/cryptobits}}}. (#403) |
