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:

• Object id properties? (Section 3.2 Retrieving objects)
• GET Actor inboxes Get Actor inbox for ActivityPub #1552
• POST Actor inboxes with HTTP Signature POST AS2 Activity to inbox with HTTP Signatures #1572
• GET Actor outboxes
• POST Actor outboxes with OAuth 2.0 POST AS2 Activity to outbox with OAuth 2.0 #1571
• Actor Following collections?
• Actor Followers collections?
• Actor Liked collections? (optional)
• Binary uploads? (Section 6 Uploading Media, optional not optional for us)

AuthZ/AuthC:

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

Conversion:

• 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?
• 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