Vanity imports for our Go repositories

Archive Software Engineering
1

First of all, I know we are super busy so this idea is probably for a hackathon or a lazy weekend (;)) However, I think it’s worth bringing it to the surface.

What are vanity imports?

In Go, packages are usually referenced by a URL: import "github.com/status-im/status-protocol-go" unless they are from the standard library then simple import "time" is enough. You can also download packages/modules in the same way using go get, for example: go get github.com/status-im/status-go.

What you notice here is that go get hits github.com. How does it know how to download a package by looking at a regular HTLM page? Like with mobile Web Apps on iOS and very likely on Android, github.com provides a special meta tag which would work on any other website:

<meta name="go-import" content="github.com/status-im/status-protocol-go git https://github.com/status-im/status-protocol-go.git">

It tells go get about the type and URL of the repository.

And that’s the magic trick.

Why would we need this?

We don’t necessarily need this but having our own domain which we can use and advertise to import our Go packages has a couple of nice properties:

  • We are independent from Github. Let’s say we need to move out from Github due to some reason. It’s enough to upload code to some other hosting and update the meta tag. That’s it. Currently, we would need to tell everyone through some communication mean that all addresses of our packages changed.
  • It’s getting serious :slight_smile: That’s the message you communicate when you have a vanity import.
  • Promotion and directing the traffic as it’s still unusual to see vanity import addresses and it just draws users’ attention to visit the website.
  • Import URLs are shorter.

It’s important to say that it does not mean we would need to move from Github now. We can still have our code there and do it like this:

<meta name="go-import" content="go.status.im/protocol git https://github.com/status-im/status-protocol-go">

Having something like go.status.im/protocol instead of github.com/status-im/status-go would be pretty cool, right?

cc @oskarth because of the new initiative https://vac.dev/ and you may want to host Go packages as go.vac.dev or something similar
cc @jakubgs because you are the master of our servers and capable of making it happen!

2 Likes
2

Not sure if I understand this right. What we want is a https://go.status.im/ endpoint that will host some HTML that will include <meta> tags that define where go get should actually get the package source. Meaning, it would be just a shorthand redirect to your github repo?

Does that page need to also include a list of available packages that can be viewed in a browser?

I found something like this that could do it for us: GitHub - kare/vanity: Go vanity domain HTTP handler

3

What we want is a https://go.status.im/ endpoint that will host some HTML that will include <meta> tags that define where go get should actually get the package source. Meaning, it would be just a shorthand redirect to your github repo?

That’s correct.

Does that page need to also include a list of available packages that can be viewed in a browser?

No, but I think it would be a nice touch.

I found something like this that could do it for us: https://github.com/kare/vanity

Yeah, there are a few such things but honestly it’s trivial to set up manually. It’s just one tag.

4

Yeah, that does sound pretty simple. How should this be updated? Manually, like through some json file in a repo? Or through some automatic mechanism for pulling go packages from our github org? I assume it wouldn’t need updating that often.

5

Done and done:

 $ curl -s https://go.status.im/protocol | grep go-import
<meta name="go-import" content="go.status.im/protocol git https://github.com/status-im/status-protocol-go">

Configured in:

Via the PACKAGES object in go_vanity.js.
Uses CloudFlare Workers to avoid having to host anything.

6

Awesome! Thanks! I will give it a go this week :slight_smile: