Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Itty Bitty: Sites contained within their own links

itty.bitty.site

Post reply on HN
Print view View original

101–110 of 111 posts

Re: Itty Bitty: Sites contained within their own links

#101

Post by recursor »

JAdamMoore wrote: post #42

This is old news from 2011. https://news.ycombinator.com/item?id=2464213 It was done better by David Chambers https://github.com/hashify/hashify.me And you can use it here: http://hashify.me/IyBUaXRsZQ==

That's cool, I hadn't come across hashify before, but I'm not sure about "better" overall - depends how you're using it...

...itsy bitsy site's demo page gives a couple of nice additions

* I use markdown a Lot, but the inclusion of codepen.io makes it simple to compose richer docs, including svg's in a page etc. (I haven't read the hashify code - I'm assuming it does support full HTML, not just MD, but the demo doesn't make that clear)

* QR code link - is just using a 3rd party zXing tool, but, nice touch for the demo

* Compression - hashify URLs seem to be longer than the content (that might mean lower effective limits on content lent), relying on 3rd party lookups for shortening, meaning accessingv the content offline looks harder to achieve (afaict itty bitty just needs the JS to decode the url)

Re: Itty Bitty: Sites contained within their own links

#103

Post by recursor »

mstade wrote: post #93
jadedhacker wrote: post #92

Earlier quoted context omitted.

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 on…

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.

Re: Itty Bitty: Sites contained within their own links

#104

Post by recursor »

e12e wrote: post #75
ddalex wrote: post #64

Earlier quoted context omitted.

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..?

Re: Itty Bitty: Sites contained within their own links

#105

Post by recursor »

Hypothetical:

Might a bad actor user something like this, combined with a homograph domain, to conceal malicious content in the URL and prevent a crawler discovering the malicious content (ignoring the fact that the homograph might be detected/redflagged on its own).

(use case might be a homograph phishing site, with a fakelogin and the target for the captured input being obfuscated into the URL)

---- Note: Homograph effectiveness depends on the browser, which you'd hope all be improving detection over time- https://dev.to/loganmeetsworld/homographs-attack--5a1p

Re: Itty Bitty: Sites contained within their own links

#106

Post by mstade »

recursor wrote: post #103
mstade wrote: post #93

Earlier quoted context omitted.

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 on…

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 rep…

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.

Re: Itty Bitty: Sites contained within their own links

#107

Post by e12e »

recursor wrote: post #104
e12e wrote: post #75

Earlier quoted context omitted.

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...

Re: Itty Bitty: Sites contained within their own links

#108

Post by recursor »

mstade wrote: post #106
recursor wrote: post #103

Earlier quoted context omitted.

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 rep…

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).

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.

Re: Itty Bitty: Sites contained within their own links

#109

Post by TimTheTinker »

Exuma wrote: post #28
ReverseCold wrote: post #24

Earlier quoted context omitted.

oh hi (I will say I'm disappointed that it wasn't a technique to make circular URLs.)

That's what it started out as, I was going to look at making a quine but then quickly gave up as I am tired

I think a quine would be impossible since there's no possibility of indirection or data compression.
Post reply on HN