Replies handling missing in Create Activity

[HelgeKrueger]

Concerns 7.2 Create Activity. In particular

Receiving a Create activity in an inbox has surprisingly few side effects;

This glosses over that a Create of an Object having inReplyTo set, should result in said Object being added to the replies collection.

This issue makes reply behavior basically unspecified as far as I can tell.

[bobwyman]

I believe it would be wrong to require that receipt of any Object containing an inReplyTo MUST result in modification to the referenced Object. It is better to leave this as an implementation option.

A few considerations:

• Users have frequently requested an ability to control replies in order to:
  • Control who can and cannot reply to their objects: (i.e. only those followed, only followers, some list of actors, those who reply before some date, etc.).
  • Close all replies for a post: Post-only users, such as news aggregators, bots, etc., who create posts but don't read replies, often say they'd like to disable replies since they don't want to falsely raise an expectation that replies will be read and they don't want the hassle of having to police or moderate replies. Some will want to prohibit all replies to a message, others will want to close replies at some time after a post is created (either manually or based on passage of a set time interval.) Note: On some systems, replies to post-only messages have turned into "secret" points of rendezvous for activity unrelated to the post's intent or content.
• One could reasonably argue that the creator of an Object has some right to control modifications of that Object. But, since the Replies element is contained within the Object, a requirement that it must be modified without the user's consent would seem to diminish the user's control of that Object.
• The subject of the inReplyTo may not be local to the machine that received the Create or it may no longer be available on that instance (i.e. a reply might be received long after the original message was purged or timed out.) Thus, at best, one could say that the Create must modify the object if it is still available.
• If message signing or encryption become supported, it may be found cumbersome to allow modifications to Objects after they are created. Similarly, any attempt to store Objects in something like IPFS would be confused by a requirement that the object must be modified after initial creation -- because such modifications would change the CID for the object. (Note: This is a general issue with AP that will need to be addressed if some folks' goal creating an "instance-independent" SocialWeb is to be achieved.)
• Not all systems will maintain InBoxes and OutBoxes. Some may simply relay or cache messages received and would not want to be required to update other in-route messages that were replied to by others.

[trwnh]

I believe it would be wrong to require that receipt of any Object containing an inReplyTo MUST result in modification to the referenced Object. It is better to leave this as an implementation option.

all other language regarding side effects is a SHOULD, so i don't see why this would be a hard requirement unlike everything else

[bobwyman]

all other language regarding side effects is a SHOULD, so i don't see why this would be a hard requirement unlike everything else

Fair point. I shouldn't have assumed you meant "MUST." But, I still think that even "SHOULD" may be too strong in this specific case. It may be best to simply say "MAY," and describe the common expected side effects.

This business of having "Reply" be a privileged type of reference to an Object has bothered me for some time. One problem is that posts that include links to other Objects are often not listed as Replies to those objects even when their intent is clearly to be a reply. Along the same lines, while one can easily find stuff that was explicitly produced as a "reply," there is normally no way for a user to "Find all posts that include links to this Object." This is, of course, one of the reasons that some people have objected to "Quote Posts" which can be implemented in such a way that it is functionally a "reply" to some post but is hidden from the author of the post replied to.

Had I been writing the AP spec, I would have argued that rather than specifically privileging Replies, we should support W3C Annotations and define a type of annotation which is a reply. Then, all references to URL's, whether or not they were for AP Objects, would be encoded as Annotations. Clients could then present all references, perhaps with different treatments for various kinds of Annotations. I would also extend the normal or default "Search" capability to not only search for tags, but also Annotations. (Note: This is now supported by Twitter. You can search for any URL to see posts that refer to it.) Such an ability to find all references to, or annotations of, an object is very useful for journalists and others who wish to see how others react to content they produce.

[trwnh]

describe the common expected side effects.

isn't this what a SHOULD does/means?

One problem is that posts that include links to other Objects are often not listed as Replies to those objects even when their intent is clearly to be a reply.

personally i hold the view that this is up to the authorial intent. if you want it to be included in the replies collection, you use inReplyTo. if you don't, you can use a plain link in the content. in the same way that you could use a mention or you could use a plain name reference. colloquially, this is known as a "subpost". similarly, you could include something in attachment or you could insert a link in the content. and so on.

all references to URL's, whether or not they were for AP Objects, would be encoded as Annotations

you could do this right now with tag and Link; i imagine you could also use tag and Annotation if you really wanted to?

I would also extend the normal or default "Search" capability to not only search for tags, but also Annotations. (Note: This is now supported by Twitter. You can search for any URL to see posts that refer to it.) Such an ability to find all references to, or annotations of, an object is very useful for journalists and others who wish to see how others react to content they produce.

the more powerful you make the search against more detailed metadata, the more likely it is that people will start intentionally authoring worse metadata in order to get around search. likewise: popularize search against the full-text of the content, and people will start degrading the fidelity of their text.

---

in any case, i think the main focus of this issue is clear: replies is given some credence in the callout box for "ghost replies", but that's it -- the side effects are not defined anywhere, nor is the word "replies" used anywhere else in the spec.

[evanp]

We expanded the primer with a page on threading. This covers how and when to add to replies. How and when to manage replies is spread across AP and AS2, and can be hard to understand. Pulling the documentation into a single primer page will hopefully help.

[trwnh]

one thing i'd like to leave as a comment here -- this isn't strictly limited to Create, and it technically happens whenever you process the object, not the activity. this may be due to a Create, an Add, a manual fetch, a webmention, or some other thing altogether. it is probably best practice to do it at time-of-Create by delivering the Create to the author, but there are reasons for not wanting to do this.

[evanp]

@trwnh can you update the Primer article too, please?

[trwnh]

@evanp I don't seem to be able to login to the wiki.

[evanp]

I incorporated @trwnh 's comment. This has been pending for weeks, so I'm closing it now.