Feed interactions schema #2383
Feed interactions schema #2383
Conversation
lexicons/app/bsky/feed/defs.json
Outdated
| "feedContext": { | ||
| "type": "string", | ||
| "description": "Context provided by feed generator that may be passed back alongside interactions." | ||
| } |
There was a problem hiding this comment.
If this is truly freeform context, I might lean towards making it an unknown object. If it's meant to be used as a nonce, token, or something like that it might be cool to reflect it in the name more explicitly (feedToken / interactionToken / feedbackToken?).
There's also probably a practical size limit to these, since all the services need to pass them around. I would lean towards something less than or equal to safe URL lengths (I usually conservatively call this ~2k).
There was a problem hiding this comment.
Yeah unknown just really blows it open and we can't add any constraints to it. Figured keeping it a string made it a bit easier to wrangle. Paul & Why both seemed cozy with an opaque string
Which speaking of, I like throwing a utf8 limit on it. 2000 sounds good 👍
| "acceptsFeedback": { | ||
| "type": "boolean", | ||
| "description": "Declaration that a feed accepts feedback from a client through app.bsky.feed.sendInteractions" | ||
| }, |
There was a problem hiding this comment.
I wonder if there's a way to unify the terminology around either "feedback" or "interactions."
There was a problem hiding this comment.
Yeah I was wondering that myself. I guess acceptsInteractions works just seemed a bit off 🤔
There was a problem hiding this comment.
thought about it & don't mind it so I changed it to acceptsInteractions 👍
| "interaction": { | ||
| "type": "object", | ||
| "properties": { | ||
| "item": { "type": "string", "format": "at-uri" }, |
There was a problem hiding this comment.
Will this generally be either a post or repost URI?
There was a problem hiding this comment.
Right now I was thinking it would always be the post uri & any repost that got it in there would be associated through the feedContext that gets sent around 🤔
I left it somewhat vague because I think it's likely we'll start passing down non-post objects in feeds at some point
| "event": { | ||
| "type": "string", | ||
| "knownValues": [ |
There was a problem hiding this comment.
If you have any thoughts on { item: at-uri, event: token, feedContext: string } versus open-union-style { $type, item: at-uri, feedContext: string, ... } I'd be interested to hear! I have a feeling both options crossed your mind 😏
There was a problem hiding this comment.
Yup that was my first pass on it but then ended up redoing it this way.
Mainly reconsidered because an array of open unions is tough in languages like Go. But also nearly all these interaction types had similar values on them so they were pretty friendly to squash down into a flat object like this so didn't seem like any resolution was lost
|
Looking at this definition of "interaction", let me raise a few questions and requests. Question:
|
|
Requests:
|
Yup that's right 👍
As well as record embeds (posts, feed generators, lists, etc). You can tell what type of embed it is by looking at the post
I dig the creativity there, but it's a bit out of scope for what we're shooting for right now. We'll likely add more clickthrough events and metadata in the future but wanted to keep it fairly simple for now. The schemas open for extension :) |
Adds a lexicon for a client to send interactions back to a feed generator.
This is an optional (but helpful) API for clients to implement to give feedgens feedback on what the user is seeing and whether the user is giving any positive or negative signals about the content, including an "I don't like this" / "Less of this content" signal.