Content
@
0 reply
0 recast
0 reaction
androidsixteen
@androidsixteen.eth
Reading the Snapchain doc: https://warpcast.notion.site/Snapchain-Public-0e6b7e51faf74be1846803cb74493886 Going to cast all my stupid questions in this thread as they come up 🧵👇
15 replies
9 recasts
36 reactions
androidsixteen
@androidsixteen.eth
> Snaps are produced by hubs every 15 seconds Does this mean any user action / delta will have a <15 second latency? So clients would optimistically display state changes before they're written to hubs?
4 replies
0 recast
7 reactions
christopher
@christopher
most clients will display state changes from a database like Postgres or local state, very few directly react to hub events.
1 reply
0 recast
5 reactions
androidsixteen
@androidsixteen.eth
So a responsive app should optimistically display a user action in the UI if writing to a hub Then reads happen from a DB that has ingested data from hubs using Shuttle? What happens in the event that an action fails to be included on...hub? Is the UI then stuck in a bad state? cc @cassie
1 reply
0 recast
2 reactions
christopher
@christopher
yes! Warpcast does this quite a bit. writes can get backed up and will require manually managing the queue. but the hubs are pretty deterministic and clearly defined in the SDKs/types/protobufs. there is little chance a write fails to hit the hub if you preprocess according to the specs.
1 reply
0 recast
1 reaction
androidsixteen
@androidsixteen.eth
hopefully no mempool eviction moving forward 🤞 don't know why there'd be if there's only 0-cost txs
1 reply
0 recast
1 reaction
