LemmyNet
Federated actions are not aware of remote blocklist
I added a comment to this issue that was closed prior to 16.4 https://github.com/LemmyNet/lemmy-ui/issues/633 Having upgraded it is better, but still not right.
Today I want to report a different problem with the search feature within the community drop down box.
Lemmy.ml has blocked exploding-heads.com exploding-heads.com has not blocked lemmy.ml
This means exploding-heads users can subscribe to communities on lemmy.ml but not contribute to them (post or comment)
So here is the problem, when creating a post on exploding-heads.com and selecting the community from the community search/drop down box - the communities you are presented with to choose from include communities on Lemmy.ml to which you are not allowed to post or comment. I do not think they should be presented to you i for whatever reason you are not allowed to contribute - either the instance of which you are a member is blocked or you personally are blocked.
If you do select the lemmy.ml instance, then you are not given any error message either - the post just goes nowhere without you knowing.
I believe, but do not know for a fact, the same applies to personal messages e.g. I would be allowed to select a user of lemmy.ml to send a message to - but unbeknownst to me they would never get it if the instance I am a member of is blocked by the instance the proposed recipient is a member of. I do not think Lemmy should be in the business of blocking one on one personal communications. Leave it to the recipient to decide and ban the send if appropriate.
@Nutomic all these federation actions are async correct? It might be necessary to move a federation check to the API, in order to return a "Instance has been blocked" error.
Yes this one is tricky. Federated actions are sent in a background thread, and its possible that they fail and get retried after some hours. So there is no real possibility to wait for an error from the remote instance. One solution would be to federate the allowlist/blocklist between instances, so the sending instance can check if federation is permitted.
The way that instance blocks work is that they block all communication with that instance. So making an exception for private messages is not really feasible.
Could we tag in someone from another apub project to ask how they handle this? Maybe @asonix has some ideas.
I'm not sure about a good solution to this either. One option would be sending a Block activity to the blocked instance after an instance block so they know not to present blocked content, but I haven't thought too much about this specific scenario
@Kap2022 As a workaround, it should help to block lemmy.ml from your side as well.
Stale issue, and I don't think there's any way around this short of fetching every remote blocklist.