artlu 🎩 on Farcaster

Content pfp

https://warpcast.com/~/channel/fc-updates

0 reply

0 recast

0 reaction

Varun Srinivasan pfp

Varun Srinivasan

FIP: Direct Casts A proposal to make Warpcast's Direct Casts an open standard that any Farcaster client can use. https://github.com/farcasterxyz/protocol/discussions/226

6 replies

16 recasts

144 reactions

KMac pfp

This is a bad idea to take on right now. Would shelf this entire idea in favor of other priorities. Full stop. But wait there’s more. Who is ‘Farcaster’ that is operating the server? gc & smh all at the same time. Protocols are rules not organizations. Conflating these leads one to think like a business instead of a headless public good. More gatekeeping‽ really Keep it as wc direct and group casts. Open that if you want but keep it out of Farcaster protocol if it’s not on a node, permissionless & independently verifiable. An idea- Work on creating more flexible app specific context-containers that are ai ready.

1 reply

0 recast

10 reactions

Andrei O. pfp

Gatekeeping is maximal because if you didn't check there's a whitelist like we are used to, so it's much worse than a centralized server, as per usual devs will need to request permission from the team not even in an automated way. I mean I am just astonished by the lack of foresight, imagine if you want to get permission to read/send DMs on Twitter, Threads, etc is easier. You can literally make an app in 5 minutes that has those permissions, how blind you must be to understand that writing such poor proposals is a complete disaster from an optics perspective.

1 reply

0 recast

1 reaction

KMac pfp

Devs gonna dev 🤷🏻‍♂️

1 reply

0 recast

1 reaction

KMac pfp

More seriously, this is likely the direct result of corporate control of a public good. This ‘working code’ ‘general consensus’ BDFL thing is now probably the last thing I’m concerned about in Farcasterland. The rest they’ve delivered on promises. Keep the dc/gc ‘protocol as MerkleM’s if you want but stop bloating Farcaster.

1 reply

1 recast

1 reaction

Andrei O. pfp

Correct, that is how it looks from the outside, building in the open was always only after, many people complained. There's no interest in building in the open, if you do a `find whitelist` command over all proprietary code that the Farcaster team drives I am sure you'll get like 50+ hits... Not trying to be cynical but for me, it seems like the main interest is to appear to be open while trying to retain as much control as possible without suffering too much backlash, that's why there is so much promotion of "openness", if you're open you don't need to promote that, because is just a fact.

1 reply

0 recast

1 reaction

artlu 🎩 pfp

isn't this needed for the Coinbase Wallet client to hook into?

2 replies

0 recast

2 reactions

KMac pfp

It’s a good question & had crossed my mind when I saw Jesse had liked my reply.

1 reply

0 recast

2 reactions

Andrei O. pfp

The whitelist is based on the "app" that needs access to DCs not on the wallet, so the wallet in theory won't matter, when doing a signature you can't do it from anywhere. At this stage of the proposal is not clear how a whitelist can be enforced, SWIF in V1 is also technically limited only to Warpcast but you can spoof it using the Warpcast infrastructure and pass it with any wallet, people(over 300+) have been able to do SWIF with Clear Wallet for many months, so, in the end, whitelist might be even ineffective against spoofing anyway. Like with the mini-apps before there was also a whitelist, but that was enforceable with domain, though in some cases like Paragraph enforceability also depended on all whitelisted domains if a single domain didn't do the validation correctly it could have been hijacked, that's exactly what I did with Paragraph that had improper validation and anyone could have used their whitelist to inject any content they wanted.

0 reply

0 recast

2 reactions