TAPS is an experimental Activitypub server, implementing both server-to-server (S2S) and client-to-server (C2S) .
It handles the following activities:
There is no web interface for administation, which is done by command line tools or an expertimental GUI.
Note that while the Activitypub spec indicates that JSON-LD must be used in message communication, TAPS also accepts messages in XML-RDF and Turtle formats. This can be useful when using simple tools to interact with the server.
The server also responds to some
Webfinger requests
(of the form https://<host>/.well-known/webfinger...
).
The server can respond in HTML for actor's IRIs. See for example the OCaml on Github bot.
The server has no blocking capabilities of accounts or instances, which are not a satisfying security solution anyway (a better proposition could be networks of consent). By now, only followers of an actor can post to the actor's inbox.
The activitypub_server package must have been installed.
A configuration file in JSON format is used to specify some values. Here is an example with comments between /* and */ ((which is invalid in JSON):
{ "https": { /* ssl certificates for server */ "cert_file": "./server-certificates/server.pem", "key_file": "./server-certificates/server.key", "ca_file": null, /* port the server listens to */ "port": 10000 }, /* the root IRI of all IRIs handled by the server */ "root_iri": "https://taps.good-eris.net/", /* the directory to store data */ "storage_root": "taps-root/", /* the directory used to cache json-ld data, not to fetch json-ld contexts for each query */ "jsonld_cache_dir": "jsonld-cache", /* the directory used to cache remote resources */ "cache_dir": "cache", /* cache validity delay in seconds, default is one hour */ "cache_delay": 3600, /* directory used to store queues of sent message */ "process_dir": "taps-process", /* the graph file to store information about a resource stored in a directory, for example an actor or a collection */ "dir_graph_file": ".graph.ttl", /* log level, can be noen, debug, info, warning, error, or app */ "log_level": "warning", /* a pair (path appended to root IRI, directory). The final IRI is used to post and retrieve attachments, the directory is used to store them. If not specified, the server will not accept posting attachments, but a client may use another service to upload attachments and use the resulting IRI in activities. */ "media_path": ("media", "media"), /* whether an actor can announce a same IRI multiple times. */ "allow_multiple_announcements": false }
You can create a default configuration file myconf.json with:
$ taps --init-conf -c myconf.json
Then edit this file and run the server, using this configuration file :
$ taps -c myconf.json
The needed directories will be created by the server at launch time if they do not exist. If the specified directories are relative, they are relative to the directory where the server is run, but absolute names can be used to specify directories.
The -c option is not mandatory; if not present, the server will use conf.json.
The server outputs log to stderr.
To add an actor, use the provided taps_create_actor tool. This tool needs the server configuration file, which can be specified with -c option, else it will read configuration from conf.json.
Synopsis:
$ taps_create_actor [-c file.json] [options] <username>
<username> is the identifier of the actor, used in IRIs.
Use --help option to list available options. They allow to set some values for the created actor:
A private/public key pair is generated and used to authenticate the actor in HTTPs requests.
Note that TAPS does not handle shared inbox for its hosted actors nor when delivering to actors on other servers.
All the profile information is stored in a RDF graph in
storage_root/actors/<username>/dir_graph_file
,
with storage_root
and dir_graph
being
defined in the server configuration file. Feel free to manually add information
into this profile file, but be aware that it must remain syntaxically correct (Turtle format)
and that this profile information is public.
To act as this actor through the client-to-server (C2S) protocol, a client must use a token to authenticate. Use the taps_add_token tool to add a named token for an actor:
$ taps_add_token <username> <token name>
The command prints on stdout the token string, of the form
<username>/<key>
. This token string can be used
in the
actor configuration of the client library
to authenticate as the actor. See the Directories and files section to
know where tokens are stored.
From the root IRI provided in the configuration file, the server handles the following IRIs:
actors/<username>
: access to <username>
's profile,actors/<username>/inbox
: <username>
's inbox (not public),actors/<username>/outbox
: <username>
's outbox; the collection is public but can contain not public activities,actors/<username>/outbox/1727988242108357191086
: an activity of <username>
with this IRI as id,actors/<username>/objects/1727988242108357205410
: an object created by <username>
, identified by this IRI,actors/<username>/objects/1727988242108357205410,likes
: the collection of likes of the object with IRI actors/<username>/objects/1727988242108357205410
,public
: public collection of local public activities.
The server files are organized as follows, under the storage_root
directory:
public/
: the public collection of local public activities,objects/<username>/
: directory with remote objects or activities referenced in
<username>
's objects or activities; this allows to fill graphs without
querying remote resources,actors/<username>/
: directory of actor <username>
, with
.graph.ttl
: public profile (RDF graph) about actor,.privkey.crt
: private key used to authenticate, the public key is included in the actor's public profile,.tokens
: the list of named tokens which can be used by a client to authenticate,followers/
: the collection of followers for this actor,following/
: the collection of actors this actor is following,inbox/
: the actor's inbox (a collection of activities),objects/
: the objects created by the actor (notes, ...),outbox/
: the actor's outbox (a public collection of activities).In a directory, the RDF graph associated is stored in file .graph.ttl
by default,
but this name can be changed in the configuration file. A directory
containing a collection will have such a file describing the collection:
Since a directory, especially inboxes and outboxes, can contain a lot of files,
the server uses a C binding to the get_dents64
system call to read directory entries faster.
Using get_dents64
instead of Lwt_unix.files_of_directory makes
reading entries of a directory about 30% faster. If get_dents64
was not available
at compilation time, a warning is issued by the server to indicate that
Lwt_unix.files_of_directory will be used instead.
Collections are also cached, so that most frequently used collections are not read from disk each time.