How do their APIs compare?

These two projects don't really have comparable "APIs" in the same sense — they're different kinds of systems serving different purposes, so let me break down what each actually exposes.

grvydev/project-lightspeed

This is a real-time streaming pipeline (OBS → FTL → WebRTC), and its "API" surface is mostly:

• A WebRTC signaling API over WebSockets — the webrtc component runs a hub that broadcasts structured messages to connected clients. For example, SendInfo marshals an Info struct and wraps it in a WebsocketMessage with an Event type (MessageTypeInfo) before broadcasting it to all clients [webrtc/ws/hub.go:L93-L107]. This is a push-based, event-typed message protocol rather than a request/response REST API.
• An internal WebRTC negotiation API built on Pion — createWebrtcApi() configures a webrtc.SettingEngine (NAT IP, ephemeral UDP port ranges) and a MediaEngine/interceptor.Registry, then constructs the webrtc.API object used to create peer connections [webrtc/main.go:L128-L165]. This isn't a public API per se — it's the internal negotiation logic triggered when a browser client connects via websocket.
• OBS-facing "API": not code, but a configuration contract — OBS is pointed at the ingest server via a services.json entry using the FTL protocol on a fixed port (8084), documented identically in both the top-level README and the ingest/README.md [README.md:L276-L315] [ingest/README.md:L121-L150].

So Lightspeed's API is small, low-level, and protocol-oriented (FTL ingest, WebSocket signaling, WebRTC media) — there's no evidence in the retrieved code of a JSON REST/RPC application API.

spacedriveapp/spacedrive

Spacedrive's frontend (packages/interface) talks to a Rust core through a typed query/mutation RPC layer, resembling tRPC-style hooks:

• Library-scoped mutations: useLibraryMutation('tags.apply'), 'media.ocr.extract', 'media.speech.transcribe', 'media.proxy.generate', etc., each namespaced like domain.action [packages/interface/src/components/Inspector/variants/FileInspector.tsx:L639-L678].
• Core-scoped queries/mutations for app-level state: useCoreQuery({ type: "core.status" }), useCoreQuery({ type: "config.app.get" }), and useCoreMutation("device.update") / useCoreMutation("core.reset") [packages/interface/src/Settings/pages/GeneralSettings.tsx:L9-L48].
• Mutation calls follow a consistent mutateAsync/mutate pattern with onSuccess/onError callbacks, e.g. generateProxy.mutateAsync(..., { onSuccess, onError }) [packages/interface/src/components/Inspector/variants/FileInspector.tsx:L1319-L1358] and resetData.mutate({ confirm: true }, { onSuccess, onError }) [packages/interface/src/Settings/pages/GeneralSettings.tsx:L29-L48].
• There's also a job-tracking API surfaced via useJobsContext()/jobs, with job objects carrying action_context.action_type strings like "locations.add", "files.copy", "volumes.index" that get formatted into human-readable labels by getJobDisplayName [packages/interface/src/components/JobManager/types.ts:L23-L105].
• React context hooks like useTopBar/useTopBarInternal throw explicit errors if used outside their provider, a common pattern for enforcing correct API usage at the UI layer [packages/interface/src/TopBar/Context.tsx:L182-L196].

Comparison