part of the did:web club
making server.reddwarf.app
performative: @whey.party
whiny: https://mas.to/@whey
1. on sidecar revision, it is safe to fallback to plain bsky
2. plain bsky version needs to be confirmed explicitly by the interacting user to prevent a different plain bsky post vs the enhanced version with the sidecar content
1. on sidecar revision, it is safe to fallback to plain bsky
2. plain bsky version needs to be confirmed explicitly by the interacting user to prevent a different plain bsky post vs the enhanced version with the sidecar content
plain bsky:
user interaction is safe to always be exactly the same as the plain post
enhanced fork with new sidecar feature:
user interaction is safe to always be locked to the sidecar revision
plain bsky:
user interaction is safe to always be exactly the same as the plain post
enhanced fork with new sidecar feature:
user interaction is safe to always be locked to the sidecar revision
1. plain target post
2. target post's sidecar extra data
3. plain interaction
4. extra proof record to CID lock all three
1. plain target post
2. target post's sidecar extra data
3. plain interaction
4. extra proof record to CID lock all three
bsky post with incomplete data + sidecar embed with important data
reply / like is strongref towards the post
sidecar data changes
reply / like is still the plain bsky one, with no way of CID-locking the sidecar data right so how do you prevent this without sidecar-ing the like too
bsky post with incomplete data + sidecar embed with important data
reply / like is strongref towards the post
sidecar data changes
reply / like is still the plain bsky one, with no way of CID-locking the sidecar data right so how do you prevent this without sidecar-ing the like too