social

getting increasingly bearish on the idea of client diversity as a means of effective decentralization

key assumptions:
1. communities are very likely to use the same client
2. you're unlikely to migrate clients

if you get nerfed that client, your ability to move clients doesn't actually help the situation unless your audience on that client also moves with you

potential half-solution: separate the feed building layer from the client layer?

not a bulletproof solution because no guarantee that you won't just get filtered at the client level anyway

next level: encrypted feed building?

Client diversity became a KPI for decentralization because Ethereum invested too much money into it. The sunk cost is ignored bc Ethereum's talking heads don't like to admit the ecosystem pursued bad ROI here

I've tried to call this out, but it's a 3rd rail in decentralization politics

friendly neighborhood shitcaster // working on @pinetree

ethereum equivalent would be snapchain implementations

blockchain clients only need to agree on the canonical chain. here we do care about total ordering of messages but also about different ordering based on user's preferences. just a chronological feed of events is not enough

afaik p0 of ethereum's client diversity is supposed to mitigate the risk of a client bug causing a consensus failure

clients in ethereum serve a very different purpose to clients in farcaster