did:w(h)e(y)b
banner
dw.whey.party
did:w(h)e(y)b
@dw.whey.party
self indulgent thought landfill
part of the did:web club

making server.reddwarf.app

performative: @whey.party
whiny: https://mas.to/@whey
blejhhh
Poll created by did:web:did12.whey.party
Click to participate in this poll
local3768forumtest.whey.party
January 12, 2026 at 6:18 PM
oh yeah i forgot that even if constellation had a filter by date feature, users can just simply lie about when they made their vote and backdate the record. so i still need some sort of stateful authority to keep track of the results at a particular time anyways
January 12, 2026 at 6:12 PM
i think im just gonna remove every feature that i cant implement solely by using constellation just because, and i mean its all public anyways. ill leave the more stateful and in depth polls for the private polls thatll need a server anyways
January 12, 2026 at 6:09 PM
yknow i just realized there is no good way of enforcing the poll expiration time only by using constellation. how do you query the counts of a backlink but before a date? i dont think it can/should. more stateful services orrr i just remove the expiration date
January 12, 2026 at 6:09 PM
also still thinking of moving around the UI a bit. maybe moving the disclaimer to the top right, moving the expiry date to the bottom right, or alternatively just replace the all votes are public with view all votes button
January 12, 2026 at 5:59 PM
it doesnt work well btw, theres no optimistic state so while your votes are actually created / deleted, it wont show up in the UI until the cache busts or constellation indexes it. also the UI to show who voted what is still not done
January 12, 2026 at 5:58 PM
yknow i thought this cheap public polls would be an easy 1hr project but nooo theres so much validation that needs to happen to make it work well
January 12, 2026 at 5:13 PM
revised poll
Poll created by did:web:did12.whey.party
Click to participate in this poll
reddwarf.app
January 12, 2026 at 4:33 PM
doesnt work btw its just an opengraph generaton test which works yay
January 12, 2026 at 4:04 PM
kinda like this. also this is just a mock and it doesnt work because of all of the issues i stated above and havent decided on a good design for the actual lexicons and interoperability and trust structure but the UI should look like this for the bsky fallback for polls i think
hello world i have this to show you all what is your favourite fruit wow incredible wow wow wow vote on the pokemon go to the polls below right now maybe methinks sauce
Should we allocate 15% of the treasury to the new liquidity pool?
Red Dwarf Polls · Secrecy provided by @polls.reddwarf.app
reddwarf.app
January 12, 2026 at 1:09 PM
i forgot to tell but my idea of the fallback system is by using bsky's external link embed type and stuffing the extra content inside the opengraph image and its useful because the link could redirect the user into the sidecar-aware client for sidecar-aware interactions, dynamic data, or extra data
January 12, 2026 at 12:37 PM
unless theres an interaction record that skips the fallback plain bsky version entirely, which is like bad for interoperability towards plain bsky users but is at least safe and convenient. probably also important to show if a reply is replying to the plain or enhanced version
January 12, 2026 at 12:29 PM
kinda tedious to have the confirmation popup appear on every like to confirm that youre not being duped via showing the plain bsky render and sidecar extra feature render side by side in a popup but like i dont see how it could work without this
January 12, 2026 at 12:29 PM
this means
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
January 12, 2026 at 12:25 PM
it works because theres two possible environments

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
January 12, 2026 at 12:25 PM
i think like the only possible way for this to work is to have a separate like / reply / CID-lock proof record to be made that includes all of the sidecars. so like the graph is
1. plain target post
2. target post's sidecar extra data
3. plain interaction
4. extra proof record to CID lock all three
January 12, 2026 at 12:22 PM
what about
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
January 12, 2026 at 12:18 PM
also funny use case to have a self hosted provider that alsways lies and like returns 999999 for the first option and -99999 for the rest
January 11, 2026 at 3:14 PM
also funny use case to have a self hosted provider that alsways lies and like returns 999999 for the first option and -99999 for the rest
January 11, 2026 at 3:13 PM
sorry i deleted the post
January 11, 2026 at 3:13 PM
and like below the poll, the provider is directly listed and must have a bsky profile to use and when clicked it goes to the provider's bsky profile page so users can block the provider and have a warning for a bad / blocked / muted provider
January 11, 2026 at 3:13 PM