Guidance on "how to interact" / "where to send activities" could be extended

[trwnh]

From Section 6.1 "Client Addressing":

Clients SHOULD look at any objects attached to the new Activity via the object, target, inReplyTo and/or tag fields, retrieve their actor or attributedTo properties, and MAY also retrieve their addressing properties, and add these to the to or cc fields of the new Activity being created. Clients MAY recurse through attached objects, but if doing so, SHOULD set a limit for this recursion. (Note that this does not suggest that the client should "unpack" collections of actors being addressed as individual recipients).

Clients MAY give the user the chance to amend this addressing in the UI.

This is generally decent advice, but could be modified slightly.

• A consideration could be made to look at context, in a similar vein as tag and inReplyTo. (generator and location are also possible, and might make sense.)
• "to or cc fields" could be replaced with "addressing properties" (since other addressing properties are possible or may be desirable, at the client's discretion and later at the user's discretion).
• A modification might be made such that when you look at these related objects, if they have an inbox, you might address them directly. (Possible tangent: "who can be addressed" is defined as "an entity", and not strictly limited to any particular entities. It makes sense to say that, since AP delivery works on inboxes, it is enough that "the entity" has an inbox.)
• A clarification should be made regarding the optional recursion, pointing out that recursing through attributedTo can allow for discovering an inbox if the current object doesn't have its own inbox.

This issue, and in particular the last two bullet points above, were motivated in part by #343 and a desire to describe the general interaction flow, i.e.:

• A Like/Announce may be sent to object.inbox, not just object.attributedTo.inbox
• A Follow may be sent to object.attributedTo.inbox, not just object.inbox

Generalizing the flow to "start at the object, then recurse upward via attributedTo if needed" allows for the widest range of interactions. To some extent this is still within the client's purview, but we can guide clients to not hardcode specific paths.

One final consideration that is somewhat related: it might be a good idea to check for presence of special collections before sending activities modifying those special collections. For example, check for object.likes before sending a Like; check for object.shares before sending an Announce; check for object.followers before sending a Follow. Sending such activities without the special collections being present is certainly possible, but has no observable side effects. Finally, depending on protocol or implementation, software might assume or otherwise detect/negotiate support for certain activities through some other logic.

---

The above information should probably be distilled into a Primer page at least, with possible minor consideration for making it into errata or next version. It doesn't rise to the level of an error, so an errata isn't strictly necessary, but it might be considered a slight normative change to expand the list of which properties SHOULD be looked at. So we have two potential errata to consider:

Clients SHOULD look at any objects attached to the new Activity via the object, target, inReplyTo, context, [generator, location] and/or tag fields

add these to the to or cc fieldsaddressing properties of the new Activity being created

[evanp]

Your first two notes are reasonable; treating context like the other object properties, and including all 5 of the addressing properties.

I don't think the ideas around treating the object properties' own inboxes the same way is as strong, and we need to have better implementations of followable objects before we give this kind of guidance in the spec itself. So, I'm reluctant to include those.

I think you have a strong set of points for a Primer page. I think the point about the addressing properties might rise to the level of an erratum, and that the rest is probably worth considering in a future version of AP.

[evanp]

Proposed erratum added:

In section 6.1 "Client Addressing", the third paragraph should begin: "Clients SHOULD look at any objects attached to the new Activity via the object, target, inReplyTo, context, and/or tag fields, retrieve their actor or attributedTo properties, and MAY also retrieve their addressing properties, and add these to the addressing properties of the new Activity being created."

[evanp]

This erratum doesn't match our preferred format, since it doesn't say what the problem is. Let's make this needs errata and come back to it.

[trwnh]

I think there might actually be two errata here. The second errata might need some further group discussion.

---

Errata 1

Error description

Section 6.1 "Client Addressing" reads in part: '''Clients SHOULD look at any objects attached to the new Activity via the object, target, inReplyTo and/or tag fields, retrieve their actor or attributedTo properties, and MAY also retrieve their addressing properties, and add these to the to or cc fields of the new Activity being created.''' However, other properties may be socially relevant for the client to suggest for inclusion. The current language could be interpreted as indicating that only "object"/"target"/"inReplyTo"/"tag" are socially relevant.

Candidate correction 1a

Add a statement that '''Clients MAY look at additional fields considered socially relevant'''.

Candidate correction 1b

Specifically mention the "context" property as a socially relevant property.

---

Errata 2

Error description

Section 6.1 "Client Addressing" reads in part: '''[...] retrieve their actor or attributedTo properties, and MAY also retrieve their addressing properties [...]'''. The usage of "addressing properties" implies "to", "cc", and "audience", but it does not imply "followers".

Candidate correction

Extend the text to read: '''[...] and MAY also retrieve their addressing properties and/or their followers collection [...]'''