This application is an implementation of the ActivityPub protocol for XWiki.
- Project Lead: Simon Urli
- Documentation & Download
- Issue Tracker
- Communication: Forum, Chat
- Development Practices
- Minimal XWiki version supported: XWiki 12.2
- License: LGPL 2.1
- Translations:
- Sonar Dashboard: N/A
- Continuous Integration Status:
dev/mastodon-federation/ provides a local development environment for testing the federation with a real Mastodon instance. It runs XWiki and Mastodon behind an HTTPS reverse proxy (Caddy), allowing you to exercise federation scenarios locally without external infrastructure.
- Docker and Docker Compose v2 (installed and running)
- Add to
/etc/hosts:127.0.0.1 xwiki.local mastodon.local - JDK 8 and Maven to build the XWiki extension locally
From dev/mastodon-federation/:
- Copy the environment template:
cp .env.example .env - Start the harness:
scripts/up.sh - View the connection details:
scripts/info.sh - Stop the harness (use
-vto remove volumes):scripts/down.sh [-v]
Caddy publishes on host ports 443 and 80 by default. If those are already taken on your machine (e.g. a host nginx), set HTTPS_PORT/HTTP_PORT in .env to free ports such as 8443/8080 and browse https://xwiki.local:8443/.
Caveat: the two instances always federate with each other inside the Docker network on the standard internal port, so container-to-container federation is unaffected by this setting. But actor/WEB_DOMAIN URLs and browser links that Mastodon and XWiki generate omit the port, so on non-standard ports a link followed from your host browser points at the default port (whatever else is listening there), not the harness. Standard 443/80 avoids this entirely.
Browsers will warn that the certificate is self-signed until you import dev/mastodon-federation/certs/root.crt as a trusted CA in your browser or system keychain. The harness generates this certificate automatically on first run.
scripts/smoke.sh is a thin objective check: it does not drive the full federation flows (those you exercise manually in the two web UIs). It asserts that Mastodon actor discovery works over WebFinger, that XWiki's ActivityPub storage is healthy (the actor endpoint responds without a 500), and reports whether an XWiki actor is resolvable yet.
XWiki materializes a user's ActivityPub actor on first use rather than automatically, so until you enable ActivityPub for a user (sign in as that user and open the ActivityPub section of their profile, or follow an account), the XWiki-side discovery check reports PENDING. That is expected on a fresh harness, not a failure.
Mastodon account passwords are not read from .env. Instead, they are generated by tootctl during provisioning and printed to the console. The .env file only specifies the usernames (MASTODON_OWNER_USER, MASTODON_TEST_USER); use the printed passwords to log into the Mastodon web UI.
This project has been partly funded by NLnet fundation as part of the NGI Search & Discovery call.