Describe the Feature
After a member floated the idea, I decided to see what and how mutes on post type could be done. I wanted to avoid having to introduce a new lexicon or fork anything existing. It seems like a good place to store this would be in app.bsky.actor.defs#preferences (since this is private; everything else I could come up would be something I could see being added to Clearsky, defeating the purpose of this).
The bulk of what I'm thinking would live in FeedTuner (could even leverage _dryrun in a preview approach - not sure how that'd work yet):
// In src/lib/api/feed-manip.ts, something like the following:
static removeRepostsByDids(dids: Set<string>) {
return (tuner, slices, _dryRun) => {
for (let i = 0; i < slices.length; i++) {
if (slices[i].isRepost && dids.has(slices[i]._feedPost.reason.by?.did)) {
slices.splice(i, 1)
i--
}
}
return slices
}
}
static removeQuotesByDids(dids: Set<string>) {
return (tuner, slices, _dryRun) => {
for (let i = 0; i < slices.length; i++) {
if (slices[i].isQuotePost && dids.has(slices[i]._feedPost.post.author.did)) {
slices.splice(i, 1)
i--
}
}
return slices
}
}
This approach keeps most of the lifting in the client - which I'm personally not happy about because that perf hit can climb as folks scroll, but it's the best way to demo the idea before considering something more graduated of an approach.
Attachments
No response
Describe Alternatives
Ideally? This would be something that could live in the bsky lexicon or in Blacksky's own version of it. That would make it easier for client applications like Heron to pick this up (they already do a bit of sniffing to see if one is coming from Blacksky or using a Blacksky PDS, to my understanding).
Additional Context
No response
Describe the Feature
After a member floated the idea, I decided to see what and how mutes on post type could be done. I wanted to avoid having to introduce a new lexicon or fork anything existing. It seems like a good place to store this would be in
app.bsky.actor.defs#preferences(since this is private; everything else I could come up would be something I could see being added to Clearsky, defeating the purpose of this).The bulk of what I'm thinking would live in
FeedTuner(could even leverage_dryrunin a preview approach - not sure how that'd work yet):This approach keeps most of the lifting in the client - which I'm personally not happy about because that perf hit can climb as folks scroll, but it's the best way to demo the idea before considering something more graduated of an approach.
Attachments
No response
Describe Alternatives
Ideally? This would be something that could live in the bsky lexicon or in Blacksky's own version of it. That would make it easier for client applications like Heron to pick this up (they already do a bit of sniffing to see if one is coming from Blacksky or using a Blacksky PDS, to my understanding).
Additional Context
No response