FIP: Social Attestations

[CassOnMars]

Abstract

Allow users to verify Github and Twitter/X accounts on Farcaster, with a standard that can be extended to support other platforms in the future.

Problem

A defining feature of Farcaster is that anyone can make an account permissionlessly. While important for sufficient decentralization, it does means that you can’t tell if a new account belongs to a well-intentioned user or a spammer. App developers often prevent new accounts from getting access to the best features (e.g. limit access to older fids).

If a new account can prove ownership of a hard to forge identity, that could help them break through these boundaries. For example, a user with an X account that is over 5 years old with 20k+ followers requires proof of work on X to create.

Specification

We propose a social attestation system where an fid can attest that another fid owns a particular account on a platform like X.

A new UserDataType is added is added for each platform that we want to support. We propose starting with X and Github because they are commonly used by our users and have an verification system (OAuth). We may add other systems in the future based on adoption and feedback from users and developers.

enum UserDataType {
  USER_DATA_TYPE_NONE = 0;
  USER_DATA_TYPE_PFP = 1; // Profile Picture for the user
  USER_DATA_TYPE_DISPLAY = 2; // Display Name for the user
  USER_DATA_TYPE_BIO = 3; // Bio for the user
  USER_DATA_TYPE_URL = 5; // URL of the user
  USER_DATA_TYPE_USERNAME = 6; // Preferred Name for the user
  USER_DATA_TYPE_LOCATION = 7; // Current location for the user
  USER_DATA_TYPE_TWITTER = 8; // Username of user on twitter
  USER_DATA_TYPE_GITHUB = 9; // Username of user of github
}

The string content of the data should omit the @ , and lengths of usernames limited to app-specific limits:

• X: 15 characters
• Github: 39 characters

If Alice is using Warpcast, the flow would look like this:

1. Alice tells Warpcast she wants to verify her Github account
2. Alice completes an OAuth flow inside Warpcast, which has now verified her ownership
3. Warpcast then emits a new UserDataAdd delta of the Github type signed with the app key it has for Alice’s account.

An observer can prove that Warpcast is attesting to Alice’s account by inspecting the delta’s signatures and doing some lookups on the KeyRegistry contract. The delta should be signed by an app key that Alice has authorized from her account but which is registered to Warpcast’s fid. See [decoding key metadata](https://docs.farcaster.xyz/developers/guides/advanced/decode-key-metadata) for details on how to do this.

Rationale

There are some important tradeoffs we are making here that are worth calling out:

1. Attestations are not verified — the attesting fid claims that it has verified that the receiving fid owns the account. it is up the observer to decide whether the attesting fid is trustworthy. the reason for this restriction is that most social platforms use OAuth, and there is no practical way to generate a proof (yet).

2. Attestations are not unique — the hubs do not guarantee a 1:1 mapping between an fid and an external social account. apps can solve this by ingesting the data, identifying duplicates and choosing a conflict strategy such as last write wins. the reason for this is that we plan to implement [sharding with snapchain](FIP: Introducing Ordering #193) which makes global uniquness impossible to guarantee.

3. Attestations are strongly typed — we considered a weakly typed approach where anyone could attest to any domain without requiring an explicit protocol change. While this adds more flexibility, we prefer a [worse is better](https://en.wikipedia.org/wiki/Worse_is_better) approach because the feature is simpler to implement, easier for apps to integrate and the majority of reputation lives in a small handful of services. there also exist alternate onchain attestations services like EAS which can be used for the long tail of attestations.

FAQ

Why not use onchain attestations like EAS?

Onchain actions are expensive, slow and often fail on mobile devices due to poor connectivity with wallets.

Why not make attestations verifiable with public signatures?
Posting a gist or tweet with a signature would create a verifiable chain of trust without needing to trust the attestor. The reason we moved away from this is that 1) the user experience is worse and 2) this does not work on all social networks that we may want to support.

Why not make attestations verifiable with zkTLS or some other zero knowledge system?

We haven’t found an easy to implement system with a good user experience (yet).

Release

Warpcast Plans

Warpcast has started verifying Twitter/X accounts and will publish them to the protocol after this feature is released. We ensure that every user has performed an OAuth to the Twitter account before publishing UserDataAdd messages with the username. We may support Github in the future but have no timeline yet.

We only plan to display attestations from Warpcast on user profiles since they can be spoofed. If you are building an app that does verified attestations reach out to @dwr.eth or @v. We are open to supporting attestations from other apps that meet some security and authentication bar.

Farcaster Plans
The release following 1.16.0 will include support for this type. After the supporting release has been shipped, Warpcast will begin publishing these messages to and consuming these messages from hubs for supported attestations from other applications.

Update

Attached a reference PR of the supporting implementation for hubs: farcasterxyz/hub-monorepo#2370

[vrypan]

Some initial thoughts.

• This is a simple solution, that is easy to implement.

• It is very restrictive. We have other use cases that these attestations could solve, for example connecting a user to a domain or a site.
  I feel that a new CRDT with deltas that describe "fid controls url " could open the way to many more use cases, without the need to update the protocol every time.

Also, who keeps track of the attestation validity? I linked my company's twitter account to my FID, now the company changed owner and they claim the twitter handle using their FID. Who will keep track of the changes and invalidate my old attestation?

Also: I can change my twitter handle. What happens then?

[varunsrin]

It is very restrictive

The FIP contains an argument for why starting simple is better, and I've also restated it here: https://warpcast.com/v/0x66dd1c2e

Also, who keeps track of the attestation validity? I linked my company's twitter account to my FID, now the company changed owner and they claim the twitter handle using their FID. Who will keep track of the changes and invalidate my old attestation?

The FIP contains an explanation of why this is not possible to implement at the protocol level, and what we recommend applications do. See "Attestations are not unique".

Also: I can change my twitter handle. What happens then?

The FIP does not make any recommendations on how this handled across all social attestations since different platforms have different ways of validating continuing ownership.

In the Twitter case, Warpcast's OAuth integration makes it possible for us to disconnect, though this isn't implemented yet.

[vrypan]

I just stated the pros (simple, easy to implement) and cons (restrictive).

I'm 100% in favor of expanding the usefulness of Farcaster profiles, and I believe there is a lot of value in doing so.

I won't argue strongly against it, but I see a pattern: Let's add a location type. Let's add a Twitter type. Let's add a Github type, and if needed, we will also add a Linkedin type and an Instagram type, etc. I believe the pattern hints towards a broad data type/structure that can cover any of these needs, and more in the future.

[stephancill]

Would have expected social attestations to make use of the verification message type. Is there a reason why this isn’t the case?

[varunsrin]

There are a few reasons:

1. Verifications are self verifying - they contain an actual cryptographic proof that can be used to prove the claim. attestations rely on trust because it is not possible (or practical) to create a claim and are conceptually different

2. Social attestations are typically 1:1 - for wallets it makes sense that you need a data structure that maps multiple wallets to users. but if you look at linktree which is the closest proxy to a social directly, most people just want a 1:1 mapping for each type.

3. CRDT limit interactions will be weird - if you connect too many wallets, your twitter verification will be lost. this is sort of a hard to explain behavior that doesn't make sense to users.

4. Verifications have global uniqueness, which we can no longer support - with the migration to snapchain we have to rework verifications since sharding makes it impossible to do global verifications.

[davidfurlong]

Am I understanding this right

Farcaster social attestations will work by clients posting unproven social attestation claims to the network, and clients will choose the other clients that they trust these attestations from.

Seems reasonable and simple as a v1, but potentially a mess long term if Farcaster is to become truly multi client. But I suppose additional actual verifications can follow in the protocol later

[vrypan]

Why would it be a mess? I know that FID=111111111111 provides reliable attestations for Github and my app trusts them if they are signed by it. It doesn't have to be my app. Similarly, if I create a service that lets users create an twitter attestation, and Warpcast trusts my service, they will use my service's attestations too.

[davidfurlong]

which fids should one trust? As a new builder how do you know which apps are trustworthy? You either use some whitelist ruled by some benevolent dictator or ignore non-Warpcast ones altogether. What if apps publish contradictory attestations? What's the risk of trusting potentially false attestations? People could press phishing links shared by falsely attested profiles, so apps may opt to be very conservative and not trust non Warpcast attestations altogether.

As a user, my connected profiles are now shown to me to be different in each Farcaster app I use. If I connect my X in supercast, it's not the same as connecting my X in warpcast. How is this communicated to the user?

This system works well if it's really just Warpcast that is universally trusted, but is rather confusing otherwise

[varunsrin]

It would be ideal to have an actual verification but this isn't practical for two reasons covered in the FAQ. See "Why not make attestations verifiable with public signatures?" and "Why not make attestations verifiable with zkTLS or some other zero knowledge system?"

Until verifications become practical, we will have to make do with attestations which have all the downsides you described. However, I think that's better than doing nothing.

[andrei0x309]

Why not link some external service like https://passport.gitcoin.co that does this for a while, and it also publishes the proofs, I guess in the long term the only issue is that a service like this might disappear.

But from UX perspective, it would be much better to use a service like this that has existed for a while.

[varunsrin]

Two reasons:

1. The user experience on mobile would be so horrific that no one but the most determined people would ever bother to do it. Not a fault of Gitcoin, just all the papercuts imposed by mobile OSes and wallet connect protocols are terrible today.

2. Gitcoin doesn't support appear to support X verifications, which are (in my opinion) the most useful ones for Farcaster today.

[andrei0x309]

It is true that Gitcoin doesn't have Twitter anymore, but it was one of the first verifications, which was found to be the most useless that's why it was deleted.

Twitter accounts are one of the cheapest accounts to buy, most scammers buy accounts with 50k plus followers, and they are cheaper than 50$. An account with 1k costs cents on the dollar.

Plus the idea of attestation is not just do one click and then you're done, in mobile you'll have a browser link. I mean if you are not willing to do the work to get the attestation is ts that even an attestation?

I think it's confusing here if we just want people to add their socials, then the title of the discussion should be different, there are many services that allow you to do that just add your socials with no verification.

So it really depends on your goal Gitcoin pass and other solutions similar are mostly for Sibyl and attestations, if you're looking just to add data, then no verification is required and any such solution is not optimal.

Most stats indicate that at least ~20/100 of Twitter accounts are fake, the number of fake accounts is astonishing, most projects that I know that had used Twitter as a means of gating failed strong, I have around 20 accounts just to test stuff, don't understand how anybody can think Twitter is a good attestation of humanity by any means...

[davidfurlong]

which was found to be the most useless that's why it was deleted.

gitcoin passport used X accounts to prove humanity, farcaster would use X to enable richer social context on users. these are not the same

[andrei0x309]

That's why I said depends on what your goals are, IMO longer term Sybil resistance and attestation is better because is just a larger domain, which also includes richer context.

Richer contexts are a subdomain of scores and attestations.

[varunsrin]

Twitter signals (account age, following etc) are actually pretty strongly predictive of spam on farcaster

We have already sampled 10,000 via warpcasts Twitter integration and the results are promising

[CharmedChris]

This would be more powerful using EAS and likely would be adopted by the Optimism Collective, even if it was off chain EAS and the user had the option to put it onchain using a 3rd party tool at their own expense.

That said I’m OK with this approach and think 3rd party tools that convert to EAS are possible anyway. I would be excited to see this version in production sooner rather than later.

[slavik0329]

Attestations with EAS don't have to be onchain. They can be made completely offchain with no gas

[alexpaden]

I would like to use LinkedIn data, and do these attestations include verified company badges from X

[varunsrin]

they don't as of now, but that would be useful to have if they make it available over the apis.

[darkcalm]

From a business owner: can this potentially expand to attesting ownership of an @acme.com email with a flow similar to sign-in with email?

[varunsrin]

yes, i think organizational attestations would be a great extension.