ActivityPub support

[strugee]

ActivityPub support is now being developed in the activitypub branch.

Copypasta from a list of general ActivityPub implementation tasks that I wrote:

Have we implemented URLs for:

• [x] Object id properties? (Section 3.2 Retrieving objects)
• [x] GET Actor inboxes #1552
• [ ] POST Actor inboxes with HTTP Signature #1572
• [x] GET Actor outboxes
• [ ] POST Actor outboxes with OAuth 2.0 #1571
• [x] Actor Following collections?
• [x] Actor Followers collections?
• [x] Actor Liked collections? ~~(optional)~~
• [ ] Binary uploads? (Section 6 Uploading Media, ~~optional~~ not optional for us)

AuthZ/AuthC:

• [x] OAuth 2.0 bearer tokens?
• [x] OAuth 2.0 authorization flow?
• [ ] oauthAuthorizationEndpoint ?
• [ ] oauthTokenEndpoint ?
• [ ] validate incoming requests with HTTP Signatures?
• [ ] sign outgoing requests with HTTP Signatures?

Conversion:

• [x] AS1 -> AS2
• [ ] AS2 -> AS1

Do we handle:

• [ ] The special Public collection?
• [ ] Local Activity side effects (including Undo side effects)?
• [ ] Server-to-server Activity side effects?
• [x] ~~Linked Data Notifications RDF representations (very optional)? (Section 8.1 Delivery)~~ not for us

Do we:

• [ ] Properly support Actor simplified login naming? (Section 4)
• [ ] Deliver activities properly?
• [ ] Implement authentication and authorization checks for clients?
• [ ] Do the same for server-to-server interactions?
• [ ] Scrub Activities for cross-site scripting attacks?
• [ ] Have a plan for combating spam?

In addition to the generic AP stuff, we have an existing network/project to worry about. So, we also need to:

• [ ] Handle AS2 vs. AS1 differences
• [ ] Handle S2S differences? I've forgotten what the plan on this is to be honest
• [ ] Migrate the web UI to understanding AS2
• [ ] Migrate the web UI to using AP endpoints
• [ ] Test everything
• [ ] Run the AP test suite against our implementation

[jankusanagi]

Looking forward to this =)

[erincandescent]

WRT ID properties: I'd suggest leaving them as is and content negotiating on the existing endpoints. AP clients are required to set their Accept header when doing a GET request such that "application/ld+json; profile="https://www.w3.org/ns/activitystreams#"" is negotiated; and you can of course identify ActivityPub posts by their content type.

This permits clients to do "transparent" upgrades: They can start requesting AS2 content, and will migrate to AP as and when the servers do, without any need to rewrite URIs, etc.

[strugee]

@oshepherd yeah, I agree. Unless any unexpected issues come up that's probably going to be the way this goes.

[snarfed]

definitely looking forward to this! I've been sketching designs to bridge indieweb to ostatus and activitypub, a la https://brid.gy (some background in https://indieweb.org/2017/ostatusbridge ; thanks @strugee!), and I hope to include pump.io.

[clacke]

Duplicated by: https://framagit.org/compa/compa/issues/4

[evanp]

I think we're doing all this in the as2 branch now.

[evanp]

Could we convert this to a project on Github? Every one of these checkboxes is a big effort and probably deserves its own issue. They could at least be assigned to different people.

[strugee]

Absolutely. The checkboxes were easier for me when I was the only one working on it but I'm but attached to them. Do you want to split stuff off or should I?

[poperigby]

Is this still in progress?

[resynth1943]

I feel like you've run into this a bit quickly, and you've ended up getting tired with it. Any way I can help?

[ghost]

@resynth1943 we waiting the 6.0.0 release to start implement the remaining parts cc: @strugee