we’ve been spending a bunch of time already during the last days to get a solution in place on our end that will allow us to selectively reject federated activities from kbin, such as allowing comments and posts while rejecting votes, which seem to be the main issue currently, but we’re seeing some stability issues with this currently.
we’re planning to unban the affected users from the communities once we have this stabilized, as we currently have to pick between
defederate from kbin.social (and other kbin instances when they are affected)
reject all inbound activities from affected instances
temporarily ban affected users in the communities associated with the issue
drop all activities with certain characteristics, such as votes, when coming from a specific instance
drop all activities with certain characteristics, such as votes, when coming from a specific instance and exceeding a rate limit
1-3 are all options we can do with existing tools, 4 and 5 require a custom implementation on our side. as 3. has the least overall impact of those we decided to go with 3 for now, which seems to work out rather well so far, except for the individual user experience of affected users.
4. has been our primary focus to implement currently, but it takes time to ensure this works as expected, as we’re essentially building this from scratch. 5. may be implemented afterwards if we want to spend additional time on it.
see https://lemmy.world/comment/8961882 for now.
we’ve been spending a bunch of time already during the last days to get a solution in place on our end that will allow us to selectively reject federated activities from kbin, such as allowing comments and posts while rejecting votes, which seem to be the main issue currently, but we’re seeing some stability issues with this currently.
we’re planning to unban the affected users from the communities once we have this stabilized, as we currently have to pick between
1-3 are all options we can do with existing tools, 4 and 5 require a custom implementation on our side. as 3. has the least overall impact of those we decided to go with 3 for now, which seems to work out rather well so far, except for the individual user experience of affected users.
4. has been our primary focus to implement currently, but it takes time to ensure this works as expected, as we’re essentially building this from scratch. 5. may be implemented afterwards if we want to spend additional time on it.