socialweb.coop

Requirements

• 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