[tahoe-lafs-trac-stream] [tahoe-lafs] #2010: Implement shortcuts to caps

[tahoe-lafs]

#2010: Implement shortcuts to caps
--------------------------------------------+---------------------------
 Reporter:  markberger                      |          Owner:
     Type:  enhancement                     |         Status:  new
 Priority:  normal                          |      Milestone:  undecided
Component:  code                            |        Version:  1.10.0
 Keywords:  usability, newurls, introducer  |  Launchpad Bug:
--------------------------------------------+---------------------------
 Most of the time users want to keep their caps secret, but there are those
 instances when you want to share caps with people easily (for example,
 Zooko serving his blog on tahoe). As previously discussed, the current URI
 and gateway URLs are long and ugly and this creates problems when sharing,
 especially with people who don't use tahoe (see ticket #882).

 To solve this issue, we could implement cap 'shortcuts' that the user
 registers with the introducer and these shortcuts would act like tinyurls.
 Then users could have access to a cap with a simple keyword or phrase,
 which makes sharing over the grid a lot easier. If the user does not want
 to share their cap over the entire grid, but wants to access the cap
 easily, they could register the shortcut with just the client.

 So in the example of Zooko's blog, Zooko could create a shortcut named
 'home' which points to the readonly cap associated with the homepage of
 his blog. Then users would be able to access his blog via
 "testgrid.allmydata.org:3456/sc/home", which would forward them to the
 messy URLs tahoe already uses.

 When the client registers with the introducer, it would receive a list of
 these shortcuts. Whenever the user creates a new shortcut they want to
 share over the grid, the introducer checks to make sure there are no
 conflicts and then registers the new shortcut with the introducer. When
 another user tries to use a shortcut that the client doesn't know about,
 the client would request a new version of the shortcut list and then
 appropriately succeed or fail depending on whether the list has that
 shortcut.

 This doesn't solve all of the problems in #882, but I think it would be a
 good way to make sharing files over http a lot easier until the new caps
 are implemented. Also this would be a simple way to solve the problem
 outlined in ticket #958, where Zooko talks about redirection caps for his
 blog. If the user wants to use a different cap for their shortcut, they
 would just have to delete the shortcut and create a new shortcut with the
 same name and a different cap. That way when Zooko switches over to the
 new cap design, his URL will still be good.

 This solution isn't perfect. If the user bookmarks the long and messy URL
 instead of the shortcut, redirection isn't accomplished. Also I'm not sure
 if this solution would work nicely once the introducer become
 decentralized. Furthermore this could be an over engineered solution (why
 not just use tinyurls instead of creating our own?) but I thought it was
 an interesting idea that I should at least share with the tahoe community.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2010>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage