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.
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:
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.
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.
That doesn’t answer the question. To say “most obvious” just rephrases your position. We have a system that disregards user input because it thinks it knows better what the user wants. That can only be an “obvious” behavior if in fact you expect the system to be incompetently designed.
Advertisement? Deception?
Calm down. Advertisement is a metaphor. If you don’t grasp it, just forget it. A capability is advertised to the user by giving them an option. Then failing to execute on the user’s instruction amounts to deception.
I admit that deception is typically a deliberate act. I did not mean to imply that. It’s safe to call it an accidental deception.
PEBCAK
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.
The problem with this way of thinking is it nannies the user by disregarding their express instructions. Telling users what they really want instead of acting on their commands. It’s a subtle attack on users’s dignity and self-determination because it denies them control (without even telling them). It’s like Google deciding to change your search queries for you.
If you look at other systems (well designed systems) involving complex rules like a variety of firewalls and email processing rules, or tools like rsync
, they are sophisticated and wise enough to not assume the user’s input is a mistake when a sensible interpretation is possible. They act on the user’s instructions. If a user does a general block but specifies a specific criteria to the contrary, there is only one smart way to interpret that while respecting the user’s wishes: to prioritise the specific rules above the general rules.
Otherwise you have blunt tools, disserviced nannied users, and chaos.
It makes sense to me that blocking an instance would block EVERYTHING from that instance.
But that’s not happening. The current implemation does not block everything. E.g. you still see public comments from the blocked instance. Lemmy is still deciding what the block and what not to block. And what it decides to block fails “the rule of least astonishment¹” particularly compared to what it decides /not/ to block.
¹ the principle/rule of least astonishment is an engineering concept that requires the system to behave in the least astonishing way. In the case at hand, if the user sees the contents of a community they subscribed to but nothing else on an instance they generally blocked, there would be no astonishment because the system would be acting on the user’s instructions. But the status quo is astonishing because the system decides to ignore some of the user’s instructions.
I believe what has happened is that Lemmy is so rich with bugs that users are simply conditioned to expect it to work poorly.
Right, which is why Lemmy should optimally implement some firewall-esque whitelist/blacklist system instead of the blunt tool that is in place now. Users would get the full/fine control over their feed that you want, but implemented in a way that should confuse no one.
With that said, the fact that you currently still see comments from users on blocked instances is definitely a bug. Regardless of the outcome of this (whether a blacklist/whitelist system is added, your suggestion is implemented, or Lemmy filters just continue working like this forever), that needs to be solved.
When a bug tracker is inside the exclusive walled-gardens of MS Github or Gitlab.com, and you cannot or will not enter, where do you file your bug report? Here, of course. This is a refuge where you can report bugs that are otherwise unreportable due to technical or ethical constraints.
⚠of course there are no guarantees it will be seen by anyone relevant. Hopefully some kind souls will volunteer to proxy the reports.
related communities in the decentralised free world: