Hacker News Reader

Comment by finagle | Hacker News Reader

Cool hack aside, can anybody think of an actual use case for this?

My mind immediately went to stuff like tickets. Can't say how many times I've gotten stuck having my ticket checked at a concert or on a train simply because there's no connectivity and the page is no longer in cache on my phone. If all the data is in the URI then it could work as an option for entirely static data. I'd say this is useful for almost anything that fits in a one page PDF.

How does that solve the no connectivity problem? You’d still need the site (with rendering scripts) cached.

Browsers have offline capabilities that are currently massively underutilized. You can store the LZMA scripts in IndexDB perhaps?

Unfortunately that comes with a bootstrapping problem: what if the first time you hit the link is when you aren't connected? If everything is embedded in the data URI and the link is in fact the data itself then it doesn't matter.

I think that's an acceptable requirement. After all, you wouldn't expect an app to work without downloading it. If instead of using lzma, gzip were used, I bet you'd be able to include some code that would unzip itself using the browser's unzip capability. I am not sure how much code that would take though.

Right, for an app that makes sense but the use case I mentioned was really just pure data. A ticket is rarely more than a qr code or some other identifier, whose veracity is then checked t the point of reading. In an arena full of people it’s not uncommon for cell towers to get overloaded, or you may be roaming if overseas and don’t want to waste data, or you’re on a moving train with no on board WiFi or if it has one it might not work right. In those cases (and it seems to happen to me a lot) I would’ve preferred that the ticket I received in my email was viewable offline, even if I’d never seen it before. With a data URI, that’s possible. It’s not an entirely contrived use case I don’t think.

Could you not register a URI format with the mobile OS to open an IttyBitty reader app that contains the rendering scripts?

Sure, initially that means only users who've noticed it would be able to benefit, but the app would be generic, not vendor-specific, so over time, it could become a standard & make it into the OS, at which point it becomes properly useful.

Edit: (sorry, I appear to have been rate-limited)

In reply to @mstated below:

---

Only really that itty bitty's compressed in the URL, not in the transport (& could be extended to add encryption).

It's absolutely true that, that may be tackling the wrong area - if data: were extended with compression/encryption options (not that itty bitty has encryption, but it's an option with the JS layer there) then the itty bitty decoder has nothing to do.

BUT, experiments like itty bitty might spur on ideas & standards changes for things like data: which to me makes it worthwhile.

(Self-contained, standardised, compressed [, encryptable?] content objects [in this case URL] renderable via ubiquitous web technologies feels like a win, itty bitty or not)

---

Also, if links are shared on html-based platforms, some block data: url's in links. Not sure of the justification, but reddit doesn't seem to render markdown formatted URLs with data: on them, as links. Not sure how to tackle that one - itty bitty sidesteps the restriction.

Why? The `data:` schema is already there and is well supported across platforms. All itty bitty does is take the base64 encoded fragment part of the URL and put it in an iframe, wrapping it in the `data:` scheme. No need to register anything new.

Only really that itty bitty's compressed in the URL, not in the transport (& could be extended to add encryption).

BUT, experiments like itty bitty might spur on ideas & standards changes for things like data: which to me makes it worthwhile.

(Self-contained, standardised, compressed [, encryptable?] content objects [in this case URL] renderable via ubiquitous web technologies feels like a win, itty bitty or not)

---

If you want the whole UI around rendering the content, sure, but you don't need that – it's just an iframe that sets a `data:` URI anyway. The link can just as well be the data URI itself. It'd be a very long link for any non trivial content, but it works just fine without any connectivity.

Seeing as tickets are typically sent in HTML emails anyway the scary looking URI can just be hidden behind a nice anchor tag or something anyway. When the recipient clicks the link, the page will open in a browser and render just fine without any connectivity. Graphics can be embedded in the same way, using `data:` URIs as image tag sources, or in embedded css.

Here's an example, turn off your connection and try this in your browser's address bar:

  data:text/html;charset=utf-8;base64,PG1ldGEgY2hhcnNldD0idXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lkdGgiPjxiYXNlIHRhcmdldD0iX3RvcCI+PHN0eWxlIHR5cGU9InRleHQvY3NzIj5ib2R5e21hcmdpbjowIGF1dG87cGFkZGluZzoxMnZtaW4gMTB2bWluO21heC13aWR0aDozNWVtO2xpbmUtaGVpZ2h0OjEuNWVtO2ZvbnQtZmFtaWx5OiAtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCxzYW5zLXNlcmlmO3dvcmQtd3JhcDogYnJlYWstd29yZDt9PC9zdHlsZT4gSGVsbG8sIEx4ciBmcm9tIEhOIQ==

EDIT: Created another, more complex, example but it's unfortunately too long for HN comments. You can see it here:

https://gist.github.com/mstade/597f7da82841b1c27c63c8b383538...

Just copy and paste the raw contents of that file into the address bar and it should render the page.

It's potentially a more reliable way of saving out a web page...

Or in a 2-step process, do that, then feed it to a PDF converter for sites that don't play well with printing.

Copy/paste content to my coworkers, like paste-bin. but without server-side storing on the paste site. It's amazing.

So rather than paste the text.. Paste the link, which they then open, to fetch the render-Middleware from this site, to render the text in the browser? Rather than just allowing the message app render the text in-line or as an attachement?

Hmmm.

Could you not put an encryption layer into a derrivative of this for some generic PGP end to end encryption, without involving/trusting a centralised provider..?

You'd need to trust the (de) cryption code... So probably better off with cutting and pasting with gpg --armor...

Reply on news.ycombinator.com