Plugin API v0 #59

New issue

Closed

opened 2026-09-21 18:05:10 +01:00 by cruelacid · 1 comment

cruelacid commented

2026-09-21 18:05:10 +01:00

Owner

Part of #37.

What Relay does

Plugin API v0 — internal in 0.8.9, public in 0.8.12. getUsers(),
getCurrentUser(), registerTextView()/unregisterTextView(), plus workspace
events system3-relay:api-ready, :v0:users, :v0:current-user, typed in a
shipped relay-plugin-api.d.ts.

What we do today

Nothing. No API surface for other plugins at all.

What changes

api.ts plus a published .d.ts. getUsers() reads awareness,
getCurrentUser() reads the session — both already exist internally. View
registration is the larger half and overlaps with what Kanban multiplayer needs.

Why it belongs after comments, not before

Relay built comments on their API. We can build ours first and extract the
API from what it needed, which yields a smaller and more honest surface than
designing one speculatively.

What must not leak

The API runs inside the trust boundary. docs/security-model.md already records
that secret ids are global to the app and any installed plugin can read our keys
— that is Obsidian's design and no storage choice changes it. This API must not
make it easier: no key material, no passphrase, no document ids paired with
paths (that pairing is the one thing that would undo the HMAC).

Risk

risk:none to sync; a real surface-area decision for the security model.

Verification

docs/security-model.md is updated to describe what the API exposes, and the
claim is checked against the code as that document is written to be.

Part of #37. ## What Relay does Plugin API v0 — internal in 0.8.9, public in 0.8.12. `getUsers()`, `getCurrentUser()`, `registerTextView()`/`unregisterTextView()`, plus workspace events `system3-relay:api-ready`, `:v0:users`, `:v0:current-user`, typed in a shipped `relay-plugin-api.d.ts`. ## What we do today Nothing. No API surface for other plugins at all. ## What changes `api.ts` plus a published `.d.ts`. `getUsers()` reads awareness, `getCurrentUser()` reads the session — both already exist internally. View registration is the larger half and overlaps with what Kanban multiplayer needs. ## Why it belongs after comments, not before Relay built comments **on** their API. We can build ours first and extract the API from what it needed, which yields a smaller and more honest surface than designing one speculatively. ## What must not leak The API runs inside the trust boundary. `docs/security-model.md` already records that secret ids are global to the app and any installed plugin can read our keys — that is Obsidian's design and no storage choice changes it. This API must not make it *easier*: no key material, no passphrase, no document ids paired with paths (that pairing is the one thing that would undo the HMAC). ## Risk `risk:none` to sync; a real surface-area decision for the security model. ## Verification `docs/security-model.md` is updated to describe what the API exposes, and the claim is checked against the code as that document is written to be.

cruelacid added this to the Phase 19 - Review and history milestone

2026-09-21 18:05:10 +01:00

cruelacid added the

labels

2026-09-21 18:05:10 +01:00

cruelacid referenced this issue

2026-09-21 18:08:51 +01:00

Relay feature parity, with end-to-end encryption (tracking) #37