What are protocol behaviors?

The information exchanged between devices through a network or other media is governed by rules and conventions that can be set out in communication protocol specifications. The nature of communication, the actual data exchanged and any state-dependent behaviors, is defined by these specifications. In digital computing systems, the rules can be expressed by algorithms and data structures. Protocols are to communication what algorithms or programming languages are to computations.

— "Normative" @ developer.mozilla.org.org

Why?

This list is provided as an informational resource to the social web community of practice.

Each behavior begs questions of:

• how to interpret the meaning of the specified behavior?
• how to implement the behavior
  • incl. in more than one programming language
• how to manually test the behavior?
• is it possible to automate the testing of this behavior (in various programming languages)?
  • incl. in more than one programming language
• what are some reference valid test fixtures to use as inputs/expectations?

Normative behaviors

In general, protocol behaviors are optionally-implementable possibilities. Some, though, are presented with normative language.

Normative is a word commonly used in software specifications to denote sections that are standardized and must be followed as a rule.

— "Communication Protocol" @ wikipedia.org

The ActivityPub protocol specification's Conformance section explains:

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

— "ActivityPub" @ w3.org

Normative language establishes judgeable norms for the behavior of systems implementing the protocol.

Not all normative behaviors are strictly required. However, in order to interoperate without harm, there are some required behaviors. The protocol specification includes Requirements Levels with most behaviors so implementers, testers, and debuggers can prioritize their efforts to interoperate according to the specified protocol. These are indicated using words in all-caps.

The key words MAY, MUST, MUST NOT, SHOULD, and SHOULD NOT are to be interpreted as described in RFC2119.

— "ActivityPub" @ w3.org

Requirements

Visit ActivityPub Requirements for an index of only the behaviors required by ActivityPub (excluding recommended or optional behaviors).

Behaviors

• Servers MUST de-duplicate the final recipient list.
• Servers MUST limit the number of layers of indirections through collections which will be performed, which MAY be one.
• The server then MUST attach this object as the object of a Create Activity.
• The server MUST accept a valid [ActivityStreams] object that isn't a subtype of Activity in the POST request to the outbox.
• The server MUST only target the values of to, cc, and/or audience on the original object being forwarded, and not pick up any new addressees whilst recursing through the linked objects (in case these addressees were purposefully amended by or via the client).
• Clients submitting [some] activities to an outbox MUST provide the object property in the activity
• The body of the POST request MUST contain a single Activity (which MAY contain embedded objects), or a single non-Activity object which will be wrapped in a Create activity by the server.
• clients submitting the following activities to an outbox MUST also provide the target property: Add, Remove.
• Additionally, servers performing server to server delivery of the following activities MUST also provide the target property: Add, Remove.
• The server MUST then add this new Activity to the outbox collection.
• actor objects must have an inbox property
• The undo activity and the activity being undone MUST both have the same actor.
• Client to server... request MUST be authenticated with the credentials of the user to whom the outbox belongs
• The following collection MUST be either an OrderedCollection or a Collection
• Identifiers MUST be provided for intransient activities posted in server to server communication
• The receiving server MUST take care to be sure that the Update is authorized to modify its object.
• intransient objects must have unique global identifiers
• Servers MUST also exclude actors from the list which are the same as the actor of the Activity being notified about.
• If a recipient is a Collection or OrderedCollection, then the server MUST dereference the collection (with the user's credentials) and discover inboxes for each item in the collection.
• The liked collection MUST be either an OrderedCollection or a Collection
• clients MUST discover the URL of the actor's outbox from their profile
• ActivityPub server must present object in response to GET request with AS2 Accept Header
• clients... then MUST make an HTTP POST request to this URL with the Content-Type of application/ld+json; profile="https://www.w3.org/ns/activitystreams".
• The server... MUST utilize the addressing originally stored on the bto / bcc properties for determining recipients in delivery.
• Federated servers MUST perform delivery on all Activities posted to the outbox according to outbox delivery.
• actor objects must have an outbox property
• Servers... unless the activity is transient, MUST include the new id in the Location header.
• Origin servers sending publicly addressed activities to sharedInbox endpoints MUST still deliver to actors and collections otherwise addressed (through to, bto, cc, bcc, and audience) which do not have a sharedInbox and would not otherwise receive the activity through the sharedInbox mechanism.
• Any to, bto, cc, bcc, and audience properties specified on the object MUST be copied over to the new Create activity by the server.
• Implementations MUST NOT deliver to the "public" special collection
• Servers MUST return a 201 Created HTTP code
• If the object of a Reject received to an inbox is a Follow activity previously sent by the receiver, this means the recipient did not approve the Follow request. The server MUST NOT add the actor to the receiver's Following Collection.
• The likes collection MUST be either an OrderedCollection or a Collection
• When Activities are received in the inbox, ...the server MUST target and deliver to the values of to, cc, and/or audience if and only if all of the following are true: This is the first time the server has seen this Activity. The values of to, cc, and/or audience contain a Collection owned by the server. The values of inReplyTo, object, target and/or tag are objects owned by the server.
• An OrderedCollection MUST be presented consistently in reverse chronological order
• In the case of a Reject, the server MUST NOT add the actor to the object actor's Followers Collection.
• The outbox MUST be an OrderedCollection.
• Servers performing delivery to the inbox or sharedInbox properties of actors on other servers MUST provide the object property in the activity: Create, Update, Delete, Follow, Add, Remove, Like, Block, Undo.
• The followers collection MUST be either an OrderedCollection or a Collection
• For non-transient objects, the server MUST attach an id to both the wrapping Create and its wrapped Object.
• POST requests (eg. to the inbox) MUST be made with a Content-Type of application/ld+json; profile="https://www.w3.org/ns/activitystreams" and GET requests (see also 3.2 Retrieving objects) with an Accept header of application/ld+json; profile="https://www.w3.org/ns/activitystreams".
• The server MUST perform de-duplication of activities returned by the Inbox.
• If an Activity is submitted with a value in the id property, servers MUST ignore this and generate a new id for the Activity.
• Such deduplication MUST be performed by comparing the id of the activities and dropping any activities already seen.
• client must include correct Accept header when retrieving objects
• When objects are received in the outbox..., the server MUST target and deliver to: The to, bto, cc, bcc or audience fields if their values are individuals or Collections owned by the actor.
• The shares collection MUST be either an OrderedCollection or a Collection
• The inbox MUST be an OrderedCollection.
• the object MUST be modified to reflect the new structure as defined in the update activity
• The server MUST remove the bto and/or bcc properties, if they exist, from the ActivityStreams object before delivery