soulseek, extracted from the platform as a plugin

Seventh plugin out, and the first that was already dead. Soulseek had been switched off since 2026-08-13: hono.ts had the router import and its mount commented out, so createSidecarProxy never ran, registerProxiedPrefix was never called, the slskd:server announcement fired into a void, and officer-slskd was not in the ecosystem at all. The permission entry had been reduced to api: [], which is why assertPermissionTotality was satisfied and the server booted clean. The UI rendered perfectly and every request 404'd. So this is a resurrection as well as a move. The mount is now /api/soulseek, derived via mountPrefix from the appName — all 47 frontend call sites repointed from /slskd/. The credential key in service_connections stays 'slskd': it names the daemon, not the route. Those two strings differ on purpose and conflating them reads the wrong row. The connection stays in core service_connections, as transmission does, so 'slskd' remains in a platform union this plugin cannot extend. Recorded in PLUGIN.md. Unlike transmission this plugin does own a schema: favourites and the two halves of the cached browse tree, which slskd has no concept of. Those three tables had been dropped from the drizzle barrel, so bun db:push would have deleted them on any server holding data. 313 palette classes converted to the semantic tone set, including a shared PHASE_TONE the three transfer views previously each copied.
2026-08-19 02:55:02 +00:00
commit c11f45c033
36 changed files with 5878 additions and 0 deletions
@@ -0,0 +1,49 @@
+import type { PluginManifest } from '@@/plugins/manifest';
+
+/**
+ * Soulseek — search and download from the Soulseek network, through your own slskd daemon.
+ *
+ * ── What this plugin is, and what it is not ──
+ *
+ * It does not install or supervise slskd, and it shares no files itself. You point it at a daemon and it
+ * speaks slskd's API on your behalf, holding the API key server-side so no device ever carries it.
+ *
+ * ── Where the connection lives ──
+ *
+ * In `service_connections`, a CORE table — the same one Transmission uses, keyed `(user_id, service)`
+ * and already encrypted at rest. That table was designed for exactly this shape and says so: services
+ * the owner has exactly ONE of. Nobody has two Soulseek daemons, so there is no label, no `is_active`
+ * and no switcher.
+ *
+ * It does mean this plugin depends on a core facility it does not own — `'slskd'` is a member of the
+ * platform's `ServiceName` union, which a plugin cannot extend. Recorded in PLUGIN.md rather than
+ * hidden, because it is the one part of this extraction that is not self-contained.
+ *
+ * ── What it DOES own ──
+ *
+ * Three tables, in `db/schema.ts`: favourites, and the two halves of the cached browse tree. Those are
+ * Officer's own features — slskd has no concept of either — and they are served by the sidecar's
+ * `/_officer/*` routes rather than proxied upstream.
+ *
+ * ── No `osDependencies` ──
+ *
+ * Nothing shells out. The sidecar speaks slskd's HTTP API over `fetch`.
+ */
+export const manifest: PluginManifest = {
+  publisher: 'officerdev',
+  version: '1.0.0',
+  platform: '>=1.0.0',
+
+  label: 'Soulseek',
+  summary: 'Search and download from the Soulseek network, via your own slskd daemon',
+  icon: 'Music2',
+  color: '#22c55e',
+
+  permissions: [
+    {
+      key: 'soulseek',
+      label: 'Soulseek',
+      description: 'Search and download from the Soulseek network',
+    },
+  ],
+};