Dan Romero on Warpcast

Content pfp

0 reply

0 recast

0 reaction

borodutch pfp

@warpcastadmin.eth

ok farcaster, let me introduce https://thefarcasterexperiment.com/ to you all basically, @dwr.eth claims that there were no breaking changes and only my stuff is broken or that neynar (cc @rish) had something broken well, let's test what @dwr.eth is saying. i launched a farcaster hub from ground up, then connected to it with official node js farcaster lib, then made @healthbot use this hub no third-party software. no me touching the backend, nodejs dependency or the hub let's see for how long this can last, i give it 2-3 months before there is a breaking change that makes me touch the code to make a thing as simple as publishing a cast every hour going again, all native farcaster hub stack, no extra dependencies, just something that "still works since the time it went permissionless" or whatever what are your bets? when will it break? this is a true stress-test of dev trust being broken or upheld

3 replies

0 recast

26 reactions

Dan Romero pfp

We are moving to a new version of the protocol in January called snapchain. So it will likely break then. We're not a mature, at-scale protocol. Still actively being built. I understand that you're busy with your own startup that you don't have time to follow along with all the changes. But the vast majority of active developers on the protocol, when surveyed, voted for moving faster and focusing on user growth vs. moving slower and making sure everything is stable.

2 replies

0 recast

2 reactions

borodutch pfp

@warpcastadmin.eth

coming back to the original topic, "how did farcaster break trust" this is how. this is my original feedback, there is no trust in whatever one builds surviving even 2-3 months without being touched and you're missing the larger set of devs that can spend some time (but not all their full-time work time) benefiting the ecosystem *most* of the things i remember using on farcaster (including 3rd party clients) from 2023 (or even early 2024) are not here today — and the most basic reason is the need to constantly support the software with never-ending breaking changes

2 replies

0 recast

1 reaction

Dan Romero pfp

@woj.eth @rish curious what you think about snapchain since you deal with the pain of the existing protocol not working? Boro seems convinced that we don't communicate this well to developers and lose trust.

3 replies

0 recast

1 reaction

rish pfp

some small number of hard forks will be necessary. I empathize with the pain of switching. However, the alternative to not making these changes is ossifying something that doesn't scale. That means we will serve the few of us who are here now and then protocol will decay and die. Scaling while unfortunately losing a few of us is the only way out. No one here - Merkle, Neynar, etc. is making breaking changes unless absolutely necessary. Ofc we all think fewer breaking changes are better and that not having them would be nice. However, I'd tradeoff a couple breaking changes to grow from 100k users -> 100M users. Re: comms - I think there were 1-2 instances of moving unexpectedly fast (e.g. longcasts), 1-2 instances of directional changes regardless of pace (e.g. automod curated channel moderation to members only) that might have caught folks off guard. Snapchain doesn't have that problem imo. It's still months away and there's already been a few month's heads up boz.com/articles/communication-is-the-job

1 reply

0 recast

1 reaction

woj pfp

i don’t have enough technical insight to can’t speak on the details, but as an app developer i can at least say that the current model didn’t work in the periods of higher traffic and since we need to 100-1000x, im fine with losing backwards compatibility

0 reply

0 recast

1 reaction

borodutch pfp

@warpcastadmin.eth

lack of communication doesn't break trust here lack of confidence in things to keep working (aka backwards compatibility) breaks trust i had *zero* issues when we switched to hub api from warpcast api because the transition period was long enough to find a weekend to rewrite things (besides lack of good documentation and fragmentation of npm libs) what i'm talking about is changes that don't have a long enough grace period of backwards compatibility being dropped without enough warning that make the users of whatever i build dm me "hey this doesn't work" on a saturday night when i need to not just open migration docs and fix whatever's new, but also sift through a bunch of outdated documentation and spend hours with trial and error trying to figure out what exactly broke and how to fix it

1 reply

0 recast

1 reaction