androidsixteen on Warpcast

Dan Romero pfp

"SIWF is actually Sign in with Warpcast" 1. The AuthKit library is open source -- anyone is free to fork it and make it work with their client. https://docs.farcaster.xyz/auth-kit/ 2. The long term goal is to make it work with any "Farcaster wallet", i.e. apps that can handle all the Farcaster-specific signatures and transactions for using the onchain / Hub identity system. 3. SIWF is currently an extension of SIWE (Sign in with Ethereum). This means you need to sign in with your Farcaster custody address / private key -- which for the vast majority of users is stored on their phone with Warpcast (many in a Passkey). 4. We opted for the pragmatic v1 where it works reasonably well (still some improvements on QR code) for most people in a more human readable way around permissions than a normal SIWE signature. 5. We will eventually add make it support multiple Farcaster wallets, but there hasn't been much demand from users and devs have preferred us to focus on growth.

23 replies

23 recasts

137 reactions

androidsixteen pfp

@androidsixteen.eth

I don't think anyone doubts that y'all are building this in good faith or that the initial centralization is just pragmatism (product led protocols, etc) But calling it SIWF when it's currently SIWW leads to lost nuance and inflated expectations (eg. cast quoted) https://warpcast.com/balajis.eth/0xdfcfcafd

1 reply

0 recast

0 reaction

Dan Romero pfp

See point 1. Any client is free to implement the core part of the standard and convince other apps to use it. It works for any Farcaster app that wants to do the work.

1 reply

0 recast

0 reaction

androidsixteen pfp

@androidsixteen.eth

I don't want to shift my liveness risk to another counterparty, I want to avoid liveness risk entirely I know y'all are going to get there, but #1 isn't sufficient to address the current risks

1 reply

0 recast

1 reaction

Dan Romero pfp

Not sure I understand?

1 reply

0 recast

0 reaction

androidsixteen pfp

@androidsixteen.eth

Maybe I misunderstood, but my concern is with the trusted relay If another client implements the SIWF flow, I think they have two options: 1) use the existing trusted relay (run by MM?) 2) spin up their own trusted relay In the case of 1, I'm still trusting MM/Warpcast. In the case of 2, I'm now trusting the new counterparty Did I get this right? Also, FYI this is 404'ing: https://docs.farcaster.xyz/auth-kit/introduction

1 reply

0 recast

0 reaction

Dan Romero pfp

What are you worried about re: trust in this scenario? You trust Warpcast with your Farcaster custody address / private key and a signer (EdDSA key)? If you don't trust the core team while the protocol is still nascent, why use the protocol?

1 reply

0 recast

0 reaction

androidsixteen pfp

@androidsixteen.eth

1) The end user trusting your client to custody and write messages to the hub 2) The app dev trusting Merkle to proxy messages for authentication with high availability These are two distinct “customers” each with a different relationship to Warpcast. Doesn’t make sense to conflate the two Your users may trust you, but we’re trying to figure out how to get more devs to use SIWF, which requires considering a different audience

2 replies

0 recast

0 reaction

androidsixteen pfp

@androidsixteen.eth

SIWE has two properties that make it better than SIWF currently: - bigger tam - less centralization The only argument I’ve gotten for using SIWF is that: - it’s better for mobile You guys are already growing tam, hence the discussion around how to reduce trust to bring SIWF to parity

1 reply

0 recast

0 reaction

Dan Romero pfp

If you're talking about building experiences for normal users, this is significantly more important than centralization / decentralization. The only argument I’ve gotten for using SIWF is that: - it’s better for mobile

1 reply

0 recast

0 reaction

androidsixteen pfp

@androidsixteen.eth

Why is it mutually exclusive? The opportunity cost seems fairly low, and @deodad already had a comment on the FIP around letting hubs relay Additionally, one of your pillars is "grow with crypto". The crypto mobile experience sucks regardless of what Warpcast does, and we're not getting normie app devs any time soon. So might as well target crypto app developers that are accustomed to asking adversarial questions. Otherwise your app dev TAM is basically some subset of Farcaster users

2 replies

0 recast

0 reaction

Dan Romero pfp

> cost seems fairly low Requires context as to what other relative priorities are? > So might as well target crypto app developers that are accustomed to asking adversarial questions. Otherwise your app dev TAM is basically some subset of Farcaster users In the last 4 years, the number one thing that attracts developers is permissionless access to a growing daily active user base. Everything else is secondary.

1 reply

0 recast

0 reaction

androidsixteen pfp

@androidsixteen.eth

You're right, I don't know Merkle's priorities :) That makes sense. Again, agreed that user base size is the most important thing If you have no scope to prioritize removing the trusted relay server, that's a fine reason But it's an honest reason I'd rather use SIWE currently (in addition to the larger tam with SIWE) SIWE is a protocol SIWF is a service

0 reply

0 recast

0 reaction