It sucks that activitypub is so under specified.

marius

The replies collection[1] present on Objects contains (what to me looks like) enough information for establishing the relationship between a received Object's inReplyTo property and the replies collection itself.

Is that too little information for your needs? What else do you require?

[1] https://www.w3.org/TR/activitystreams-vocabulary/#dfn-replies

Jenniferplusplus

@mariusor i can read the vocabulary. It doesn't describe any behavior. What is the actual message that would cause a new reply from a second party to appear in the original object's replies collection? Where should that message be sent? How would anyone else know it happened and was accepted?

marius

@jenniferplusplus sorry to be an ass about this, but it feels like you're not cooking with your heart.

It's not spelled out for us but it's clear from reading the spec(s) that the message needs to be "sent" from the server where the reply comes from to the server where the original is. Therefore the client of the reply guy actor needs to add the original's attributedTo actor to the list of recipients if it wasn't already there.

Anyone else would know it happened if they were also in the recipients list, or when their client retrieves the replies collection of the original.

Helge

Just sliding in here, as I consider having a proper replies specification important and the way ActivityPub handles it: Just plain wrong.

Having a proper replies specification is important due to: Well it's a hard problem, and popular implementations like Mastodon handle replies in a way that is IMO wrong. What is wrong with Mastodon's replies, you ask? Take your reply. It is addressed to

  "cc": [
    "https://metalhead.club/users/mariusor/followers",
    "https://hachyderm.io/users/jenniferplusplus"
  ],

whereas Jennifer's are addressed to her own follower's collection. A correct behavior would be all posts addressed to Jennifer's followers collection. Not this alternating stuff.

So if AP was a proper spec, I could open a bug ticket against Mastodon. Currently, it's just my opinion. I would even go so far as Mastodon having quote-toots faking being replies due to this behavior.

Jenniferplusplus

@mariusor this is supposed to be a formal technical specification for a communication protocol. I shouldn't have to guess. I shouldn't even be able to guess. "Cooking with your heart" is fine for recipes, not computers. That's how we wound up with a dozen mostly incompatible implementations. That's why we can't move forward on harmonizing those incompatibilities.

marius

@helge addressing is up to the client. In my opinion there's no "wrong" way to do it. The authors of the Activities should be the ultimate arbiters of whom receives it. The fact that Mastodon (and most of the clients) in the fediverse hide this option is the *actual* problem in my opinion.

@jenniferplusplus

marius

@jenniferplusplus there's no formal specification for activities addressing because, like I replied to Helge, it's up to the author and their client to determine whom it gets delivered to.

That's why the specification tells us about what happens when receiving objects/activities with inReplyTo populated, but not how one finds where to send them.

To me it makes perfect sense, but I'll grant you that I might be missing things.

Jenniferplusplus

@mariusor the only specified behavior for receiving an activity on an object with an inteplyto value is to consider that value for inbox forwarding.

Jenniferplusplus

@helge @mariusor I'm not actually sure I agree that's how it *should* work. But my point is that it shouldn't even be possible to have this disagreement. The specification should specify these things. We could then like it, or not. We could use it, or not. But we couldn't argue about whether something is good, or correct, or valid. Not for such huge and fundamental parts of the spec. The time for that was while the spec was being written.

The Nexus of Privacy

Does that mean Undo(Block(Undo)) is also valid? And (Block(Undo(Block(Undo)))?

@hrefna @jenniferplusplus @ivy

Jenniferplusplus

@thenexusofprivacy @hrefna @ivy it's very difficult to produce an invalid AP document. It's a little more interesting to discuss whether it's meaningful or legible, but that's a matter of convention, not specification.