Kutt – a modern, open-source URL shortener | Hacker News Reader

Kutt – a modern, open-source URL shortener

github.com

109 pointshugodutka58 comments

To me at this point I question the wisdom of even using URL shorteners.

They almost all get abused by spammers and malware, they end up getting blacklisted, and as a best practice they are generally advocated for end users not to click on them.

In a Corp business environment I haven't found the pains that come with using them worth the shorter URL.

What places are they still widely used outsider of social media?

They're useful when you need to get people (especially large groups) to type in a URL. For example, I use them when teaching classes to e.g. fill out attendance sheets because I can simply write the url on the board.

I'd agree that if the method of delivery is a link, there is no valid reason to use a shortener.

We at least use one internally at my big corp. It's nice because instead of routing to some non-vanity URL that looks more like a raw Azure host, we can register x.company.com/whatever to redirect to it. Can only access the links and shortener from inside the firewall.

AFAIK Microsoft use their own URL shortener all over the place including their blog, project, and docs https://aka.ms .

Instead of using random characters, they use a name that clearly shows what it is about for a URL, https://aka.ms/terminal-video as an example. I think it is the best usage of a URL shortener so far.

https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Na...

Yes, and it's a parade of randomly dead links, I really hope they stop using it soon. Or at least stop deadlinking their own content.

Many companies use shortened URLs in SMS messages.

This is probably the best answer I've seen to this, the others make valid points also, thanks for the response.

>What places are they still widely used outsider of social media?

Is that not a good enough reason to begin with?

But really, URL shorteners are the direct result of:

1)Most websites not having human-readable URL's

2)Many places not allowing HTML-style links

Both (1) and (2) apply to this forum; e.g.:

news.ycombinator.com/reply?id=21870064&goto=item%3Fid%3D21867994%2321870064

As a result, we have URL shorteners. They perform the function of <a href="">link text</a>, with the advantage of the users being able to type them by hand, if needs be.

They are immensely useful as an internal tool: if you run one locally, URLs of the form http://link/useful-link-description will quickly become the norm.

And I might add:

They are useful for granular tracking (e.g. If you send a link to a resume and you want to make they have read it).

if you have a long URL you want to turn into a QR-Code, using a URL shortener will decrease the complexity of the Code (=improve the readabilty), while allowing you to track how many people scanned it and on top of that you can change which site it is pointing to without redirects or reprints.

Yep. I think most people don't realise what most end URLs used in shorteners look like.

You can share

  http://example.com/vfdge34

  http://company.com/blog/2000/12/13/top-10-reasons-use-url-shorteners-today-you-wont-believe-number-7?utm_source=twitter&utm_campaign=another_stupid_recycled_post_campaign_for_social_media&utm_content=look-how-modern-we-are-with-url-shorteners&utm_term=buy_now

> Most websites not having human-readable URL's

What problems human-readable URLs solve in the context of URL shortening and modern websites? Their benefit in the past was that on websites with clear hierarchy you could strip URL path or change a word, thus quickly navigating on a site without resorting to clunky menus or site maps, but modern web doesn't look like that, and "human-readable URLs" slightly changed their appearance over the time too.

I find modern auto-generated URLs like, say, news.ycombinator.com/item/21867994-Kutt-a-modern-open-source-URL-shortener to be much inferior: 1. they're longer and much harder to type by hand (and I've seen websites where lowercasing or omission of a single letter past the id results in 404) 2. they don't work well when the author decides to change title (and even HN submission titles change a lot, often multiple times as a result of a long discussion). In fact, (1) is exactly the reason why one would consider using URL shortener today: it's so much easier to dictate and type in by hand!

"Modern" URIs don't have to be unusable. Discourse is a good example of this done right. If HN used discourse style urls, the example you gave above would look like this:

news.ycombinator.com/item/21867994/Kutt-a-modern-open-source-URL-shortener/

Further, several redirects are created, so you can access it at any of these uris:

news.ycombinator.com/item/21867994

news.ycombinator.com/item/Kutt-a-modern-open-source-URL-shortener/

news.ycombinator.com/item/21867994/arbitrary-text-here

The last form means that when the title changes, the canonical uri can be updated without breaking links to the old location. The only unstable form is the second, without the id.

"What problems human-readable URLs solve in the context of URL shortening and modern websites?"

The problem arises anytime you need to cut and paste, or otherwise transport, a URL between components that aren't directly linked ...

If all you're doing is click-click-clicking like a good end-user, it probably doesn't matter - but if you need the URL for some reason, it can be very difficult - especially in a terminal - to properly move around a 500 character URL.

I have my doubts that you'll find an increase in url shorteners internally, as one this can be handled through Dns if it must. And how often are people reading and typing urls locally?

For anything like needing to widely distro a URL it will be posted In a commonly accessible page, a email to those needing it, or distribed slide deck.

Or even physically posted QR Codes.

As far as putting them in line in a post, i can see the value there but me personally 250 characters isn't going to make or break my ability to read them.

To each their own though, ans thanks for the insight.

>I have my doubts that you'll find an increase in url shorteners internally

ahem go links ahem

https://medium.com/@golinks/the-full-history-of-go-links-and...

I'm not really seeing how this AD by golinks conveys an increasing trend of a 3rd party application to handle internal url shorteners.

Just seems to me that any company with a remotely competent IT staff could handle this with a few Dns records and a very simple lookup system.

But I've been wrong before admittedly.

>Just seems to me that any company with a remotely competent IT staff could handle this with a few Dns records and a very simple lookup system.

Sure, but that's just an in-house URL shortener :)

> I'm not really seeing how this AD by golinks conveys

It shows that there's enough demand for URL shorteners in the corp world that a company is making a business out of it (even though it's almost trivial to make one yourself).

I've worked at several companies that use some form of go links before.

The primary advantage of them is that they are very easily self-serviceable. Anyone can create a new go link, and it's easy enough to do even the HR department managed their own.

You are definitely correct that the same thing can be handled using DNS records and something like a reverse proxy configured to route them based on the subdomain. However, that introduces permissions and ease of use issues. You typically don't want HR to have access to edit DNS records. You can relegate it to a subdomain, but at the point you're typing in "mylink.links.company.com" the shortening effect is dubious. Secondly, managing DNS records is typically technical enough that some groups like HR are not going to want to do it. And if I have to go talk to some group every time I want a go link, I'm just not going to do it.

It's shockingly useful to think "This is a page other people should know about" and be able to enter "go/page-name/edit", paste the link in the box that comes up, and have "go/page-name" go to that page on everyone's computer in the company. Done and done, you made it accessible in less time than it would take to figure out who you have to talk to get a domain name set up.

A secondary benefit is that you can enter a description in your go link. So I can just go to "go/" and get an index of all the golinks we have, with descriptions. It's sometimes useful for when I'm working on a system I haven't used before and want to see what other people have "bookmarked" about it.

"Or even physically posted QR Codes."

... or use an "Oh By" code, which allows you to:

1) pass around a very easy to say/read/write code - no computer/camera/app required.

2) create something like a QR code without any third party helper/app/site

[1] https://0x.co

What makes a project "modern"? Seriously curious, as it seems to often be used to describe projects/tools. Is it that the tools and languages used to build it are new? If so, should I care? I suppose if the point is to showcase a useful project in some new language/framework, then I'd care. But otherwise, do I? Like, what if this were built in some really old language and with ancient tools? Feel free to ignore this ramble, just curious what people think.

Hmm, TypeScript + deployed as a container?

Not cutting-edge, but definitely not obsolete, and does have obvious benefits over e.g. a traditional plain Python-based app which you need to package and host yourself.

What are the obvious benefits? I don't follow your example... you can run a Python app on AWS, directly on an EC2 instance or in a container, using Lambda, whatever.

Installing Python code and having all dependencies correctly resolved is a common source of problems and complaints.

OTOH URL shortener run as a Lambda looks like a good idea in many cases.

I hear ya, but still...I think I feel that you're overstating things. You can use pipenv or poetry or whatever to minimize issues with dependencies, bake into an image and run as a container. I've nothing against typescript or any other techniques/practices you might be alluding to, but choosing those languages/tools based on the kinds of benefits you're pointing to seems rather off to me. It's a bit of work (just a bit) to get deployments working correctly, but once you do, it's there and you can rely on it as part of your infrastructure. I think the decision of which language or framework is going to be used should be informed by something more than the benefits you stated (assuming you meant those are the primary ones) because those seem a bit weak tbh.

A full-scale database server (Neo4j or PostgreSQL), a heavy frontend React app with Redux. A little over-engineered for a URL shortener, I think. That’s a lot of spinning wheels to maintain for a relatively simple service.

You may want to think twice before marketing this to anyone who speaks Dutch.

the Dutch equivalent of the c-word in English.

Written with a single t, but a word we use to describe poor quality, annoying people, the sensation of hitting one's toe against furniture, that moment when you realize you forgot something important, female reproductive organs (though this is not a very respectful word.) A very versatile word indeed, more the equivalent of the F word I think.

And now we can add k*link to it to mean a dead link. Fittingly I'd say.

Reminds me of how the Zune amused French-Canadians.

What does it mean in French-Canadian?

In Hebrew it is the modern noun for "fuck" (as in, the act of coitus) - perhaps you mean that? (And to add insult to injury, you used to "squirt" songs)

I guess the same was true for Flickr.

But trying to find a brand name that doesn't offend in any language, while also not having to pay $10k to some domain squatter is basically impossible nowadays.

I feel better about this than a commercial service I suppose.

But links should be what they are—the address of a page and not the product of a cloaking and tracking service that takes you to a page with added delay.

Agreed. FWIW, our reason for implementation is to reduce character count for SMS. Not for tracking/cloaking.

Is there a better solution for what to do when space is at a premium? The choices are:

- Don't post the link

- Post the link and let it get lopped off in the middle

- Post the link without adequate context surrounding it

- Create a shortened link that points to the original

Is space really at a premium though?

Tweets and SMS can allow full-sized links while retaining character limits for UX reasons. It's almost 2020. Our networks can handle a few more bytes.

When presenting visually (such as outdoor advertising), users should be able to simply scan the link - either as text or QR code.

There's a limit to the length of an SMS, built into the protocol. 160 characters iirc.

Recently set up a system, the limit was preventable by concatenating multiple messages, with the end-user not knowing this was done.

By the way, we were going just a few characters into the next message so for pricing / logging issues we decided on shortening our own URL.

Just to add to the list - Go/Redis/gRPC: https://github.com/LevInteractive/dwarf

And a js/ts client to interface with it: https://github.com/LevInteractive/dwarf-client-ts

Edit: Fix url.

> we moved from Neo4j

Strange, why even use graph databases for this kind of service? It does not seem like it would be needed for this use case.

I started my project (https://onefiftyone.run) using Mongo. It wasn't intentional, that was simply my stack.

We quite quickly outgrew it, and had to rip out that plumbing for Postgres. It wasn't fun, but in retrospect I realise I was using the new, cool, hip technologies instead of actually evaluating things on their merits.

Maybe this project fell into the same trap?

There's a link in the official Microsoft documentation (for office-js if I remember it right) that uses bitly or a similar service. I don't what happened to that link but now, when clicked, it tries first to load some random porn site and then redirects to a YouTube video (about a car or something like that). I wanted to report it, but didn't find an easy way of doing so, so there must be still there trying to add malware or who knows what to the poor people reading official Microsoft documentation.

I can pick up a few here:

https://github.com/MicrosoftDocs/azure-docs/search?q=bit.ly&...

Edit: All those seem "legit", but do point to a pattern

I've been through this source code, really clean and well written modern javascript (as far as I can tell). I was completely new to this whole webstack, learned a ton about javascript and building front ends from this. I think an underrated way to get good at coding or even to learn whole new methods is to extend well written open source code. I find myself regularly working with high quality code off github, learning more from the developers on there than the developers I interact with at work.

Hey, creator of Kutt here! Wanted you to know that I'm refactoring client side as well to use TypeScript and new React features like hooks to ditch Redux, and I'm really really excited to push this code into production, so much cleaner now. You check the progress here:

https://github.com/thedevs-network/kutt/tree/feature/refacto...

For hosting this myself, the major 2 things I am seeing:

this requires captcha it seems for link creation? I'm getting captcha errors. Would much prefer requires being signed in to work.

And on that note, no easy ENV var type way to disable sign ups.

I really like the concept, but would love it as private only.

It's on my list and will implement it soon.

Why do you need to "ditch redux"? Redux is excellent. People aren't "overusing" it as we did previously, but it is still a very good way to manage data and state, and sagas etc are a great way to approach building clients for traditional APIs.

There isn't really anything in pure hooks that can really replace it, performance wise.

If you for some reason really dislike it, mobx-state-tree is probably the best contender to replace it.

It really depends on the use case. For mine, too much time spending on writing boilerplate specially when used with TypeScript. Even mobx-state-tree seems too much for me. I went with something way simpler called "easy-peasy" alongside React Context and I'm very happy with them so far.