Farcaster isn’t a true protocol

Just enough theater to get developers' trust

I like running, poker and oysters | Founder, Social Forensics (SocialForensics.com) | Berkeley & UPenn | Learning to listen

Say more? 

What's a true protocol and why farcaster isn't one?

+ only one server by only one company, no node diversity
+ majority client has non-open features
+ regular proto changes, non stable
+ all major changes come from one central actor

it's a protocol by definition, but as far as protocols go, it's not a good one. unwise to build in this ecosystem, especially when you see major builders getting their whole platform obviated by flippant breaking changes.

nobody sane would try competing with Hubble or Warpcast (unless they have 8 figures to burn thru) and that is a significant problem for the whole "open protocol" argument. this is merkel land and merkel will make or break rules to sink any serious competition.

Full-stack digital product consultant @ BoundCorp.net - eng @daylight

1) but only 1 Hub software and no incentive to run them, Google "what is client diversity" then get back to me

2) but one megafunded official majority client that doesn't fully share critical features like channel creation, DMs, closed source Shuttle

3) you introduced longcasts with less than 24h notice, you're turning channels upside down, and also any private non-proto features from #2 that you push should count against the "stable protocol" argument too, as all competing clients must match them and keep up to stand any chance of actually replacing warpcast as anyone's primary client

4) nobody is dumb enough to try to compete with you in your own billion dollar sandbox where you are judge and jury, why do you keep pretending this is viable?

got any examples of you interacting in good faith with critics from your community? general vibe is widely agreed that you do not. these replies certainly do not count.

#opensourcewarpcast (proud to boast that i started that slogan and repeated it until it spread)

1. There are plenty of Hubs. 

2. Multiple clients that work fine with centralized requirement.

3. What *protocol* changes are frequent and non-stable?

4. Who else is proposing, building consensus and then writing the code for the changes?

Hubble APIs haven’t changed significantly

If you build just on these you‘re fine

THOUGH as you said

Warpcast non protocol features are expected by users and hubs don’t have these by definition 

So one has to design within these constraints

The counter to my no rapid protocol changes is long casts. They fucked me over with that since that’s a can’t argue about it change being pulled into protocol in 24hrs