Document handling replies

[dclements]

The current spec defines multiple behaviors without mandating that those behaviors be visible. This was pointed out by Christine Lemmer-Webber a while back and it has proven to be a pain in the sides of people who have tried to write compliance test suites. This is also why compliance tests have often involved a checklist of "do you think you are doing $foo?"

When writing unit tests and even integration and systems tests the best practices advice often include some form of "don't test private methods," "focus on exposed state," or "only test the public API." The idea is that a need to test private methods is often a sign of a structural flaw in the software: it should be on an injected class or similar.

It may only be testable with certain parameters set or with a mocked receiver, but it should be automatically testable rather than relying on a checklist, and it should codify common behaviors.

What's more, the spec does not codify some behaviors at all. This has lead to substantive discussions (/arguments) on how to get some things, such as limiting who can reply to a message, and significant delays in getting these things added to fediverse applications in a way that is cross-compatible:

For example:

• https://github.com/mastodon/mastodon/issues/8565
• https://codeberg.org/fediverse/fep/src/branch/main/fep/5624/fep-5624.md

To underscore this: How am I supposed to handle replies?

I see inReplyTo and… what? I recurse it to contextualize it for forwarding from inbox, but is that how I'm supposed to handle replies? Should I update the replies on the original object? inReplyTo is "owned by the server," but it isn't clear what they are supposed to do with that.

Am I supposed to just send an accept/reject? Should I look for things that Add to the replies Collection? Should I implement replies by giving the objects that can be replied to an inbox and an outbox and having them act (in the classical actor model sense) when they are addressed?

What are the downstream behaviors that I can expect?

It would be incredibly useful to explicitly document the expected range of behaviors here in a way that can be tested.

[nightpool]

The ActivityPub spec does not describe / implement a replies collection. Therefore, any such collection provided by servers are extensions / fully presentational properties that are outside of the scope of the current spec. That's why they're not specified and there's no requirement put on them by the specification.

This is not an issue of "focus on exposed state", because there is no requirement set about replies, full stop. Different servers have different behaviors not because we're "testing a private method", but because this is just not an area that the specification considers or provides guidance for.

inReplyTo is "owned by the server," but it isn't clear what they are supposed to do with that.

This is a fully incorrect reading of the spec, it says no such thing. Instead, what the spec says is:

[T]he server MUST target and deliver to the values of to, cc, and/or audience if and only if all of the following are true: [...] The values of inReplyTo, object, target and/or tag are objects owned by the server

That is: if the server foo.com receive an activity in its inbox that's to: "foo.com/followers" and inReplyTo: "foo.com/post/12312", and it meets all of the other criteria in section 7.1.2, then it must send that activity on to all of the members of the foo.com/followers collection (subject to implementation-specific filtering rules, e.g. spam filtering.)

In this requirement, "owned by the server" just means "has the same domain as the server currently processing it". So "If the object is a reply to an object on the "foo.com" domain, and targeted to a collection on the "foo.com" domain, then you need to act as a relay, and forward it on to the members of that collection" There are no other requirements in the ActivityPub spec that address inReplyTo more than cursorily.

The spec currently does not provide any guidance on how or when a reply should be shown or considered "authorized", since it takes authorization as fully out of its scope beyond the simple cases of same-domain ownership. Any consideration for "disabling" or "disallowing" replies, or other sorts of "reply approval" would need to be fully new extensions

[evanp]

@dclements so, this is helpful advice, but it feels like it starts off very meta, and then gets down to some specifics. I don't know if the first half of your issue is fully actionable.

However, I think the second half definitely is. We can add a page in the ActivityPub Primer that describes how to handle replies from a client side and a server side. I'll put it at https://www.w3.org/wiki/ActivityPub/Primer/Replies .

Essentially, you have the correct idea. The original post's server should keep a list of replies in the replies collection. There's also a loose idea of "inbox forwarding", although I think using an Add or Accept activity is clearer and more useful. So I will write this up, and once it is complete, you can review.

[evanp]

The ActivityPub spec does not describe / implement a replies collection.

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

[trwnh]

Regarding specification of the replies collection and how it behaves, there is also https://w3id.org/fep/7458