coatless
commented
1 week ago Agreed, it would be nice to have. On the AT moderation tools, I think that relies upon a login to access via app.bsky.actor.getPreferences, which this is setup to avoid given the static nature of deployments.
There are two approaches that I can implement to address it:
- Each post currently has a
labelsattribute that I think contains different kinds of flags (spam/nsfw/trigger/???) - A filtering system built into
_quarto.ymllike:
bluesky-comments:
mute-patterns:
- "📌"
- "🔥"
- "spam"
muted-users:
- "did:plc:someuserdid123"
- "did:plc:anotheruserdid456"
filter-empty-replies: true
visible-comments: 3
visible-subcomments: 5The configuration options listed are:
mute-patterns: Array of strings or patterns to filter outmuted-users: Array of Bluesky DIDs to mute by defaultfilter-empty-replies: Boolean to control filtering of empty/spam repliesvisible-comments: Number of comments to show initially before "Show more comments"visible-subcomments: Number of subcomments to show initially before "Show more replies"
Thoughts?
Looking at the large number of 📌 replies in the example, it occurs to me that one probably wants some kind of moderation controls on this.
Describe the solution you'd like A "client-side" or muting like approach would be to enable some kind of filtering by content or metadata. A file in the site source, listing words, regexes, and/or people to mute, could pass this info to the JS that fetches the comments and filters those things out.
Describe alternatives you've considered An AT-native moderation approach probably would require your site to have some kind of AT identity so that moderation tools could be used - e.g., blocking users from interacting with posts from the site.