Content
@
https://warpcast.com/~/channel/social
0 reply
0 recast
0 reaction
Stephan
@stephancill
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?
7 replies
0 recast
29 reactions
Stephan
@stephancill
my assumptions might be wrong. time will tell
0 reply
0 recast
5 reactions
rubinovitz
@rubinovitz
Your half solution is @mbd ?
2 replies
0 recast
1 reaction
jd ๐บ
@jdl
separating the feed from the client is the way. bsky does this today that said both assumptions presume the absence of a protocol. email does this today
1 reply
0 recast
0 reaction
df
@df
decentralized clients. ios app store signing key delegated to a consensus algo or smthg
1 reply
0 recast
1 reaction
androidsixteen
@androidsixteen.eth
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
1 reply
0 recast
0 reaction
๐ถ๐๐๐๐ฟโจ
@toyboy.eth
Yeah just about right on the nerfed issue
0 reply
0 recast
0 reaction
john ๐
@know
it might be possible that everyone will vibecode their own clients, that level of personalisation seems possible eventually
0 reply
0 recast
0 reaction
