GoActivityPub Documentation Wiki

The .well-known stand alone application provides some of the .well-known endpoints relevant to the ActivityPub and OAuth2 specifications.

The most important ones are:

• The webfinger endpoint for resource discovery. It accepts both acct and http resource types.
• The oauth-authorization-server endpoint for exposing metadata about how to dynamically register OAuth2 clients

Running the server

The well-known server accepts the same configuration .env file as FedBOX and accepts it as a --config argument in the command line.

Configuration with the .env file

$ point --config /storage/.env

The environment variables it recognizes and uses from that file are STORAGE, STORAGE_PATH and ENV. They are described in the FedBOX .env.dist file.

ENV

The environment that the well-known server will run as. The values are prod, qa, and dev.

STORAGE

The STORAGE env variable represents the storage type, currently we support the same ones as described in the storage modules list.

• fs - file system
• sqlite - sqlite single file database
• boltdb - BoltDB key-value store
• badger - Badger key-value store

STORAGE_PATH

The STORAGE_PATH represents the path on disk to the storage directory.

It supports some conveniences placeholders that are replaced with corresponding values:

• If a path starts with ‘~’, it gets replaced with the current user’s home directory, if the HOME environment variable is present in the running environment.
• If a path contains ‘%env%’ it gets replaced with the current ENV value.
• If a path contains ‘%storage%’ it gets replaced with the current STORAGE value.

Configuration using a storage path directly

$ point --path fs:///storage/example.com/qa

The storage path logic can be circumvented by using directly a custom dsn that has the following structure: type:///actual/disk/path, where type is the storage type described above, and /actual/disk/path is the actual path on disk of the storage directory.

Running the server together with FedBOX

To be able to have a setup with a mixed configuration, where the well-known server runs alongside FedBOX, you get the additional requirement that the requests done to the well-known endpoints are proxied to the correct service.

Here’s an example using Caddy:

# server .well-known endpoints
handle /.well-known/* {
	reverse_proxy http://well-known-service:2345 {
		transport http
	}
}