Content
@
0 reply
0 recast
0 reaction
androidsixteen
@androidsixteen.eth
The "onchain" narrative is a bit weird to me because it's like flexing about being "onAWS" or "oncloud" A chain is only one part of your tech stack. In fact, having to compose everything onchain is an anti-pattern that emerged because light client support sucks Offchain is more expressive, safe, and cost efficient
23 replies
3 recasts
112 reactions
Henri Stern Ꙫ
@henri
💯 I quite like the term but agree with a lot of this Never picked a product because it's NoSQL, personally
1 reply
0 recast
3 reactions
androidsixteen
@androidsixteen.eth
And you avoided many tears and sleepless nights as a result Maybe that's one commonality between "onMongo" and "onchain" — it signals that you're a masochist 😆
1 reply
0 recast
2 reactions
Henri Stern Ꙫ
@henri
dark 😆 -- there is the fact that onchain implies deeper user implications (since self custody and interop are the benefits) than a db choice -- so it feels like more of a difference in kind than (eg) lower latency. Part of what's interesting in our work (at Privy): it's developer tooling but very user centric
1 reply
0 recast
1 reaction
androidsixteen
@androidsixteen.eth
Self custody (or PKI) is off chain :) And interop is unfortunately onchain because we lack trust-minimized IO with offchain coprocessors. I hope that next gen infra focuses on light clients for reads and fast proof generation/verification for writes The root of trust (the chain) should have less app code IMO
3 replies
0 recast
2 reactions
artlu is on lunchbreak
@artlu
Yes and more yes. Sidebar every FC app dev handling signers was a trust black hole. Kudos to Neynar Privy and Pinata for centralizing in professional hands, AND to Open Source kings for showing it can be done trustlessly (with other tradeoffs of complexity and owners' responsibility)
0 reply
0 recast
1 reaction
