Show HN: An open-source alternative to Bitly
github.com
Sink is A Simple / Speedy / Secure Link Shortener with Analytics run on Cloudflare.
github.com
For those looking for more options, Dub[1] is a matured open-source[2] link shortener with Analytics.
For not-so-large volumes of links, say for friends-family, and the occasional public links, you can run something off Github Pages[3] with their built-in Jekyll + Redirect-From Plugin[4]. If you do not want to, you do not even need to have the code run locally, just edit on Github. I run one to easily share links for the family and relatives (photos, that document link, along with the Rick-Roll Video).
Tip: If one wants to run an indie or personal or family/friends shortlink for easy sharing, try to have it on your own domain. This allowed me to moved between tools that powers it.
So I simplified it. Currently only relying on one platform.
https://dub.co/docs/self-hosting
At the scale of their SaaS service this makes sense, but for a typical user a Sqlite database (or as you did a Cloudflare Workers KV) is really all you need
That's why I set up my own thing. I don't care about analytics at all, so I just wrote a simple build system doto generate some very basic HTML redirects.
It isn't perfect but it's very cheap to run!
/ https://example.com
/cv https://example.net/cv.pdf
/git https://github.com/octocat
Even if the supplier disappears, it is possible to quickly switch to another platform
If a resource has been relocated off of a host/url, often part of that situation is that we don't have immediate access to implement a redirect from that host to the resource's new location.
Now I see a shortlink manager as a centralized redirect manager, which is so much more rational and stable than creating a tangle of redirect config across dozens of hosts or hundreds of content applications.
The caveat is that you don't need to use a 3rd party domain or service, you should definitely at least use your own domain. You also don't need to make them unreadable hashes, they can actually be more human-friendly.
People who track link usage use links to a tracking service which redirects to the target, or embeds tracking metadata in the URL. You could have a tracker which produces shortened links, or try to hide your tracking metadata by putting the already tracked link through a shortener, but that's all without consequence as a shortened URL looks no less suspicious than a URL with kilobytes of metadata. I suppose some trackers might try to (mis)brand themselves more positively as shorteners though.
Nothing about a shortener helps you block spam URLs - quite the contrary, they tend to be used to hide spam URLs.
The main legitimate use-case I can think of for shortened URLs are those used in advertisements or manuals, where the user might need to type it manually.
Link analytics is explicitly one of the stated use cases on Bitly, and you can even add UTM parameters automatically:
- https://support.bitly.com/hc/en-us/categories/360001889231-B...
- https://support.bitly.com/hc/en-us/articles/115003371927-How...
> Nothing about a shortener helps you block spam URLs - quite the contrary, they tend to be used to hide spam URLs.
It does, like on Twitter where ever url is behind a t.co shortener. If a spam url is identified you just have to kill the t.co url redirect.
This is against not in favour of your argument - it's a case of Bitly enabling users to still use other systems for tracking (UTM) while using a link shortener (as said by person you replied to), not evidence of tracking being the purpose of the link shortener.
Bitly does have their own basic analytics built in, so some people do use it for tracking, but that's still a secondary function for people who don't care enough to set up independent tracking. It's not a sale pitch of "if tracking is what you want, link shortening is the solution".
And the t.co example isn't actually useful for spam prevention, if Twitter decides that a certain URL is considered spam they can just as easily remove that link from any tweets trying to use it as they can disable a t.co. Meanwhile the t.co does add friction for users seeing whether the destination URL looks likely to be spam. I don't think I've ever heard anyone before argue that link shorteners are a good thing for fighting spam, only either bad or at best neutral.
Don't take my word for it, that's how Twitter described it when they launched it here: https://blog.x.com/en_us/a/2012/shutting-down-spammers
From a scale perspective it also seems a lot easier to remove one redirect from happening vs. finding every Tweet that contains a certain url you want to remove.
> Additionally, we now use our link shortener (t.co) to analyze whether a tweeted link leads to malware or malicious content. This helps us prevent users from visiting malicious links and helps us shut down hundreds of thousands of abusive accounts.
It is possible that their task was made easier by having the t.co system in place - impossible to know without understanding engineering details of how Twitter and t.co work - but it's not a claim they've made publicly, nor a reason for their deciding to use shortened links.
And for tracking, as you say. This would be understandable when the person sharing the link doesn't run the web server and can't simply look in access logs to find click rates, but then what they end up doing is giving everyone a unique link using marketing software and it can be tracked exactly who opened which link at what time on an individual level, as if that's necessary
I would get behind the argument that there aren't good use cases for 3rd party url shorteners. A url shortener should preferably be operated by the target website (like youtu.be), and failing that be operated by the originator of the link (linked.in, t.co, time.com).
Long links are not convenient when people have to type them into devices with no physical keyboard.
There may be a need to change the links after printing, and this is where the advantages come into play