Mastodon Preliminary Implementation Report

[nightpool]

Not sure how to turn this into the markdown format, but this is the preliminary implementation report for mastodon: https://test.activitypub.rocks/download-report/ujyxdji36uc36s544wvzv5wztp6f5hvekgpfbi3bf7xluugeu2yq

There are a couple of security things I'd like to fix before this is finalized, and I'm not sure it's fully accurate (lists "MUST: Performs delivery on all Activities posted to the outbox" as "[N/A]", which seems ... wrong), but other then the spurious N/As, should be correct. I'd like someone to check my work though.

Server: Federation Tasks
MUST: Performs delivery on all Activities posted to the outbox	[N/A]
MUST: Utilizes to, bto, cc, and bcc to determine delivery recipients.	[N/A]
MUST: Provides an id all Activities sent to other servers, unless the activity is intentionally transient.	[N/A]
MUST: Dereferences delivery targets with the submitting user's credentials	[N/A]
MUST: Delivers to all items in recipients that are Collections or OrderedCollections	[N/A]
MUST: Applies the above, recursively if the Collection contains Collections, and limits recursion depth >= 1	[N/A]
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	[No]
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]
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.	[No]
SHOULD: Recurse through to, bto, cc, bcc, audience object values to determine whether/where to forward according to criteria in 7.1.2	[No]
SHOULD: Limit recursion in this process	[No]
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.	[Yes]
SHOULD: Add the actor to the object user's Followers Collection.	[Yes]
SHOULD: Add the object to the Collection specified in the target property, unless not allowed to per requirements in 7.8	[No]
SHOULD: Remove the object from the Collection specified in the target property, unless not allowed per requirements in 7.9	[No]
SHOULD: Perform appropriate indication of the like being performed (See 7.10 for examples)	[Yes]

Server: Common Tasks	--
NON-NORMATIVE: Server responds to GET request at inbox URL	[No]
MUST: inbox is an OrderedCollection	[No]
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)	[No]
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	[Yes]
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	[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]
NON-NORMATIVE: Implementation takes care to santizie fields containing markup to prevent cross site scripting attacks	[Yes]

[cwebber]

There's no need to convert ot Markdown, all I need to do is wget your report to this repo: https://gitlab.com/dustyweb/activitypub.rocks/tree/master/reports

I probably should remove the implementation reports directory in this repo.

Will pull it in in a few minutes! Thank you for your report!

[cwebber]

Oh! It says don't pull yet, so I won't until we resolve those issues.

[nightpool]

Okay, I think I have a couple concerns about the new implementation report—it doesn't include license, questions about open-source implementations, or notes on individual items. There are a couple of spec items we fulfill partially, or fulfill with additional restrictions, that I'd like to note down

[nightpool]

Plus, as mentioned, the JSON doesn't reflect the implementation report completely since I was never prompted for some questions it marked as "N/A", but mastodon does support.

[cwebber]

Hey @nightpool, you're right about those missing fields... in fact I had those in and then I commented them out because I didn't want to overwhelm contributors with fields and I could add it myself by looking at a source repo if provided. But since you noticed, I guess that means I should add it back in :)

[cwebber]

lists "MUST: Performs delivery on all Activities posted to the outbox" as "[N/A]", which seems ... wrong

Nobody is doing an HTTP POST to the outbox endpoint right? Because Mastodon doesn't implement ActivityPub's C2S API! But maybe it's conceptually confusing because there's the "abstract concept of submitting to the outbox" and then there's "doing an HTTP POST to the outbox". If I instead reworded to "submitted via HTTP POST to the outbox endpoint", would that be clearer?

[nightpool]

Ah, sorry, I guess I was referring to stuff like "Utilizes to, bto, cc, and bcc to determine delivery recipients" that should still be a requirement, right?

I think I misread "outbox" for "inbox" in the one I quoted.....

[cwebber]

Ah, sorry, I guess I was referring to stuff like "Utilizes to, bto, cc, and bcc to determine delivery recipients" that should still be a requirement, right?

"Sort of". The addressing should all be there for sanity's sake but really, if you're not using C2S, you could still deliver to individual inboxes without ever listing them... that sounds strange, but imagine a server is deciding recipients itself and effectively used the bcc / bto fields. By the time the message was sent across the wire those would be stripped out. So if you aren't using C2S, it's much more of a server implementation decision of what inboxes to deliver to.

That said, if you deliver to sharedInbox endpoints, the receiving servers would have to determine addressing based off of the to and cc fields...

[nightpool]

ah, right. not everybody uses sharedInbox for everything. aah :)

(I ... we might not actually do anything differently with things delivered to /inbox rather then sharedInbox. I should look into that)

On Mon, Nov 13, 2017 at 8:02 PM Christopher Allan Webber < notifications@github.com> wrote:

Ah, sorry, I guess I was referring to stuff like "Utilizes to, bto, cc, and bcc to determine delivery recipients" that should still be a requirement, right?

"Sort of". The addressing should all be there for sanity's sake but really, if you're not using C2S, you could still deliver to individual inboxes without ever listing them... that sounds strange, but imagine a server is deciding recipients itself and effectively used the bcc / bto fields. By the time the message was sent across the wire those would be stripped out. So if you aren't using C2S, it's much more of a server implementation decision of what inboxes to deliver to.

That said, if you deliver to sharedInbox endpoints, the receiving servers would have to determine addressing based off of the to and cc fields...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/activitypub/issues/271#issuecomment-344111057, or mute the thread https://github.com/notifications/unsubscribe-auth/AAORVxHtph2c5TAMwqOe6cgp4xzyvJulks5s2OakgaJpZM4QXApA .

[cwebber]

Let me know when you think the report is good enough to be merged or if there's anything I can answer to help that along. I'm excited to get this on the implementation reports page!

[cwebber]

Note that if you're okay with it, we can (and I think it's a good idea) also push up the current version as-is and that doesn't mean Mastodon's submission can't be iterated on. Would you be okay with that @nightpool or would you rather wait until we have all the loose ends tied up?

[nightpool]

I think i'm fine submitting it now. Here's the about section:

Mastodon is a free, open-source, decentralized microblogging application with support for the ActivityPub and OStatus protocols. Built for global networks of close-knit communities, Mastodon puts social networking back in the hands of users.

Interoperability notes:

All actors must support Webfinger resolution, with a unique preferredUsername per host, so that they can be interacted with by other users. Posts to the inbox must be signed using the HTTP Signatures draft spec with a public key that can be fetched from the actor, using the publicKey object format from the WebPayments JSON-LD Security Vocabulary.

[cwebber]

Added to the implementation reports page! Horray! https://activitypub.rocks/implementation-report/

@nightpool I'm not sure if you think I should close this now or not (depends on whether you think there will be some changes coming soon I suppose? We can always make changes) so I'm closing it, but if you think otherwise just let me know.