Hashify: what becomes possible when one is able to store documents in URLs?
1–10 of 84 posts
Re: Hashify: what becomes possible when one is able to store documents in URLs?
#2What becomes possible? The entire internet could effectively get rid of hosting account providers, with each page in every site being contained in a hashify URL, and with each page linking to other pages using other hashify URLs.
Trouble is, there might be a DNS-like system needed to match hashify URLs to more human-readable strings (or a way for existing DNS to resolve to hashify style URLs).
Neat idea.
Re: Hashify: what becomes possible when one is able to store documents in URLs?
#3What becomes possible? The entire internet could effectively get rid of hosting account providers, with each page in every site being contained in a hashify URL, and with each page linking to other pages using other hashify URLs. Trouble is, there might be a DNS-like system needed to match hashify URLs to more human-readable strings (or a way for existing DNS to resolve to hashify style URLs). Neat idea.
The data needs to be stored somewhere. In their implementation they in effect use bit.ly as the hosting provider for the data by shortening the url's, so while it's a fun little experiment, it boils down to a content addressable system. We already have good examples of content addressable systems. Git for example is built on content addressable storage.
Re: Hashify: what becomes possible when one is able to store documents in URLs?
#4Boiling it down, it's a new file format with a built in viewer. You need to find a way to store the data.
Interesting, but I can't think of any practical application, apart from the service provider not having to worry about storage (maybe that's key ... more thinking needed).
Re: Hashify: what becomes possible when one is able to store documents in URLs?
#5[deleted]
Re: Hashify: what becomes possible when one is able to store documents in URLs?
#6What becomes possible? The entire internet could effectively get rid of hosting account providers, with each page in every site being contained in a hashify URL, and with each page linking to other pages using other hashify URLs. Trouble is, there might be a DNS-like system needed to match hashify URLs to more human-readable strings (or a way for existing DNS to resolve to hashify style URLs). Neat idea.
The data needs to be stored somewhere . In their implementation they in effect use bit.ly as the hosting provider for the data by shortening the url's, so while it's a fun little experiment, it boils down to a content addressable system. We already have good examples of content addressable systems. Git for example is built on content addressable storage.
It also assumes that there's no limit on URL space that bit.ly provide. Tomorrow they could just max out the "long_url" field or whatever they call it to just accept 1500 chars or something
Re: Hashify: what becomes possible when one is able to store documents in URLs?
#7[deleted]
Re: Hashify: what becomes possible when one is able to store documents in URLs?
#8Earlier quoted context omitted.
The data needs to be stored somewhere . In their implementation they in effect use bit.ly as the hosting provider for the data by shortening the url's, so while it's a fun little experiment, it boils down to a content addressable system. We already have good examples of content addressable systems. Git for example is built on content addressable storage.
It also assumes that there's no limit on URL space that bit.ly provide. Tomorrow they could just max out the "long_url" field or whatever they call it to just accept 1500 chars or something
There is:
"Storing a document in a URL is nifty, but not terribly
practical. Hashify uses the [bit.ly API][4] to shorten
URLs from as many as 30,000 characters to just 20 or so.
In essence, bit.ly acts as a document store!"Re: Hashify: what becomes possible when one is able to store documents in URLs?
#9Very neat idea, but I think the reliance in bit.ly is self-defeating. This kind of approach would allow people to distribute documents using the web without having to trust them to a particular server, which can be very convenient if your target audience is in a country where access to the server storing your documents can be closed. For this to work you need to be able to recover the document from the URL locally.
Some years ago a friend and I wrote http://notamap.com, a very similar idea for sharing/storing/embed geotagged notes fully encoded on a URL, without having to rely on a server. Looking at it now I wish we had not put all the crazy animations. Maybe I should recover it and simplify the UI.
Re: Hashify: what becomes possible when one is able to store documents in URLs?
#10Earlier quoted context omitted.
It also assumes that there's no limit on URL space that bit.ly provide. Tomorrow they could just max out the "long_url" field or whatever they call it to just accept 1500 chars or something
There is: "Storing a document in a URL is nifty, but not terribly practical. Hashify uses the [bit.ly API][4] to shorten URLs from as many as 30,000 characters to just 20 or so. In essence, bit.ly acts as a document store!" http://tinyurl.com/3n6h8px
hence the "bit.ly – "rate limit exceeded" :\" message on top...
maybe switch to goo.gl?