[rom-antics]

We're talking about URL shorteners here. If you have a 20 character URL, which points at a blockchain, which points at a 50 character URL - just store the original 50 character URL and skip the blockchain.

The only real use case for URL shorteners is length-limited fields like 280-character tweets, but Twitter runs their own URL shortening service already, so again, no blockchain needed.

[sharkbot]

The article talks about ownership transfer of a url database and the potential for history rewriting. An incentivized blockchain could be part of the solution to ensure history rewrites are not economically possible. I don’t have a protocol sketch, this is just a marginalia comment.

Exercise left for an interested reader, which sounds like isn’t you :)

[rom-antics]

The article says that such a URL database should never be used in the first place. You don't have to pay anybody to preserve the history of your data, if you just maintain control of your data in the first place. It's just 30 more bytes to store, I think we all can afford the cost.

[sharkbot]

I don’t mean to belabour the point, but I think the nuance is worth exploring.

The key point in my view is “control”. You’ve referred to Uber.com/Xmas-sale as an example where Uber the economic entity is in charge of their own shortening and therefore avoids the problem. However, Uber the company may fall on hard times, sell their real and intellectual property and we’re facing the same issue of a lifetime mismatch between an owner and an URI.

Incentivized blockchains are theoretically singletons and perpetual; the worst case of a history rewrite is economically disincentivized. The lifetime of the URI database exceeds the URI lifetime.

In practice, I agree with you that companies should ensure control over their URIs over their lifetime. The advantages of a blockchain approach are far outweighed by the current downsides.

[rom-antics]

If I understand you, if the URI database outlives the URI itself, the URIs in the database would still be useless, right? If somebody buys uber.com, it does not matter if we preserve "uber.com/xmas-sale", since the uber.com domain can be pointed at a different server. So you need to save the content as well, which means you'd need something like IPFS. I could see the usecase for something like IPFS on a blockchain (assuming IPFS is not working well enough as is; I have no idea)

[JohnFen]

I think it would not be controversial to say that a blockchain would not address most of the problems IPFS currently has.

Just to avoid misunderstanding -- IPFS right now does work pretty well, but there is plenty of room for improvement.

[lazyasciiart]

The guardian did maintain control of their data.

[wrs]

The other real use case is printed URLs. Also, why is Twitter’s URL shortener exempt from this concern? If I recall right, they got a special exception to have the only single-character .co domain, and if they go into bankruptcy…

[rom-antics]

> printed URLs

True, but I still think users would trust "uber.com/xmas-sale" over "tinyurl.com/FgL82" or whatever. It's not that much extra typing.

> Also, why is Twitter’s URL shortener exempt from this concern?

Twitter's character limit means that some URLs can't fit in a tweet due to length limits. So some form of shortening is required, but it's still definitely not ideal. Because everything is owned by the same company, they are controlling their own data (without a blockchain), in a roundabout way. I would never use a t.co link outside of Twitter.

[JohnFen]

> True, but I still think users would trust "uber.com/xmas-sale" over "tinyurl.com/FgL82" or whatever. It's not that much extra typing.

I would.

One of the main problems I have with shortened URLs is that they remove transparency. I have no idea where the shortened URL actually goes unless I click on it. That means that I have to blindly trust whoever is giving me the shortened URL.

In practice, that means I won't use shortened URLs unless they come from a person or company that I already trust.