-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document handling replies #400
Comments
The ActivityPub spec does not describe / implement a 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.
This is a fully incorrect reading of the spec, it says no such thing. Instead, what the spec says is:
That is: if the server 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 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 |
@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 |
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-replies |
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:
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 thereplies
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 thereplies
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.
The text was updated successfully, but these errors were encountered: