Post

Algorithmic Choice! This "For You" feed by @spacecowboy17.bsky.social is what it's all about. You don't have to use Discover. Other people can make great algorithms.

it really needs "feed feedback" to work better! i want to use it more but it feels a lot more stale which i think is because it's unaware of what i've seen

I know a PR that would be a quick win

sorry got a lot on my plate but i’m gonna try and get that merged this week!

Awesome! Thanks for putting up with my pestering ^^

I’m eagerly anticipating inline feedback so I don’t have to do this on a separate site

ohhhh really cool that you have a web UI for this! def easier to do the basic more/less in-app, but there is a ton of potential for both configuration and communicating "why is this in my feed" or "what is my clustering" in a separate web UI

+1 Consider hiding the already seen posts on the client side so that you don't have to expose who has seen what to the feed owners. That would be a cleaner solution from the privacy perspective. I got multiple requests to hide posts from the follows.

I don't understand the problem with feeds knowing what you've seen. They know what you've loaded so why would you worry if they know whether you've viewed it?

Fair question! If we are talking about what the user has seen in For You feed only - then there is nothing to worry about. Bluesky should implement this But people have requested treating what they have seen in other feeds like Following as seen for For You. In that case it is not so worry free.

also not a fan of that option because I don't want to basically have to lose posts like that just because I've already seen them once. I might want to go back for some reason. And that's a lot of clicks/time/energy

also from a creator standpoint I really wish we had impressions statistics for posts + stats for which views/what engagement came from which feed, etc

this already happens for muted settings and it breaks my read detection logic, since i lose the ability to map a feed response 1:1 to an actual feed entry in the bsky client. worst case it turns 50 posts into 5, requests the next cursor immediately and it breaks logic +

because i need to detect read speed. if the user is not reading "as a user should" AKA approximately 1 post per second then they're scrolling for the fun of it (or finding a specific post) and i should ignore read behavior. the "fix" is passive interactions but i can only hope that goes through.

i don't think that's actually a good solution because the client would have to keep paginating more and more aggressively (since the feed will not know not to return already seen posts), spamming the server. it's maybe a workaround that can work sometimes but imo the server needs to be aware

I think your suggestion is for the app to send the list of seen posts (similar to the cursor parameter), which makes sense. Do "seen posts" only include what was seen in this feed (1) or other feeds as well (2)?

they could try adding a global setting to hide Liked posts from all Feeds it's pretty rare that I ever want to see a post I already liked