Support ActivityPub

[hmadison]

Hi pushcx,

Per our previous discussions in #lobsters and our feeling that we have come to some level of agreement. I would like add ActivityPub support to the lobste.rs codebase to act as a formalized API, and to allow for twitter style and mailing list style integrations with other ActivityPub supporting websites (e.g mastodon instances).

I don’t intend for these changes to:

• Change the invite process we have in place
• Take comments from the outside
• Force federation on lobster.rs

In the spirt of openess, I do intend to provide options for sister sites to opt into these behaviors if their communites so desire.

My proposed milestones for this are as followed:

• Phase One: Add OAuth2, UI for generating Api Keys and the public inboxes for stoires and tags.
• Phase Two: Add Private inbox support for users.
• Phase Three: Add write support to resources (voting, submitting stoires via api). At this point would be a ActivityPub conformant Server.
• Phase Four: Support s2s messaging, verification profiles (listed below)

The changes I would make are listed below:

Client to Server (Phase One to Three)

Client To Server authentication would be implemented with OAuth2 (probably doorkeeper).

Actors

We would use two kinds of activity stream actor types, Person and Service.

Person would represent a lobste.rs user. Service objects would represent tags. Their names would either be lobsters (for the home page feed) or tag-<tag-name> for the tag specific feed. These names would be unavailable for registration.

Objects

We would use three kinds of objects Tags, Documents, and Notes. Tags and Documents would be used for stories and Notes would be used for comments.

Collections

For Persons

At this stage, the inbox would be a combination of the user’s front page, private messages, direct replies to user comments and all replies to user submitted stories. Filtering a tag would remove the tag from the inbox. Likewise hiding a story would remove user comments from the inbox. Inboxes would only be accessible to their owners.

The outbox would be a combination all stories submitted by the user and all comments posted by the user.

The liked collection would be all upvoted stories by the user.

For Services

The inbox be all stories posted to that tag or present on the home page. The outbox would be an empty collection.

Interactions Mapping

ActivityPub Action	Site Action
Create	Submits a story or comment to the site. Clients submitting a story should use the Document object type, and must include at least one tag. Clients submitting a comment should use the Note object type and provide an inReplyTo pointing to a comment or story.
Update	Updates an already submitted comment / story.
Delete	Deletes a story or comment from the website.
Follow	If federation is enabled, lets actors on 3rd party sites follow a Person or Service or other services to follow other services.
Add	Attempts to add a story to a tag’s inbox collection will suggest to add it.Remove Attempts to remove a story from a tag’s inbox collection will suggest to remove it.
Like	Votes a story or comment “up”.
Undo	"Performs the following actions:Like, removes the vote “up”Follow, removes the follow"Block Not allowed, the codebase doesn’t support the concept of blocking users.

Server to Server (Phase Four)

Collections

To enable server to server, Person and Service would gain followers collections to track the 3rd party (federated) entities wanting to be notified of updates. Services would gain a following collections to track and ingest comments and stories from other servers.

Delivery and Verification

I feel we need to support 3 delivery and verification strategies.

Off

This would disable federation entirely.

Trusted Users Only

This would be the mode that lobste.rs would run in.

Each submitted story or comment would have its Linked Data Signature checked and validated against the user database. Only invited users in good standing with their public key added to the database would be allowed to post from outside instances.

Full

This would allow for sites running the lobster.rs codebase to run and build a federated network between themselves.

[pushcx]

This is great, and it's clear I have a lot of reading to do. I'm happy to replicate our Twitter + ML integration to this new platform and really appreciate you volunteering to start this.

[talklittle]

Phase One: Add OAuth2, UI for generating Api Keys and the public inboxes for stoires and tags.

I've done a bit of work towards this using the Doorkeeper gem. It's been stalled for now, depending on a feature in the unreleased Doorkeeper 5.0 related to applications and scopes.

https://github.com/talklittle/lobsters/tree/oauth-2.0

Anyone working on OAuth support, feel free to fork, or ignore if you have something better.

[pushcx]

@talklittle What prompted you to work on OAuth2? Did you see it as a first step towards ActivityPub, or did you have another goal in mind?

[talklittle]

I worked on OAuth toward the goal of an API supporting the creation of scripts, native apps, etc.

https://lobste.rs/s/t1xkue/add_oauth_2_0_support_lobste_rs

[nicolasmaia]

This is great. For reference, you might get some ideas here https://mastodon.social/@prismo/100165010311738421

[xuv]

Get in touch also with https://github.com/mariusor/littr.go for inspiration and collaboration

[mariusor]

Hi, apparently I've been summoned. :)

Yes, if you guys need any information regarding ActivityPub I can help, I've been working on a naive library implementation of it for golang and I've passed through most of the spec, plus the ActivityStreams vocabulary, plus JSON-LD.

I'm also in touch with other developers that are working on federated link aggregators. One of these, called Prismo, is actually based on RoR so it might be easier to borrow good ideas from it.

Let me know how/if I can help.

[strypey]

Any progress on this?

[nileshtrivedi]

Some time ago, I added ActivityPub support in https://learnawesome.org which is an open-source Ruby on Rails app. The approach is very similar: Both users and topics become AP actors and we don't consume any AP events except follow/unfollow requests. It actually turned out to be quite easy. This comment might be helpful.

A suggestion would be to keep testing this regularly. Mastodon keeps changing their signature validation which broke the integration a couple of times.

[pushcx]

@nileshtrivedi How do you know it's broken, manually check that content shows up? And: do Mastodon's changes not put them out of spec in some way? Why would signature validation change in the first place? Hearing that it may be a drain to keep working is pretty disconcerting, I'd like to understand the landscape better.

@strypey All activity is visible on this issue.

[nileshtrivedi]

@pushcx I did not look very deeply yet. I have tested my AP work using Mastodon only. Users complained that their follow requests sent from Mastodon to LearnAwesome were not being auto-approved and when I investigated, I found that Mastodon had changed their signature validation in a minor release.

From everything I hear, AP spec is fairly stable and all apps in Fediverse are integrating nicely. There are auxiliary things like WebFinger which are outside the scope of AP but are often recommended.

[nileshtrivedi]

BTW, I did not link to the implementation details correctly. See this comment on how little work was needed for my Rails app to be AP-compatible: learn-awesome/learn#121 (comment)

I gave a couple of talks about AP-implementation in webapps:

• https://www.youtube.com/watch?v=vmshzcmTeB8
• https://conf.tube/videos/watch/c42604a8-d71d-4bd0-8081-d2c77210f206?start=0s