backend: implement not forwarding block activities #212
Johann150
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "non-federating-blocks"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Fixes #211
Commits pulled from https://github.com/misskey-dev/misskey/pull/7799
Todo:
Make Block sending opt-in, not opt-out.Changed back to federating blocks by default.Changelog: Added
backend: implement not forwarding block activitiesto WIP: backend: implement not forwarding block activitiescce6973326e6a13c177dWIP: backend: implement not forwarding block activitiesto backend: implement not forwarding block activitiesI suggest squashing this PR when merging, with
Co-authored-bytrailers of course.I know the spec says "SHOULD NOT" but that's fairly permissive, and there are many good reasons to send them out (that have been discussed previously in IRC).
Otherwise this is fine imo - letting users pick is all well and good, it just should be on by default for people that do not care (rather than off, which leads to some fairly bad scenarios).
2a42a4114730a192bdf130a192bdf1b4a83bea38Ok, I should have those concerns addressed.
@ -0,0 +1,14 @@import {MigrationInterface, QueryRunner} from "typeorm";I think this migration should be adapted to how the other migrations look. I.e. plain javascript, therefore no need for this import.
There should be no type annotations and the file extension should be
.js.@ -28,3 +28,3 @@// deliver if remote blokingif (Users.isLocalUser(blocker) && Users.isRemoteUser(blockee)) {if (Users.isLocalUser(blocker) && Users.isRemoteUser(blockee) && blocker.federateBlocks) {This could lead to problems if the block was federated but the user later decides blocks should not be federated and then the unblock is not federated.
Since I think unblocks must signify some level of trust it should always be okay to federate them. Or otherwise, whether the block was federated or not should be stored in the database.
@ -335,6 +335,7 @@ export const UserRepository = db.getRepository(User).extend({isLocked: user.isLocked,isSilenced: user.isSilenced || falsy,isSuspended: user.isSuspended || falsy,federateBlocks: user!.federateBlocks,I think it might be a better idea to move this to the
opts.detail && isMepart further down. I.e. not show this publicly since we've also stopped showing blocked instances publicly.16c9647597557885a720557885a720667d791c85