df on Warpcast

Content pfp

0 reply

20 recasts

20 reactions

df pfp

The Farcaster protocol does very little today in the way of solving conflicts or UX problems around multiple competing clients; which, one might expect, is the hard & important thing to solve in a social protocol. Farcaster is being controlled & governed by the 99% client (Warpcast), repeatedly making choices that limit the ability of alternate clients to build and compete (See SIWF, Messaging, Channels). As a builder, it's unclear why Farcaster is not any different from early Twitter, which was open, had alt clients, but one overwhelmingly dominant client. Once Twitter became big enough, it shifted from attracting to extracting, and shut down their API, becoming the Twitter of today, ruled by a benevolent dictator. Is Farcaster/Warpcast just running back the Twitter playbook? Why should we users and builders trust Warpcast's continued benevolence, when their short term choices are already showing a willingness to compromise on the Protocol part in the name of monoclient growth?

13 replies

37 recasts

81 reactions

rish pfp

sorry decentralized hubs and onchain identities are not the same as twitter APIs Yes there are some things that aren't on the protocol yet but that's not the same as saying the whole thing is centralized and can be pulled away like Twitter seems to be written overly dramatic in one direction to create a conversation maybe? not sure

2 replies

1 recast

4 reactions

df pfp

I didn‘t say the whole thing is centralized. I said that its ruggable. Given the long history of platforms rugging developers and MM backpedaling on the protocol I think it’s entirely fair concern.

2 replies

0 recast

9 reactions

rish pfp

what's the rug scenario when there are thousands of independent hubs and fids are on optimism?

2 replies

0 recast

1 reaction

christopher pfp

But you can just fork the hubs and contracts and keep the social graph you already have?

1 reply

0 recast

0 reaction