Name System Design Discussion

[Stebalien]

Most blockchains (really, most systems in general) end up with some form of name system because humans aren't great at dealing with binary identifiers and random hashes. Without user deployable actors, a Filecoin name system would be convenient but not critical. However, once the FVM ships, users will want to be able to name versioned code and actor instances.

This is not a proposal. Instead, I'm just going to lay out some use-cases and try to extract requirements.

Guiding Use-Cases

Debugging

A user wants to know what some actor "is". This involves resolving the actor's address into a human readable name and/or the actor's code CID into a human readable name + version.

Key features:

• This needs to be efficient, ideally not requiring the user to build a reverse index locally (mapping resources back to names).
• There needs to be canonical names for resources.

Method Calls

A user wants to call some actor by a convenient name. This involves (likely off-chain) looking up the actor by-name and resolving that name to an address.

Key features:

• There needs to be support for mutable names.
• There should be support for mapping multiple names to a single actor. E.g., multiple users may want to declare that a single actor is, e.g., their bank.

Code Deployment

A user wants to deploy some code by name, rather than hard-code a CID somewhere.

Key features:

• Immutable names. There needs to be support for name "records" that cannot be changed. That way, a user can, e.g., deploy some specific actor version and know that the deployed code will always be the same.
• There needs to be able to have versioned names. This can likely be done through namespacing. E.g., /glif/wallet/v1 where the name itself is immutable, there's a convention on version ordering, and /glif is owned by some other actor.

Access Control

A user wants to allow actors of some specific type (or actors named/tagged by some user) to call some method on their actor. Currently, we do this by checking the caller's CID or address. Unfortunately:

1. This becomes an issue if the caller is upgraded independently of the called code.
2. This doesn't allow specifying, e.g., that some class of actors is allowed to call another actor.

Names could be used to solve this.

Key features:

• Namespaces. E.g., given some code named /fil/miner/v1, an actor may specify constraints: can only be called by /fil actors, can only be called by miners (/fil/miner), can only be called by miners between some set of versions.
• Namespace delegation. It must be possible to delegate control of some name's namespace to some other actor (not the actor that controls the root namespace).
• Efficient "contains" checks. I.e., there needs to be a way to efficiently check "is resource X named by any record of type R in namespace N". For example, the question "is this a builtin actor" would be: is the actor's code CID named by a "code name record" in namespace /fil.

Non-Filecoin Resources

A user wants to name a website, a libp2p node, an IPFS resource, etc.

Key features:

• Flexible record types.
• Multiple records per name? There are really two ways to do this:
  • Multiple records per name (like DNS). For example, /stebalien may have an "ACCOUNT" record, a "CONTACT" record, etc.
  • A well-known name convention. For example, /stebaliens account may be /stebalien/_account. However, if not implemented correctly, this can lead to some... security issues. Multiple records per name is likely a better solution.

Key Takeaways/Features:

From these use-cases, we can extract a few key features:

• Namespaces with control delegation.
• Support for both immutable and mutable names. A user must be able to verify that some name cannot be changed.
• Multiple record types/subtypes per "name".
• An efficient reverse-name resolution, specifically for code and actor objects.
• An efficient way to determine if a resource "is named" in some namespace (for the access control use-case).

Design Notes

• The actual name management actor (or actors) should have very little logic. Any access control, market-place, etc. logic should be handled in "controller" actors.
• If used for access control, this could become a hot-path.
  • We may want first-class FVM integration (e.g., caching).
  • It may also be possible to map names to sequential IDs for more efficient lookup (a literal "oracle").
• Lookups across multiple namespaces should not require digging through multiple HAMTs. Instead, records should be stored in a single flat HAMT (or one HAMT per record type).

[motherdomains]

Perpetual Name System is critical - permalinks / names that will persist, as long there is Internet / Filecoin.

Soulbound Token (SBT) could be considered for the first instance of Identity.

There needs to be thought put into name reservation, moderation, is there any paywall (like ICANN / Unstoppable, etc)?

Should names/domains be free for all?

Is there exclusive reservation of a single name, or can people have whatever name they like, with some sort of short "zip code" identifier?

How do we handle the point it becomes another domainer land rush - whoever is in first, grabs the best names? How to / should we limit? How to determine somebody's worthiness for a particular name, e.g. "Amazon", "John Smith", "ABC Computing"?

These are questions we've been ruminating on for nearly a decade, with many interesting recent solutions in play, but I don't think anybody is close to cracking it.

I feel the answer might be something more like a distributed bookmarking system, where autonomous democracy from the global community, augments individual freedom/choice. DataDAOs have a big role to play in this.