Section 7.1: relax requirement not to deliver to yourself?

[trwnh]

Servers MUST de-duplicate the final recipient list. Servers MUST also exclude actors from the list which are the same as the actor of the Activity being notified about. That is, actors shouldn't have their own activities delivered to themselves.

this is actually allowed by software such as mastodon, albeit through internal mechanisms instead of through activitypub.

i think this is something that could be relaxed. there are times when you might want to send a message to yourself, and thus explicitly address yourself as one of the recipients, and it could be a violation of expectation for the server to strip you from the recipients list. the intention could very well be for the activity to end up in your inbox and not just remain in your outbox. this is something that some people will do in email, for example -- send an email and address yourself.

[TallTed]

Yes. This should be a configurable option, optimally giving the user the ability to set their own "normal"/default setting, while able to over-ride that default on any given Activity, as with email where you might have a default to CC or BCC the sending address (and/or any other specific address(es)) and have the ability to edit the CC and/or BCC lists while composing your message.

The now-common default behavior to not [B]CC yourself was implemented when storage was far more expensive. Also, ActivityPub being a logical descendant of NetNews/NNTP, I have a feeling AP has been infected with some poorly considered NNTP rules (e.g., limiting cross-posting of any given article to 3 or 5 newsgroups, where a cross-post would put pointers to one "physical" copy of the article into multiple groups, minimizing the data volume of that cross-post, even if it were cross-posted to 100s of groups, while the workaround of manually posting "physical copies of the article "directly to each group massively multiplied the data volume).

[evanp]

I think this is a good point. I think there was an assumption among the editors and authors that activities you create always are put into your inbox. This isn't explicit in the spec, so the restriction not to deliver to one's own inbox seems capricious. I think our next version should loosen this requirement.

[trwnh]

It looks like this may have originated from #76 in particular:

The target(s) for final delivery of an Activity are:

• an actor in to, cc or bcc fields
• the actors for all objects in the object, target or inReplyTo fields

So there seems to have been an intent (at some point) that recipients get determined not solely by explicit addressing, but also by checking certain "relevant" properties. This seems to have evolved into a more client-focused flow where the client instead suggests recipients based on those "relevant" properties, but ultimately gives users the chance to amend those recipients.

Compare to this finalized language in 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.

Under the old interpretation, it makes sense that when you perform an Activity on your own object, i.e. you are the object.attributedTo, you don't necessarily need to notified of this. But under the current interpretation where notifications flow to the inboxes of explicitly targeted actors, it makes less sense.

The "notification targeting" language was later cleaned up in #161 and effectively retooled in favor of "addressing targets".