Boosts are federated to instances that have been suspended (blocked) by the original author's instance

[fallerOfFalls]

awoo.space works around this problem by requiring all instances they federate with to block/suspend the worst offending instances.

Ideally, a boost would not be sent to instances that are suspended by the instance from which the toot originated.

Crom explains better in this thread.

---

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.
• This bug happens on a tagged release and not on master (If you're a user, don't worry about this).

[Gargron]

Sorry but there is no way this is possible. A boost is basically a copy of the original message, embedded in another message. You can't control where the copy goes once it's out.

[Gargron]

Sorry but there is no way this is possible. A boost is basically a copy of the original message, embedded in another message. You can't control where the copy goes once it's out.

[fallerOfFalls]

I think there may be a misunderstanding here.

Obviously there's no way to control a toot once it's on someone else's instance. That's not what I'm suggesting.

But just as a respectful user can refrain from boosting an awoo toot, if they know it would be seen by users of an instance that awoo blocks, so could a respectful instance (at least theoretically) refrain from showing awoo toots to those instances.

We're not talking about awoo controlling their own toots once they are on another instances, we are talking about how other instances are coded to federate those toots. A malicious instance can do whatever, but a respectful instance can take care of the toots they've received from sensitive instances. Can instances be coded to be respectful of toot authors' instance blocks?

[fallerOfFalls]

I think there may be a misunderstanding here.

Obviously there's no way to control a toot once it's on someone else's instance. That's not what I'm suggesting.

But just as a respectful user can refrain from boosting an awoo toot, if they know it would be seen by users of an instance that awoo blocks, so could a respectful instance (at least theoretically) refrain from showing awoo toots to those instances.

We're not talking about awoo controlling their own toots once they are on another instances, we are talking about how other instances are coded to federate those toots. A malicious instance can do whatever, but a respectful instance can take care of the toots they've received from sensitive instances. Can instances be coded to be respectful of toot authors' instance blocks?

[sterdev]

we are talking about how other instances are coded to federate those toots

Do you realise that this goes entirely out of the scope of Mastodon? There are GNU social, postActiv, friendica, and soon pleroma. Are you telling that we should code the status-blocking mumbojumbo for all of these?

Personally if awoo blocked my instance and I wanted to block their posts, I'd just block awoo myself.

[sterdev]

we are talking about how other instances are coded to federate those toots

Do you realise that this goes entirely out of the scope of Mastodon? There are GNU social, postActiv, friendica, and soon pleroma. Are you telling that we should code the status-blocking mumbojumbo for all of these?

Personally if awoo blocked my instance and I wanted to block their posts, I'd just block awoo myself.

[Cassolotl]

That's the case for DMs and private toots on Mastodon already - as soon as they hit a non-Mastodon instance they're public and repostable. I'm not saying anything for or against the original idea, I'm just saying... Mastodon devs have already shown they'll make features that federate questionably.

[Cassolotl]

That's the case for DMs and private toots on Mastodon already - as soon as they hit a non-Mastodon instance they're public and repostable. I'm not saying anything for or against the original idea, I'm just saying... Mastodon devs have already shown they'll make features that federate questionably.

[sterdev]

@Cassolotl Yeah, that's true. The only solution for the user in this case is not contacting with instances other than Mastodon, while from the perspective of developer it would probably require reimplementing the backend stuff, effectively destroying the compatibility with every other OStatus implementation.

[sterdev]

@Cassolotl Yeah, that's true. The only solution for the user in this case is not contacting with instances other than Mastodon, while from the perspective of developer it would probably require reimplementing the backend stuff, effectively destroying the compatibility with every other OStatus implementation.

[Cassolotl]

@sterbfly That sounds about right. :S Not ideal!

[Cassolotl]

@sterbfly That sounds about right. :S Not ideal!

[Gargron]

Can instances be coded to be respectful of toot authors' instance blocks?

This would require:

1. to leak the origin instance's blocks openly (questionable consequences)
2. to encode such information with every message (new spec required)

I don't think that presents a feasable feature, unfortunately.

[Gargron]

Can instances be coded to be respectful of toot authors' instance blocks?

This would require:

1. to leak the origin instance's blocks openly (questionable consequences)
2. to encode such information with every message (new spec required)

I don't think that presents a feasable feature, unfortunately.