Feed user parameters for customization

[MetaflameDragon]

Currently, feeds often end up being separated into variations. I believe the most common example is a pure-SFW, mixed, and pure-NSFW.

Would it be feasible to include optional user parameters that feeds could receive?
Examples would include:

• Boolean toggle (e.g. include replies?)
• Text field (e.g. filter by handle/DID)
• A range slider (e.g. include posts with 3+ likes)
• A datetime picker (e.g. display posts before date)
• An enum picker (e.g. SFW/Mixed/NSFW)
• ...

The idea is that this could merge several feed variants into one customizable feed, and allow users to customize their feeds even further, if the feed can provide it. Use cases could include having a feed with filterable post categories, feeds that simplify providing statistics about an account (e.g. "Show me all non-replies from user alice.example with 50 or more likes"), and other feed interactivity.

The parameters could be accessible in a readily available panel, giving the user quick sliders and toggles to change the behavior of their feed.

When defining a feed, optional parameters would be defined in its record within the repo - this would be mainly used by the frontend to set up the configuration interface. If I understand right, any update to field types would require the creation of a completely new feed, but this could be addressed e.g. by having the feed provider server return a response that a new version is available (this could have a special type of response handled by the protocol), which could let the user re-subscribe to the updated version with new parameters. In this case, the feed provider may or may not return posts for outdated versions, and may or may not react to the previous parameters.
In addition, these parameters would be non-checked, which could allow developers to test their feed providers by sending them hidden parameters. The only checking done by the server should be ensuring reasonable text field length, or similar safety measures.

[MetaflameDragon]

(I'm posting this in Lexicons, as felt like this most refers to app.bsky.feed.getFeedSkeleton. Hopefully this is the right place for it!)

[pfrazee]

I'm definitely a +1 to this, it would be great to have these tools

[bnewbold]

I think this is nice! A couple Lexicon/design notes:

• if there are common fields/patterns, we could try to define them as (optional) parts of the getFeedSkeleton Lexicon itself. Eg, "must include/not-include labels", or "before/since datetime", or "include replies" / "include reposts" booleans. Even if custom params are also supported, nice to have guidelines for simple/common cases.
• I'm not sure if custom params will be straight-forward with the existing HTTP API (XRPC) Lexicon semantics. getFeedSkeleton is a query (HTTP GET), with specified query parameters. I don't think all XRPC client API implementations allow arbitrary query parameters to be supplied. It would be simpler if this was a procedure (HTTP POST), as there is an any type that could be used for arbitrary custom parameters. I'm sure we can come up with a solution, maybe tweaking how query Lexicons are specified, or coming up with a simple string encoding trick.
• whatever we come up with, should ensure that it works well with HTTP caching. I think it probably will by default, but should double-check
• a huge simplification would be a fixed set of variations, listed/described in the feed record, and requested via a variation query param. This loses a lot of power/flexibility being described here, but just pointing out the option. The UX might be more successful.

[MetaflameDragon]

There's a lot to consider to shape the interface in such a way that developers don't shoot themselves in the foot. Providing an infinitely flexible framework can be a good idea, but providing a slightly more restricted framework that discourages anti-patterns is an even better idea.

An example would be making an everything-feed. One feed, way too many parameters, no consistency or general purpose. Currently, feeds only really decide based on the user ID, so their purpose is clear each time. Providing common toggles and settings (SFW/NSFW/Mixed, Y/N replies, Y/N reposts; date from/to, min-likes...) would add customizability, but should still ensure that each feed is made with a clear purpose. In addition, a limited selection of parameters might encourage server-side caching better, and other optimizations.

However, developers also shouldn't be forced into hacky workarounds to add more options to their feeds, if thought through well. A hybrid approach may be worth considering - the extension to the skeleton with common fields, as you described; and then extra POST data with custom parameters. This might even encourage splitting backends into a common skeleton handler, which filters posts according to common parameters, and then an optional custom-parameter filter that works on top of that.

Yeah, your idea to add common parameters into the skeleton is a good way to encourage some optimization and UX, while the optional POST or something similar could add even more flexibility. Adding a few default parameters could even lead to these being "expected" to be supported by the majority of feeds instead of making parameters a niche/optional thing, and services like SkyFeed could automatically support them for easy feed creation.