FIP: Namespaced FIDs and Address-based FIDs

[musnit]

As part of the Permissionless Onboarding FIP (#91) there has been some discussion about whether to use Address-Based FIDs or Integer-based FIDs (#91 (comment))

I think this may warrant a longer discussion with its own FIP. In my opinion, this is a significant decision that may provide additional unexpected benefits to Farcaster. I also believe there are solutions to some of the discussed trade offs of each option.

To explain, let's distinguish between FID creation/ownership-assignment and activation:

• Creation and Ownership Assignment: Address-based IDs are created client-side and self-assign ownership. They do not require any kind of global consensus. They're owned by the creator irrespective of anyone else. This makes them more decentralized and future-proof than any FID that depends on a chain's consensus. Integer-based IDs are created only via a system that provides consensus on ownership assignment at time of creation.
• Activation: Address-based IDs would be activated by some payment. Same for Integer-based.

Address-based IDs unbundle Creation/Ownership-assignment from Activation. Integer based FIDs bundle them all together.

This directly relates to one of Farcaster's design qualities of "each Hub must store a copy of every user’s data", ie, there is global consensus on what the state of the Farcaster network is. It doesn't really matter that creation/ownership-assignment and activation are bundled together if global consensus is enforced on everything else anyway.

This quality imo is one critical differentiator for Farcaster's protocol from other decentralized social networks like SSB/Mastodon/etc and allows Farcaster to solve many UX issues that those networks have. However, it also results in excluding those communities due to reasons like:

• They may not actually want that quality
• They may be sensitive towards the technology (ie, blockchain/crypto) that is required to achieve that quality
• They may want certain features which are not compatible with that quality, like free signups

This differentiator is important, but at the moment, it kills both technical interoperability and social interoperability with those networks and communities. I think Address-based IDs may be able to create frictionless technical and social interoperability with these traditional dWeb social network technologies and communities that could be a valuable unlock for Farcaster's growth and wider acceptance.

Consider the following design:

• Farcaster implements a parallel FID system that allows for namespaced FIDs
• Namespaces can be anything - a centralized service, a chain ID, a smart contract address, a public key or hash of a public key (ie, address)
• A namespace can be it's own FID (eg: if it's a public key) or can contain sub-FIDs (eg: the existing Goerli FID registry with integer IDs)
• Farcaster Mainnet has a hardcoded or onchain whitelist of namespaces that are accepted by Hubs
• Farcaster Mainnet Hubs today whitelist only namespaces that are onchain registry contracts which charge $5 or so for names and only consider sub-FIDs in that namespace valid.
• Farcaster Mainnet Hubs today set a default namespace, such that integers without a namespace are assumed to be in the default namespace, allowing us to retain the benefits of integer IDs

Then, this means that there could exist a non-Mainnet, federated network of Hubs that work as follows:

• Each controls its own whitelist
• A federated hub operator can potentially allow address-based namespaces as IDs with free signups if they want it, and have whatever bot-mitigation strategies of their own that they want
• A federated hub operator and their users can have zero interaction with any blockchain or cryptocurrency whatsoever if they don't want it
• Users on any hub in the federated network could at any point pay any accepted registry contract on the Mainnet whitelist if they want to upgrade themself and their messages into Mainnet and become part of the global Mainnet consensus

This could also allow Farcaster Testnets be semi-interoperable with Mainnet too. Of course it may not make sense to implement any of this now, but implementing a parallel FID system that can support future Address-based IDs enables this possibility in future.

Of course, this kind of interoperability could have a dangerous side too - if enforcement of global consensus becomes softer and more flexible than it is today, there may be, in practice, some increased risk of losing it and the benefits that come with it. It could increase the likelihood that an alternative community creates their own "Forked Mainnet" with alternative payment mechanisms, alternative whitelisted contracts or alternative bot/sybil mitigation mechanisms for activating FIDs. Reducing the technical friction and message liquidity moat for forks could be a good thing too though

Lastly, the Permissionless Onboarding FIP discusses some criteria to assess whether to choose address-based FIDs or not. Let's re-assess those with a parallel namespaced FID design in mind:

• Migration: Hubs and apps need significant refactors, some data loss for threaded casts

Yeah, refactor is pretty much unavoidable. Data loss may be avoidable with parallel system that allows for a backwards-compatible lane.

• Portability: Cannot re-initialize FIDs on a new EVM-chain, must create parallel fid system

With a parallel fid system, address-based FIDs are more portable than integer based ids, since they can be activated via any chain/registry on the whitelist, not just a specific chain.

• Recovery: Only smart contract or MPC wallets are recoverable, EOAs have no recovery

I suspect that there is way to introduce a new message type that would allow EOA-based FIDs to add and remove recovery keys or even configure a social recovery setup by letting them store a kind of "recovery key-chain" on Hubs, without sending any Ethereum transactions. Of course, the underlying Ethereum private key may not be recoverable, but the FID generated from it still could be. Also, perhaps something like https://darkcrystal.pw/ may be worth considering, though that may be overkill.

• Gas Cost: Counterfactual wallets are ~25k gas cheaper since no registry transaction

Yeah, counterfactual or even EOA-based are cheaper.

• Data Size: Each message is ~ 16 bytes larger increasing Hub size by ~ 200 GB / million users

The parallel ID system allows for both small integer IDs and address-based IDs to coexist. Mainnet could choose to only allow integer based ones, or allow address-based fids if they pay a bit extra.

[varunsrin]

Thanks for the comments.

Compatibility with other social networks can be achieved by wrapping FID's into some sort of DID. That's going to be a lot cheaper and easier than implementing an address based system which is expensive and has the downsides I outlined here.

Of course it may not make sense to implement any of this now, but implementing a parallel FID system that can support future Address-based IDs enables this possibility in future.

I'm not opposed to adding a parallel system in the future if there are clear benefits from it.

With a parallel fid system, address-based FIDs are more portable than integer based ids, since they can be activated via any chain/registry on the whitelist, not just a specific chain.

That's only if you use an EOA wallet which has no recovery. Over 10% of Farcasters have already lost their seed phrase, so that's not a viable option for us to pursue. The address based approach can only be done with a counterfactual wallet, which may not be easily parallelizable across chains.

I suspect that there is way to introduce a new message type that would allow EOA-based FIDs to add and remove recovery keys or even configure a social recovery setup by letting them store a kind of "recovery key-chain" on Hubs, without sending any Ethereum transactions.

I can't think of a way to do it that is both secure and user-friendly.

[philcockfield]

↑👍 re "DID"

[TimDaub]

That's only if you use an EOA wallet which has no recovery. Over 10% of Farcasters have already lost their seed phrase, so that's not a viable option for us to pursue.

smart contract wallets CREATE2

[musnit]

Thanks for the comments.

Compatibility with other social networks can be achieved by wrapping FID's into some sort of DID. That's going to be a lot cheaper and easier than implementing an address based system which is expensive and has the downsides I outlined here.

I'm not opposed to adding a parallel system in the future if there are clear benefits from it.

Compatibility of the social graph is where Integer-based FIDs may become constraining. Link Messages will point to Integers, not DIDs. That means that different networks will need to be capable of unwrapping DIDs to verify Link messages and compose social graphs. Either:

• (a) each network's hubs would need to index and/or understand each other network's DID-unwrapping mechanism, or
• (b) each network's client would need to understand this and then re-sign the parts of the social graph that it wants into the new network when bootstrapping a new user.

With (a), networks need to explicitly opt-in and take on an additional technical dependency & cost to interoperate with each other's social graphs. With Address based IDs, interoperability comes at a much lower cost.
With (b), users need to opt-in to interoperability. This could be good in some cases, but may also create challenges for new networks looking to bootstrap on existing social graphs.

In either case, technical & social complexity goes quadratic in the number of different networks in order to preserve interoperability. Flexible Storage considerations will add further constraints to interoperability.

Anyway, there are certainly workarounds to these ideas, but the point is, by choosing to go with Integer based FIDs, Farcaster is making a design choice that will constrain its flexibility in the social-graph-liquidity design space.

If we can find a way to solve the problems with address-based IDs and use them as the default namespace, then it means we can preserve that flexibility - especially for future work like Context Separation.

With a parallel fid system, address-based FIDs are more portable than integer based ids, since they can be activated via any chain/registry on the whitelist, not just a specific chain.

That's only if you use an EOA wallet which has no recovery. Over 10% of Farcasters have already lost their seed phrase, so that's not a viable option for us to pursue. The address based approach can only be done with a counterfactual wallet, which may not be easily parallelizable across chains.

If you're referring to counterfactual smart wallets, yeah fair, I'm definitely overly/blindly optimistic that counterfactual smart wallets will eventually settle into something highly parallelizable, but tbh idk with the upcoming ZKEVMs.

I suspect that there is way to introduce a new message type that would allow EOA-based FIDs to add and remove recovery keys or even configure a social recovery setup by letting them store a kind of "recovery key-chain" on Hubs, without sending any Ethereum transactions.

I can't think of a way to do it that is both secure and user-friendly.

Will reply properly on the new FIP re onchain signers, but basically allow the existing EOA custody address to add additional EOA-based custody addresses via offchain signatures as backups, even as m of n multisigs.

[varunsrin]

Compatibility of the social graph is where Integer-based FIDs may become constraining. Link Messages will point to Integers, not DIDs.

Using an address based system doesn't result in any practical composability - I can't jump over and post on another network with this address today, or anytime in the near future. But it does impose non-trivial costs on our users and developers, which I'd like to avoid.

On a more philosophical note, I don't think there is a path to true composability between today's social protocols. Each has made different design decisions about identity, storage, consistency and features that make interop impractical. These are intentional decisions and a good thing, I think. We have very different views on what will make a decentralized social network successful, and we're testing our hypotheses. If two protocols are so similar that they are easily composable, then you probably don't need two protocols.

[musnit]

Using an address based system doesn't result in any practical composability - I can't jump over and post on another network with this address today, or anytime in the near future. But it does impose non-trivial costs on our users and developers, which I'd like to avoid.

Yeah, it's not at all relevant today - the question is more regarding some potential future where there are multiple Farcaster-based networks and if that is worth building for yet or not.

On a more philosophical note, I don't think there is a path to true composability between today's social protocols. Each has made different design decisions about identity, storage, consistency and features that make interop impractical. These are intentional decisions and a good thing, I think. We have very different views on what will make a decentralized social network successful, and we're testing our hypotheses. If two protocols are so similar that they are easily composable, then you probably don't need two protocols.

Agree, though I've been imagining this mostly in the context of a multiple future Farcasteresque-based networks, rather than actually composing with Mastodon or other pre-existing protocols. I think the set of design decisions that Farcaster has made helps it stand out from many of the other pre-existing protocols, such that a version of the protocol that could run with flexible connectivity to Ethereum & cross-community-driven flexible consistency is a pretty interesting one too with regards to potential for success.

[TimDaub]

At Kiwi I‘m happy to take the other side of that bet and make addresses first class citizens.

[varunsrin]

I think addresses today are too fragile (EOA) or too expensive (SCW) to be viable, but that will likely change in the future.

When it does, we can do a migration to burn fids into SCW's if we believe that is the right path forward, and go back to an address based world. Doing it too might hamper growth far too much.

[TimDaub]

What makes me excited is that moving the FC delegates registry onchain, may mean I can allow Farcaster profiles to post on Kiwi News. I hope validating signatures from a delegate address to the custody address and then to the FID is not painful. That I might be able to resolve an ecrecovered address via an FID to user profile metadata is really cool.

[varunsrin]

Thanks for the detailed proposal @musnit

Ultimately, we ended up deploying integer-based fids on OP Mainnet since they provided the greatest long term flexibility (rationale in #91). Closing this for now.