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
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.
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?
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.
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.
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.
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.
Hey, I'm the creator. I wondered why there were two issues raised within 24 hours, checked here, and well, that explains it... I've just fixed the async error (#4), so any of you having issues with "$ not defined" should have them solved now.
For me the big benefit here is that when I'm communicating code snippets that are often "format sensitive" through channels such as IRC, email or project management tools (like basecamp) I will almost always use a paste service in order to ensure that no crap creeps in throughout the process. I most frequently either use sprunge.us or pastie.org and grab the "raw" URL before pasting it in.
This does, however, create an external dependency, and it has happened before that pastie.org was down and a bunch of tasks I had meticulously created couldn't be read by the person who was supposed to be doing them (it didn't last long but it was annoying).
Sprunge.us is actually open source so you can grab and host your own, but that takes a little time and effort and I've never ended up bothering ... THIS, on the other hand, provides a handy way for me to create these little "pastes" and share them with my team, secure in the knowledge that if things bum out I can, at a pinch, get an alternative service live to read the formatted data in.
Of course, this doesn't apply if the URL has been shortened ;)
Speaking of which, you could stick a URL shortener in pretty easily based on the one I did for CueYouTube[1]. I used this library http://www.myjqueryplugins.com/jquery-plugin/jly1 which has an API that works entirely on the client side.
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.
What advantage does this site give over just pasting the data directly? The shortened URL aspect is gone, so the only "advantage" I can see is obfuscation. And if you want that you can base64 your text directly.
I'm able to paste the URL in firefox, but Chrome doesn't allow it.