social.coop is one of the many independent Mastodon servers you can use to participate in the fediverse.
A Fediverse instance for people interested in cooperative and collective projects. If you are interested in joining our community, please apply at https://join.social.coop/registration-form.html.

Administered by:

Server stats:

492
active users

dynamic

Why is it so hard to find documentation on what (if any) consequence "Limit" level moderation of an instance has on the Limited instance's ability to view content from the Limiting instance?

All that the JoinMastodon documentation page (docs.joinmastodon.org/admin/mo) seems to say is "At this moment, limit does not affect federation."

Does anyone have more specific information on this?

(boosts welcome)

docs.joinmastodon.orgModeration actions - Mastodon documentationActions that can be taken against unwanted users or domains.

@dynamic limit is like a mass silence.

They can see all your stuff, but your users only see things from users they follow, and any users from that instance get stuck behind a follow request.

@ajroach42

So does instance level "Limit" do the same thing as an individual-level "Block" by all members of the Limiting instance against all members of the Limited instance?

Also, is there specific documentation on this?

(and thanks!)

@dynamic if you don't have authorized fetch enabled, limit is roughly equivalent to instance wide block.

If you do have authorized fetch enabled, it is more aggressive, preventing posts from your instance from secondary federation (boosted in to) the limited instance.

I haven't seen any good docs on it, I've just been doing this for 7 years.

@ajroach42

Glad to hear a voice of experience. One question that I have is whether---if this isn't part of the documented expected behavior---if this is something that could be silently switched around in a future version of Mastodon without people realizing until afterward.

@ajroach42

Wait, "authorized fetch" makes the Limit *more* restrictive?

Also... are you saying that a Block doesn't protect posts from secondary federation (being boosted into a blocked instance)?

@dynamic oof sorry, it's early and I'm mixing words.

Suspend works like block.

Limit works like silence.

Limited instances still get all your posts and follow/follower relationships are preserved.

Suspend gets stronger with authorized fetch, without authorized fetch posts can be boosted in to suspended instances.

Suspend breaks all follow/follower relationships.

@dynamic I'm sure it is documented somewhere, I just don't know where.

Behavior of authorized fetch was changed in 4.0 branch.

@ajroach42

I'm surprised to learn that Suspend by itself doesn't protect against secondary federation.

Getting back to what you'd originally said, is it correct to say that from the perspective of users on a Limited instance, all users in the Limiting instance behave as though they have "Require follow requests" turned on?

@dynamic

> is it correct to say that from the perspective of users on a Limited instance, all users in the Limiting instance behave as though they have "Require follow requests" turned on

Yes. Existing follow/follower relationships are preserved, and new ones become follow requests.

If I go to a profile on, for example, Mastodon.social it says "This profile has been hidden by the moderators of retro.social." and then gives me a "show profile anyway" button.

@dynamic

> I'm surprised to learn that Suspend by itself doesn't protect against secondary federation.

Lots of people were.

A suspend or a block is contingent on the receiving server respecting that suspend or block. It is a suggestion, not a requirement. Pleroma, for years and possibly still now, ignored that suggestion.

If the content is still Public it can be fetched through the public API. The user doesn't have to specify where they are pulling from. Hence, AIUI, authorized fetch, which requires public API users to be authorized.

As I recall, the argument went: Public content is public, we're not going to verify that the receiver is authorized when they could just go to the web.

and the counter argument went:
Wow, please don't make it any easier for me to be harassed.

and, for various reasons, the authorized fetch compromise was born.