Content
@
https://opensea.io/collection/dev-21
0 reply
0 recast
2 reactions
Stephan
@stephancill
It is a bit baffling to me that devs are so willing to outsource key components of their app like auth to third parties that have 0 interoperability Rolling your own auth is not hard nor dangerous today - there are tons of frameworks that give you the exact same devex without the vendor lockin
7 replies
2 recasts
24 reactions
Andrei O.
@andrei0x309
Exactly, that's why I was so disappointed when I saw Warpcast using Privy for the wallet and other authentication needs. They already used a wallet library because you imported the private key, and on top of that, they added Privy. It looked super unprofessional. Warpcast's wallet should have been implemented with the internal wallet library they used. For me, this was akin to something like Facebook using Google authentication as their main implementation. Rule number one for any company that wants to be considered a social network: never use third-party authentication and security systems.
3 replies
0 recast
2 reactions
Stephan
@stephancill
i think there is a credible argument to be made that they are focused on innovating on transaction ux, not wallet infra. the fid recovery flow would not work with EOAs, so privy's key sharding tech is a useful compliment i'm not aware of them using privy for authentication - can you share more?
2 replies
0 recast
0 reaction
Dan Romero
@dwr.eth
We don’t. We use Sign in with Farcaster.
1 reply
0 recast
2 reactions
Andrei O.
@andrei0x309
No, you use eip191 sign from custody wallet for generating auth token. That's the way it has been even SIWF, and SIWF is just practically a SIWE with another name, nothing different than also having FID in the signed message. But that doesn't matter much anyway, what matters is that Warpcast wallet IMO should have been implemented with the existing wallet library in the app not with a third party provider.
1 reply
0 recast
0 reaction
Dan Romero
@dwr.eth
> But that doesn't matter much anyway, what matters is that Warpcast wallet IMO should have been implemented with the existing wallet library in the app not with a third party provider. Good luck building a consumer-grade experience without seamless recovery.
1 reply
0 recast
1 reaction
Andrei O.
@andrei0x309
I respect your opinion, it might be true but in the long run this can bite. Nobody stops anyone to add any kind of recovery to a implementation of a wallet. You already allow PK export from both custody address and warplet address, which means if PK is compromised you can't do recovery. Seamless recovery makes a lot of sense when you custody the account sure but it has little value when primary recovery is wallet export. It already has some drawbacks, for example people that want to use the custody address in warplet and mini apps can't, and they need to either use CB or Rainbow as preferred wallet If warplet would have been made with the app library that would not have been a issue. Using the internal library had no limitations it just would have costed more resources.
1 reply
0 recast
0 reaction
Dan Romero
@dwr.eth
We've done 57,557 recoveries of the FID (which is the root wallet controlling the Warpcast Wallet).
1 reply
1 recast
1 reaction
Andrei O.
@andrei0x309
That's exactly my point that it would have been better to implement everything with the library inside the app instead of privy. Like I said before using, the library instead of privy for implementing had no major drawback it would have been better in all scenarios, the only drawback is cost and resources of implementing things that you can import from a third party provider but overall would have been much better especially in the long run.
1 reply
0 recast
0 reaction
