What?

“I’m allowed to lie to you and then set a boundary that you can’t probe the lie when you sense something is amiss” is some top-tier manipulation. You skipped straight past D and A, and came with RVO right out of the gate.

If you had said pretty much exactly what you said, but then followed it up with “But of course, you forfeited your right to police the other person’s behavior when you started lying to them about important things, so none of this generally-sensible advice applies in your case” I would actually agree with you. Nothing in the advice is really totally off-base. But, also, don’t lie about big stuff.

Incorrect. She will sense something amiss and keep digging.

Maybe this sounds like sexism, but in my experience you cannot outsmart women about this type of stuff. Whatever deception your male brain comes up with will be like a 4-year-old trying to play chess with an adult.

Trying to continue the deception, now that you fucked up by attempting it for some reason, won’t work. Refusing to talk about it won’t work. Admitting you lied to her definitely won’t work. Hiring a random woman to pretend to be your ex won’t work. Faking your own death to escape the situation won’t work. Going back in time and dating a real person and then incepting her memories so that she remembers you talking about this other real person won’t work.

How do you win, then? You make decent money, you keep yourself fit and generally do what you’re supposed to do, and you lose arguments and get outsmarted sometimes. All of a sudden shit will be fine. That is the winning.

Lol

I’m happy with what I’ve posted so far. Part of the reason I engage in this stuff in the first place is that it is useful to learn things by having people assert them to me or challenge other things I am saying, and then I can go and look up what the actual truth is, see what other people say, go back and forth about it a little bit.

You and me have long since passed the point where it’s productive, though, on this topic. I wish you the best.

Oh yeah, that side of it made perfect sense to me, like I said.

What the commenter was saying was a little bit different though. They said they, as a Canadian, were upset with the heinous nature of the Democratic party, and then they were sick of obnoxious Americans coming to their town and trying to defend the Democrats. And, also, there’s a housing crisis, and immigrants are making it worse.

If they’d said what you said, I would have been far less suspicious about what they were saying. They did switch after the fact to saying that they were sick of Americans who were using being Democrats as a shield against criticism of their country, which again makes good sense to me.

Hey, that’s a really good point. I think I should go back to the ActivityPub spec, look up what is the exact behavior for this kind of thing, go into the Mastodon code, see what it’s doing, in what areas its behavior is mandated by the spec and in what areas they were just doing their own implementation, basically make sure I am fully educated on the issue, and then have Claude write up a full comparative analysis in bullet points, with sources so everyone can verify, to make absolutely sure that it can be clearly seen by anyone who wants to take the time to verify, that I’m right about this.

I’ll get right on that. It sure would be a waste of time if, instead of that, I just kept repeating over and over and over, what my point of view was. That would be a huge waste of time. I definitely won’t do that.

That’s not really how election laws work. There are a ton of different things large and small that powerful people can do to distort the equation “people learn what’s going on -> people vote for good outcomes -> good outcomes happen” and a lot of American democracy comes from people making deliberate efforts to try to preserve the functioning of that system. Just having “you can vote” and calling it good is no guarantee of anything at all. People in Russia can vote with secret ballots, for example.

Sir, we’ve had complaints from some of the other patrons. Can you just go back to your seat and quiet down?

even without this flaw ActivityPub is not the way to go for anything private.

This is the real issue. The whole story about how his partner’s posts were getting shown to random people should have ended with both of them realizing that these posts were in no reliable way “private,” and to stop putting them up with the assumption that they would be. Not with them yelling at Pixelfed for the way it works, and then yelling at Pixelfed again for starting to honor these fake privacy settings.

I so much miss old YouTube.

I did a whole analysis of what the spec actually says, how it relates to “private” posts, and Mastodon’s implementation details. TL;DR they just made things up and it’s a huge disservice to Mastodon users to give people the impression that these posts are private.

Did I? I don’t even remember this… if I did volunteer I don’t think it ever went anywhere no.

We’ve had this technology for years

Or, she’s working with the US government in some secret capacity and now thanks to Trump they know about it.

It could just be random. But either one is a strong possibility, and Putin’s involvement seems likely.

I was planning to just give it a rest, since we were going in circles, but you wandered into several additional comments sections and replied to me in all of them with a couple of new arguments, so I decided I would respond.

They’re really not.

Here’s the relevant docs, and a little summary of how they relate to private posts and Mastodon’s specific implementation of them.

Specs: https://www.w3.org/TR/activitypub/#delivery

Mastodon code where you can verify that this is how they are handled: https://github.com/mastodon/mastodon/blob/main/app/lib/activitypub/tag_manager.rb (look at the cc() and to() functions)

Overall summary in detail:

ActivityPub Specification

What ActivityPub Explicitly Mandates

1. Audience Targeting (Section 5.1):

   • Activities must include audience targeting fields (to, cc, etc.)
   • Servers must deliver activities to the specified audiences

2. Public Posts (Section 7.1.2 and 7.1.3):

   • Activities addressed to the Public collection must be delivered to all followers
   • Servers MAY deliver Public activities to all known sharedInbox endpoints

3. Filtering (Sections 5.2 and 7.1.2):

   • Servers SHOULD filter inbox content according to the requester’s permissions
   • Servers MAY filter delivery targets according to implementation-specific rules

4. Privacy of Non-Addressed Content (Section 7.1 Note on “Silent and private activities”):

   • For activities with no recipients, it’s “recommended” (not required) that objects remain private
   • An activity sent only to the “public” collection should be viewable in the actor’s outbox but not delivered to any actors

What ActivityPub Leaves Undefined

1. Visibility Levels:

   • No explicit definitions for “public,” “unlisted,” “private,” or “direct” as formal visibility modes
   • No mandatory behavioral requirements for different audience targeting patterns

2. Privacy Enforcement:

   • No explicit requirements for how receiving servers should restrict visibility based on audience fields
   • No requirements that servers must hide content from non-addressed users

3. Timeline Placement:

   • No specification about which posts should appear in public timelines vs. home timelines

Mastodon’s Implementation

Visibility Levels in Mastodon

Mastodon implements four primary visibility levels:

1. Public

   • UI Name: “Public”
   • ActivityPub Implementation:
     • to: [“https://www.w3.org/ns/activitystreams#Public”]
     • cc: [“https://example.com/users/username/followers”]
   • Behavior: Visible to everyone, appears in public timelines

2. Unlisted

   • UI Name: “Unlisted” or “Quiet public” (newer versions)
   • ActivityPub Implementation:
     • to: [“https://example.com/users/username/followers”]
     • cc: [“https://www.w3.org/ns/activitystreams#Public”]
   • Behavior: Visible to everyone but doesn’t appear in public timelines

3. Private

   • UI Name: “Followers-only”
   • ActivityPub Implementation:
     • to: [“https://example.com/users/username/followers”]
     • cc: [] (empty)
   • Behavior: Only visible to followers

4. Direct

   • UI Name: “Mentioned people only”
   • ActivityPub Implementation:
     • to: [array of mentioned user URLs]
     • cc: [] (empty)
   • Behavior: Only visible to mentioned users

Key Implementation Details

1. Visibility Through Addressing:

   • Mastodon uses the to and cc fields to indicate intended visibility
   • The presence and position of the Public collection determines visibility level
   • No explicit “visibility” property is included in ActivityPub messages

2. Convention-Based Visibility:

   • The difference between “public” and “unlisted” is determined by whether the Public collection is in to (public) or cc (unlisted)
   • This is a convention defined by Mastodon, not explicitly required by the spec

I also sent a user-targeted explanation of how Mastodon’s privacy settings work, that might be helpful for you to read. You can probably find it in my profile.

Lol

Here’s the relevant section of this quite good explanation of how Mastodon’s privacy settings operate:

https://marrus-sh.github.io/mastodon-info/everything-you-need-to-know-about-privacy-v1.3-020170427.html

Something you may not know about Mastodon’s privacy settings is that they are recommendations, not demands. This means that it is up to each individual server whether or not it chooses to enforce them. For example, you may mark your post with unlisted, which indicates that servers shouldn’t display the post on their global timelines, but servers which don’t implement the unlisted privacy setting still can (and do).

Servers don’t necessarily disregard Mastodon’s privacy settings for malicious reasons. Mastodon’s privacy settings aren’t a part of the original OStatus protocol, and servers which don’t run a recent version of the Mastodon software simply aren’t configured to recognize them. This means that unlisted, private, or even direct posts may end up in places you didn’t expect on one of these servers—like in the public timeline, or a user’s reblogs.

That’s the explanation. You’ve been persistently pretending to fail to understand it, but it’s honestly pretty straightforward and clear. And now you’re following me into new comments threads to try to restart the argument in new places. Great stuff.

Of course it’s a good thing if Pixelfed wants to start to honor these advisory privacy settings, and I can understand why Dansup gave a high priority to the fix starting to honor them. That doesn’t mean that it’s Pixelfed’s “fault” that this happened in the first place. That’s all I was saying.

I’m not sure I would go that far. A lot of “trust and safety” type things are like this, just soft boundaries to try to shape the types of interactions people are going to get themselves into to be a little more on the pleasant side. There’s nothing wrong with Pixelfed trying to show some honor to the same advisory boundary. The real problem comes into it when projects like Mastodon start giving people the impression that “private” posts that are federated out are going to be able to stay private. As long as the user expectation is clear that it’s just an advisory setting that will tweak the algorithms for showing the post in non-assurable ways, it is fine.

Oh, you feel like repeated postings of exactly the same thing is unnecessary? Funny about that, I had a similar reaction.