FIP-9: Globally Unique Verifications

[varunsrin]

Title: Globally Unique Verifications
Type: Implementation FIP
Authors: @sanjay, @v

Abstract

Verifications should be globally unique instead of per fid.

Problem

Currently, multiple fids can have the same verified addresses associated with them. The lack of a 1-1 relationship with fids constrains how the ethereum addresses can be used. e.g. if an address could only be associated with a single fid, 3rd party apps dealing with that address could enrich it with farcaster profile information (username, profile image, links etc).

We did not originally require global uniqueness because it would constrain sharding for hubs. We've since settled on not sharding at least in the medium term, so the original rationale no longer holds.

Specification

The Verification CRDT conflict rules which currently state:

A conflict occurs if there are two messages with the same values for m.data.fid, m.data.body.address

will be changed to

A conflict occurs if there are two messages with the same values for m.data.body.address

The conflict resolution rules remain the same. If another account publishes a verification message for the same address with a newer timestamp, the older message is revoked.

Implementation

The Hub will create a secondary index for verification messages based on the address. This index will be checked when new messages are accepted to ensure addresses are globally unique.

An implementation PR can be found here: farcasterxyz/hub-monorepo#1450

Rationale

Why is this change required?

There are certain kinds of UX that's not possible when addresses are not unique. e.g. Being able to use a verified address to prove ownership of a Farcaster account, 3rd parties being able to enrich a verified address with Farcaster profile information etc. There are very limited number of cases where addresses are actually shared across multiple parties. In those cases, it would make sense to created a shared Farcaster account as well between all the parties.

Why was this not globally unique in the first place?

Sharding hubs would be a lot more complicated with global state. So, everything was scoped to fids as much as possible to enable sharding in the future.

Release

The changes will be released in protocol version 2023.10.4 (Hubble 1.6.0)

[varunsrin]

The same Ethereum address can be verified to multiple fids on Farcaster according to the current verification design. Global uniquness is valuable from a UX perspective since it lets us establish 1:1 relationships for things like usernames. The original reason we didn't do this is we wanted hubs to be easily shardeable.

However this is creating additional complexity as clients like Warpcast are starting to implement the logic themselves. We should consider just making it globally unique for now since we've taken the global state approach with hubs.

[varunsrin]

cc @sanjayprabhu