That’s by design. It could be due to spam/DDOS protections on the forwarding server’s side so it doesn’t become a spam zombie on behalf of another server. Or because the forwarding server (or actor on that instance) has determined that the content is harmful and doesn’t want to propagate it.
Once OCAP is in ActivityPub, the latter becomes even easier to enforce and reject system wide.
Sure. Everything is known to the state of California to cause cancer, too. But you’re discarding a well-established solution with big warning signs printed in the spec about it (inbox forwarding), and going with a custom solution where you’ll have to rethink all of these interactions.
This is the exact definition of the “ghost reply problem” that inbox forwarding intends to solve.
Inbox forwarding does have the origin actor that the local actor is following, send the Activity to that local actor. However, it’s someone else’s Activity. That’s good because the local actor can now fetch that Activity on the remote peer to make sure it’s not a lie, and process its raw side effects in situ.
ActivityPub is built on the premise of processing linked data piecemeal, but it sounds like you want to have two conflicting source of truths for a conversation: you have the raw incoming Activities on the one hand, which builds the tree as you go, and on the other you want to have this Collection of everything in the conversation in a linear form. Which begs the question: why? If it’s to easily find all messages in a thread without recursive lookup, others have solved this by using a conversation token (it might look like an IRI, but it’s nothing, not even a collection) for easy DB lookup by index.
I think this is where I see the approach causing technical friction.
And that’s kind of the point, no? The ActivityPub model is that Activities are easy data to interoperate, but implementations can do different things side effect wise. The ones that interoperate well all agree to a baseline that “Create means at least adding it to a cache”, etc, but the other side effect details may differ.
The activity encapsulates this single side effect idea.
Trying to force your apps’ single side effect details into multiple Activities breaks this encapsulation. It is not great design for the health of the ecosystem.
EDIT: There’s also a practical argument to be had: you can’t expect every other federated peer out there to send an
Add to you in the manner you want, so you have to solve your reply-problem without these Activities being sent anyway.