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 🧵👇
14 replies
10 recasts
38 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
christopher
@christopher
yeah lol if a message makes it to a hub, assume it’s committed to the snapchain. we will likely need to move to a PoS mechanism for ordering after this PoA one.
1 reply
0 recast
0 reaction
androidsixteen
@androidsixteen.eth
I don't know about that assumption -- even the tradeoff section says: > State management for apps — deltas sent to a write hub remain in a pending state and may be rejected after a delay. apps need to write logic to handle this and explain it to end users. You could have an incorrect contract event inclusion by a validator, and that would cause the entire snap / block to be dropped by the network If apps don't factor this in, then they would show bad state to users
1 reply
0 recast
1 reaction
christopher
@christopher
oh i didn’t even consider other hubs contributing to a bundle rejection hmmmmmmmm
0 reply
0 recast
1 reaction
