(Lemmy) blocking an instance while subscribing to a community on that instance yields an empty community

This was discovered by Jim East:

https://slrpnk.net/post/27305276/18006810

I must say it fails the principle of least astonishment. If a user blocks Lemmy.World but subscribes to !linux@lemmy.world, for example, they obviously want to exceptionally see content in the subscribed community but nothing else from that node. But what happens is the instance block overrides the specific community subscription. So the general rule is prioritised above the specific rule.

And worse, when visiting the subscribed community it just shows no posts without reminding the user that they have a relevant block in place.

10 comments

This current behaviour does make the most sense to me. But I think it was the Tesseract dev who was experimenting with a "soft block" system that would provide the behaviour you want. You would be able to set a full instance block on the instance that works exactly as it does today, or you could instead set a soft block on it that allowed you to whitelist particular communities/users that you would still like to see.
- This current behaviour does make the most sense to me.
  Can you elaborate? If you block a whole instance but then specifically subscribe to community X on that instance, what would the point be to subscribing to a community on an instance you block other than to have exceptional visibility on that community?
  What do you get by subscribing to a community on a blocked instance under the current implementation?
  You would be able to set a full instance block on the instance that works exactly as it does today,
  To be clear, there is no such thing as a full instance block w/the stock client. E.g. when you block an instance public comments from that instance are still displayed. Just not DMs and community timelines (even when subscribed). So the devs have selected /some/ content to still be visible from blocked instances, and it defies intuition.
  
  Nothing. It makes sense to me that blocking an instance would block EVERYTHING from that instance. The "Subscribe" button on should probably currently be disabled on all communities on a blocked instance. To me, a block is a block. If someone wants to block something but allow a certain subset of that blocked thing, there needs to be some whitelist/blacklist system instead of the simpler "it's either blocked or it isn't" settings available right now.
That is the behaviour I'd expect.
But I guess a relatively easy fix would be to unsubscribe a user from all communities on an instance when it is blocked (and then prevent subscribing to them in the future).
- That is the behaviour I’d expect.
  Why? When a user blocks a whole instance generally but then specifically subscribes to a particular community on that instance, why would you expect the subscribed community to be empty?
  But I guess a relatively easy fix would be to unsubscribe a user from all communities on an instance when it is blocked (and then prevent subscribing to them in the future).
  Indeed if you have a false advertising scenario, there are two possible fixes:
  change the ad to be truthful; or
  implement what the ad claims
  You seem simultaneously acknowledge that there is a deception but that you would expect it? It’s like saying you expect the design to be sloppy. In any case, what you suggest would be one possible fix to the problem. But if implementing that fix, it should go further and inform the user of subscribed communities that will be unsubscribed along with an option to back out of it to prevent data loss.
  
  Why? When a user blocks a whole instance generally but then specifically subscribes to a particular community on that instance, why would you expect the subscribed community to be empty?
  Because you blocked the entire instance these communities are on. I feel that is the most obvious behavior. Subscriptions don't really factor in here as they aren't "whitelists" for blocks.
  Indeed if you have a false advertising scenario [...] You seem simultaneously acknowledge that there is a deception
  Advertisement? Deception?
  It's a technical feature that doesn't behave like YOU were expecting. There is no false advertising or deception here ... calm down.

10 comments