@enc-protocol/plugin-runtime

Server-side plugin runtime. Two classes:

• PluginRegistry — slot ↔ impl registry, mirror of the client SDK's registry but for the server (dataview / enclave).
• ServerDataview — wraps an AppClient and exposes higher-level query methods that apply registered plugins before returning to clients.

When to use

In your dataview process (the JS/TS service that materializes app projections before clients see them):

import { PluginRegistry, ServerDataview } from '@enc-protocol/plugin-runtime';
import { rank } from '@enc-protocol/plugin-ranker-engagement';
import { search } from '@enc-protocol/plugin-indexer-bm25';
import schemaJson from '@enc-protocol/twitter-cli/schema.json' with { type: 'json' };

const registry = new PluginRegistry({
  pluginSlots: schemaJson.pluginSlots,
  bindings: { RankerFn: rank, IndexerFn: search },
});

const dataview = new ServerDataview({
  client: appClient,                  // existing AppClient from impl-cli
  enclaveName: 'Twitter',
  registry,
  projectors: {
    post_created: (e) => ({ ...JSON.parse(e.content), authorId: JSON.parse(e.content).author_id /* etc */ }),
  },
});

// Clients call HTTP endpoints (not shown) that delegate to:
app.get('/feed/:viewer', async (req, res) => {
  res.json(await dataview.ranked('post_created', { pubkey: req.params.viewer }));
});

Now the client sees already-ranked results; the full corpus stays on the server.

In a single-process demo

example/twitter/ uses this exact pattern in-process to demonstrate the architectural boundary without a separate runtime.