ajnavarro commented 1 year ago

GNS (Gnoland Name Service)

Abstract

GNS intends to be a solution to have a decentralized registrar for names. It can be used for different things inside and outside the gnoland ecosystem, like gno package and realm names, decentralized web pages stored inside or outside gnoland, and other use cases where human-readable names improve the UX. All of this with no dependency on central servers.

Specification

Registrar DAO

The core of this functionality will be a Realm where the source of truth will be stored. All domain names must finish with .gno

The registration record will contain the owner, the name as a unique key, and an undetermined list of A records that can be used for different use cases.

Buy a name

When someone starts the process of requesting a name, a bidding process will start. Anyone can check all the bidding processes that are open, and anyone can bid for any of these processes. The highest bid will get the domain ownership.

When the name is a special one as we will describe above, the price for the domain will be an average of all the previous winner bids (still to be defined).

Special names

We can reserve already existing names on GitHub/Bitbucket/Gitlab, to help developers to keep the same digital handler as they are normally using at web2.0.

That can be done by generating a signature for a specific domain/handler and adding that signature to a specific file inside the repository in a specific branch. We need external applications checking periodically that the signature is still valid on the specified Git services.

This will be done by creating a special GenerateRegistrarSignature Realm method that will return the signature needed to verify that your Handler is yours. After that, you can use that signature to register your .gno domain.

We should periodically load these handlers into the Realm to avoid others to register them without the mentioned signature.

General names

Anyone should be able to register any name that is not included in the previously mentioned blacklist at any point in time.

Renewal

All domains will have a TTL that will expire after a year. The price for the domain for the next year will be the same as the previous year (still to be defined). Special names won't have an expiration time, instead, we will check periodically that the used handler is still in use and with the needed signature on it. That check will stop when the owner has at least one package or realm registered using this name, and it is being used at least by one realm/library with a different domain.

DNS over HTTPS

We can create services around this Realm to provide other services, like DNS over HTTPS. That will fill the gap between web2 and web3, making it possible for browsers to resolve .gno domains.

A records

A records can be added, modified, or removed for the specific domain. They can be used for a bunch of use cases.

Subdomains

Any subdomain can be registered as a prefix of the domain by the owner. Each subdomain will contain its own list of A records.

waymobetta commented 1 year ago

There is currently a project known as Gno.domains that is already doing this.

I have reached out to them over Twitter since I couldn't find a contact email on their site. More information will be shared here upon successfully engaging with them.

deelawn commented 7 months ago

@ajnavarro I stumbled upon this by accident. Great stuff. I was recently thinking about how to solve this issue, especially to combat the problem of people squatting on certain realm names. Your solution is almost identical to what I was thinking, with one difference.

What if this domain that handles registrations doesn't actually contain any realms with its subpaths? Instead the registration realm just maintains mappings of a top level registered paths to the realms deployed by the account that registered them. With minimal changes to the keeper, we could designation this a special realm that looks at incoming requests, retrieves the path mapping from realm storage, and changes the path in the message to the actual realm to route the request to. It could act as a sort of proxy. This would also allow realms to be easily upgradeable but would impose a certain level of work on the DAO to review upgrade requests to make sure nothing malicious is going to. This registration realm could serve three purposes:

reserve names
route requests
be THE definitive home of trusted, code reviewed realms from members of the community

If if we don't go with that, I like your approach. Perhaps we could also integrate this with the github handle registration process where a user is automatically granted ownership to a realm path like (base path + github handle) upon successful verification.

ajnavarro commented 7 months ago

A Gno program, like a Go program, is highly coupled with the domain serving its source code (every import contains the domain, the go.mod/gno.mod contains the package/realm name, a.k.a the domain+path, and so on). That's why creating a proxy might be more difficult and collide with more things from the Go world than we thought.

Maybe I didn't understand your proposal well, feel free to add more info if that is the case.

As a total random though: If giving to GitHub users a full domain for free is too much, maybe we could give subdomains instead:

ajnavarro.gh.gno
deelawn.gh.gno

gnolang / hackerspace