llIlI.lI: a URL shortener using only I/l to encode domains

[lnyan]

https://llili.li/

[9woc]

This gave me a laugh. These are 3 different webpages:

    llIIlIIIlIllIIIIIIlIIIlIllIlIIII.llIlI.lI
    lIllIllllIIllIllIIllllllIIIIIlII.llIlI.lI
    lIlllIIIIlIIlIlIIllllIlIlIlIIlII.llIlI.lI

[ykonstant]

This reminds me of my unary directory hierarchy: a segment in my test suite consisting entirely of unary newline files and subdirectories, i.e. with filenames '\n\n...\n' for some number of newlines. I use it to test if shell script authors understand how to treat filenames correctly.

[Daviey → ykonstant]

Funny yes, but any shell script I write I'd be happy for it to fail (gracefully) this test. Unless you can convince me there is a requirement for something as convulted as this?

[ykonstant → Daviey]

When you are writing shell scripts to be deployed to systems you do not control, you are required to handle filenames you do not control; i.e. all of them. I don't care about convincing you, I did not write the tests for you in particular.

[ahazred8ta → ykonstant]

You monster!

[smokel]

Some basic detective work led me to the source code for the URL generation [1]. We can all stop reverse engineering the algorithm now: it appears that it uses a random generator to come up with the I's and l's.

[1] https://github.com/chenxuuu/shit-url/blob/llIlI.lI/inc/class...

[beardyw]

Google offers to translate the home page from Finish - ends up with the same.

[fredthedeadhead]

So, I think this hilarious, but link shorteners have to be stable, right? What happens when link shorteners go offline? Is there a way of decoding shortened links without the server?

[danpalmer → fredthedeadhead]

Link shorteners always depend on the server. They just put the link in a database and map it to some shorter code.

You could have just an encoding and compression scheme, with no storage, but it wouldn’t be able to shorten the urls by much in most cases.

[crtasm → fredthedeadhead]

There's at the very least one group working to archive them: https://wiki.archiveteam.org/index.php/URLTeam

[rsync → fredthedeadhead]

"So, I think this hilarious, but link shorteners have to be stable, right?"

Yes, a link shortener does need to be stable but luckily they are extremely simple to operate.

You should be able to run a very popular link shortener on a leftover 1U with very low associated bandwidth and power costs. It's not unrealistic for a person, or group, to commit to this indefinitely.

[beardyw → fredthedeadhead]

Thinking about it that is absolutely possible, but only for you personally. A site could store your destination as local storage and translate through a service worker (which runs even if the site is offline). Half a page of JS would do it. Not sure if it is useful though?

[lelag → fredthedeadhead]

All link shorteners, even those that use a readable URL, keep the target URL in a database. It's not possible to decode any of them without the service being available.

The novelty here is that the service deliberately makes itself unusable for comedic effect

[e38383]

Thank you, internet. I needed that today :)

[cornholio]

The interface seems to be broken on desktop Firefox with uBlock, I can't shorten anything.

[Cyphase → cornholio]

You can use this in the dev console:

  await fetch('https://llili.li/api/set.php', {method: 'POST', body: JSON.stringify({url: "https://news.ycombinator.com/item?id=40332992"})}).then(r => r.json()).then(d => d.content.url)

[haunter]

I first saw barcoding in Starcraft 2, players use this since the game’s release.

[DaSHacka → haunter]

Barcode usernames are quite popular in FPS games with cheaters as well.

Not sure why, makes it really easy to differentiate a player who got lucky with timing from one with ESP.