Unofficial Implementation Reports

[cjslep]

This is where I will post unofficial implementation reports of this library generated by the thin server wrapper around this library at https://github.com/go-fed/report.

Since I am tackling the implementation report one step at a time, as it is very comprehensive, I wanted to provide insight along the way.

Once an official version is available, I will close this issue and refer to that in the README.

[cjslep]

This first report was done at 33c5320, one commit beyond the initial 0.1.0 release. Note that I do not plan on ever providing an unofficial report for version 0.1.0. I strongly recommend to upgrade to 0.1.1 and beyond. The 0.1.0 release is distinct in being the very first release and therefore is expected to not pass many parts of the implementation report.

At this commit, the report is as follows:

Client to Server & Common

Item	Implemented
MUST: Accepts Activity Objects	[Yes]
MUST: Accepts non-Activity Objects, and converts to Create Activities per 7.1.1	[Yes]
MUST: Removes the bto and bcc properties from Objects before storage and delivery	[No]
MUST: Ignores 'id' on submitted objects, and generates a new id instead	[Yes]
MUST: Responds with status code 201 Created	[Yes]
MUST: Response includes Location header whose value is id of new object, unless the Activity is transient	[Yes]
MUST: Update	[Yes]
NON-NORMATIVE: Supports partial updates in client-to-server protocol (but not server-to-server)	[Yes]
SHOULD: Create	[Yes]
SHOULD: merges audience properties (to, bto, cc, bcc, audience) with the Create's 'object's audience properties	[Yes]
SHOULD: Create's actor property is copied to be the value of .object.attributedTo	[Yes]
SHOULD: Follow	[Yes]
SHOULD: Adds followed object to the actor's Following Collection	[No]
SHOULD: Add	[Yes]
SHOULD: Adds object to the target Collection, unless not allowed due to requirements in 7.5	[Inconclusive]
SHOULD: Remove	[Inconclusive]
SHOULD: Remove object from the target Collection, unless not allowed due to requirements in 7.5	[Inconclusive]
SHOULD: Like	[Inconclusive]
SHOULD: Adds the object to the actor's Liked Collection.	[Inconclusive]
SHOULD: Block	[Yes]
SHOULD: Prevent the blocked object from interacting with any object posted by the actor.	[Yes]
NON-NORMATIVE: Supports the Undo activity in the client-to-server protocol	[Yes]
MUST: Ensures that the activity and actor are the same in activity being undone.	[Yes]
NON-NORMATIVE: Server responds to GET request at inbox URL	[Yes]
MUST: inbox is an OrderedCollection	[Yes]
SHOULD: Server filters inbox content according to the requester's permission	[No]
MAY: Allow dereferencing Object ids by responding to HTTP GET requests with a representation of the Object	[Yes]
MUST: Respond with the ActivityStreams object representation in response to requests that primarily Accept the media type application/ld+json; profile="https://www.w3.org/ns/activitystreams"	[Yes]
SHOULD: Respond with the ActivityStreams object representation in response to requests that primarily Accept the media type application/activity+json	[Yes]
MAY: Responds with response body that is an ActivityStreams Object of type Tombstone (if the server is choosing to disclose that the object has been removed)	[Yes]
SHOULD: Respond with 410 Gone status code if Tombstone is in response body, otherwise responds with 404 Not Found	[No]
SHOULD: Respond with 404 status code for Object URIs that have never existed	[No]
SHOULD: Respond with a 403 Forbidden status code to all requests that access Objects considered Private (or 404 if the server does not want to disclose the existence of the object, or another HTTP status code if specified by the authorization method)	[Yes]
NON-NORMATIVE: Server verifies that the new content is really posted by the actor indicated in Objects received in inbox and outbox	[Yes]
NON-NORMATIVE: By default, implementation does not make HTTP requests to localhost when delivering Activities	[Yes]
NON-NORMATIVE: Implementation applies a whitelist of allowed URI protocols before issuing requests, e.g. for inbox delivery	[Yes]
NON-NORMATIVE: Server filters incoming content both by local untrusted users and any remote users through some sort of spam filter	[No]

Server to Server

Not yet run

Explanations (top-down, these are the Nos except those noted as Inconclusive):

• MUST: Removes the bto and bcc properties from Objects before storage and delivery
  Filed When serving ActivityPub objects, remove bcc/bto #47
• SHOULD: Adds followed object to the actor's Following Collection
  We follow the more thorough advice of waiting to receive an Accept before adding an object to the actor's following collection. I am considering adding a toggle to enable this simpler behavior, default off for backwards compatibility.
• SHOULD: Adds object to the target Collection, unless not allowed due to requirements in 7.5
  SHOULD: Remove
  SHOULD: Remove object from the target Collection, unless not allowed due to requirements in 7.5
  SHOULD: Like
  SHOULD: Adds the object to the actor's Liked Collection.
  These are inconclusive. At this time, the test suite cannot handle Collections whose items are non-arrays. Many thanks to cwebber for taking the time to fix this for future runs.
• SHOULD: Server filters inbox content according to the requester's permission
  This must be determined by the implementor and cannot be abstracted away by this library at this time, as it has no concept of ACLs or OCAPs.
• SHOULD: Respond with 410 Gone status code if Tombstone is in response body, otherwise responds with 404 Not Found
  Filed Respond with 410 Gone status if fetching a Tombstone #44
• SHOULD: Respond with 404 status code for Object URIs that have never existed
  App.Get calls return errors for not-found issues, which are transparently returned to the implementor. So it is up to the implementor to interpret their "not found" errors as 404 response codes instead of 5XX response codes.
• NON-NORMATIVE: Server filters incoming content both by local untrusted users and any remote users through some sort of spam filter
  This library provides hooks to help manage spam. But spam filtering does not work out-of-the-box. It is up to implementations to determine the correct behavior.

[cjslep]

Server: Client-to-Server tests

Item	Implemented
MUST: Accepts Activity Objects	[Yes]
MUST: Accepts non-Activity Objects, and converts to Create Activities per 7.1.1	[Yes]
MUST: Removes the bto and bcc properties from Objects before storage and delivery	[Yes]
MUST: Ignores 'id' on submitted objects, and generates a new id instead	[Yes]
MUST: Responds with status code 201 Created	[Yes]
MUST: Response includes Location header whose value is id of new object, unless the Activity is transient	[Yes]
MUST: Update	[Yes]
NON-NORMATIVE: Supports partial updates in client-to-server protocol (but not server-to-server)	[Yes]
SHOULD: Create	[Yes]
SHOULD: merges audience properties (to, bto, cc, bcc, audience) with the Create's 'object's audience properties	[Yes]
SHOULD: Create's actor property is copied to be the value of .object.attributedTo	[Yes]
SHOULD: Follow	[Yes]
SHOULD: Adds followed object to the actor's Following Collection	[No]
SHOULD: Add	[Yes]
SHOULD: Adds object to the target Collection, unless not allowed due to requirements in 7.5	[Inconclusive]
SHOULD: Remove	[Inconclusive]
SHOULD: Remove object from the target Collection, unless not allowed due to requirements in 7.5	[Inconclusive]
SHOULD: Like	[Inconclusive]
SHOULD: Adds the object to the actor's Liked Collection.	[Inconclusive]
SHOULD: Block	[Yes]
SHOULD: Prevent the blocked object from interacting with any object posted by the actor.	[Yes]
NON-NORMATIVE: Supports the Undo activity in the client-to-server protocol	[No]
MUST: Ensures that the activity and actor are the same in activity being undone.	[Yes]

Server: Federation tests

Item	Implemented
MUST: Performs delivery on all Activities posted to the outbox	[Yes]
MUST: Utilizes to, bto, cc, and bcc to determine delivery recipients.	[Yes]
MUST: Provides an id all Activities sent to other servers, unless the activity is intentionally transient.	[Yes]
MUST: Dereferences delivery targets with the submitting user's credentials	[Yes]
MUST: Delivers to all items in recipients that are Collections or OrderedCollections	[Yes]
MUST: Applies the above, recursively if the Collection contains Collections, and limits recursion depth >= 1	[Yes]
MUST: Delivers activity with 'object' property if the Activity type is one of Create, Update, Delete, Follow, Add, Remove, Like, Block, Undo	[Yes]
MUST: Delivers activity with 'target' property if the Activity type is one of Add, Remove	[Yes]
MUST: Deduplicates final recipient list	[Yes]
MUST: Does not deliver to recipients which are the same as the actor of the Activity being notified about	[Yes]
SHOULD: SHOULD NOT deliver Block Activities to their object.	[Yes]
MAY: Delivers to sharedInbox endpoints to reduce the number of receiving actors delivered to by identifying all followers which share the same sharedInbox who would otherwise be individual recipients and instead deliver objects to said sharedInbox.	[No]
MUST: (For servers which deliver to sharedInbox:) Deliver to actor inboxes and collections otherwise addressed which do not have a sharedInbox.	[No]
MUST: Deduplicates activities returned by the inbox by comparing activity ids	[Yes]
MUST: Forwards incoming activities to the values of to, bto, cc, bcc, audience if and only if criteria in 7.1.2 are met.	[Yes]
SHOULD: Recurse through to, bto, cc, bcc, audience object values to determine whether/where to forward according to criteria in 7.1.2	[Yes]
SHOULD: Limit recursion in this process	[Yes]
NON-NORMATIVE: Supports receiving a Create object in an actor's inbox	[Yes]
SHOULD: Assuming object is owned by sending actor/server, removes object's representation	[Yes]
MAY: MAY replace object's representation with a Tombstone object	[Yes]
MUST: Take care to be sure that the Update is authorized to modify its object	[Yes]
SHOULD: Completely replace its copy of the activity with the newly received value	[Yes]
SHOULD: Don't trust content received from a server other than the content's origin without some form of verification.	[No]
SHOULD: Add the actor to the object user's Followers Collection.	[Yes]
SHOULD: Generates either an Accept or Reject activity with Follow as object and deliver to actor of the Follow	[Yes]
SHOULD: If in reply to a Follow activity, adds actor to receiver's Following Collection	[Yes]
MUST: If in reply to a Follow activity, MUST NOT add actor to receiver's Following Collection	[Yes]
SHOULD: Add the object to the Collection specified in the target property, unless not allowed to per requirements in 7.8	[Yes]
SHOULD: Remove the object from the Collection specified in the target property, unless not allowed per requirements in 7.9	[Yes]
SHOULD: Perform appropriate indication of the like being performed (See 7.10 for examples)	[Yes]
SHOULD: Increments object's count of shares by adding the received activity to the 'shares' collection if this collection is present	[No]
NON-NORMATIVE: Performs Undo of object in federated context	[No]

Server: Common tests

Item	Implemented
NON-NORMATIVE: Server responds to GET request at inbox URL	[Yes]
MUST: inbox is an OrderedCollection	[Yes]
SHOULD: Server filters inbox content according to the requester's permission	[No]
MAY: Allow dereferencing Object ids by responding to HTTP GET requests with a representation of the Object	[Yes]
MUST: Respond with the ActivityStreams object representation in response to requests that primarily Accept the media type application/ld+json; profile="https://www.w3.org/ns/activitystreams"	[Yes]
SHOULD: Respond with the ActivityStreams object representation in response to requests that primarily Accept the media type application/activity+json	[Yes]
MAY: Responds with response body that is an ActivityStreams Object of type Tombstone (if the server is choosing to disclose that the object has been removed)	[Yes]
SHOULD: Respond with 410 Gone status code if Tombstone is in response body, otherwise responds with 404 Not Found	[Yes]
SHOULD: Respond with 404 status code for Object URIs that have never existed	[No]
SHOULD: Respond with a 403 Forbidden status code to all requests that access Objects considered Private (or 404 if the server does not want to disclose the existence of the object, or another HTTP status code if specified by the authorization method)	[No]
NON-NORMATIVE: Server verifies that the new content is really posted by the actor indicated in Objects received in inbox and outbox	[No]
NON-NORMATIVE: By default, implementation does not make HTTP requests to localhost when delivering Activities	[No]
NON-NORMATIVE: Implementation applies a whitelist of allowed URI protocols before issuing requests, e.g. for inbox delivery	[No]
NON-NORMATIVE: Server filters incoming content both by local untrusted users and any remote users through some sort of spam filter	[No]

Here are explanations for the No and Inconclusive results:

Server: Client-to-Server tests

• SHOULD: Adds followed object to the actor's Following Collection
  We follow the more thorough advice of waiting to receive an Accept before adding an object to the actor's following collection. I am considering adding a toggle to enable this simpler behavior, default off for backwards compatibility.

• SHOULD: Adds object to the target Collection, unless not allowed due to requirements in 7.5
  Inconclusive, expected to be "yes" but I am unsure why the automatic testing failed to detect this.

• SHOULD: Remove
  Inconclusive, expected to be "yes" but I am unsure why the automatic testing failed to detect this.

• SHOULD: Remove object from the target Collection, unless not allowed due to requirements in 7.5
  Inconclusive, expected to be "yes" but I am unsure why the automatic testing failed to detect this.

• SHOULD: Like
  Inconclusive, expected to be "yes" but I am unsure why the automatic testing failed to detect this.

• SHOULD: Adds the object to the actor's Liked Collection.
  Inconclusive, expected to be "yes" but I am unsure why the automatic testing failed to detect this.

• NON-NORMATIVE: Supports the Undo activity in the client-to-server protocol
  Clients are expected to do this. (This should have been 'no' in the previous run above) While the Undo activity is supported by the library, it only passes it through to implementations. This library provides no default actions.

Server: Federation tests

• SHOULD: Server filters inbox content according to the requester's permission
  Clients are expected to do this. This cannot be abstracted away by this library at this time, as it has no concept of ACLs or OCAPs.

• MAY: Delivers to sharedInbox endpoints to reduce the number of receiving actors delivered to by identifying all followers which share the same sharedInbox who would otherwise be individual recipients and instead deliver objects to said sharedInbox.
  Shared inbox support's feature request is Support delivery to shared inboxes #27.

• MUST: (For servers which deliver to sharedInbox:) Deliver to actor inboxes and collections otherwise addressed which do not have a sharedInbox.
  Not currently applicable, but will be for Support delivery to shared inboxes #27.

• SHOULD: Don't trust content received from a server other than the content's origin without some form of verification.
  Should be "Not Applicable" since go-fed/activity doesn't trust any other server than the content's origin. So the prior of this statement is false, and the second part about verification is not applicable. Between "yes" and "no", the "no" response seemed less misleading.

• SHOULD: Increments object's count of shares by adding the received activity to the 'shares' collection if this collection is present
  The feature request for Announce activity types is Support Announce Activities and object Shares Collection #37.

• NON-NORMATIVE: Performs Undo of object in federated context
  Clients are expected to do this. While the Undo activity is supported by the library, it only passes it through to implementations. This library provides no default actions.

Server: Common tests

• SHOULD: Server filters inbox content according to the requester's permission
  Clients are expected to do this

• SHOULD: Respond with 404 status code for Object URIs that have never existed
  Clients are expected to do this

• SHOULD: Respond with a 403 Forbidden status code to all requests that access Objects considered Private (or 404 if the server does not want to disclose the existence of the object, or another HTTP status code if specified by the authorization method)
  Clients are expected to do this

• NON-NORMATIVE: Server verifies that the new content is really posted by the actor indicated in Objects received in inbox and outbox
  The library does not re-fetch Objects presented to an inbox or outbox.

• NON-NORMATIVE: By default, implementation does not make HTTP requests to localhost when delivering Activities
  Clients are expected to do this

• NON-NORMATIVE: Implementation applies a whitelist of allowed URI protocols before issuing requests, e.g. for inbox delivery
  Should be "Unsure" instead of "No". I need to verify what protocols the golang net/http.Client supports, which may inherently restrict this to http and https only.

• NON-NORMATIVE: Server filters incoming content both by local untrusted users and any remote users through some sort of spam filter
  Clients are expected to do this

Bugs

The following bugs were filed as part of this effort:

• Fix ActivityPub Accept & Content-Type Header Detection #58 Fix ActivityPub Accept & Content-Type Header Detection
• Skip Activity action when received multiple times #59 Skip Activity action when received multiple times
• Support IRI object on Delete/Update when origin checking #62 Support IRI object on Delete/Update when origin checking
• Dedupe Ordered Items will fail if IRIs are not fetchable #63 Dedupe Ordered Items will fail if IRIs are not fetchable

All are slated to be fixed for the next patch release.

[cjslep]

The official implementation report for v0.2.0 has been submitted:

w3c/activitypub#318

[cjslep]

Go-fed is now listed on the implementation report site

[GwynethLlewelyn]

Aye, but that report is only for v0.2.0 — what about v1.0.0, the last one released (3 years ago, at the time I'm writing this)?