Skip to content

ActivityPub in Rust

Jump to bottom
Riley edited this page May 12, 2019 · 5 revisions

Routes

/ap/inbox

  • GET
    • Maybe not supported
    • Return public posts (everyone except local users)
  • POST
    • Must verify with HTTP Signatures
    • Create Object or Link

/ap/outbox

  • GET
    • Maybe not supported
    • Return public posts (only local users)
  • POST
    • Maybe not supported
    • Must verify with basic auth or bearer tokens
    • Create Object or Link
    • Trigger Delivery Workers

/ap/user/{user-identifier}

  • GET
    • Return Profile
  • POST
    • Not Supported

/ap/user/{user-identifier}/inbox

  • GET
    • Must verify with basic auth or bearer tokens
    • Return inbound posts for that user
  • POST
    • Must verify with HTTP Signatures
    • Create Object or Link

/ap/user/{user-identifier}/outbox

  • GET
    • Maybe not supported
    • Return public posts by user
  • POST
    • Must verify with basic auth or bearer tokens
    • Create Object or Link
    • Trigger Delivery Workers

/.well-known/webfinger

  • GET ?acct={user}
    • Return user info

Database

Buckets

Objects

  • Stores: Whole ActivityPub Objects and Links
  • Key: ID
Usage

When any ActivityPub Object or Link is created, it is stored here.

ObjectDates

  • Stores: IDs of ActivityPub Objects and Links
  • Key: item creation timestamp (created on server, not published_at ActivityPub field)
Usage

When any ActivityPub Object or Link is created, we store that item's ID behind the a timestamp so we can look them up in order by date.

{ActivityPub type} (maybe not this one)

  • Stores: IDs of ActivityPub Objects and Links
  • Key: item creation timestamp (created on server, not published_at ActivityPub field)
Usage

When any ActivityPub Object or Link is created, we store that item's ID behind a timestamp in a bucket with that item's type, so we can look up specific ActivityPub types by date.

{user-identifier}-inbox

  • Stores: IDs of ActivityPub Objects and Links
  • Key: item creation timestamp (created on server, not published_at ActivityPub field)
Usage

When any ActivityPub Object or Link is created and resolved to be intended for a local user, it's ID is stored behind a timestamp in this bucket so it is possible to quickly look up posts for a given user

{user-identifier}-{ActivityPub type}-inbox

  • Stores: IDs of ActivityPub Objects or Links
  • Key: item creation timestamp (created on server, not published_at ActivityPub field)
Usage

When any ActivityPub Object or Link of a certain type is created and resolved to be intended for a local user, it's ID is stored behind a timestamp in this bucket so it is possible to quickly look up posts of a given kind for a given user.

{user-identifier}-outbox

  • Stores: IDs of ActivityPub Objects and Links
  • Key: item creation timestamp (created on server, not published_at ActivityPub field)
Usage

When any ActivityPub Object or Link is created by a user, it's ID is stored behind a timestamp in this bucket so it is possible to quickly look up posts by a given user. This bucket will need to have filters applied to it in many cases to avoid showing posts not intended for the user performing the lookup.

{user-identifier}-{ActivityPub type}-outbox
  • Stores: IDs of ActivityPub Objects or Links
  • Key: item creation timestamp (created on server, not published_at ActivityPub field)
Usage

When any ActivityPub Object or Link of a certain type is created by a given user, it's ID is stored behind a timestamp in this bucket so it is possible to quickly look up posts of a given kind by that user. This bucket will need to have filters applied to it in many cases to avoid showing posts not intended for the user performing the lookup.

Extra Functionality

  • When creating and starting this application, a custom Configuration can be provided that specifies an Actix Actor that will receive a Message with created ActivityPub Objects and Links.
  • In order to bypass the need for HttpRequests to create ActivityPub items, pre-formatted items can be sent to an Actix Actor via a Message, which will handle the processing for that item.
  • In order for basic auth or bearer tokens to work properly, a hosting application must provide a callback, possibly in the form of a Trait, that can be used to look up and verify users.
  • This service will need to have it's own job processor in order to ensure delivery of posts to federated servers. An existing job processor instance may be supplied during the creation of this resource in order to reduce duplication of running processes.

More

  • An ActivityPub User Agent, like Aardwolf, could mount this resource within their Application via Actix's actix_web::App::service. Other ActivityPub User Agents could still utilize this ActivityPub server via some method like OAuth, in combination with the ActivityPub Client to Server API.
  • It is possible that we could extract User Management into it's own Actix resource, similarly to the way this document has outlined extracting ActivityPub into it's own Actix service. If we go down the route of creating a dedicated user management and OAuth actix resource, we could depend directly on that resource with this one and almost introduce a "plug-n-play" activitypub server for rust projects
Clone this wiki locally