Add federation readiness diagnostics #103

New issue

Open

opened 2026-06-05 07:58:53 -05:00 by erik · 0 comments

erik commented

2026-06-05 07:58:53 -05:00

Owner

Goal

Research how Slugkit-generated sites should assess ActivityPub/federation readiness without adding bespoke federation diagnostics to the Slugkit management API contract.

The output should clarify what readiness means for a generated site, which checks belong in generated-site/template code, which belong in deployment documentation, and which checks should not be owned by the Slugkit API or CLI.

Requirements

Treat ActivityPub readiness as generated-site/template functionality, not as a Slugkit API resource.
Do not add /api/v1/activitypub/* diagnostics routes or any other bespoke federation diagnostics endpoint to the Slugkit API contract.
Do not make slug doctor depend on federation-specific API responses.
Review the current Fedify-backed template behavior: WebFinger, actor document, inbox, outbox, followers, following, featured, actor keys, runtime config, public origin, and production safety checks.
Identify concrete readiness questions a generated site owner needs answered before enabling federation in production.
Distinguish checks that can run in-process against local template code/config from checks that require a deployed public HTTPS origin.
Define anti-goals that preserve Slugkit philosophy: generated sites own their code, the Slugkit API remains generic, and ActivityPub operational policy is not forced through the management API.
Compare implementation options such as a template-local script, a generated-site test suite, documentation-only checklist, or future site-owned admin page.
Recommend the smallest future implementation task, if any, that fits the project philosophy.
Document findings in a project note or design document.

Acceptance criteria

Research document explains why federation readiness should not be exposed as a Slugkit API endpoint.
Research document identifies generated-site/template-owned readiness checks for actor config, key material, canonical URLs, WebFinger, actor document, and Fedify collections.
Research document separates local/in-process checks from public deployment checks.
Research document lists anti-goals and API-boundary constraints.
Research document compares at least two implementation options and recommends one.
Any proposed future work is framed as generated-site/template functionality, not a Slugkit API contract change.
No code changes add federation diagnostics to /api/v1 or slug doctor.

Dependencies

none

## Goal Research how Slugkit-generated sites should assess ActivityPub/federation readiness without adding bespoke federation diagnostics to the Slugkit management API contract. The output should clarify what readiness means for a generated site, which checks belong in generated-site/template code, which belong in deployment documentation, and which checks should not be owned by the Slugkit API or CLI. ## Requirements - Treat ActivityPub readiness as generated-site/template functionality, not as a Slugkit API resource. - Do not add `/api/v1/activitypub/*` diagnostics routes or any other bespoke federation diagnostics endpoint to the Slugkit API contract. - Do not make `slug doctor` depend on federation-specific API responses. - Review the current Fedify-backed template behavior: WebFinger, actor document, inbox, outbox, followers, following, featured, actor keys, runtime config, public origin, and production safety checks. - Identify concrete readiness questions a generated site owner needs answered before enabling federation in production. - Distinguish checks that can run in-process against local template code/config from checks that require a deployed public HTTPS origin. - Define anti-goals that preserve Slugkit philosophy: generated sites own their code, the Slugkit API remains generic, and ActivityPub operational policy is not forced through the management API. - Compare implementation options such as a template-local script, a generated-site test suite, documentation-only checklist, or future site-owned admin page. - Recommend the smallest future implementation task, if any, that fits the project philosophy. - Document findings in a project note or design document. ## Acceptance criteria - [ ] Research document explains why federation readiness should not be exposed as a Slugkit API endpoint. - [ ] Research document identifies generated-site/template-owned readiness checks for actor config, key material, canonical URLs, WebFinger, actor document, and Fedify collections. - [ ] Research document separates local/in-process checks from public deployment checks. - [ ] Research document lists anti-goals and API-boundary constraints. - [ ] Research document compares at least two implementation options and recommends one. - [ ] Any proposed future work is framed as generated-site/template functionality, not a Slugkit API contract change. - [ ] No code changes add federation diagnostics to `/api/v1` or `slug doctor`. ## Dependencies - none

erik added the

labels

2026-06-05 07:58:53 -05:00

erik added

priority:low

and removed