Closed steve-bate closed 1 week ago
The idea was the only put into ActivityPubNode behaviors that are clearly specified in the ActivityPub spec, but put all others into grab-bag FediverseNode. That's in order to avoid that somebody who has implemented ActivityPub, but not for the purpose of interoperating with Mastodon etc., gets up and says "but the spec doesn't require that".
That doesn't mean I got it right which is which. Lots of them -- the ones we have, and more to come -- are judgment calls imho.
The idea was the only put into ActivityPubNode behaviors that are clearly specified in the ActivityPub spec ...
I thought it might be something like that, but the operations I listed are defined in the ActivityPub spec, so I wasn't sure. For example,
def make_a_follow_b(self, a_uri_here: str, b_uri_there: str, node_there: ActivityPubNode) -> None:
is explicitly dependent on an ActivityPubNode
. I think it would be better to move these "interface" methods into the ActivityPubNode
. It's not clear to me that we need a FediverseNode
type at this point.
Let's deal with this after #273
This is now a "system" test functionality rather than a "protocol" test functionality, so it's in the right place.
These seem to be ActivityPubNode operations:
make_create_note
wait_for_object_in_inbox
make_announce_object
make_reply
make_a_follow_b