Implement shortcuts to caps #2010

New Issue

markberger · 2013-07-02T13:39:04Z

markberger commented

2013-07-02 13:39:04 +00:00

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.

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.

markberger added the

labels 2013-07-02 13:39:04 +00:00

markberger added this to the undecided milestone 2013-07-02 13:39:04 +00:00

gdt commented

2013-07-02 13:52:26 +00:00

This is a major architectural change, to add a new namespace. Before it happens, I think it needs a a complete written architectural design and protocol explanation. A few concerns:

Absent a really good reason, the feature should be at the protocol/WAPI level, not at the WUI level. I think you meant that, but I'm not sure.
This is basically an extension to the aliases file, with a grid-wide shared namespace. So perhaps having an aliases.public that is published would make sense.
One needs to have unpublish if there is publish, probably.
Synchronization of aliases should have predictable semantics. Re-fetch on miss does not satisfy this.
I think sharing by pointing at a foreign WUI is bad practice; that's a hack for a web server with a tahoe backend filesystem. Sharing by a cap that allows the reader to find an introducer and speak the protocol is another matter.
It seems clear to me from reading your examples that there are serious issues with a flat namespace in a grid with multiple people.
The mechanism could be abused to store (small amounts) of data without write authorization, but perhaps that's not incrementally a bug. Once there is write authorization in place, this will be a bug.

This is a major architectural change, to add a new namespace. Before it happens, I think it needs a a complete written architectural design and protocol explanation. A few concerns: * Absent a really good reason, the feature should be at the protocol/WAPI level, not at the WUI level. I think you meant that, but I'm not sure. * This is basically an extension to the aliases file, with a grid-wide shared namespace. So perhaps having an aliases.public that is published would make sense. * One needs to have unpublish if there is publish, probably. * Synchronization of aliases should have predictable semantics. Re-fetch on miss does not satisfy this. * I think sharing by pointing at a foreign WUI is bad practice; that's a hack for a web server with a tahoe backend filesystem. Sharing by a cap that allows the reader to find an introducer and speak the protocol is another matter. * It seems clear to me from reading your examples that there are serious issues with a flat namespace in a grid with multiple people. * The mechanism could be abused to store (small amounts) of data without write authorization, but perhaps that's not incrementally a bug. Once there is write authorization in place, this will be a bug.

markberger commented

2013-07-02 16:29:55 +00:00

I agree that the feature should be at the protocol level. That was my original idea but I forgot to explicitly state that.
When I was talking about sharing, I had the idea of sharing via a publicly accessible gateway, similarly to how the tiddly wiki works. If a user is running their own client, shortcuts should be able to be used with the WUI, but I agree that it is not the way to share files.
You're right in that there are serious issues with the flat namespace. If accounting were implemented a user could have their own namespace for their respective shortcuts.

* I agree that the feature should be at the protocol level. That was my original idea but I forgot to explicitly state that. * When I was talking about sharing, I had the idea of sharing via a publicly accessible gateway, similarly to how the tiddly wiki works. If a user is running their own client, shortcuts should be able to be used with the WUI, but I agree that it is not the way to share files. * You're right in that there are serious issues with the flat namespace. If accounting were implemented a user could have their own namespace for their respective shortcuts.

zooko commented

2013-07-02 19:23:17 +00:00

markberger: how would this be better than a tinyurl service, such as http://tinyurl.com?

markberger: how would this be better than a tinyurl service, such as <http://tinyurl.com>?

gdt commented

2013-07-02 19:29:07 +00:00

We should also think about security properties, and MITM attacks on expansion of shortcuts. That's an obvious bug with tinyurl.com. The other obvious bug is disclosing shortcut data to third parties, when it should perhaps be grid-private.

tahoe-lafs added

code-frontend

and removed

code

labels 2013-07-02 22:43:31 +00:00

Sign in to join this conversation.