@nightpool @bug a known bug, which is known to be fixed.

@kaniini @nightpool @bug also, once again, not entirely a pleroma problem. You could make fairly trivial modifications to any activitypub compliant server software and run it as an instance and achieve this easily, so it's nonsense that people have been blaming this on pleroma.

@pea It's not a pleroma problem that pleroma shipped a non-compliant implementation of activitypub for months? what?

You could also run an email server that made every email public, easily, but people would still say that it was your problem when they found it out.

@nightpool wut

noncompliant? have you read the activitypub spec? If so point out where it includes blocking or privacy settings

I don't know how you've gone so long without finding this out, but you can't trust remote servers to do everything exactly how you expect. They could be running anything. It's a flaw in mastodon in the first place expecting an external server to do exactly "what it's supposed to do" and it's doubly problematic that there's no document published talking about everything that's nonstandard in mastodon and how it should be handled in other server implementations.

@pea

....

i literally wrote the document you're asking about. I wrote a document about all of mastodon's non-standard behaviors and published it with mastodon's implementation report.

Also, did you miss "Targets for delivery are determined by checking the ActivityStreams audience targeting; namely, the to, bto, cc, bcc, and audience fields of the activity"

@pea or perhaps or perhaps "In the case of receiving an Accept referencing this Follow as the object, the server SHOULD add the actor to the object actor's Followers Collection. In the case of a Reject, the server MUST NOT add the actor to the object actor's Followers Collection."

@nightpool I'm not really sure what the part you're quoting has to do with blocking

@pea (which is the actual requirement pleroma was violating, they completely ignored accept/reject until this was pointed out to them as a privacy problem)

@nightpool also apologies for missing that then, i'd never seen that document and i'd hunted one down for a bit

@nightpool either way, nothing is insured when you're using a protocol like ActivityPub. In the end MUST is just a word and not an inviolable rule

@nightpool a Bad Actor can break those rules at any time, and it's up to implementations to guard against that when possible

@pea which mastodon does? It only sends posts to people that can see them, and we have moderation tools for when people things in ways the software can't prevent. (remote servers sharing posts without proper authorization)

@pea I don't understand what "a protocol like activitypub" is doing here. Even if this was the perfect e2e encrypted protocol, it wouldn't prevent a bad actor like the followbot had from re-publishing all private posts publicly.

@nightpool @pea or other ways, the followbots are just a visible one. When you start to take a look at your nginx|apache|caddy access logs, you can clearly see that it's only the tip of the iceberg...

@gled @pea what does that have to do with accessing private posts.

@nightpool @gled @pea just signaling that there are many ways of accessing 'private' posts, no expectation to be had on that at the moment, that's all :)

@gled @pea you can't access private posts by requesting them unless you're already a valid follower, authenticated with HTTP signatures?

@nightpool @gled @pea not everywhere unfortunately, a lot of leaks have been plugged though I suspect a few are left ( I will come back once I have certitudes, I am currently investigating 2 weird behaviors ). Oh and not to mention the 2 instances that left their ES wide open ;)

@gled well, if you find any information that you think is important, you know how to reach me and/or gargron.

@nightpool I was more referring to the follow requests bit but w/e