FIP-11: Sign in with Farcaster

[varunsrin]

FIP-11: Sign in With Farcaster

Title: Sign in With Farcaster
Type: Standards FIP
Authors: @v, @sanjay, @deodad, @horsefacts

Abstract

A standard that allows Farcaster users to authenticate into other applications using the EIP-4361 “Sign in With Ethereum” standard. Conceptually similar to “Sign in with Google”.

Problem

A user should be able to sign in to a third-party app using a signature from their Farcaster account. In theory, this is possible since a Farcaster account is an Ethereum wallet and there are standards for producing and transmitting signatures.

In practice there are two problems:

1. Most users are on Warpcast which doesn’t have a signature request flow.
2. The most common request flows (e.g. WalletConnect) are not 100% reliable on mobile.

Specification

The proposal includes two standards:

1. A Sign in with Farcaster signature format, for producing valid signatures.
2. A Sign in with Farcaster request flow, for requesting signatures from Warpcast.

Signature Format

A user must produce an EIP-4361 Sign in With Ethereum message signed by the custody address. The message must include the following fields defined in EIP-4361:

1. REQUIRED: The statement ”Farcaster Auth”
2. REQUIRED: A chain-id equal to 10 (The ID of Optimism Mainnet)
3. REQUIRED: A reference to the signing party’s FID as a resource, with the format farcaster://fids/<fid>.

The following message is an example:

https://example.com wants you to sign in with your Ethereum account:
0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2

Farcaster Auth

URI: https://example.com/login
Version: 1
Chain ID: 10
Nonce: djyP0B2JUD8RFuI3J
Issued At: 2021-09-30T16:25:24Z
Expiration Time: 2021-09-30T16:35:24Z
Resources:
- farcaster://fids/1234

Request Flow

An app can request a signature from the Warpcast client with a deeplink and uses a trusted FC Auth Relay server to proxy the results of the request back to the app.

1. A user clicks a “Sign in with Farcaster” button on an app.
2. The app makes an API call to the FC Auth Relay to create a new channel with a secret.
3. The app displays a QR code which will open Warpcast and pass along the channel secret.
4. The user scans the QR code with the mobile device and approves the request in Warpcast.
5. Warpcast produces the signature and uploads it to the channel on the FC Auth Relay.
6. The app, which has been polling for the signature from the channel, now receives it.

Auth Relay

The Auth Relay server acts as a relay between the app the user is signing in to (requesting app) and the Farcaster wallet app producing the signature (signing app). In the current implementation, the signing app is always the Warpcast mobile app, though this can be extended easily.

The server has three API endpoints:

• Create Channel — used by requesting app to create a new channel
• Authenticate — used by the signing app to post the signature to the channel
• Status — used by the requesting app to fetch the signature from the channel

Connect

An app may call channel to request a new secret channel token, which is encoded both as a URL and as QR code that is displayable to the user. A channel lives for one hour on the connect server after which it is expired.

POST [https://connect.farcaster.xyz/v1/c](https://connect.farcaster.xyz/connect)hannel


- `siweUri` REQUIRED. SIWE message URI. 
- `domain` REQUIRED. Origin domain of app frontend.
- `nonce` OPTIONAL. Nonce to use in generated SIWE message, at least 8 alphanumeric
          characters. If a nonce is not provided, one will be generated by the 
          connect server and returned in the response.
- `notBefore` OPTIONAL. The time when the signed authentication message
              will become valid. Its value must be an ISO 8601 datetime string.
- `expirationTime` OPTIONAL. The time when the signed authentication message 
              is no longer valid. Its value must be an ISO 8601 datetime string.
- `requestId` OPTIONAL. A system-specific identifier that may be used to uniquely
               refer to the sign-in request.
- `redirectUrl` OPTIONAL. A url to redirect the user after a signature has been provided.


- Responses 


	201 CREATED	
	- `channelToken`: Connect relay channel token UUID.
	    - "3b842370-c519-4cd1-a30f-fdaece6a566"

	- `url`: Sign in With Farcaster URL to present to the user.
	    - "https://warpcast.com/~/sign-in-with-farcaster?nonce=djyP0B2JUD8RFuI3J&channelToken=3b842370-c519-4cd1-a  
	30f-fdaece6a566&domain=example.com&uri=https://example.com/login&redirectUrl=https://example.com/login"
	
	400 BAD REQUEST - Missing or invalid request params

Authenticate

A signing app (Warpcast) can call authenticate to post an SWIF signature message along with metadata about the user back to the channel to fulfill the request. The connect server does not accept signatures from non-warpcast clients, though this can be changed in the future.

POST https://connect.farcaster.xyz/v1/channel/authenticate

- Headers:
  - `Authorization: Bearer <channelToken>`
  - `X-Farcaster-Auth-Relay-Key: <authKey>`
  - `channelToken`: UUID channel identifier
  - `authKey`: API auth key

- Body JSON:
  - `{"message": "example.com wants you to sign in...", "signature": "0x113a68..77460f"}`
  - `message`: SIWE message string
  - `signature`: Hex signature
  - `fid`: User's fid 
  - `username`: Username (string)
  - `bio`: Bio for the user (string)
  - `displayName`: Display Name for the user (string)
  - `pfpUrl`: Profile picture URL


- Responses
	200 OK - Message accepted
	401 UNAUTHORIZED - Channel token does not exist or expired
	400 BAD REQUEST - Missing/invalid request params

Status

A requesting app with the channel secret can poll status to check the status of the request and fetch the SWIF signature message and metadata if submitted by the signing app.

GET https://connect.farcaster.xyz/channel/status

- Required headers:
    - `Authorization: Bearer <channelToken>`
    - `channelToken`: UUID channel identifier


- Body JSON
    - `state`'pending' | 'completed'
    - `nonce` SIWE message nonce
    - `message`. SIWE message.
    - `signature` SIWE message signature.
    - `fid` user FID
    - `username` preferred Farcaster name for the user
    - `bio` user bio
    - `displayName` user profile display name
    - `pfpUrl` user profile photo

- Responses
	200 OK - Auth pending or completed
	401 UNAUTHORIZED - Channel token does not exist or expired

Warpcast

Warpcast implements a Sign in with Farcaster approval screen which is triggered by the deeplink. When approved, it generates the signature and uploads it to the channel.

Rationale

Why not support non-Warpcast clients?

Warpcast is the only actively developed wallet client today. This design can easily be extended to support non-Warpcast clients, but doing it today carries no additional benefit and might be less robust since we’re not getting feedback from these clients about their constraints.

Why not use Wallet Connect to transport signatures?

Wallet Connect still fails occasionally on mobile devices for reasons that are not easy to divine. We made an explicit tradeoff to optimize for the user experience and use a hosted, trusted server. Wallet Connect can be adopted in the future if it becomes easier to use on mobile.

Why can’t we sign with a delegate signer?

It adds a lot of complexity for little benefit. Signatures would require a two step verification with hubs.

Why not allow sign in with verified wallet?

This adds significantly more complexity: display and select FC wallet vs non FC wallet, connecting the correct verified wallet, a rainbowkit type modal, connect to metamask/WalletConnect, then produce signature. The benefit is that it is nicer for the desktop to desktop case, but that does not seem worth the additional UI overhead. This is a nice to have worth considering in the future.

Release

Sign in with Farcaster does not require any changes to hubs or contracts. It is ready to use as of 01/12 when the Auth Relay server and Warpcast changes went live.

[Robinnnnn]

Would this allow the underlying app to cast on the user's behalf? Or simply verify they control an fid?

[varunsrin]

To cast on a user's behalf you need a signer, which already exists.

This is just to verify ownership.

[turbahn]

(Cross-posting from Warpcast)

This is great!

“The only downside is that if you have multiple wallet apps they might compete for the farcaster:// association similar to mailto://“

This will quickly become an issue IMO. Might make sense to address today as part of v1.

Second - Do you imagine this as an option in a list of wallet options, i.e you have

• Metamask
• Coinbase
• Farcaster
• WalletConnect

Or you envision it closer to an oauth service

• Sign in with Google
• Sign in with Apple
• Sign in with Farcaster

[varunsrin]

On the issue of competing for farcaster:// links, I think it's mostly a non-issue on mobile because:

1. Just like email, you probably don't want two farcaster clients for the same account (getting the same message notifications twice would be annoying)

2. If you do have multiple clients and want to use them, you could use an in-app camera to scan the QR code. That way, the user picks which app to use to open the camera (h/t to @danromero for this suggestion)

On desktop the problem is a little more annoying. Open to suggestions for fixing this on desktop.

[varunsrin]

On the "what do we envision this as" -- for this FIP, we're targeting the "Sign in with Farcaster" use case, where someone wants to verify that you own a Farcaster account.

[dylsteck]

I do agree that it's a bit more tricky on desktop. One idea could be to redirect to a webpage that lets the user choose from a list of Farcaster clients -- although ideally there could be a more native and quicker way to handle that, since I could see some friction having to go to a webpage and choose the client each time.

[turbahn]

I think what you mention in point 2 relates to sign in with Farcaster vs sign in with [app name].

You can either have it so that folks scan the QR code from the relevant app, or show multiple app names on the website to chose from. It's a bit similar to the two approaches you can take with walletConnect - show a wallet name on the desktop interface or show a genetic QR code and hope folks scan with the wallet they want to use on mobile for the specific site.

My main question I guess is whether there is an expectation that the average user will know about Farcaster vs the app they use. Meaning is it more like email (you know gmail is an email client) or more like oauth (you have no idea what technology is used to power sign in with Facebook). If I understand correctly, it sounds like it's the former?

[varunsrin]

My main question I guess is whether there is an expectation that the average user will know about Farcaster vs the app they use. Meaning is it more like email (you know gmail is an email client) or more like oauth (you have no idea what technology is used to power sign in with Facebook). If I understand correctly, it sounds like it's the former?

Email is the way we're thinking about Farcaster - an open protocol with many clients and apps, which will have their own brands and relationships to users (e.g. Gmail vs Protonmail vs Outlook)

[turbahn]

One more quick question - how are you thinking about step 3? A user decides whether they want to scan the QR code or click the deep link in the modal?

[varunsrin]

Apps should present both and let the user decide imo.

[deodad]

The message should include owner: address that matches the signer of the message rather than the FID since the FID can't be trusted. Applications will need to use the contract to resolve the FID owned by the signer. Including it in the message opens the door for bad implementations by applications who trust the FID instead of resolving it:

• FID 1 Signs In with Farcaster to App
• App trusts FID in message and creates an account for this user
• A malicious user Signs In with Farcaster to App with a message that includes FID 1 but is signed by some other EOA
• App trusts FID in message and the malicious user is signed into App as FID 1

[deodad]

Related: sessions must only be bound to the address and not the FID to properly handle transfers.

[horsefacts]

Alternative signature suggestion: use ERC-4361 (Sign in With Ethereum), with FID as a scoped resource. (We'd need to define a URI scheme for FIDs).

I prefer 712 signatures, and it's too bad that the message must read "wants you to sign in with your Ethereum account" (rather than "Farcaster account"), but this spec is pretty widely used and already anticipates a number of authentication edge cases.

Mapping from the signature proposed above to 4361:

• fid — resources
• timestamp — expiration-time, not-before
• domain — scheme, domain
• randomValue — nonce

Something like:

https://example.com wants you to sign in with your Ethereum account:
0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2

Log in with Farcaster

URI: https://example.com/login
Version: 1
Chain ID: 10
Nonce: 32891756
Issued At: 2021-09-30T16:25:24Z
Expiration Time: 2021-09-30T16:35:24Z
Not Before: 2021-09-30T16:25:24Z
Resources:
- farcaster://!1234/

[vrypan]

I would like to suggest that the farcaster:// URI scheme is defined in a separate FIP.

We need a URI scheme that will allow linking or triggering actions that is application-neutral. For example:

• If I want to link to a cast, I shouldn't have to link to a specific fc client, like Warpcast, but use something like farcaster://v1/cast/12345
• If I want to link to a farcaster user, the same
• If I want to trigger a "cast this" action (FIP-2).
• Or (in the case of this FIP), if I want to login with farcaster.

In all of the cases above, in an ideal world I would use the farcaster:// URI scheme and it would trigger the user's default fc client, much like http://, ftp:// and other protocol URI schemes work.

However, this requires there is a well-defined URI scheme that all farcaster clients can implement. I suggest we create a separate FIP to define the scheme.

[vrypan]

I opened a new fip-idea discussion on this: #123

[horsefacts]

Thank you! I agree. I'll pull some of the existing URIs used by Warpcast as examples and post over in that discussion.

[varunsrin]

great idea, thanks @vrypan

[vrypan]

I'd like to propose an alternative approach, which will require some changes at the protocol level but I think there is a chance of making the flow simpler. It may be a bad idea, but I wanted to share, just in case.

The idea is similar to "tweet this message to verify your identity", but designed to not overload hubs, and avoid creating timeline noise.

1. We introduce a new cast type (let's call it backend_cast) which is extremely ephemeral (TTL=5 minutes for example) and not intended to be presented to "user-facing" UIs like warpcaster (nothing prevents them from doing so, but normally they are not expected to do so).
2. The service that requires login-with-farcaster prepares a secret (a nonce, or something more advanced) and asks the user to post it as backend_cast. Ideally, this will be a farcaster:// URI that will open the user's farcaster client. The client can also use an optimised UX to show these types of casts when posting (ex. no editing).
3. The user posts the cast.
4. Once the cast is posted, the service reads it from a farcaster hub (or using a third party API). At this point the service knows that the specific fid that posted the cast has verified its identity.

The flow can be optimised by requiring the backend_cast to have a specific parent URL (ex: example.com/farcaster-login), to make it easy to use GetCastsByParent(CastsByParentRequest) to find them.

A side effect of such an architecture is that it can help farcaster become the messaging backbone used in other use cases too. For example, home automations triggered by backend messages signed by the home owner, that don't appear in their public timeline.

Also, the service has a proof of login which it can keep in its records where this is required by law for example: the signed cast, which can be verified at any time, even if deleted from hubs.

--
Updated the post by replacing "message" with "cast" to make it clear that this message type is 99% like a normal cast.

[vrypan]

1. Indeed, speed may be an issue.

2. Re: security. The server asks the client to visit a URI like farcaster://post/this/message/123. No one else knows the message until it is posted. At this point, yes, I could post the same message as you. However, instead of a nonce the server could use a hash of something both you and the server know like your current HTTP session id.

3. Also, regarding making the process public (not to most end users, but a malicious user will be able to "eavesdrop" for sure), it can be done in ways that a third party can't be able to connect you and the service. For example, a cast with body="sdzfjkskfjhskfhskfhsk" and parent_url="d41d8cd98f00b204e9800998ecf8427e" gives no insight on what this message is about. Even in this case however, I assume that most services will have a parent_url format that an eavesdropper may be able to identify, so yes, this is a possible issue.

4. On the plus side, in this flow hubs don't have to access arbitrary URLs (callback in step 7 of the original flow) which a) I consider a security risk b) adds complexity and c) ties us to web2 infrastructure like the DNS. As far as hubs are concerned, this is just a cast with a short TTL.

[varunsrin]

i think this approach would a great one when we need to implement things like direct casts at the protocol level, where neither participant has a canonical dns location and routing via hubs is the only reliable, decentralized way to find them.

however with apps, we can assume that they have a canonical location on DNS, which greatly simplifies the core implementation by just sticking with simple REST APIs which are going to be much easier to debug and implement. it also makes it a lot more secure by avoiding metadata leakage about what apps people are authenticating to on a globally available data stream.

[vrypan]

My bad. I misinterpreted step 6, and assumed that the hub should be able to call the callback URI (async), but it's a synchronous response.

[vrypan]

@horsefacts, @varunsrin, I heard in the recent dev call that you are facing some challenges with fc connect. Would it make sense to reconsider my proposal above?

[Aranmobinarann]

Nic

[betashop]

Hi,

I read through the discussion and I have some questions.

First, I’m trying to understand what we are solving here.

If the intent is that the user is able to sign in with ethereum and bring their Farcaster social graph with them, that’s already possible with Airstack APIs and devs are utilizing that. User signs a tx from their walket that is connected to their FC account and we are able to have their FC profile and social graph come with them. We’re finding that most users have their FC and ENS and Lens all in the same wallet that they use universally for logging in with ethereum. This alone is already useful for apps that want to leverage the social graph and identity of the user but maybe not write to hubs all the time (eg content recommendations, games, etc)

Then if user needs to also sign and send messages or follow, signors can be authorized. The current Signor flow is pretty good but could also be improved. Ideally any app that user signs up for Farcaster with could issue signors rather than having to go back to warpcast, and/or any app authorized for signors could auth another app

[vrypan]

Valid point. But I think that signing in with farcaster and be a "lighter" version of SIWE. For example, a simple way to sign in to a servcoe, even if the connected eth address is managed by a hardware wallet you don't carry with you. There are many apps that I would prefer to use a farcaster login than my ledger or metamask wallet.

[betashop]

Let’s take an example of a wordle type game that enables you to “login with Farcaster” and bring your profile with you and your social graph with you, thus able to recommend other players based on whom you follow and follows you. Maybe there’s some onchain betting or payouts in the app. You can play the entire game without writing to hubs

but then perhaps you want to show off your winning board or badges and then and only then you cast a message

I’m excited about helping spur thousands of these types of use case - that don’t try to replicate or enhance the warpcast model, rather utilize the Farcaster social graph for new use cases

[vrypan]

Personally, I'd like to be able to login to this app on my mobile, as soon as you mention it on farcaster, rather than waiting to go home, connect my ledger wallet and use SIWE. I would even prefer not using my metamask for these kind of simple account verification: having my Metameask wallet popup regularly just increases the chance I approve a malicious tx.

[betashop]

User is either going to need to sign a tx or auth via an installed Fc client. Both are valid options imo

[varunsrin]

Personally, I'd like to be able to login to this app on my mobile, as soon as you mention it on farcaster, rather than waiting to go home, connect my ledger wallet and use SIWE. I would even prefer not using my metamask for these kind of simple account verification: having my Metameask wallet popup regularly just increases the chance I approve a malicious tx.

lots of users and developers want this flexiblity that @vrypan is calling out. it would be a huge ux win to enable it.

[betashop]

Valid point. But I think that signing in with farcaster and be a "lighter" version of SIWE. For example, a simple way to sign in to a servcoe, even if the connected eth address is managed by a hardware wallet you don't carry with you. There are many apps that I would prefer to use a farcaster login than my ledger or metamask wallet.

— The data thus far (revealed preference) shows that it’s one and the same tho

[varunsrin]

If the intent is that the user is able to sign in with ethereum and bring their Farcaster social graph with them, that’s already possible with Airstack APIs and devs are utilizing that.

we'd prefer having an open standard instead of encouraging proprietary api usage for authentication of accounts.

I do think it would be nice for any FC client to be able to auth another client — thus avoiding MM or other wallets

but also not sure if it’s a real problem that needs solving

allowing users to sign in with the wallet they're using every day is an obvious ux win. the average farcaster DAU spends more time in their farcaster wallet than in their metamask wallet.

imo this should be strongly encouraged as the way -- so farcaster can connect and interoperate with the broader ethereum ecosystem rather than being an island

why would using the Sign In With Ethereum standard with an Optimism Wallet make this "an island"? if anything, encouraging L2 wallet usage seems inline with the goals of the ethereum community.

[manan19]

This enables the connected addresses to be used to represent the custody address

@betashop I'm not sure that's correct. The same address can be connected as a verification to multiple accounts.

Consider the following case - Alice can add Bob's address as a connected address to her own account for some mutual gain without Bob sharing his key with Alice. But that doesn't mean Bob should be able to claim that he's Alice.

[jasperstuffs]

just following up, is this correct? 1 address can be connected to multiple fids? @varunsrin

[varunsrin]

1 fid can be owned by only 1 address at any time.

however, that fid can verify ownership of multiple other addresses with a signed message.

[jasperstuffs]

can 2 different fid both verify ownership of the same address via signed message?

[manan19]

This design seems to be optimized for farcaster apps that have a backend.
Does the nonce really need to be generated on the backend? Does the callback URL need to be calling the domain backend?

Can a mobile app generate the nonce and link into Warpcast for the signature with a deep link back into the app as a callback url?

An approach where an app’s client sits between a farcaster wallet and the app’s backend (if the app has one) will be more approachable for developers building frontend-only apps on Farcaster

---

edit - oops, I over-indexed on the implementation diagram. looks like the redirect_uri is meant for frontend-only apps.

[horsefacts]

Yeah, you should be able to do a frontend-only flow using redirect_uri. The distinction between redirect_uri and callback_uri could be clearer above, I'll revise the language.

[manan19]

Could the app developer keep repeating steps 6 & 7 with the signature at each session launch instead of doing 8?

[manan19]

Users will likely have one wallet on a device, for the same reason that they have one email client per account on one device. It’s very annoying to get multiple notifications an reminders for the same items from different apps, and most people just train themselves to use one at a time.

notifications can be turned off.

Either we should have support for multiple wallet apps or people will need wallet with multiple accounts. 1 app, 1 wallet is very restrictive for developers that are testing all the time. Metamask doesn’t support multiple accounts after 5+ years.

Another potential solution for multiple wallets might be to build out an onchain registry for wallet developers? An onchain walletconnect if you will.

• App developers use an SDK that scans the onchain wallet registry for potential wallet providers.
• Wallet developers register their domain https://fcwallet.com on the onchain registry and handle the universal link in their app.

[varunsrin]

notifications can be turned off.

you can see usage patterns for browsers and email clients to get a good proxy for revealed preference. 99.9% of users primarily use a single client per account. no good reason to assume fc will be different.

Either we should have support for multiple wallet apps or people will need wallet with multiple accounts.

I expect the latter to become common for the reasons youve called out - there's no technical reason you can't implement a multi-account client today.

[varunsrin]

Another potential solution for multiple wallets might be to build out an onchain registry for wallet developers? An onchain walletconnect if you will.

This would definitely work, but its about 10x the complexity of the current solution, and the benefit to users is marginal.

[manan19]

What’s the best way to keep siwf and signer spec close to each other from a developer UX standpoint?

They’re basically signing in with different permissions using a farcaster wallet.

• id the user and read
• id the user, read and write

There’s a spectrum of permissions in between. Would we have other permission levels in the future?

• id, read and write reactions only
• id, read and write direct casts

[deodad]

This is a good point—whatever workflow that we come up with for SIWF should also be able to support the signer flow.

[varunsrin]

What’s the best way to keep siwf and signer spec close to each other from a developer UX standpoint?

Do you have thoughts on what you'd like to see here?

They’re basically signing in with different permissions using a farcaster wallet.

Read vs write isn't the right separation - you can always read someones data since its a permissionless public network. The two actions would be best described as:

• Auth
• Auth + Write

In the future we might separate Auth+Write into sub systems (Auth + Write Casts vs Auth + Write Reactions)

[deodad]

A critical component of the Implementation diagram is missing: the Domain Frontend obtaining an access token from Domain Backend to make authenticated requests with. I think this will be a pain point for app developers because they'll need to implement a secure mechanism to achieve this and it's not clear to me exactly what this should be.

[deodad]

Alternative proposal that would take care of ☝️ for app developers: use a hub as a relay server. The relay server would be an isolated module that doesn't interact with the core hub functions and could run in its own process. Its state would be local to a specific hub and not synced. It should also be possible for a the relay server to be run outside the hub by a server provider like Neynar.

The specific transport (i.e. Long Polling, Server Sent Events, or Websockets) would need further research, but in any case the high level flow would work like this:

1. App makes a request to a specific hub to open channel and get's back a channel id (or fully formed deep link URL)
2. App presents a sign-in link that identifies the channel `farcaster://sign-in?channel=http://nemes.farcaster.xyz/sync-channel/1234
3. FC Wallet collects signature and posts it back to the sync channel
4. App receives the message + signature payload over the channel and submits it to the backend for authorization

Channel communication would be e2e encrypted. There are other technical considerations that I'm omitting in favor of getting the basic idea and the cost + benefits down.

Benefits

• simplifies the app developer integration
  • backend becomes optional
  • backend doesn't need to track state about pending sign in requests (nonce can be stored in a cookie)
  • backend doesn't need an additional security mechanism to deliver an access token back to the client
• additional data like was the qr code scanned could be passed over the channel

Drawbacks

• additional complexity in Hubs
• hub downtime would result in failures

[vrypan]

Will this flow require higher quotas on the Ethereum RPC provider (Infura/Alchemy) for hubs?

[vrypan]

@horsefacts What will this FIP require from FIP: farcaster: URI scheme?

[vrypan]

About the name: @varunsrin said in the last team Dev Call that this will be called Farcaster Connect.

I like the term, and I would like to take it a step further, and call it Farcaster Connect 0 (FCC-0).

This will make it easy to use the same term (FCC) for all types of connection, without having to invent new terms. And it will also make it easy for users to understand the level of control they delegate.
For example:

• FCC-0: Just prove that you control a fid
• FCC-9: Approve a signer.
• FCC-11: Give your seed phrase / private key ("Up to eleven").

If we have something in between in the future, it will be easy to add it, without confusing users.

[varunsrin]

We changed it to:

Sign in with Farcaster == proof of fid
Connect to Farcaster == give permissions to your account

This is similar to what Google, Slack etc use and is terminology people are already familiar with.

[pavlovdog]

Speaking of UserDataTypes, I would like to add a signer field to it, which contains the public key of the active signer.

[payton]

Farcaster Connect channels currently build SIWE messages with FID resources formatted like "farcaster://fid/1234". However, the spec states that they are plural "farcaster://fids/1234". Can the spec be updated to reflect the current state of Farcaster Connect?

The Farcaster Connect SIWE message statement is also Farcaster Connect while this FIP states Farcaster Auth.

(cc @horsefacts)

[Ashoat]

Is there a way to get some custom string into the SIWE statement? The reason I ask is that it would be cool if we could use the SIWE statement as a "social proof" in our app. Right now, it seems like a user of a FC-login-enabled app can't independently verify that app's claims about what a user's Farcaster FID is.

[Ashoat]

Looks like we could potentially use requestId for this

[varunsrin]

The ethereum address signing the message also owns the fid onchain, which you can verify by calling the IdRegistry contract.

Would that solve your issue?

[Ashoat]

Hmm... I don't think so, but I could be missing something.

What we're trying to do: Comm users post messages using a Comm public key, so we want the Farcaster identity to sign a message attesting that it's represented by this Comm public key.

This might be achievable through some other mechanism in Farcaster though. I imagine an onchain signer would work, but our current plan is to defer that until the user wants to cast.

[ZhakkaDada315]

lfggg

[normanzb]

gm, thx for the spec!
however there are a few things caught my eyes while reading through it, thinking might be helpful posting them here:

1. The URL in the first connect example is somehow messed up, it shows POST [https://connect.farcaster.xyz/v1/c](https://connect.farcaster.xyz/connect)hannel
2. Can we use the same term consistently across the spec? Sometimes the channel token is called channel secret.
3. SIWE message URI isn't a very helpful explanation for siweUri, it requires the reader to jump to different spec to understand it, why not just paste the actual meaning over?