# FIP: Social Attestations

Source: https://github.com/farcasterxyz/protocol/discussions/199
Kiwi News: https://news.kiwistand.com/stories/FIP-Social-Attestations?index=0x6710dd6349e4e8d2b2437c0b9f61bc7daa6e3c37b743ac04ce36125ac8b95821d79ba573
Submitted by macbudkowski.eth on 2024-10-17 UTC, 4 upvotes, 2 comments

## Summary

Farcaster's proposed FIP would let users verify Github and Twitter/X accounts through a social attestation system, with a standard extensible to other platforms later. An app such as Warpcast would verify ownership via OAuth and publish a UserDataAdd message of the matching type, signed by an app key registered to the app's fid. The proposal states that attestations are not verified by the protocol, not unique per fid, and strongly typed, and that Warpcast plans to display its attestations only on user profiles because they can be spoofed. Warpcast has begun verifying Twitter/X accounts, with Github support possible later and no timeline set.

## Article

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:

Alice tells Warpcast she wants to verify her Github account

Alice completes an OAuth flow inside Warpcast, which has now verified her ownership

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:

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).

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.

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

## Comments

**macbudkowski.eth**: "Why not use onchain attestations like EAS?

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

💀

**tim**: > 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.

This is actually what would be really interesting and the proper technical solution but, of course, nobody is willing to make the investment to actually build this