||2 years ago|
|assets/templates||2 years ago|
|cmd/rushlink||2 years ago|
|db||2 years ago|
|gobmarsh||2 years ago|
|handlers||2 years ago|
|metrics||2 years ago|
|.gitignore||2 years ago|
|LICENSE||2 years ago|
|README.md||2 years ago|
|go.mod||2 years ago|
|go.sum||2 years ago|
A URL shortener and (maybe) a pastebin server for our #ru community.
Use standard-Go-libraries if the job can be done with those. As of now, these are the exceptions:
github.com/gorilla/muxprovides useful stuff for routing requests.
github.com/gorilla/sessionsfor session management.
go.etcd.io/bboltis our database driver.
github.com/prometheus/client_golang/prometheus/...has easy Prometheus functionality.
We will be using
go.etcd.io/bbolt. This file should be the only file
apart from our monolithic binary. All settings and keys should go in here.
Any read-only data resides in the binary file (possibly compressed).
All shortened URLs exist as a key on the root of the webserver, i.e.
That means that we have to separate every other page with some kind of
/z/reserved for flat pages.
/z/static/reserved for "static files".
Previous, I was planning to put pastes (not redirects) in a separate bucket and below a url namespace. Then when one was created, we would immediately generate a redirect link.
Turns out it's easier though to just save a unit (we call it a "paste") which can be of different types. For example:
- Hypothetical other stuff:
Shorten keys and collisions
First of all: A sextet is a value of 6 bits.
For generating keys, we will initially generate a random value of 4 sextets,
where the first bit is set to
0. If this collides with an existing key, we
will generate a new one made out of 5 sextets, and set the prefix bits to
0b10. We will keep doing this until we don't have any collisions anymore.
To get proper-looking keys, we format the key to characters using the base64url alphabet described in (RFC4648, par. 5). The encoded value will be saved in the database.
As is tradition in a lot of URL-shortener/pastebin-like services, we will put
everything in a single
<pre> tag, and if possible, just serve
A good example is https://0x0.st.
The reason we would use
text/html instead of
text/plain is basically
useful if users could also use the website and/or drag-and-drop files and URLs.
On the other hand, using
text/plain saves us so much effort, because we
The best thing would probably to do both, and correctly listen to the
header that the client sends. We can still wrap the plain-text page in a single
<pre> to keep it easy for ourselves.
- If we can, we don't want to have user accounts. We store the sessions forever, and store a user's data in there, without having to collect personal data in any way.
- URL-shortening links will be retained for always, unless the submitter
revokes it, in which case it will be replaced by a
- The probles of pastes are not solved. This is an unsolved problem[*].
[*] In any case, we going to comply with all European laws and reasonable requests for deletion.
We will try as hard as possible to not store any data about our users, and will only provide any data when we have the legal obligation to do so.