Design optional syndication adapter model #96

New issue

Open

opened 2026-06-04 08:23:48 -05:00 by erik · 0 comments

erik commented

2026-06-04 08:23:48 -05:00

Owner

Goal

Create a design for how Slugkit-powered sites can optionally implement external syndication/discovery protocols such as Standard.site (https://standard.site) and ActivityPub without adding protocol-specific Slugkit API endpoints or CLI commands.

Requirements

Define the boundary between the Slugkit API contract and optional site-level protocol adapters.
Explain how Standard.site (https://standard.site) could be implemented behind the scenes using existing Slugkit site/post data.
Identify any generic extension points Slugkit should provide or document, such as publish lifecycle hooks, implementation-owned metadata, route ownership outside /api/v1, or template/head link injection.
Avoid adding Standard.site-specific Slugkit commands or API routes.
Compare the model to ActivityPub support where useful, emphasizing optional implementation rather than core requirement.
Produce a concise design document with recommended phases and tradeoffs.

Acceptance criteria

Design document describes the optional adapter model and API boundary clearly.
Design explains how a site could implement Standard.site publication and document verification using Slugkit data.
Design identifies generic hooks or metadata needs without requiring protocol-specific Slugkit endpoints or commands.
Design includes recommended implementation phases and open questions.
Design explicitly states Standard.site remains optional for Slugkit-powered sites.

Dependencies

None

## Goal Create a design for how Slugkit-powered sites can optionally implement external syndication/discovery protocols such as Standard.site (https://standard.site) and ActivityPub without adding protocol-specific Slugkit API endpoints or CLI commands. ## Requirements - Define the boundary between the Slugkit API contract and optional site-level protocol adapters. - Explain how Standard.site (https://standard.site) could be implemented behind the scenes using existing Slugkit site/post data. - Identify any generic extension points Slugkit should provide or document, such as publish lifecycle hooks, implementation-owned metadata, route ownership outside `/api/v1`, or template/head link injection. - Avoid adding Standard.site-specific Slugkit commands or API routes. - Compare the model to ActivityPub support where useful, emphasizing optional implementation rather than core requirement. - Produce a concise design document with recommended phases and tradeoffs. ## Acceptance criteria - [ ] Design document describes the optional adapter model and API boundary clearly. - [ ] Design explains how a site could implement Standard.site publication and document verification using Slugkit data. - [ ] Design identifies generic hooks or metadata needs without requiring protocol-specific Slugkit endpoints or commands. - [ ] Design includes recommended implementation phases and open questions. - [ ] Design explicitly states Standard.site remains optional for Slugkit-powered sites. ## Dependencies - None

erik added the

labels

2026-06-04 08:23:48 -05:00

erik added

priority:low

and removed

priority:medium