Varun Srinivasan pfp
Varun Srinivasan
@v
We're starting to think about a new sync model for Farcaster. The current system works but is unlikely to scale up another 10x. Here's our articulation of the problem we want to go after.
15 replies
81 recasts
436 reactions

Alberto Ornaghi pfp
Alberto Ornaghi
@alor
re Pruning: does pruning generate diff syncs between hubs? if so, why? do we need pruning to be in sync? if we only prune very old data, can we let it up the single hub instance the choice to delete them when they want? I don't see the need to sync pruning between all hubs
1 reply
0 recast
7 reactions

Varun Srinivasan pfp
Varun Srinivasan
@v
Pruning changes the state of the “bag” of deltas So if I’m comparing my deltas with you and you have pruned differently we won’t be in sync
1 reply
0 recast
2 reactions

Alberto Ornaghi pfp
Alberto Ornaghi
@alor
what I'm proposing is that pruning does not change the bag of deltas. what's the issue if one hub has performed pruning already and another one still have to perform it? those are old data and different hubs my decide to keep old data for longer periods. up to them to pay for the extra storage. imho not a big deal if the state is not in sync on old data. it's crucial on new one, but old data can be left there even not in sync. since hubs don't deny casting if you are over the quota (just delete the old data to make room for the new one), I don't see the reason to be in sync with that part.
1 reply
0 recast
2 reactions

Varun Srinivasan pfp
Varun Srinivasan
@v
it's important that all hubs have the same state and don't make different decisions on what data is held. it would be very annoying if you logged onto warpcast and it had a different history than when you logged on to supercast.
1 reply
0 recast
1 reaction