Question: Why are make_create_note, etc., on FediverseNode instead of ActivityPubNode?

[steve-bate]

These seem to be ActivityPubNode operations:

• make_create_note
• wait_for_object_in_inbox
• make_announce_object
• make_reply
• make_a_follow_b

[jernst]

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.

[steve-bate]

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.

[jernst]

Let's deal with this after #273

[jernst]

This is now a "system" test functionality rather than a "protocol" test functionality, so it's in the right place.