-
Notifications
You must be signed in to change notification settings - Fork 632
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Polls & Poll Answers #3248
Conversation
"defs": { | ||
"main": { | ||
"type": "query", | ||
"description": "Get poll answers for a given poll which reference a post.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"description": "Get poll answers for a given poll which reference a post.", | |
"description": "Get poll answers which reference a given post.", |
I think this is a bit confusing in terms of protocol design, since for example the poll could be edited out of a post and nothing is stopping a user from submitting a app.bsky.feed.pollAnswer
that references a post that doesn't exist (yet) or doesn't have a poll (yet). The latter case could easily happen during normal use if multiple AppViews are involved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a downside to the implementation I have put together so far. I considered instead creating an individual record called a Poll, which would then be associated with a Post, which could mitigate this. The issue I had with that is then you have this object that can only really ever have a relationship to a post, or can otherwise just be orphaned, and I figured that wouldn't be very useful.
I'm open to changing this though!
}, | ||
"minLength": 2, | ||
"maxLength": 4 | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This only covers single-choice polls in terms of poll definition.
Rather than a binary single-choice and any-number-of-choices system, it would be cool to have the maximum number of distinct selections given as an integer:
} | |
}, | |
"maxAnswers": { | |
"type": "integer", | |
"minimum": 1, | |
"default": 1 | |
} |
It should be specified what happens when the number is changed, but that's necessary anyway because multiple-choice polls (if/once allowed) can be edited into single-choice ones and vice versa. (The easiest solution would be to discard/disregard all previous answers when poll post content is edited of course, which is what Mastodon does I believe.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is good to have too. I'm going to hold off on committing this in for now, as I would like to figure out the validation behavior that will allow this to work properly. Your mention of poll editing is key here. In the last question that I answered I was considering moving to having Polls be their own record, and, that may be necessary to handle poll editing properly, ensuring that PollAnswers are discarded, by nature of referencing a stale copy of the poll at edit time (that is to say, editing a poll would create a new poll record).
Aside from the review comments, the option limit of 4 seems quite low. (The eventual UI may need some mitigation for page stretching for the overall post, however, as even (1+4) times 300 graphemes is quite long in this context. Mastodon has a shorter limit here, it allows (entry of! It likely can display many more.) up to 50 characters per answer.) |
I feel like That would give a bit more freedom on how the UI for browsing those should work, i.e. for paginating through specific selections individually when they are listed separately. |
Co-authored-by: Tamme Schichler <tamme@schichler.dev>
Co-authored-by: Tamme Schichler <tamme@schichler.dev>
Co-authored-by: Tamme Schichler <tamme@schichler.dev>
Thank you for the info, the setup I have here is configured pretty differently. While I set the initial protocol-level maximum to 4, I chose a database type of int8, which should allow for 8 bit-masked answers. That's still less than 12 of course, so, perhaps it'd be better to use just a |
I think it's fine to limit it to a value that can be stored in an integer bitfield. |
I got very ahead of myself in this branch and did a bunch of work/codegen. Most of this was just because I was curious to see how implementing the lexicon would look. That being said, that's against the contribution guidelines, so, I will be closing this PR, keeping it only for the sake of reference. I'd like to move any discussions or comments for feedback to a new PR: #3298 This is based on a separate branch, where I have cherry-picked all of the commits from this PR's branch which pertain to lexicon changes only. |
Recently I read #1310 and got interested in what an implementation of polls could look like.
This is partially complete, the main work done here is defining lexicons for polls as embeds of posts, as well as pollAnswers, which are their own records which copy a lot of stuff from likes. Polls contain a set of strings which are possible answers an actor could pick, and pollAnswers container an integer which is intended to reference a selected answer chosen by an actor. Importantly, the answer field of pollAnswer is intended to be used as a bitmask. This way, polls could support multi-answer selections in the future with little additional work.
This implementation is WIP, and experimental I have not finished writing up the aggregation code for poll answers, and, I'm sure I'm missing more things. I'd like to get an early sense of how people feel about this implementation! I could also use some mentoring on working with the atproto codebase. I have some of it down, but, I'm sure i'm missing things, and, I don't know what I don't know.
Largely, this is a 'playground' PR for determining if the lexicon is going to make sense for implementation.
I have opened a separate, non-draft PR, where I will collect feedback on the lexicon only: #3298