You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Follow-up to #206 (plugin system) and #164 (extract WebFinger/OAuth). The observation driving this: JSS's optional features are already pseudo-plugins — server.js registers each as an encapsulated Fastify plugin with options, gated by a createServer flag. The plugin system (#206) shouldn't be built and then have plugins written for it; it should formalize what eight features already do, then open the door to third parties.
The core/plugin line
Core (never plugins): LDP/storage, the auth chain (Bearer/DPoP/NIP-98), WAC. These ARE the pod — everything depends on them, and "disabling" them is just a broken server. Honest layering keeps them in src/.
Each feature gains a jss.plugin.json ({id, version, entry}) pointing at the module that already exists; entry wraps the current Fastify plugin in activate(api) using api.fastify.
createServer flags become plugins.entries.<id>.{enabled, config} — keep the old booleans as deprecated aliases for a transition window.
Adopt openclaw's "bundled plugin" concept (shared with jsclaw): shipped in-tree, sensible defaults, but loaded through the same machinery as external plugins — so plugins list shows them, allow/deny applies, and the loader has eight battle-tested consumers from day one.
The features themselves are the test suite: behavior must be byte-identical behind the new loading path.
The rest in any order; MCP last (it grows the extra registerMcpTool seam while moving)
Result: server.js shrinks toward core-only, every optional feature demonstrates the plugin contract, and third-party plugins (#157 CardDAV, #184 pane store) arrive into a system with eight working examples.
Reference: the same migration logic in jsclaw — its channels/commands/MCP tools were built in-tree first, then the plugin layer (jsclaw/jsclaw#64, jsclaw/jsclaw#77) formalized the seams they already used.
Follow-up to #206 (plugin system) and #164 (extract WebFinger/OAuth). The observation driving this: JSS's optional features are already pseudo-plugins — server.js registers each as an encapsulated Fastify plugin with options, gated by a createServer flag. The plugin system (#206) shouldn't be built and then have plugins written for it; it should formalize what eight features already do, then open the door to third parties.
The core/plugin line
Core (never plugins): LDP/storage, the auth chain (Bearer/DPoP/NIP-98), WAC. These ARE the pod — everything depends on them, and "disabling" them is just a broken server. Honest layering keeps them in src/.
Bundled plugins (migrate):
notificationsPluginactivityPubPlugin+ flagwebrtcPlugin+ path optionterminalPlugintunnelPluginremoteStoragePlugincreateServer({mcp: true})idpPluginMigration mechanics (mostly mechanical)
jss.plugin.json({id, version, entry}) pointing at the module that already exists; entry wraps the current Fastify plugin inactivate(api)usingapi.fastify.createServerflags becomeplugins.entries.<id>.{enabled, config}— keep the old booleans as deprecated aliases for a transition window.plugins listshows them, allow/deny applies, and the loader has eight battle-tested consumers from day one.Ordering
api.fastify)registerMcpToolseam while moving)Result: server.js shrinks toward core-only, every optional feature demonstrates the plugin contract, and third-party plugins (#157 CardDAV, #184 pane store) arrive into a system with eight working examples.
Reference: the same migration logic in jsclaw — its channels/commands/MCP tools were built in-tree first, then the plugin layer (jsclaw/jsclaw#64, jsclaw/jsclaw#77) formalized the seams they already used.