source/projects/activitypub_relay
2022-11-20 22:39:44 -07:00
..
src/python/relay Fmt 2022-11-20 22:39:44 -07:00
BUILD Setting up to do some minimal admin auth for the relay 2022-11-20 22:00:12 -07:00
Dockerfile Start trimming some of the __main__ crud 2022-11-20 22:34:07 -07:00
README.md Intern the relay 2022-11-19 23:45:47 -07:00
relay.sh Start trimming some of the __main__ crud 2022-11-20 22:34:07 -07:00
relay.yaml.example Intern the relay 2022-11-19 23:45:47 -07:00

ActivityPub Relay

A generic ActivityPub/LitePub compatible with Pleroma and Mastodon.

What is a relay?

A relay is a webserver implementing ActivityPub/LitePub. Normally when posting content on an ActivityPub server, that content is only listed publicly on the feed of the hosting server, and servers to which your server announces that content.

Relays provide a way for ActivityPub servers to announce posts to and receive posts from a wider audience. For instance there are public lists of nodes offering relaying.

Nuts and bolts of ActivityPub

ActivityPub is a protocol by which Actors exchange messages. An actor consists of two key things - an inbox and an outbox. The inbox is a URL to which other actors can POST messages. The outbox is a URL naming a paginated collection which other actors can GET to read messages from.

Any user in an ActivityPub system, for instance @arrdem@macaw.social is an actor with such an inbox outbox pair. ActivityPub messages for follows of users or messages mentioning users are implemented with messages directly to the user's outbox.

In addition, Mastodon ActivityPub servers themselves have "instance actors". These actors communicate using server to server interactions. Instance actors (f. ex. https://macaw.social/actor) emit and receive messages regarding system level activities. New posts (Create) are the major thing, but plenty of other messages flow through too.

The relay "protocol" is a Follow of the relay's actor by an ActivityPub server that wishes to participate in the relay. The relay will acknowledge the follow request, and then itself follow the participating server back. These two follow relationships in place, the participating server will announce any new posts to the relay since the relay follows it. This is just the normal ActivityPub behavior. Likewise, the relay will announce any new posts it gets from elsewhere to the participating server. Same deal.

That's it.

Why relays at all?

In theory, two ActivityPub servers can talk to each other directly. Why relays?

Relays are 1 to N bridges. Follow one relay, get activity from every other host on that bridge. This makes it easier for new, small nodes to participate in a wider network since they only need to follow one host not follow every single other host. Traditional relay/clearing house model.

What is this program?

The relay itself is a webserver providing two major components.

  • A hardcoded webfinger implementation for resolving the user acct:relay@your.relay.hostname
  • A message relay, which will perform a stateless relay of new activity to connected nodes

The relay offers three moderation capabilities:

  • An explicit allowlist mode restricting connected nodes
  • A denylist mode restricting connected nodes by name
  • A denylist mode restricting connected nodes by self-identified server software

Getting Started

Normally, you would direct your LitePub instance software to follow the LitePub actor found on the relay. In Pleroma this would be something like:

$ MIX_ENV=prod mix relay_follow https://your.relay.hostname/actor

On Mastodon the process is similar, in Administration > Relays > Add New Relay one would list the relay's URL

https://your.relay.hostname/actor

Status

  • Works
  • Poorly packaged
  • Not yet threaded (nor is upstream)
  • Not yet tested (nor is upstream)
  • Missing web-oriented administrative functionality
  • Missing web-oriented configuration/state management

This work is derived from https://git.pleroma.social/pleroma/relay, which is published under the terms of the AGPLv3.