RFC: use `tendermint.org/` as Go vanity import paths

[moul]

I propose adopting Go vanity import paths, such as tendermint.org/gno, instead of github.com/gnolang/gno. This change would improve project branding, make our import paths easier to identify in Go files and go.mod, and provide independence from GitHub. Vanity paths would also future-proof the project, allowing seamless migration to other platforms (e.g., Gno-hosted repos) without breaking imports.

However, this change introduces complexity for contributors, especially non-experts, as working with vanity paths requires additional setup. Clear documentation would be needed to guide contributors on how to clone, build, and open PRs for the project.

The key questions to discuss are:

1. Does this make sense overall? Are there other pros or cons to consider?
2. When should we do this? Should we implement it now while our user base is small, or wait until a future reorganization like a repo split?

I’d appreciate community input on the feasibility, timing, and potential trade-offs of this proposal.

[thehowl]

so, use tendermint.org even though we are "NewTendermint"?

imo, it's a bit confusing for branding

[aeddi]

So to the summarize, the main benefits are:

• it makes the project seem more serious for a project of Gno's scale
• It allows for decoupling the import from the servers where the code is hosted

Regarding the potential downsides now, in the context of Berty, I remember having issues due to the use of a vanity URL, but I can't recall exactly what those issues were. Some were related to gopls at the early stage of its development, while others were related to third-party tools like go-astilecron, for example. But as I remember, all of them could be resolved with workarounds such as adding a replace directive to a go.mod or something similar, so lets say these issues were frustrating but minor.

Moreover, it's possible that most of the problems we experienced back then (during the time of Go 1.11 and the few subsequent versions which introduced a lot of changes around modules and GOPATH) have been resolved in the current versions of Go.

Worth mentioning also the risks of losing control over the domain, an attacker could setup a malicious redirect. So we should triple-check the security around the domain administration access if not done already.

So I would say that we can make the switch if the Core Team is ready to endure a few (potential) frustrating moments and if we ensure to strengthen the security around the domain.

[thehowl]

I have another consideration to make: if we have vanity imports, we can make the vanity import URLs have a pkgsite page, avoiding the license restriction.

Overall, I think it makes sense to do this, also because I think this could be better if we were to do a repo split (whereby we can consider keeping the same import paths even when we do the split).

I still have doubts on whether it makes sense for our own branding as "NewTendermint" to use the tendermint.org domain.

[github-actions[bot]]

This issue is stale because it has been open 6 months with no activity. Remove stale label or comment or this will be closed in 3 months.

[moul]

Let's discuss this soon.

[zivkovicmilos]

I second what @thehowl and @aeddi have laid out

I'm generally a fan of vanity import paths, but I need to say that using the tendermint.org one for gno feels wrong. I have never associated the Tendermint branding with the Gno.land project, even though it powers it under the hood, like it powers many blockchain projects

I believe we should keep these things separate, Tendermint is its own universe that doesn't need to be nailed to one project, but to an ecosystem of projects like it is now. It is a toolbox, an infrastructure layer of sorts, that (in my opinion) goes beyond Gno.land

What other options would you be willing to consider?