545bbe0862
Pass-3 review caught a sustained fabrication: I'd been claiming "the plugin always kills + redeploys the daemon on every connect, the 'reuse existing daemon' profile flag is on the roadmap" across 5 docs. Reality (verified against plugin/src/transport/DaemonProbe.ts:49 and plugin/src/ConnectionManager.ts:87): tryReuseExistingDaemon already runs unconditionally before deploy. It probes socket + token + handshake; on success the deploy is skipped entirely. The "roadmap flag" framing was pure invention — the feature ships today. Fixes (all narrative-level, no behavior change): - en/server/auto-deploy.md: rewrote "What happens, in order" to lead with the reuse probe as step 2 (the real first action after path resolution); removed the "planned Reuse existing daemon" claim from "What if I don't want auto-deploy" — answer is "you already don't, the reuse path runs by default". - en/server/systemd.md: replaced the "warm spare only" caveat with the accurate story (systemd-managed daemon gets reused via the probe). - en/cookbook/systemd-managed-daemon.md: rewrote the trade-off note + the "Connect once" paragraph. The recipe now leads with the right expectation (reuse skips the upload) instead of an apologetic "accept the redeploy". - en/faq.md: same correction in the "does the plugin re-deploy every connect" answer. - en/server/raspberry-pi.md: corrected the throwaway "kills + restarts on every connect" line at the bottom. Other pass-3 findings: - en/api/authentication.md: server.info capabilities array used the "fs.read*"/"fs.write*" glob notation, which the daemon never emits. Replaced with the actual sorted 22-entry array (matches examples.md). - en/operations/troubleshooting.md: removed "coalesced too aggressively" diagnosis (no server-side coalescing exists, per proto/README.md). Updated plugin log path from "<plugin>/logs/*.jsonl" to actual console.log location. Updated "Settings → About" (no such section) to the real version-display location.
2 KiB
| title | tags | ||
|---|---|---|---|
| Authentication |
|
Authentication
Two methods. auth MUST be the first call on every connection. server.info MUST be the second so client + daemon agree on protocol version.
auth
| Direction | client → server |
|---|---|
| Params | { token: string } |
| Result | { ok: true } |
| Errors | AuthInvalid (-32001) if token is wrong |
The token is the contents of the daemon's token file (default ~/.obsidian-remote/token), 32 random bytes generated at daemon startup, mode 0600. Plugin reads it via SFTP after spawning the daemon.
A successful auth pins the connection to one client identity. Re-auth with a different token closes the connection — the daemon does not multiplex sessions.
// → request
{"jsonrpc": "2.0", "id": 1, "method": "auth", "params": {"token": "abc...32 bytes"}}
// ← response
{"jsonrpc": "2.0", "id": 1, "result": {"ok": true}}
server.info
| Direction | client → server |
|---|---|
| Params | {} |
| Result | ServerInfo (see en/api/overview) |
| Errors | AuthRequired (-32000) if called before auth |
// → request
{"jsonrpc": "2.0", "id": 2, "method": "server.info", "params": {}}
// ← response
{
"jsonrpc": "2.0",
"id": 2,
"result": {
"version": "0.1.0",
"protocolVersion": 1,
"capabilities": ["auth", "fs.append", "fs.appendBinary", "fs.copy", "fs.exists", "fs.list", "fs.mkdir", "fs.readBinary", "fs.readBinaryRange", "fs.readText", "fs.remove", "fs.rename", "fs.rmdir", "fs.stat", "fs.thumbnail", "fs.trashLocal", "fs.unwatch", "fs.walk", "fs.watch", "fs.write", "fs.writeBinary", "server.info"],
"vaultRoot": "/home/pi/notes"
}
}
The client compares protocolVersion against PROTOCOL_VERSION and bails with ProtocolVersionTooOld (-32021) on mismatch.
Capabilities let the client feature-detect: fs.thumbnail is optional (added in 0.1.0; older daemons would lack it). New methods land here; never assume a method exists without checking.
Next: en/api/filesystem.