Content
@
0 reply
0 recast
0 reaction
Stephan
@stephancill
global state is even more overkill than i initially thought tbh hubs replicate cast and reaction data across thousands of nodes. this provides hard data availability guarantees for much longer than that data is actually relevant i.e. a couple of days vs a full year – 2 orders of magnitude off! makes more sense for static data like social graph and profile info but then again it doesn't actually make sense to store social graph data on rented storage since the nature of the data is much more permanent
4 replies
6 recasts
43 reactions
Stephan
@stephancill
perhaps it would make more sense for storage on hubs to behave more like blobs on ethereum where there is a shorter data availability guarantee and an expectation for archival services to archive data with less redundancy
0 reply
4 recasts
26 reactions
Dan Romero
@dwr.eth
You might find this article interesting. https://anderegg.ca/2024/11/15/maybe-bluesky-has-won
0 reply
1 recast
5 reactions
vrypan |--o--|
@vrypan.eth
The "problem" is social activity (casts, reactions), not the social graph. This is why I could see social activity moving to an other layer, in order to maintain a truly decentralized "L1" for the social graph. It's old now, but take a look at this post, considering the above pov. https://blog.vrypan.net/2024/06/26/farcaster-l2/
0 reply
0 recast
1 reaction
Jorge Pablo Franetovic 🎩
@jpfraneto.eth
when i first started reading i thought you would talk about an app and immediately thought that i have 5 <XProvider> wrapping the main layout and was like ooooooops 8 $degen
3 replies
0 recast
0 reaction