There is a maximum length for URLs in general. I think the maximum in IE is somewhere around 2000 characters.
Edit; From the README:
Different browsers have different limits of the total URL length, however around 2000 characters seems to be the recommended safe maximum. At the moment there is currently nothing to enforce the limit, however a checksum is added to check that we get all the data.
IRC chat would be my guess. Since data isn't stored on a server/can't be taken down, this seems like this could be useful in the shadier IRC rooms sharing questionable content.
There are a range of issues with that but the few that spring to mind immediately are:
1) Pasting into an IRC channel as already noted by someone else and;
2) Pasting text where formatting is important (such as a code snippet) into an email
The latter is of particular importance when sending through things like "tags" (ie. javascript snippets) to be embedded in HTML pages for things like analytics, conversion tracking, Wufoo forms, Wistia embeds and the like. If the formatting is off on a lot of that stuff because people have been copying and pasting it in and out of emails then they can end up not working at all.
NOW ... the advantage for me over something like pastie.org or pastebin is that when I paste a snippet into a Basecamp todo list item, for example, I'm creating an external dependency on those services for some or all of the relevant data to the todo list item.
By having a service which embeds the data into a URL that can then be decoded into it's original format without error, using something that I can reimplement myself if the original service should disappear, I end up with a much more "future proof" and reliable storage of that format sensitive information.
I would really love to see Shortly plus the Stanford Javascript Crypto Library to be able to create encrypted and password-protected serverless pastebins.
Javascript crypto does not work. The server can the manipulate the JS to send back the text, so it could be server side in first place. And serverside crypto is worse than useless.
Why? This seemed like a good idea to me. I want to be able to decrypt messages sent client-side. My plan was to have a nodejs proxy that gets the data, encrypts it, and then I decrypt client side using this lib. Problem?
In theory won't it now take just as long to transmit the link as it would to transmit the content itself? I get that this is cool from a "can't take it down" standpoint but I feel like if you're going to have to copy and paste a link containing the entire content you might as well just copy and paste the content.
Then again, you could just offload the work to bit.ly and get around that issue.
Shortly compresses the text using the DEFLATE algorithm (http://en.wikipedia.org/wiki/DEFLATE) followed by Base64 encoding (https://en.wikipedia.org/wiki/Base64) before storing it in the URL. Base64 increases the size of data by 33%, but DEFLATE usually decreases the size by more than that. Thus, the link will usually be shorter than the content.
I'm sure it will be somewhat shorter than the content but it will definitely be in the same order of magnitude and likely within a factor of 2. A link that is half as long as its content is pretty unwieldy and will take non-trivial time to transmit at longer lengths. Sort of defeats the point of a link in the first place.
Yes. You might as well just send a gzip'd file directly. It will be higher compression than Deflate (or if not, use BZip or 7zip), won't have the Base64 overhead, and (gasp) won't depend on a web service to decode. It also has the distinct advantage of not being really friggin annoying.
In other words, this is entirely useless, except as an amusement. Because it's funny how useless it is.
Well, no. To people, a pastebin.com/asdovnasdofnvopdsisadvasdfgv link is just as unmemorable as a base64 encode of an actual 1kb code data. However, nowadays, if I have a 1kb snippet I want fairly securely shared, sticking it in a chat box isn't a problem.
Well, except that it's a web site. That's why I would be attracted to this: it's something that I can send to anybody and it will always, always work. No hassle.
Seconded on offloading the work to bit.ly (or at least an option to). I'd rather click a box to give me a bit.ly link back since you're not /truly/ running without a server here.
And/or throw the url to a hidden box on the screen that will automatically copy when I hit cmd/ctrl C. Fun trick otherwise.
Absolutely. See https://news.ycombinator.com/item?id=5696462. Basically just add some HTML and JavaScript to the link with the encoded content and you're good to go. But as I said in another comment, at that point you're just sending the text itself over the wire in a convoluted way without much space savings. At that point I'd just use some public key encryption and post the content directly (PGP?)
> at that point you're just sending the text itself over the wire in a convoluted way without much space savings
Yes, in fact, with the solution linked, it's an increase in space requirements! In my experience, even with a traditional pastebin, the problem isn't being able to get the data over the wire -- it's formatting it. Also, this service opens up the possibility of (ab)using link shorteners for storage.
I’m sure it would be possible. You’d have to embed the CSS and JavaScript in https://github.com/lucaspiller/shortly into an HTML page, then represent that page as a data: URI. You could leave out the text-compression code and include only the decompression code, because the page only needs to decompress its embedded message. You would minify the code so there is less of it to store in the URL. You might even be able to shorten the URL by having the page bootstrap itself – DEFLATE all code except the code for INFLATEing, then INFLATE on the rest of the code for displaying the text, then run that code to INFLATE the text itself and display it.
Alternatively, you could just give someone a Shortly link and write a note next to it saying “If that link doesn’t work, just run that URL’s hash fragment through Base64-decode followed by INFLATE”, relying on the user to search for suitable software in that case. That would not help a user who is offline, unless their OS comes with utilities for those algorithms, but it would help if you’re just worried about Shortly going down.
This could be combined with whatever algorithm is being used on Shortly. This still needs the Shortly website for decoding ... your method would allow the embedding of the encoding/decoding function in the link itself which is more interesting imo. The added length of some obfuscated JavaScript will be very small compared to large-content links.
This is awesome, that's exactly what I was talking about. This is truly "serverless" whereas Shortly is not. Also if the creator of Shortly is reading my comments, I apologize for the negativity I was mostly just thinking out loud. Kudos to you for making something interesting and putting it out there.
I fixed and cleaned it up a little.
Put it into tinyurl, just to be able to post it here properly (reload once after clicking)
http://tinyurl.com/cu3zcjy
78 comments
[ 3.8 ms ] story [ 147 ms ] threadEdit; From the README:
Different browsers have different limits of the total URL length, however around 2000 characters seems to be the recommended safe maximum. At the moment there is currently nothing to enforce the limit, however a checksum is added to check that we get all the data.
http://stackoverflow.com/questions/417142/what-is-the-maximu...
http://softwareas.com/the-url-shortener-as-a-cloud-database
The link is really just an encoded form of the text anyway.
EDIT: Not to shit on this project, it's just that pastebin's are typically used to reduce the amount of text that gets pasted in an IRC channel.
1) Pasting into an IRC channel as already noted by someone else and;
2) Pasting text where formatting is important (such as a code snippet) into an email
The latter is of particular importance when sending through things like "tags" (ie. javascript snippets) to be embedded in HTML pages for things like analytics, conversion tracking, Wufoo forms, Wistia embeds and the like. If the formatting is off on a lot of that stuff because people have been copying and pasting it in and out of emails then they can end up not working at all.
NOW ... the advantage for me over something like pastie.org or pastebin is that when I paste a snippet into a Basecamp todo list item, for example, I'm creating an external dependency on those services for some or all of the relevant data to the todo list item.
By having a service which embeds the data into a URL that can then be decoded into it's original format without error, using something that I can reimplement myself if the original service should disappear, I end up with a much more "future proof" and reliable storage of that format sensitive information.
http://crypto.stanford.edu/sjcl/
The problem is of course not specifiy to javascript. It should be "fat client crypto does not work".
Then again, you could just offload the work to bit.ly and get around that issue.
In other words, this is entirely useless, except as an amusement. Because it's funny how useless it is.
But it still seems a bit unreliable. Accidentally clip a character off the URL and you're basically screwed.
And/or throw the url to a hidden box on the screen that will automatically copy when I hit cmd/ctrl C. Fun trick otherwise.
I'm able to paste the URL in firefox, but Chrome doesn't allow it.
I made the same observation re: just sending the message: https://github.com/alfg/jot/issues/1
EDIT: Looks like another commenter has already developed a solution :)
Yes, in fact, with the solution linked, it's an increase in space requirements! In my experience, even with a traditional pastebin, the problem isn't being able to get the data over the wire -- it's formatting it. Also, this service opens up the possibility of (ab)using link shorteners for storage.
Alternatively, you could just give someone a Shortly link and write a note next to it saying “If that link doesn’t work, just run that URL’s hash fragment through Base64-decode followed by INFLATE”, relying on the user to search for suitable software in that case. That would not help a user who is offline, unless their OS comes with utilities for those algorithms, but it would help if you’re just worried about Shortly going down.
data:text/html;,<textarea id="txt" cols=80 rows=24>hello there</textarea><br><input value="get link" type=button onclick="(function(){document.location.href=(document.location.href.replace(/24\>.*<\/textarea>/,'24>'+document.getElementById('txt').value+'</textarea>')); }())">
data:text/html;base64,PHRleHRhcmVhIGlkPSJ0eHQiIGNvbHM9ODAgcm9 3cz0yND47byk8L3RleHRhcmVhPjxicj48aW5wdXQgdmFsdWU9ImdldCBsaW5r IiB0eXBlPWJ1dHRvbiBvbmNsaWNrPSIoZnVuY3Rpb24oKXtkb2N1bWVudC5sb 2NhdGlvbi5ocmVmPSdkYXRhOnRleHQvaHRtbDtiYXNlNjQsJysod2luZG93Lm J0b2Eod2luZG93LmF0b2IoZG9jdW1lbnQubG9jYXRpb24uaHJlZi5zdWJzdHI oMjIpKS5yZXBsYWNlKC8yNFw+Lio8XC90ZXh0YXJlYT4vLCcyND4nK2RvY3Vt ZW50LmdldEVsZW1lbnRCeUlkKCd0eHQnKS52YWx1ZSsnJmx0Oy90ZXh0YXJlY SZndDsnKSkpfSgpKSI+
http://support.microsoft.com/kb/208427
Ugly.
Edit: Actually, now that I think of it, I might do that as a project.