okay who's the patient zero for this “fedi should have no admins” take and why does it sound like something a repressed power-grabber would say

@flussence sounds a lot like the "Mastodon shouldn't federate blocks" thing someone posted on the issue tracker

@ben @flussence Mastodon shouldn't federate blocks, it should federate the side effect.

@kaniini @flussence how do you propose that Mastodon federate "this user can't see this public post but other users can"

@alexa @ben @flussence @kaniini if i understand correctly, the only time something would federate in this situation is if you blocked a user that follows you
The problem is that Mastodon federates blocks to prevent you from seeing a user's public posts when they block you. Federating the "remove follow" is fine.
@ben @flussence @kaniini
What'd you test? That's how it's worked, or at least, how it's supposed to work.
@ben @flussence @kaniini
@alexa @nik @ben @flussence @kaniini
> Federating the "remove follow" is fine.
I disagree with that. Federating the remove follow should only work if your user has to manually accept who it can be followed by.
@Mikoto @alexa @ben @flussence @kaniini why? even on a public account, AP mandates that the newly followed account sends an Accept Follow to confirm the follow
You can remove followers without blocking them now, this is just doing that by default (having a locked account means nothing except for an icon).
@ben @flussence @kaniini @nik
Not sure on Pleroma, on Mastodon you can do it in your settings.
@Mikoto @ben @flussence @kaniini

@Mikoto @alexa @ben @flussence @nik

as:manuallyApprovesFollowers is a UX hint only.

all relationships are ACKed by the server, and you are explicitly disallowed from following users who have blocked you in the AP spec. blocks must deny any interaction.

@kaniini @alexa @ben @flussence @nik I see. IMO, it would only make sense to have manual approves and force-unfollows only if there was an implementation of manual approves that also encrypted every follower-only post with a key shared only between the manually approved followers. Otherwise I think that both manually approved followers and the existence of block itself is an anti-feature that can be circumvented by just running your own modified server software.

@nik @alexa @kaniini

because all I'm hearing is "Mastodon should remove blocks as a feature" unless someone can explain to me how hiding public posts from one user on another instance would work without telling that instance

No, that wouldn't and shouldn't work. It's anti-user.
@nik @kaniini
@ben @alexa @kaniini im confused what you're saying here, are you saying that if nik@lall blocks, will stop seeing nik@lall's posts?

because mastodon doesn't do this

@nik @alexa @kaniini mastodon does do that

other instance types ignore it, but telling mastodon to stop federating it is telling mastodon to also ignore it

@ben @nik @alexa

yes, and it should, it's bad design that leads to people adopting bad security postures based on the belief that the security anti-feature is meaningful.

security 'features' that can be bypassed simply by viewing the remote profile directly are not 'features'

@kaniini @alexa @nik ... fixing the security feature is the solution

not deleting it

@ben @kaniini @alexa the security feature we have right now is followers-only posts, it works
@ben @alexa @nik

you cannot fix this "feature."

let me explain.

if you block me, i can go to and still browse your posts.

nobody who cares enough to stalk you is deterred by this restriction.

it's a bad feature. it needs to be removed. it leads people to believe things are safe when they aren't.

@kaniini @alexa @nik

I could put my instance in whitelist-only mode right now.

What exactly is your definition of a block that differs from not having someone follow you, exactly?

@ben @alexa @nik

okay, and? if you do it, i can still browse your public profile. stalking complete.

@kaniini @alexa @nik

I don't think you understand what I just said

there doesn't need to be a public profile

Mastodon already supports turning it off

@ben @alexa @kaniini i.............what

if Objects cannot be accessed via GET, it would break so much
@ben @alexa @kaniini unless you're dealing only with followers-only posts, which makes all of these other "security features" unnecessary
Show more

@ben How do you think federation works? If you do this, you’re lying if you claim your post is as:Public, as it’ll effectively be followers only @nik @kaniini

@ben @nik @alexa

fundamentally, the feature is broken from a security POV anyway, because it depends on the recipient server *lying* to the recipient about the existence of your data.

@nik I swear his next argument is that you don’t need to address it to as:Public and it’s like, yes, that’s the point. @ben @kaniini

@kaniini @ben @alexa @nik is there something expensive on the application side that makes keeping blocks (as we typically understand them in their twitter-esque form) around? I'm trying to understand why it's such a big deal since you can maintain the functionality but also make it clear "hey, this doesn't really protect you" similar to what we have to do with DM's.

Because, just in terms of using the application, it doesn't seem completely trivial to be able to stop someone from seeing and interacting with my stuff in-app.
@kaniini @ben @alexa @nik
> it's a bad feature. it needs to be removed
Just wondering, why don't you remove it then?
@ben @alexa @kaniini wait what

i just blocked my account and that account can still see my posts here
@ben @nik @alexa

that isn't a feature, that's trying to impersonate twitter in a network model where it is trivially bypassed (in fact that 'feature' is trivially bypassed on twitter too)

the side effect that needs to federate is the unsubscribe part.

trying to hide public posts is pointless.

@kaniini @alexa @nik what I'm hearing is "some people can get around the restriction with custom-built software and therefore we should remove the restriction from all existing software"

@ben @alexa @nik

well, that's a stupid take, mastodon should remove the restriction because the restriction is pointless. it needs no further justification than that.
@ben @kaniini @alexa no, they're not getting around the restriction with custom built software, they're getting around it by *viewing a person's public profile*

@nik @alexa @kaniini oh, you're talking about the public web interface?

yeah, that's still a way around it, but that's a different problem

I think that trying to prevent people from seeing or interacting with public posts is way more effort than it's worth.
@ben @flussence @kaniini
@alexa @ben @flussence @kaniini if you block someone that follows you, your instance should federate something that will force that user to unfollow you (be it reject follow or block)

@nik @alexa @ben @flussence @kaniini
> if you block someone that follows you, your instance should federate something that will force that user to unfollow you (be it reject follow or block)
Good idea, then these can be detected and drive a bot that screenshots their public posts and posts them to be made fun of.

@BillShortening @alexa @ben @flussence @kaniini okay, let's not federate anything, and allow the user you just blocked to continue seeing your new followers only posts
@BillShortening @alexa @ben @flussence @kaniini no it doesn't, because currently, federated blocks force an unfollow
@BillShortening @alexa @ben @flussence @kaniini the discussion here was the idea of switching from federating a Block to every user you blocked (bad) to sending a Reject Follow to users that are following you that you block (and nothing to users that aren't following you)
Sign in to participate in the conversation is an any-topic moderated Mastodon instance made by me, Ami. Hosted in Roubaix, France.