writing down filecaps: revise URI scheme

[warner]

I'd like to sit down and draw up a plan for "cap reification": what are the exact strings used to represent our various file/directory capabilities. We know that there will be at least two kinds (human-readable and packed machine-readable), and that we might want the human-readable ones to be browser-friendly (or 72-column friendly, or concise, or some combination thereof). And we've drawn up a couple of proposals based upon adequate crypto key sizes and "base62" encoding schemes, but we haven't finished the roadmap yet.

Various features and tradeoffs:

• printable
• pronounceable, error-resistant (base32 with o/0 tolerance)
• short
• browser-friendly (starts with http://localhost)
• IANA-friendly (starts with x-tahoe: or tahoe:)
• email friendly (printable and shorter than 72 characters)
• self-identifying (includes some redundant prefix, version number)
• visually distinct

[warner]

Related tickets:

• #418: create tahoe: URI scheme identifier, register with IANA
• #217: DSA-based mutable files, will enable shorter caps
• #102: "smaller and prettier directory URIs"
• #105: "command-line access to URIs" (printable caps should be distinguishable from filenames, so "tahoe cp $CAP local/foo.txt" is not too ambiguous)
• #52: "browser integration": caps that are legal URIs and make IANA happy can also

be handled by browser plugins

• #125: caps for files and directories should be human-distinguishable. It is even

more important that humans be able to distinguish read-caps and write-caps.

[zooko]

See also #52 (browser integration).

[warner]

NewCapDesign is the place to design the new cap format. It contains a detailed list of design criteria.

[davidsarah]

Tagging issues relevant to new cap protocol design.

[zooko]

Some old notes about this are on ticket #102. Please read them!

[meejah]

Ticket retargeted after milestone closed (editing milestones)