FIP: Basenames

[sanjayprabhu]

Title: Basenames
Type: Implementation FIP
Authors: @sanjayprabhu, @aditiharini , @varunsrin

Abstract

Proposal to allow users to set their Basenames as their username on Farcaster

Problem

Currently users only have the option of using Farcaster names or L1 ENS names, with other chains like Base continuing to gain adoption, we should allow users to bring their identity from there and use it on Farcaster.

Specification

This proposal builds on FIP-4: ENS Usernames.

From the client perspective, there is only one change. The UserNameType enum will be extended to add BASENAME

enum UserNameType {
  USERNAME_TYPE_NONE = 0;
  USERNAME_TYPE_FNAME = 1;
  USERNAME_TYPE_ENS_L1 = 2;
+ USERNAME_TYPE_BASENAME = 3;
}

Clients can register and set Basenames exactly the same way they currently do for ENS names (see doc). First submit a UserNameProof message with type set to USERNAME_TYPE_BASENAME. The name MUST end with .base.eth, and owner MUST be a custody address or a verified eth address for the fid. Finally, the name must resolve to the owner address.

If the above conditions are satisfied, the message will be accepted (and merge event emitted). The username proof will be listed along with the fname or any existing ENS name on the GetUserNameProofsByFid RPC endpoint.

At this point, the client can set the username of the fid to the basename by submitting a UserDataAdd message with type USER_DATA_TYPE_USERNAME.

Implementation

On Snapchain, the validating nodes will require a new config variable for querying Base RPCs. When they receive a UsernameProof with type set to BASENAME, the proposer will perform the same checks it does for ENS names, except using the Base RPC. Non-validating nodes do not require Base RPCs.

Revocation

Snapchain does not currently automatically revoke ENS or Basenames if they expire or are updated to point to a different address. In the future, the validators will periodically validate that external name proofs are valid, and revoke outdated proofs and corresponding UserDataAdd for the username.

Rationale

Adding a new type for Basename is the simplest way to support an additional namespace. We considered moving name validation to the fname server, which would let snapchain validators not require Base RPCs, but that's a bigger change. And something that can be done later. Since there are only a handful of validators, and full nodes don't require a new RPC, we opted to stick to the simpler design.

Release

This change requires a protocol upgrade. The nodes will be updated to support the new API the week of June 2nd. But Basename username proofs will not be accepted by nodes until the next protocol version goes live. The next protocol version is currently scheduled for June 16th.

[vrypan]

Will nodes refuse to start if a base RPC endpoint is not provided?

[sanjayprabhu]

No, full nodes don't need a base RPC endpoint

[vrypan]

Out of curiosity:

• I validate an ENS (or Base) name.
• After a day, it expires.
• Right now all validators agree that the name is controlled by me, because when they checked, it was.
• A new validator is added, and comes online.

What happens in this case? Will the new validator check the validity of the existing UsernameProof?

[sanjayprabhu]

No, the validator replays historical blocks as is. As long as the signatures on the block is valid, it will trust that the validator set at the time verified the ENS name at the time of inclusion.

[vrypan]

Thanks.