[MegaThread] Test Cases Implementation Tracker

[cjslep]

I'll probably just need to keep re-editing this post to fill out the task chart, but here is a list of tests from the official test suite to port over. Usually porting one tests from the official test suite takes multiple tests in this repository, since it is trying to automate each of the test cases. I'm not going to list all of the fan-outs to individual unofficial tests, except in the case that the test "kind" ("Common", "S2S", "C2S") is deviating from the official test suite. If the "Unofficial Test Kind" cell is empty, it is because that row hasn't been examined/thought through yet. Also note that sharedInbox will not be supported in any of the test cases, an opinionated decision. This is not the place for revisiting that discussion.

The list is in very rough priority order.

The list of official test cases comes from this comment.

Total Unofficial Tests (will not match count in list below): 52

Official Test Kind	Official Test Name	Unofficial Test Kind	Unofficial Test Supported?
Common	NON-NORMATIVE: Server responds to GET request at inbox URL	Common	Yes
Common	MUST: inbox is an OrderedCollection	Common	Yes
Common	SHOULD: Server filters inbox content according to the requester's permission	S2S
"	"	C2S
Common	MAY: Allow dereferencing Object ids by responding to HTTP GET requests with a representation of the Object	Common	Yes
Common	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"	Common	Yes
Common	SHOULD: Respond with the ActivityStreams object representation in response to requests that primarily Accept the media type application/activity+json	Common	Yes
Common	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)	Common	Yes
Common	SHOULD: Respond with 410 Gone status code if Tombstone is in response body, otherwise responds with 404 Not Found	Common	Yes
Common	SHOULD: Respond with 404 status code for Object URIs that have never existed	Common	Yes
Common	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)	Common	Yes
Common	NON-NORMATIVE: Server verifies that the new content is really posted by the actor indicated in Objects received in inbox and outbox	S2S
"	"	C2S
Common	NON-NORMATIVE: By default, implementation does not make HTTP requests to localhost when delivering Activities	S2S
"	"	C2S
Common	NON-NORMATIVE: Implementation applies a whitelist of allowed URI protocols before issuing requests, e.g. for inbox delivery	S2S
Common	NON-NORMATIVE: Server filters incoming content both by local untrusted users and any remote users through some sort of spam filter	S2S
"	"	C2S
S2S	MUST: Performs delivery on all Activities posted to the outbox	S2S	Yes
S2S	MUST: Utilizes to, bto, cc, and bcc to determine delivery recipients.	S2S	Yes
S2S	MUST: Provides an id all Activities sent to other servers, unless the activity is intentionally transient.	S2S	Yes
S2S	MUST: Dereferences delivery targets with the submitting user's credentials	S2S	Yes
S2S	MUST: Delivers to all items in recipients that are Collections or OrderedCollections	S2S	Yes
S2S	MUST: Applies the above, recursively if the Collection contains Collections, and limits recursion depth >= 1	S2S	Yes
S2S	MUST: Delivers activity with 'object' property if the Activity type is one of Create, Update, Delete, Follow, Add, Remove, Like, Block, Undo	S2S	Yes
S2S	MUST: Delivers activity with 'target' property if the Activity type is one of Add, Remove	S2S	Yes
S2S	MUST: Deduplicates final recipient list	S2S	Yes
S2S	MUST: Does not deliver to recipients which are the same as the actor of the Activity being notified about	S2S	Yes
S2S	SHOULD: SHOULD NOT deliver Block Activities to their object.	S2S	Yes
S2S	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.	S2S	No
S2S	MUST: (For servers which deliver to sharedInbox:) Deliver to actor inboxes and collections otherwise addressed which do not have a sharedInbox.	S2S	No
S2S	MUST: Deduplicates activities returned by the inbox by comparing activity ids	S2S	Yes*
S2S	MUST: Forwards incoming activities to the values of to, bto, cc, bcc, audience if and only if criteria in 7.1.2 are met.	S2S	Yes
S2S	SHOULD: Recurse through to, bto, cc, bcc, audience object values to determine whether/where to forward according to criteria in 7.1.2	S2S
S2S	SHOULD: Limit recursion in this process	S2S
S2S	NON-NORMATIVE: Supports receiving a Create object in an actor's inbox
S2S	SHOULD: Assuming object is owned by sending actor/server, removes object's representation
S2S	MAY: MAY replace object's representation with a Tombstone object
S2S	MUST: Take care to be sure that the Update is authorized to modify its object	S2S	Yes*
S2S	SHOULD: Completely replace its copy of the activity with the newly received value	S2S
S2S	SHOULD: Don't trust content received from a server other than the content's origin without some form of verification.
S2S	SHOULD: Add the actor to the object user's Followers Collection.	S2S	Yes
S2S	SHOULD: Generates either an Accept or Reject activity with Follow as object and deliver to actor of the Follow	S2S	Yes
S2S	SHOULD: If in reply to a Follow activity, adds actor to receiver's Following Collection	S2S	Yes
S2S	MUST: If in reply to a Follow activity, MUST NOT add actor to receiver's Following Collection	S2S	Yes
S2S	SHOULD: Add the object to the Collection specified in the target property, unless not allowed to per requirements in 7.8
S2S	SHOULD: Remove the object from the Collection specified in the target property, unless not allowed per requirements in 7.9
S2S	SHOULD: Perform appropriate indication of the like being performed (See 7.10 for examples)
S2S	SHOULD: Increments object's count of shares by adding the received activity to the 'shares' collection if this collection is present
S2S	NON-NORMATIVE: Performs Undo of object in federated context
C2S	MUST: Accepts Activity Objects
C2S	MUST: Accepts non-Activity Objects, and converts to Create Activities per 7.1.1
C2S	MUST: Removes the bto and bcc properties from Objects before storage and delivery
C2S	MUST: Ignores 'id' on submitted objects, and generates a new id instead
C2S	MUST: Responds with status code 201 Created
C2S	MUST: Response includes Location header whose value is id of new object, unless the Activity is transient
C2S	MUST: Update
C2S	NON-NORMATIVE: Supports partial updates in client-to-server protocol (but not server-to-server)
C2S	SHOULD: Create
C2S	SHOULD: merges audience properties (to, bto, cc, bcc, audience) with the Create's 'object's audience properties
C2S	SHOULD: Create's actor property is copied to be the value of .object.attributedTo
C2S	SHOULD: Follow
C2S	SHOULD: Adds followed object to the actor's Following Collection
C2S	SHOULD: Add
C2S	SHOULD: Adds object to the target Collection, unless not allowed due to requirements in 7.5
C2S	SHOULD: Remove
C2S	SHOULD: Remove object from the target Collection, unless not allowed due to requirements in 7.5
C2S	SHOULD: Like
C2S	SHOULD: Adds the object to the actor's Liked Collection.
C2S	SHOULD: Block
C2S	SHOULD: Prevent the blocked object from interacting with any object posted by the actor.
C2S	NON-NORMATIVE: Supports the Undo activity in the client-to-server protocol
C2S	MUST: Ensures that the activity and actor are the same in activity being undone.

*Not automatically detected, relies on submitter's honesty

[cjslep]

I am hosting the available tests at https://test.activitypub.dev/ so far.