Add method to get URL for a public item

[nilclass]

Apps need a straight-forward way to get the URL of an item they just published (i.e. stored in the public category).

[nilclass]

Implemented as baseClient.getItemURL(path). Apps need to take into account, that there is no way to build the URL until a user is connected. In that case getItemURL return null.

[michielbdejong]

just as a sidenote, URLs obtained through this method will of course also break whenever the user migrates to a different storage provider. after an account migration, each app will have to call this method again to get the new URLs for items.

On Wed, Sep 12, 2012 at 3:43 PM, niklas notifications@github.com wrote:

Implemented as baseClient.getItemURL(path). Apps need to take into account, that there is no way to build the URL until a user is connected. In that case getItemURL return null.

— Reply to this email directly or view it on GitHubhttps://github.com/unhosted/remoteStorage.js/issues/80#issuecomment-8493838.

[jancborchardt]

How do the links look by the way? app.com/#user@host/filename would be good for instance.

Regarding provider migration: 1) this is an edgecase for which the links should not be uglified 2) the original storage should not be completely terminated, but rather redirects set up.

[nilclass]

"app.com/#user@host/filename" won't work if user@host doesn't support discovery (e.g. storage-first ONLY scenario), otherwise I agree it's nice. Also this won't work if the link is to be followed by a traditional client. If I want to embed a photo or video which is stored on my remoteStorage into a third party site, I can't use fragment URLs to redirect, but need the canonical URL (i.e. the one pointing directly to my storage) or some sort of persistent URL, that always resolves to my storage's URL via a traditional redirect.

[michielbdejong]

@jancborchardt: this is about links to data, in practice mainly links to images probably, not links pages or addresses that users ever get to see.

On Wed, Sep 12, 2012 at 4:08 PM, niklas notifications@github.com wrote:

"app.com/#user@host/filename" won't work if user@host doesn't support discovery (e.g. storage-first ONLY scenario), otherwise I agree it's nice. Also this won't work if the link is to be followed by a traditional client. If I want to embed a photo or video which is stored on my remoteStorage into a third party site, I can't use fragment URLs to redirect, but need the canonical URL (i.e. the one pointing directly to my storage) or some sort of persistent URL, that always resolves to my storage's URL via a traditional redirect.

— Reply to this email directly or view it on GitHubhttps://github.com/unhosted/remoteStorage.js/issues/80#issuecomment-8494652.

[melvincarvalho]

The format of the URL doesnt really matter (so long as it's using legal characters), but the important thing is that it has one. You might say, that wrt to The Web, "URL or it didnt happen". I'd strongly advise against using the # character in 'creative' ways, as it has a special meaning, and it can break the whole integrity of the ID. There's lots of characters commonly used such as ; : and good old ?.

What I often do is take the sha1 of the identity. As pointed out, the user need never see the string, it's mainly for computer programs.

[jancborchardt]

@nilclass if there’s no discovery mechanism, are public links even possible without the app having a central database?

@michielbdejong since this issue came out of https://github.com/vcuculo/ghost-unhosted-webrtc/issues/2, I assumed it’s also about links you send to friends.

@melvincarvalho the # we use for the simple fact because it makes everything following not be sent to the server, which is nice.

TL;DR correct me if I’m wrong, I assumed this is about the links which are shared with humans, not machines.

[melvincarvalho]

Yes I understand why you want to use # to hide data from a server that you might not trust completely. But this is an issue between the client and the server, and should not be used as a side effect to name your identifiers, which is a much important task. A system or app is only as strong as its identifiers.

It may well be the case that the # URIs are unusable outside of a small specific context. In order to benefit from the massive network effect of the web, I actually think that any app that misuses # will need to be forked to use ? instead. Seems to be no other way.

[nilclass]

I think there's some confusion here. There can be two kinds of "public URLs" being discussed:

1) app specific ones, e.g. app.com#user@host/something would "open" a thing called "something" from the user "user@host" in the app at "app.com" 2) the actual place where the data lives, e.g. https://5apps.com/storage/nilclass/public/pictures/something

(1) will only work, if: a) user@host can be discovered and b) it is a valid link in scope of the app and c) it is opened within a browser that can actually run the app (2) on the other hand could be used to display the picture on another site, or whatever. It represents the data and will still be valid if the app that put it there has long gone or moved to another location.

The main difference is that (1) links to a function of the application, while (2) links to the data.

This issue is only about (2). Determining a good URI strategy for apps is within the app's scope, remoteStorage.js has nothing to do with that.

makes sense?

[melvincarvalho]

Yes makes total sense.

The reason I mention it is that there has historically been a connotative bias towards using # to hide data from an untrusted server. Better to use a server that you trust, as you wont be able to hide other things such as your access logs and browser version etc. The main motivation raising the point is that once you're locked in to a particular naming scheme, it becomes very hard to change, so it's one of the things that is a big advantage to get right from the beginning.