Implements the two read-key-scoped calls in
apps/server/src/obs/plugin.routes.ts: GET /api/obs/:slug/slots and
POST /api/obs/:slug/token.
Three pieces, all in core/ with no OBS dependency:
- stplugin::json -- a small, strict JSON reader. Hand-rolled rather than
vendoring nlohmann because the only JSON this plugin ever sees is two
fixed-shape responses from its own server, and the parser has to build on
three platforms with no package-manager step in CI. It never throws,
bounds its recursion (kMaxDepth=32) so a hostile response cannot overflow
the stack inside OBS, rejects trailing garbage, and returns the caller's
fallback for wrong-typed access instead of aborting.
- stplugin::HttpClient -- a two-method injectable interface, with libcurl
behind it on Linux/macOS and WinHTTP on Windows. WinHTTP rather than curl
on Windows because it ships with the OS and does TLS through SChannel: the
self-hosted winvm-builder runner has no package manager, and per the
scaffold README does not even have cmake preinstalled. Both backends cap
the response body at 4 MiB, keep TLS verification on (the read key is a
credential), and honour a whole-request timeout.
- stplugin::ApiClient -- maps the responses onto an ApiStatus enum that
distinguishes NotFound (404), Unavailable (503), NetworkError,
MalformedResponse and InvalidConfig. It deliberately does not claim to
know whether a 404 was a wrong key or an unknown slug, because the server
deliberately does not say. Server URLs are normalised the way an operator
actually pastes them, defaulting to https so the read key is never sent in
the clear by accident, and redactedUrl() exists so a URL can be logged
without the key.
Tests (279 checks across two new suites) run at two levels: a fake
HttpClient covering every response and error branch, and a real loopback
HTTP server on 127.0.0.1 driving the actual platform backend -- so libcurl
on Linux/macOS and WinHTTP on Windows are each exercised in CI rather than
assumed. The loopback cases deliberately include the ones that must not hang
OBS: a truncated JSON body, a connection accepted and closed without a
reply, non-HTTP garbage, a dead port, and a stalled server that has to be
cut off by the client's own timeout.
Verified locally on Ubuntu 24.04:
ctest --test-dir build --output-on-failure -> 4/4 passed
test_json: 158 checks passed
test_api_client: 121 checks passed
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE
Adds cmake/LiveKitSDK.cmake, adapted from
livekit-examples/cpp-example-collection's helper of the same name, with the
VERSION="latest" GitHub-API resolution path removed: this project pins an
exact client-sdk-cpp release (1.10.1, the newest tag as of today), and the
pin should not be silently bypassable. The module also now exports the
runtime shared libraries so packaging can stage liblivekit/liblivekit_ffi
next to the plugin module later.
core/ links LiveKit::livekit PUBLIC. A new smoke test proves the SDK is not
just linked but loadable and callable: livekit::initialize()/shutdown()
round-trip in-process, a second initialize() reports "already initialized",
the log level round-trips, and the SDK's generated LIVEKIT_BUILD_VERSION is
asserted equal to the version CMake pinned (so a stale extracted SDK
directory fails loudly rather than being silently reused).
Also adds core/tests/test_util.h, a dependency-free assertion harness that
keeps running after a failure and prints a pass/fail count, so CI output says
how much actually ran instead of dying on the first bare assert().
cmake_minimum_required goes 3.16 -> 3.19 (file(ARCHIVE_EXTRACT)).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE
First CI run confirmed winvm-builder is a self-hosted act_runner
labeled "windows-latest" but not the GitHub-hosted windows-latest
image -- cmake isn't on PATH there (unlike the Linux/macOS runners,
which do have working system/brew package managers). Use
lukka/get-cmake to fetch a pinned cmake+ninja without needing
admin/choco.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE
First pass on the streamer-tools OBS camera plugin: a minimal but real
CMake project matching the design doc's core-library/OBS-adapter split
(docs/superpowers/specs/2026-09-06-obs-camera-plugin-design.md in the
streamer-tools repo). No LiveKit FFI integration yet -- this proves the
toolchain works.
- core/: dependency-free C++17 library (no OBS dependency), unit tested
via CTest with no external test framework.
- obs-adapter/: adapted from obsproject/obs-plugintemplate (commit
3e7d7ac, 2025-12-09). Registers a real, stubbed OBS source type;
builds as a genuine dynamically-linked OBS module against Ubuntu's
system libobs-dev (confirmed via ldd/nm, not a fake stand-in).
- Simpler hand-written top-level CMakeLists.txt in place of the
template's full buildspec-driven bootstrap (which downloads full OBS
source + prebuilt deps) -- find_package(libobs) alone is enough on
Linux; falls back to core-library-only when libobs isn't found
(expected on macOS/Windows CI for now).
- .gitea/workflows/build.yml: 3-platform matrix (ubuntu-latest,
macos-latest, windows-latest) matching the runners confirmed
available to this repo under the CyberCoveLLC org.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE
shadowdaoandClaude Sonnet 5