You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You'll need three accounts to test this scenario: ListAdmin, Listee, and Subscriber.
ListAdmin makes a bogus moderation list (let's say it's called KittenHaters) and adds Listee to the list.
Subscriber subscribes to KittenHaters and chooses "block". Subscriber now blocks Listee on an inherited basis from Listee being on the KittenHaters list Subscriber is subscribed to.
Bluesky T&S deletes the KittenHaters list because ListAdmin is accusing people of the heinous crime of hating kittens.
Subscriber can now see Listee's account again! Except a lot of remnants of the block still linger:
Subscriber will still see the "Blocked by KittenHaters" message on Listee's profile
Subscriber will still not see Listee's account profile header image
Listee's icon/profile pic will still be blurred
Subscriber can also interact with Listee again! Except a lot of remnants of the block still linger:
Subscriber's reply will appear in Listee's notifications
But Subscriber's reply will not show in thread view if you click the post of Listee's that they replied to
If you click on Subscriber's reply (such as from a feed, notification, quote post, etc) the parent shows as "Blocked post"
If you view Subscriber's reply on a feed, the reply line shows as "Reply to a blocked post"
The KittenHaters list no longer appears in Subscriber's "moderation lists" section of their settings, and there is no way for them to unsubscribe from the list and fix any of the above symptoms of the lingering block.
If Listee views Subscriber's profile, they can see the posts, comments, header image, profile pic, etc, but they also see the "User blocking you" bug between the user's bio and their posts.
I am Listee in this situation, not Subscriber, so there may be other lingering effects that I couldn't identify since I didn't want to walk the various Subscribers through a full range of "what does it do if you do X" questions, but basically it looks like the inherited block from a list you're subscribed to is being cleared for the purpose of "can I see the contents of this account" but not for pretty much anything else when the list is deleted for being abusive.
I have verified that this happens in the iOS client, mobile web, and desktop web; I don't have an Android device around to try it on that, but I can't imagine it wouldn't be the same there. I dithered between whether this should be put in bluesky-social or atproto because I suspect this might be a protocol-level issue, but I can only verify that it's happening on bluesky-social so I stuck it here to be on the safe side!
The text was updated successfully, but these errors were encountered:
I'm also seeing this issue from a moderation list that I subscribed to (muted, not blocked) from an account (ListAdmin) that was banned. The users (Listees) from that list are still muted in replies (and likely in feeds too.) I have been unable to find where the moderation list subscription record is actually stored in my PDS repo in an attempt to manually delete it and hopefully fix the issue for me.
Steps to Reproduce
You'll need three accounts to test this scenario: ListAdmin, Listee, and Subscriber.
I am Listee in this situation, not Subscriber, so there may be other lingering effects that I couldn't identify since I didn't want to walk the various Subscribers through a full range of "what does it do if you do X" questions, but basically it looks like the inherited block from a list you're subscribed to is being cleared for the purpose of "can I see the contents of this account" but not for pretty much anything else when the list is deleted for being abusive.
Attachments
No response
What platform(s) does this occur on?
iOS, Web (Desktop), Web (Mobile)
Device Info
No response
What version of the app are you using?
Build version: 1.93.0; Bundle info: 5f449e3 (prod); Bundle date: 24111700; Platform: web
Additional Information
I have verified that this happens in the iOS client, mobile web, and desktop web; I don't have an Android device around to try it on that, but I can't imagine it wouldn't be the same there. I dithered between whether this should be put in bluesky-social or atproto because I suspect this might be a protocol-level issue, but I can only verify that it's happening on bluesky-social so I stuck it here to be on the safe side!
The text was updated successfully, but these errors were encountered: