[tahoe-dev] [tahoe-lafs] #217: DSA-based mutable files -- small URLs, fast file creation

[tahoe-lafs]

#217: DSA-based mutable files -- small URLs, fast file creation
------------------------------------+---------------------------------------
 Reporter:  zooko                   |           Owner:  zooko     
     Type:  enhancement             |          Status:  assigned  
 Priority:  major                   |       Milestone:  eventually
Component:  code-mutable            |         Version:  0.7.0     
 Keywords:  mutable crypto newcaps  |   Launchpad_bug:            
------------------------------------+---------------------------------------

Comment(by zooko):

 Yeah, not speaking for Brian but for myself I want to have as few crypto
 formats to support as possible, so I would like to jump straight from the
 current cyrpto structure to the best crypto structure I can.
 Unfortunately this seems to have paralyzed my forward progress for a
 couple of years now as I am always learning about new improved crypto
 primitives and structures (like Elk Point 2, HKDF-Poly1305-XSalsa20, hash-
 function-combiners, cipher-combiners...) that are EVEN BETTER than the
 ones I had previously thought of.

 Along these lines, I'm currently feeling a bit polarized about Brian's
 preference for simplicity vs. the features of Elk Point 2.  I highly value
 short URLs and long-lived crypto, and at least to some degree I would be
 willing to accept complexity in return for those values.

 I think polarization is what I get when people express value judgments
 without a lot of technical detail.  When I get into comparing technical
 details then even if I still disagree with someone else's preference, at
 least I don't feel as frustrated about it -- I can look at a table of
 tradeoffs and say "Okay I can live with this and that tradeoff".  I think
 the way forward on that issue is to make comparable documentation for the
 three current candidates (Elk Point 2, Simple, Semi-Private-Keys), or
 maybe for David-Sarah to divulge their latest ideas.

 By the way, the reason I keep posting on this ticket about people who
 complain about Tahoe-LAFS URLs, bots that ban Tahoe-LAFS URLs, etc. etc.
 is to show that the issue with long URLs is not just my personal
 preference.  There seems to be plenty of evidence that long URLs are
 unacceptable to a significant, perhaps overwhelming, fraction of users.
 One of the data points that isn't already recorded on this ticket is that
 as soon as allmydata.com had paid Brian and me to invent Tahoe-LAFS, they
 then immediately paid someone else to invent a tiny-url-central-database
 to hide Tahoe-LAFS URLS.

 If anyone has any evidence that users are okay using Tahoe-LAFS-sized
 URLs, please post it to this ticket!  As far as I know, I'm the only human
 in the universe who doesn't mind using Tahoe-LAFS URLs on the Web.  (Note:
 I don't mean putting Tahoe-LAFS caps in your aliases files or whatever, I
 mean on the Web.  Sharing the URLs with other people, posting them on
 blogs, etc. etc.)  Of course, I am not a representative data point for
 this issue since I am not only a hacker but also a Tahoe-LAFS hacker.  If
 you are a hacker and you don't mind using Tahoe-LAFS URLs, I would like to
 know it, but I would be even more interested if your mom is okay using
 Tahoe-LAFS URLs.  But I'll take whatever data points I can get, because I
 think making a major technical decision about something like URL size
 without considering real world observations of user preferences is a sin
 (akin to optimizing without measuring).  :-)

-- 
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/217#comment:63>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid