FIP: Farcaster Connect #204
Replies: 15 comments 39 replies
-
|
If I understand correctly, the proposed workflow looks like this:
For a better UX, can we remove step 2 and directly show users all wallet apps in the Farcaster ecosystem? Then, the channel could be created when the user scans a QR code or clicks a deeplink, similar to how Warpcast handles it today. |
Beta Was this translation helpful? Give feedback.
-
|
from the user side yes, from the server side there are more lookups and requests. Wallet app managing private key here is the signer though (app key in new wording). So yes it is a private key but not a general Ethereum Wallet Private key :D |
Beta Was this translation helpful? Give feedback.
-
I like the current approach better. If we show all users, all wallet apps, it will then result in a WalletConnect style clutter of apps that users have never heard of. |
Beta Was this translation helpful? Give feedback.
-
|
@varunsrin Adding the UX flow to the spec is a good idea though. A little fuzzy on steps 5 and 6 i.e. does the user need to pick "Supercast" and then "Desktop" to be routed properly? Do we need 2 round trips to the Connect Server? |
Beta Was this translation helpful? Give feedback.
-
|
@manan19 see this comment: #204 (reply in thread) |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
this would collide and confuse users with multiple apps. better to produce a deeplink targeted at the specific app. |
Beta Was this translation helpful? Give feedback.
-
|
+1 for the signup use-case |
Beta Was this translation helpful? Give feedback.
-
|
I personally like the idea of generic deeplinks that would give the user control over which app is opened. This is a commonly accepted use case for things like email clients, text messaging services or browsers in mobile today and let's users shortcut their own preferred app with an "always open with _" pattern. Wallets already implement this if you use wallet connect on mobile |
Beta Was this translation helpful? Give feedback.
-
the user controls what app is opened by setting their preferred client using the userdata property. once you know exactly which app a user wants, a universal link is preferrable to a protocol handler (which is what i think you mean by generic deeplink) since it has nicer fallbacks and is generally more reliable on all mobile platforms. |
Beta Was this translation helpful? Give feedback.
-
How do we go from app fid > app server > app manifest? In other words, how do apps define their manifest at the protocol level? |
Beta Was this translation helpful? Give feedback.
-
|
most likely requires an extension with a external URL to the key registry? or since an FID is attached it could be the link set in profile of that FID somehow. Likely easier and doesn't require a contract change. this would then also enable link in bio |
Beta Was this translation helpful? Give feedback.
-
|
planning to update the spec with this soon |
Beta Was this translation helpful? Give feedback.
-
|
Also interested in the details around what defines a |
Beta Was this translation helpful? Give feedback.
-
I don't quite understand this tradeoff. Can you elaborate? |
Beta Was this translation helpful? Give feedback.
-
|
You never know what Ethereum wallet a user may be using, so you always have to show a wallet picker page. You may know (in the majority of cases) exactly what Farcaster wallet someone is using because they have a single app key. In that case, you can just skip the "choose your wallet" step entirely. You may also be able to skip the choose your platform step similarly if this wallet is only available on a specific platform. So it may be as nice as a "type in username" -> "click to connect" |
Beta Was this translation helpful? Give feedback.
-
|
this looks great! 1)
Where is the threshold between the SDK provided by Farcaster and the implementation for each client. I'm happy to provide an open-source solution for clients, but unclear how to scope this yet. |
Beta Was this translation helpful? Give feedback.
-
|
we might just provide a public good at connect.farcaster.xyz that anyone can use per @davidfurlong's suggestion |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Will there be a mapping of App Fid => Application ? Who will own that translation? For example, there is a new client MemeCast with an embedded IOS/Android app, I assume we would route the request to the MemeCast app for approval? |
Beta Was this translation helpful? Give feedback.
-
|
app fid is implicitly mapped to application. if you create a new client you can just create a new fid. |
Beta Was this translation helpful? Give feedback.
-
|
@varunsrin .. But when you deep link to mobile how would you know which app to route that request to that client? |
Beta Was this translation helpful? Give feedback.
-
|
the current proposal is to simply look at the user's app keys. each app the user users must register an app key, which is mapped back to the app's fid onchain in the KeyRegistry. there's another idea someone suggested which is to more explicitly define it in the UserData. |
Beta Was this translation helpful? Give feedback.
-
|
On the topic of using the Key Registry to find the list of preferred applications, why go this route versus doing it in user data on the protocol? If it is assumed that an app already has access to a user's signer, the lift to send a message is much lower than hosting a Viability of a userdata approach also depends on the answers in this question as I understand an app with 100,000 users that share a single signing key would then need to submit 100,000 user data messages to the protocol to update the homepage. |
Beta Was this translation helpful? Give feedback.
-
|
The main benefit of the KeyRegistry approach is that the data is already there onchain and requires no additional work from apps. The nice thing about your UserData proposal is that apps can declare if they have the custody address or not, and if they are honest then we can easily it narrow it down to one app, and eliminate a screen. |
Beta Was this translation helpful? Give feedback.
-
My understanding is that the goal here is:
The KeyRegistry does not have any additional metadata about the app it originated from (unless I misunderstood), so how would this involve no additional work? |
Beta Was this translation helpful? Give feedback.
-
On that note, you have
|
Beta Was this translation helpful? Give feedback.
-
|
it's probably fine to have a userdata type and just restrict it so that the app it claims to be from must sign it |
Beta Was this translation helpful? Give feedback.
-
|
@varunsrin The Frames v2 FIP is very exciting. What about using Frames to implement Farcaster Connect? If the "Farcaster Connect" button had a way to open a specific frame in my Farcaster client, then it's easy to authenticate, right? |
Beta Was this translation helpful? Give feedback.
-
|
the goal is to make FC Connect work inside of frames v2. needs some prototyping to validate. |
Beta Was this translation helpful? Give feedback.
-
|
Any particular reason why it doesn't just login through an embedded browser popup to That would avoid the need for the user to fill out their name for every new app, as it could be stored client side on that domain/autofilled. |
Beta Was this translation helpful? Give feedback.
-
|
good suggestion |
Beta Was this translation helpful? Give feedback.
-
|
How could we add a way for apps (not the Farcaster client) to sponsor account creation during this flow? Farcaster Connect + Notifications can be the easiest way to implement authentication. No passwords, no emails, everything a site needs to authenticate and build a "relationship" with a user is included. The only problem is Farcaster user base. What if we made it easy for the app (site) to sponsor account creation? |
Beta Was this translation helpful? Give feedback.
-
|
that's a good idea, but it might be worth doing as a follow on fip. i think the work there is significant and also cleanly separated from this. |
Beta Was this translation helpful? Give feedback.
-
|
Another version of this proposal is to do the above, but also shift the auth signature from the custody address to the app key. Users would be able to generate two kinds of app keys. Level 1 would let an app write messages on behalf of the user while Level 2 would let an app write messages and sign in to other apps on behalf of the user. The main benefit is that authentication into frames is simpler, because the app can just provide the signed token without needing to prompt the user. The other benefit is that users can have multiple apps that can log them in without giving them control over the seed phrase. The downside is that the security model changes considerably. Instead of each action being authorized by a wallet which is often user controlled, it is now authorized by an app key which is often app controlled. Users need to be careful about which apps they give level 2 permissions to, and a compromise of a level 2 app will be difficult to recover from since there is no easy way for the app to revoke all the keys if it gets popped. We will also need all apps to re-request a level 2 key which requires an onchain transaction. There are plans to make this a snapchain level operation that requires no fees, but that may take a few months. |
Beta Was this translation helpful? Give feedback.
-
|
Putting the various options we have here in one place: Custody AuthAs proposed above in the specification. Pros
Cons
App Key AuthA new type of app key is introduced (Type 2) which can provide login credentials and Farcaster Connect / SIWF uses this signature for auth as described in the parent post. The custody signature is no longer used. Pros
Cons
Custody + App Key AuthWe do not introduce a new kind of app key but we allow both kinds of auth. The default will be custody auth but frames can optionally ask for app key auth instead, which can be done in the background without UI. Pros
Cons
|
Beta Was this translation helpful? Give feedback.
-
|
My mind has a very hard time dealing with the terms. For some reason "connect", "sign in", "authenticate", etc get confused :-( Trying to lay out what we have today:
Right now, in theory, a third party service can ask an other app for the following levels of authentication:
V, help me understand where Type2 keys fit in this. Are they App Keys that the user has explicitly stated that they can be used in other apps, other than Farcaster? Are Type2 keys considered more or less critical than Type1 keys? ("It's ok to login with this in a casual app, but not Farcaster!" vs "You can use Farcaster with this key, but also use it in more critical apps"?) The way I see it, it is up to the service to decide what level of proof they need. The "claim this POAP" service may be fine with just a simple proof of identity, while a "note-taking" service may require a stronger proof. What are we trying to solve? |
Beta Was this translation helpful? Give feedback.
-
|
i've updated the spec with the latest thinking on this. we're proposing custody keys for authentication, see the rationale section for details on why app keys can be used to cast but not authenticate the user. |
Beta Was this translation helpful? Give feedback.
-
|
on the tech side, i don't have anything to add what hasn't been asked in the commends |
Beta Was this translation helpful? Give feedback.
-
|
A few thoughts: 1 Renaming to Farcaster Connect sounds great to avoid confusion In clear wallet https://github.com/andrei0x309/clear-wallet I had for many months SWIF working as it's now I'll probably add farcaster connect if that is implemented, also wallet is listed on many well-known websites like ethereum.org, alchemy and wallet connect/reown. The best follow is always one that shows a QR and a link that is copiable, it is standard and I think it creates the least amount of confusion. |
Beta Was this translation helpful? Give feedback.
-
This is incorrect, no part of this specification relies on the Warpcast app. The only dependency is an open source relay server, similar to Wallet Connect. |
Beta Was this translation helpful? Give feedback.
-
Are 100/100 you sure it's incorrect? How can a QR or deep link be captured/handled by any app on mobile, other than Warpcast? At the mobile OS level only links that do not contain a domain, can be handled by any app. If the mechanism requires links that include I think the spec is overall complicated and not super well thought out, it doesn't seem standard and I would not agree that is similar at all with Wallet Connect, Wallect connect uses I don't think this should be rushed, bringing in some people who have done this before might be a very beneficial idea, a mistake here is critical, and can't be easily reverted later. |
Beta Was this translation helpful? Give feedback.
-
|
If got this right, the idea is that the relay server generates an app-specific deep link, after the user has picked their preferred Farcaster wallet. |
Beta Was this translation helpful? Give feedback.
-
vrypan is correct on this one. it's a simple, decentralized system where a user chooses the app they want, the apps define how their universal link should be produced, and the relay generates the universal link.
if wallet connect worked reliably on mobile, we would happily use wallet connect and not try to build our own solution. in our testing, we observed > a 50% failure rate across different wallets. if they fix this in the future, we should probably just deprecate FC Connect and align on WC. but for the time being, its unacceptable to show our users something that fails half the time. |
Beta Was this translation helpful? Give feedback.
-
|
The issue with creating a custom link before is that it involves many unnecessary steps. Wallet connect issues do not come from links, an agnostic link and a domain link are handled exactly the same on the mobile the only difference is that the domain link can't be used by multiple apps. Probably wallet connect issues come from websocket relay issues, caching invalidation, wallet implementation, and not at all from handling the link. Having fixed non-domain links cuts a lot of unnecessary steps from processes that can create bugs, and does not require additional steps, in defining specific apps or a database of apps or anything like that which improves decentralization. How can a user choose an app without a DB of apps? If a DB of apps exists this system is highly centralized, if the DB selection is defined by the app, and does not come from a centralized DB but from the client that presents the selection that is better but still, the properest form of decentralization is to have the fixed universal links that can be handled by any app that declares they can handle them. Selection of the app should be done at the OS level not prior at the client level. Again I don't know where the idea that links are the root of WC issues, is because that is not at all the case, I don't see any advantage of defining custom links every time instead of having a fixed link protocol. |
Beta Was this translation helpful? Give feedback.
-
|
As a general thought I think the relay's url specified in the implementation should not be limited to |
Beta Was this translation helpful? Give feedback.
-
|
agreed, the spec doesn't require that you use the connect.farcaster.xyz ui and relay, just defines them as the most convenient path. in theory, anyone can fork the relay repo and run their own version at a different url. |
Beta Was this translation helpful? Give feedback.
-
|
Yep, just wanted to be sure people coming to the finalized docs that might be new would read it that way or knew that it was possible. Also in the last part about the Mobile Wallet Protocol, it says Coinbase wallet and Metamask, but should it say Coinbase wallet and Rainbow? May just be a typo but I thought those were the two that currently supported the protocol |
Beta Was this translation helpful? Give feedback.
-
|
A nice side-effect of a commonly used relay is users will not have to enter their username every time. The relay can set a cookie with the username, and auto-fill it next time you visit. |
Beta Was this translation helpful? Give feedback.
-
|
The relay is a very interesting infrastructure piece. We could easily extend it to work outside this specific flow. For example, connect.farcaster.xyz/?to=myFrameUrl to generate a deep link for my preferred farcaster client that will open a specific frame. In this case, a web page could provide a link that would cause the browser to open the page inside a Farcaster client and let me take advantage of Frames v2 functionality. |
Beta Was this translation helpful? Give feedback.
-
|
The way I read it was that once the two clients establish a channel between each other (facilitated by the relay) then you could potentially add more features like this that didn't rely on the relay, using the universal links possibly? |
Beta Was this translation helpful? Give feedback.
-
FIP: Farcaster Connect
Title: Farcaster Connect
Type: Implementation FIP
Authors: @v, @dwr.eth, @horsefacts.eth
Acknowledgements: @df, @payton
Abstract
Update Sign in with Farcaster (FIP-11) to work with any wallet and rename it to Farcaster Connect to avoid confusion.
Problem
Users can sign into apps with their Farcaster account by signing a SIWE message from the wallet that holds their account. Negotiating this signature requires a connection protocol to link the requesting app and the signing app or wallet, which may be on different devices. Existing Ethereum protocols do not support mobile or have high failure rates leading to a bad user experience.
Farcaster solved this by introducing SIWF or FIP-11 which is a connection protocol to request SIWE signatures using a relay. This results in a significantly better user experience but the current design assumes that the signing app is always Warpcast.
Specification
SIWF (FIP-11) is extended to support signing request to any app that holds the user's custody address. It is renamed to Farcaster Connect to make it clear that it is a protocol for passing around SIWE signatures between apps, and not an alternative to SIWE.
FC Connect uses a relay server which establishes a secure channel between the requesting app and the signing app. The main changes we propose are:
connect.farcaster.xyz. The relay offers an optional frontend that requesting apps can use to complete the entire connect flow.The happy path works like this:
connect.farcaster.xyzfrom the relay server.If the user does not have the UserData set correctly, the relay should look up the user's installed apps from a list and provide one. If there is no installed app or if the app fails to produce the correct signature, the relay should return a generic list of popular apps or encourage the user to set this value.
Linking Action
The linking action is a mechanism to open the signing app and pass the channel id secret to it. The signing app can then ask the user to approve the signature and return it over the channel. The mechanism of the action depends on the platform of the requesting app and the signing app as shown below:
Mobile > Mobile: universal link with channel id is returned and invoked
Desktop > Mobile: QR code with universal link with channel id is displayed
Desktop > Desktop: link with channel id is displayed for user to click on, channel id is also exposed to copy paste
Mobile > Desktop: same as above
UserData
TBD. UserData should include the domain of the application and possibly also the platform(s) supported.
FC Connect Manifest
TBD. Manifest should include metadata on platforms supported and how to construct deeplinks with the channel secret.
connect.farcaster.xyz
TBD. The connect app should be open sourced, served from the relay and show how authentication works.
Tradeoffs
Relay is a single point of failure. If the relay goes down or blocks a user, they will be unable to use FC connect. This is mitigated by offering an open source version of the relay that can be self hosted.
Requests are visible to the relay. Connect requests can be made private by making the UserData request client side and blinding the server to the user. This requires significant work and can be considered in a future update.
Signing app must have a backend service to talk to the relay. This is necessary so that a path can easily be established from the requesting app to the signing app at all times.
Open Questions
Rationale
Why is it necessary to input the username?
If you ask for the username you can identify the app they use to store their custody address, and the platform that it lives on. In the best case, this lets us produce a deeplink or QR code straight into that app that works 100% of the time. Without this, you would have to show a user the list of all possible apps and have them choose one. As the number of apps grows, this gets tedious.
Why use universal links instead of using a general protocol handler (fc://)?
Once you determine the app a user is using, the best ways to link into the app are QR code (desktop > mobile), universal link (mobile > mobile) and regular link (mobile > web, web > web). Protocol handlers on mobile are more failure prone and have a worse UX than their counterparts. They are are necessary in a world where you cannot determine what app a user is using, but the Key Registry solves this problem.
Why not use app keys to let multiple apps use FC Connect simultaneously?
App keys can be modified to let the app sign in as the user. Many apps could simultaneously offer Sign in with Farcaster support without the custody address, which is a benefit for authenticating into frames. The issue is that a malicious or compromised app could sign in as the user, and services like Privy which use FC Connect / SIWF today would not be able to rely on it for secure auth. It would also diverge from the Ethereum SIWE standard and lose many of the benefits of composability.
Why not use Wallet Connect?
This works reasonably well for desktop > desktop, but has a high failure rate when mobile platforms are thrown into the mix. Since most Farcaster users are on mobile, which is unusual in crypto, this solution does not work for us. We hope that WC improves over time and that we can deprecate the FC Connect standard in the future.
Why not use Mobile Wallet Protocol for mobile > mobile cases?
It's only supported by Coinbase and Rainbow wallets today.
Release
TBD
Beta Was this translation helpful? Give feedback.
All reactions