FIP: Opportunity For Another Chain

[CassOnMars]

Abstract

Snapchain should support multiple resolvers and contract sources for FIDs and names. This FIP seeks to generate discussions and a full proposal on how to achieve this.

Problem

Optimism is losing mindshare as one of it's more prominently corporate-funded forks (Base) captures the L2 audience. Another OP fork, Zora, is effectively defunct and the core product that used it has since moved to the same corporate-funded fork. It goes without saying, but corporate centralized sequencer chains lack credible neutrality and threaten the "sufficiently" decentralized nature of the protocol. As an anti-fragile resistance measure and answer to spam considerations, ID and name resolvers should be configurable such that clients and the network are separated from control sources that are centrally controlled.

High Level Solution

FIDs

The majority of identity-based resolution depends on the use of FIDs, they are intrinsically intertwined with each RPC and are a heft source of tech-debt. This does not mean it is impossible to work with, but requires something mutually compatible with existing clients and backend services.

The route to resolve this is two-faceted:

• a mutually-agreed namespacer first two bytes: 0x0000 being reserved for the original FC FID contract (and thus impacts no existing tooling), and subsequent enabling PRs to contribute different, compatible ID registry sources.
• an extension to RPCs using FIDs to specify an FID-resolver. As an example:

message FidRequest {
  uint64 fid = 1;
  optional uint32 page_size = 2;
  optional bytes page_token = 3;
  optional bool reverse = 4;
}

can be changed to:

message FidRequest {
  uint64 fid = 1;
  optional uint32 page_size = 2;
  optional bytes page_token = 3;
  optional bool reverse = 4;
  optional uint32 fid_resolver = 5;
}

Chain ingestion for snapchain is straightforward and pluggable, and can be hooked into other networks (especially EVM compatible, but as long as an SDK exists, standardized formatting can be achieved)

Fnames

Fnames are slightly more complicated, as they depend on a separate resolver that has on chain and off chain components, but presently they're intrinsically bound to the accessible keys of a user. We can leverage this functionality to support other chains, meaning we can also grow this to allow farcaster custody accounts to be of other keytypes, like ed25519 (solana, tezos, others), ed448 (Q).

The resolver however, is also straightforward and pluggable, meaning supporting this is not particularly complicated. The protobuf types are already entirely pluggable, so if a comprehensive resolver (FID/Fname) is being added, it can be noted via amending the type:

enum UserNameType {
  USERNAME_TYPE_NONE = 0;
  USERNAME_TYPE_FNAME = 1;
  USERNAME_TYPE_ENS_L1 = 2;
  // add new options here
}

Notes

FID resolver PR: [wip]
Additional name resolvers PR: farcasterxyz/snapchain#732

[UmmayFatema]

I hope they see it and it works out 😓... We don't wanna lose farcaster as a social platform 😓

[cboscolo]

Currently there are still signers/ associated addresses also store onchain (Optimism) associated with a FID. How would this proposal handle these additional onchain associated keys/addresses?

[vrypan]

I think that if we could trust the validator set, we could rely on reading these evens from snapchain. Not 100% sure.

[vrypan]

Hmm, I also think that signers are associated with FIDs, not addresses.

[cboscolo]

Correct.

I've always felt uncomfortable about this direction of Snapchain being the source of truth for the signers/wallet addresses associated with my FID. I'd prefer to see them on a chain where security guarantees are well understood. But my concern isn't founded on a formal analysis.

[vrypan]

Appkeys are onchain (KeyRegistry smart contract). This is why we used to pay some gas to register or revoke one.