Background
Part of the phase 3 interoperability smoke test rollout tracked in #682.
WriteFreely is a minimalist blogging platform that federates blog posts
as Article objects — distinct from the Note objects used by
microblogging services. This makes it a good target for verifying
Fedify's handling of long-form content types.
Docker image requirements
- Deployable via Docker Compose with no manual steps beyond configuration
- Exposes an HTTP endpoint reachable by the Caddy TLS proxy within the
smoke Docker network
- Supports ActivityPub federation out of the box
- Allows programmatic account creation and API token issuance without
requiring email verification
- Note: WriteFreely does not implement the Mastodon-compatible API.
The provisioning script and any new scenarios must use the WriteFreely
API directly
Test scenarios
The six baseline scenarios in orchestrator.ts do not apply here since
WriteFreely does not implement the Mastodon-compatible API. The following
new scenarios are required:
- Fedify → WriteFreely (
Follow a blog): follow a WriteFreely blog
from the Fedify harness and verify Accept(Follow) is received.
WriteFreely auto-accepts follows, so no server-side relationship API
is needed — poll the harness inbox directly for the Accept
- WriteFreely → Fedify (
Create(Article)): publish a post on
WriteFreely and verify the harness inbox receives a Create activity
whose object type is Article
The harness Create inbox listener needs to be extended to capture the
object type, and store.ts needs an objectType field on
ReceivedActivity (this may already be done as part of the Pixelfed
sub-issue).
Acceptance criteria
test/smoke/writefreely/ is added with the required files:
docker-compose.yml, Caddyfile.writefreely,
Caddyfile.fedify-harness, generate-certs.sh, provision.sh, and
a server config file
- The provisioning script creates a test user, obtains an API token, and
resolves the Fedify harness account
- Both scenarios above pass reliably
- A GitHub Actions workflow (
.github/workflows/smoke-writefreely.yml)
is added, triggered on pushes to main, next, and
*.*-maintenance branches, and on workflow_dispatch
Background
Part of the phase 3 interoperability smoke test rollout tracked in #682.
WriteFreely is a minimalist blogging platform that federates blog posts
as
Articleobjects — distinct from theNoteobjects used bymicroblogging services. This makes it a good target for verifying
Fedify's handling of long-form content types.
Docker image requirements
smokeDocker networkrequiring email verification
The provisioning script and any new scenarios must use the WriteFreely
API directly
Test scenarios
The six baseline scenarios in
orchestrator.tsdo not apply here sinceWriteFreely does not implement the Mastodon-compatible API. The following
new scenarios are required:
Followa blog): follow a WriteFreely blogfrom the Fedify harness and verify
Accept(Follow)is received.WriteFreely auto-accepts follows, so no server-side relationship API
is needed — poll the harness inbox directly for the
AcceptCreate(Article)): publish a post onWriteFreely and verify the harness inbox receives a
Createactivitywhose object type is
ArticleThe harness
Createinbox listener needs to be extended to capture theobject type, and
store.tsneeds anobjectTypefield onReceivedActivity(this may already be done as part of the Pixelfedsub-issue).
Acceptance criteria
test/smoke/writefreely/is added with the required files:docker-compose.yml,Caddyfile.writefreely,Caddyfile.fedify-harness,generate-certs.sh,provision.sh, anda server config file
resolves the Fedify harness account
.github/workflows/smoke-writefreely.yml)is added, triggered on pushes to
main,next, and*.*-maintenancebranches, and onworkflow_dispatch