Add Misskey-family smoke tests (non-strict and strict)

[sij411]

Summary

As part of the interoperability smoke test suite (#481 Phase 1), add smoke tests targeting the Misskey family of ActivityPub servers, covering both non-strict (HTTP) and strict (HTTPS + signature verification) modes.

Why Sharkey over pure Misskey

We will use Sharkey as the Misskey-family representative rather than upstream Misskey for the following reasons:

• Misskey-family representative: Sharkey is a soft fork that closely tracks Misskey upstream, so testing against it effectively covers the Misskey protocol dialect (different JSON-LD context, activity shapes, _misskey_content, MFM formatting, etc.).
• Mastodon-compatible API: Sharkey exposes a Mastodon-compatible REST API (/api/v1/) alongside the native Misskey API. This lets us reuse a similar orchestrator pattern to the existing Mastodon tests (OAuth token, status posting, follow/unfollow via REST).
• Active maintenance: Sharkey is actively developed with regular releases (latest: 2025.x series), unlike some other Misskey forks that have gone dormant.
• Docker image available: Sharkey publishes pre-built Docker images at registry.activitypub.software/transfem-org/sharkey.

Implementation details

Docker infrastructure

Follow the same pattern as the existing Mastodon smoke tests:

• Services: Sharkey web, PostgreSQL, Redis, Fedify test harness (reuse existing harness from test/smoke/harness/)
• Image: registry.activitypub.software/transfem-org/sharkey:<pinned-version>
• Config: Sharkey uses .config/default.yml rather than environment variables, so we'll need to template this config file

Differences from Mastodon tests

Aspect	Mastodon	Sharkey
Provisioning	tootctl CLI + direct SQL	Sharkey admin API or direct DB seeding
Config format	Environment variables	.config/default.yml (YAML file)
Account pre-registration	Direct SQL insert into Mastodon schema	Different DB schema (Misskey user, user_profile, etc.)
API for orchestrator	Mastodon REST API	Mastodon-compatible API (/api/v1/)

Files to create

• .github/workflows/smoke-sharkey.yml — Non-strict CI workflow
• .github/workflows/smoke-sharkey-strict.yml — Strict CI workflow
• test/smoke/sharkey/docker-compose.yml — Non-strict Docker Compose
• test/smoke/sharkey/docker-compose.strict.yml — Strict Docker Compose
• test/smoke/sharkey/provision.sh — Non-strict provisioning script
• test/smoke/sharkey/provision-strict.sh — Strict provisioning script
• test/smoke/sharkey/sharkey.yml — Sharkey configuration template
• test/smoke/sharkey/sharkey-strict.yml — Strict-mode config template
• TLS cert generation script (may reuse/adapt from Mastodon strict setup)

Test scenarios

Same 6 scenarios as the Mastodon tests:

1. Server → Fedify (Follow)
2. Fedify → Server (Follow)
3. Fedify → Server (Create Note)
4. Server → Fedify (Reply)
5. Server → Fedify (Unfollow)
6. Fedify → Server (Unfollow)

CI strategy

• Non-strict: Run on pushes to main, next, and *.*-maintenance branches, plus workflow_dispatch
• Strict: Run on daily cron schedule, plus workflow_dispatch

Related

• Parent issue: #481
• Existing Mastodon smoke tests: .github/workflows/smoke-mastodon.yml, .github/workflows/smoke-mastodon-strict.yml

[sij411]

I think non-strict test isn't necessary so it might be good enough without non-strict parts.

• Sharkey needs Caddy for both http and https structures.

[dahlia]

Yeah, non-strict tests are unnecessary.