New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support ActivityPub #499

Open
hmadison opened this Issue May 31, 2018 · 5 comments

Comments

Projects
None yet
4 participants
@hmadison
Contributor

hmadison commented May 31, 2018

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 comment has been minimized.

Show comment
Hide comment
@pushcx

pushcx May 31, 2018

Member

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.

Member

pushcx commented May 31, 2018

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

This comment has been minimized.

Show comment
Hide comment
@talklittle

talklittle May 31, 2018

Contributor

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.

Contributor

talklittle commented May 31, 2018

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

This comment has been minimized.

Show comment
Hide comment
@pushcx

pushcx May 31, 2018

Member

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

Member

pushcx commented May 31, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@talklittle

talklittle May 31, 2018

Contributor

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

Contributor

talklittle commented May 31, 2018

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

@picsi

This comment has been minimized.

Show comment
Hide comment
@picsi

picsi Jun 8, 2018

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

picsi commented Jun 8, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment