Reply notifications

ActivityPub Server to Server
1

Is anyone using an Update activity to notify actors that a reply collection has been updated?

This is the use case that I was thinking about.

  1. actors foo.social/nick and bar.social/mattie follow each other
  2. actors foo.social/nick and baz.town/vanessa follow each other
  3. foo.social/nick creates a note and both folowers receive the create note activity
  4. bar.social/mattie replies to the note and foo.social/nick receives the create note activity
  5. foo.social/nick creates an Update activity with the replies collection as the object to all followers
  6. baz.town/vanessa receives the update activity, connects that the replies collection is associated with the conversation, and requests collection to fill out missing objects of interest
{
  "type": "Update",
  "actor": "https://tavern.town/users/nick",
  "object": "https://tavern.town/objects/799b9617-dace-4510-9b95-7b84f747008a/replies",
  "to": [
    "https://www.w3.org/ns/activitystreams#Public",
    "https://tavern.town/users/nick/followers"
  ]
}
2

Alternatively, the Add activity could be used.

{
  "id": "https://tavern.town/activities/a7433405-a063-4699-b5f8-83785cec838e",
  "type": "Add",
  "actor": "https://tavern.town/users/nick",
  "object": "https://foo.town/objects/8e45a0ff-a957-4165-aaee-e01a56f443ce",
  "target": "https://tavern.town/objects/799b9617-dace-4510-9b95-7b84f747008a/replies",
  "to": [
    "https://www.w3.org/ns/activitystreams#Public",
    "https://tavern.town/users/nick/followers"
  ]
}

In the above example, the actor is the “owner” of the replies collection that the object is being added to.

3

I’m not aware of any because this doesn’t look like it would scale well – I can DDOS someone else by replying to all the people they follow.

4

Plus, I’m not understanding the use case here. The inbox forwarding machanism in ActivityPub should already notify followers of new replies by others.

5

I think it’s worth pointing out that practically any network activity could look like a DDOS attack. I think performance considerations like that should be left to operators. Between server inboxes and deferred activities (activities should be sent +5 minutes from time to allow batching to occur, etc.), reasonable measures can be taken.

The use case is to allow for actors interested in the activity of a conversation, but who aren’t followers of everyone involved in the conversation. Inbox forwarding is another option, yes, and it is worth considering. I would say that an Update or Add activity would be less “noise” because it comes directly from the origin actor that the local actor is following.

6

To follow a conversation in Friendica we are sending the “Follow” activity where the object is the starting post. This then triggers the inbox forwarding.

7

Oh interesting. Does that happen automatically or is that an explicit action by the user/actor?

8

I was thinking about this more and have an issue. It doesn’t provide any context as to why the thing is forwarded. My thought was that an actor may not “accept” someone’s comment as an official reply to their object/note/article/whatever, therefor wouldn’t want it to be relevant to the conversation. The inbox forwarding mechanic is interesting, but it doesn’t help forward the context of the side effects the activity/object had on the actor forwarding it that may be relevant to the audience.

9

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 Update or Add to you in the manner you want, so you have to solve your reply-problem without these Activities being sent anyway.

10

That all makes a lot of sense. I appreciate your thorough reply.