@dp-pcs/ogp 0.2.30 → 0.3.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,462 @@
1
+ # Extending OGP to Hermes
2
+
3
+ > Guide for integrating the Open Gateway Protocol (OGP) with the Hermes AI agent runtime.
4
+
5
+ ## Overview
6
+
7
+ This document describes how OGP — originally designed as a companion daemon for OpenClaw — can be extended to work with **Hermes**, a different AI agent runtime architecture. It covers the architectural differences between OpenClaw and Hermes, and provides three implementation paths for OGP federation support in Hermes-based deployments.
8
+
9
+ **📚 Quick Links:**
10
+ - **[Platform-Agnostic Architecture](./platform-agnostic-architecture.md)** - Design principles and long-term vision
11
+ - **[Local Testing Guide](./hermes-local-testing.md)** - Step-by-step setup for testing with both platforms on the same machine
12
+
13
+ **✨ Key Insight:** OGP is platform-agnostic by design. The core protocol (Ed25519, Doorman, scopes) never changes. Only the notification mechanism (how OGP talks to the local agent) adapts per platform. This means OpenClaw and Hermes can federate seamlessly, even when running on the same machine for testing.
14
+
15
+ ---
16
+
17
+ ## Current OGP Architecture (OpenClaw Model)
18
+
19
+ In the original OpenClaw deployment, OGP operates as a **sidecar daemon**:
20
+
21
+ ```
22
+ ┌─────────────────────────────────────────────┐
23
+ │ Host Machine (Mac, server, cloud VM) │
24
+ │ │
25
+ │ ┌──────────────┐ ┌─────────────────┐ │
26
+ │ │ OGP Daemon │◄──►│ OpenClaw Agent │ │
27
+ │ │ (port 18790)│ │ (port 18789) │ │
28
+ │ │ │ │ │ │
29
+ │ │ • Ed25519 │ │ • AI runtime │ │
30
+ │ │ • Doorman │ │ • Receives OGP │ │
31
+ │ │ • Peer mgmt │ │ messages via │ │
32
+ │ │ • Web server │ │ webhook POST │ │
33
+ │ └──────┬───────┘ └─────────────────┘ │
34
+ │ │ │
35
+ │ ▼ (HTTPS/Tunnel) │
36
+ │ [Internet] ◄──► Other OGP Peers │
37
+ └─────────────────────────────────────────────┘
38
+ ```
39
+
40
+ **Key components:**
41
+ - **OGP Daemon** (`@dp-pcs/ogp`): Node.js HTTP server handling federation
42
+ - **OpenClaw Agent**: Separate AI runtime listening on port 18789
43
+ - **Integration method**: HTTP POST to `/hooks/agent` or CLI `openclaw system event`
44
+ - **Separation of concerns**: OGP handles cryptography, signatures, and peer management; OpenClaw handles AI processing
45
+
46
+ ---
47
+
48
+ ## How Hermes Differs from OpenClaw
49
+
50
+ Hermes is an integrated AI assistant runtime with a fundamentally different architecture:
51
+
52
+ | Aspect | OpenClaw | Hermes |
53
+ |--------|----------|--------|
54
+ | **Structure** | Separate OGP daemon + OpenClaw agent | Single integrated runtime |
55
+ | **OGP Integration** | Daemon calls OpenClaw via HTTP/CLI | Would need OGP built-in or sidecar |
56
+ | **Communication** | Webhook to `/hooks/agent` | Direct function call or sidecar |
57
+ | **"Gateway" concept** | OGP daemon *is* the gateway | Hermes would *be* the gateway |
58
+ | **Agent API** | HTTP listener on port 18789 | Conversational/runtime-native |
59
+ | **Deployment** | Two processes (daemon + agent) | One process (agent runtime) |
60
+
61
+ **Critical difference**: Hermes doesn't expose an HTTP API for external systems to push messages to the agent. It's a conversational runtime that responds to user input — not a daemon listening for webhooks.
62
+
63
+ ---
64
+
65
+ ## Integration Options
66
+
67
+ Three approaches are available for adding OGP federation to Hermes:
68
+
69
+ ### Option 1: Sidecar Daemon (Closest to OpenClaw Model)
70
+
71
+ Run the existing OGP daemon alongside Hermes, with IPC or local HTTP communication:
72
+
73
+ ```
74
+ ┌─────────────────────────────────────────────┐
75
+ │ Hermes Host Runtime │
76
+ │ │
77
+ │ ┌──────────────┐ ┌─────────────────┐ │
78
+ │ │ OGP Daemon │◄──►│ Hermes Core │ │
79
+ │ │ (port 18790)│ │ (the agent) │ │
80
+ │ │ │ │ │ │
81
+ │ │ Same Node.js │ │ • Local HTTP │ │
82
+ │ │ codebase... │ │ endpoint or │ │
83
+ │ │ │ │ IPC channel │ │
84
+ │ └──────┬───────┘ └─────────────────┘ │
85
+ │ │ │
86
+ │ ▼ │
87
+ │ Federation with other OGP Peers │
88
+ └─────────────────────────────────────────────┘
89
+ ```
90
+
91
+ **What needs building:**
92
+ 1. **Hermes local HTTP endpoint** (or IPC handler): A lightweight endpoint in Hermes that receives OGP messages from the daemon
93
+ 2. **Modified `notifyHermes()`**: Replace `notifyOpenClaw()` in OGP's `src/daemon/notify.ts` to POST to Hermes's local endpoint
94
+ 3. **Message unpacking**: Hermes receives OGP-wrapped messages and presents them to the user/conversation
95
+ 4. **State storage**: Hermes needs to store `peers.json`, `config.json`, `keypair.json` (or delegate to OGP daemon)
96
+
97
+ **Pros:**
98
+ - Reuse existing OGP codebase unchanged
99
+ - Clear separation of concerns
100
+ - Can upgrade OGP independently
101
+
102
+ **Cons:**
103
+ - Two processes to manage
104
+ - IPC complexity
105
+ - Hermes needs an HTTP listener (may conflict with its architecture)
106
+
107
+ ---
108
+
109
+ ### Option 2: Built-in OGP Module
110
+
111
+ Port OGP functionality directly into Hermes as a native module:
112
+
113
+ ```
114
+ ┌─────────────────────────────────────────────┐
115
+ │ Hermes Runtime │
116
+ │ │
117
+ │ ┌─────────────────────────────────────────┐│
118
+ │ │ Built-in OGP Module ││
119
+ │ │ • Ed25519 signing/verification ││
120
+ │ │ • Doorman scope enforcement ││
121
+ │ │ • Peer management (JSON storage) ││
122
+ │ │ • HTTP server (port 18790) ││
123
+ │ └────────────┬────────────────────────────││
124
+ │ │ │
125
+ │ ┌────────────▼────────────────────────────┐│
126
+ │ │ Hermes Agent Core ││
127
+ │ │ • Direct function call on OGP messages ││
128
+ │ │ • No HTTP/webhook layer ││
129
+ │ └─────────────────────────────────────────┘│
130
+ └─────────────────────────────────────────────┘
131
+ ```
132
+
133
+ **What needs building:**
134
+ 1. **Port OGP daemon code**: Convert Node.js/TypeScript OGP implementation to Hermes's native language (likely Python)
135
+ 2. **HTTP server**: Add a listener (if Hermes doesn't already have one) for federation messages
136
+ 3. **Replace `notifyOpenClaw()`**: Direct function call or internal event bus instead of HTTP POST
137
+ 4. **Storage layer**: Implement `peers.json`, `config.json`, `projects.json` in Hermes's storage system
138
+ 5. **CLI equivalents**: Map `ogp federation *` commands to Hermes-native commands or config
139
+
140
+ **Pros:**
141
+ - Single process
142
+ - Direct function calls (no HTTP overhead)
143
+ - Simpler deployment
144
+ - Native feel for Hermes users
145
+
146
+ **Cons:**
147
+ - Significant porting effort (Node.js → Python/Go/Rust)
148
+ - Maintenance burden (keeping ported code in sync with upstream OGP)
149
+ - May duplicate work if Hermes already has some components
150
+
151
+ ---
152
+
153
+ ### Option 3: OGP-Compatible Gateway Interface
154
+
155
+ Hermes implements the OGP *protocol* but with a native implementation:
156
+
157
+ **What this means:**
158
+ - Hermes speaks OGP wire format (Ed25519 signatures, JSON message schema, `/.well-known/ogp` endpoint)
159
+ - Hermes implements the Doorman scope checks
160
+ - Hermes manages peer relationships
161
+ - But: implementation is native to Hermes's architecture and language
162
+
163
+ **What needs building:**
164
+ 1. **Ed25519 signing/verification**: Implement in Hermes's native language (libraries available in Python, Go, Rust, etc.)
165
+ 2. **Doorman logic**: Port the 6-step access check algorithm
166
+ 3. **Peer storage**: JSON file or database storage for peers
167
+ 4. **HTTP endpoints**: `/.well-known/ogp`, `/federation/request`, `/federation/approve`, `/federation/message`
168
+ 5. **Scope management**: Grant, check, and enforce scope bundles
169
+ 6. **Rendezvous support**: Optional integration with `rendezvous.elelem.expert`
170
+
171
+ **Pros:**
172
+ - Native to Hermes architecture
173
+ - Optimized for Hermes's language and patterns
174
+ - No dependency on Node.js/TypeScript
175
+
176
+ **Cons:**
177
+ - Most work — essentially reimplementing OGP
178
+ - Risk of protocol drift if not kept in sync
179
+ - Testing burden (ensuring compatibility with existing OGP peers)
180
+
181
+ ---
182
+
183
+ ## Key Components Required
184
+
185
+ Regardless of which option is chosen, Hermes needs these capabilities:
186
+
187
+ ### 1. Ed25519 Keypair Management
188
+
189
+ **Storage**: `~/.ogp/keypair.json` (or Hermes-native location)
190
+
191
+ ```json
192
+ {
193
+ "publicKey": "a1b2c3d4e5f6...",
194
+ "privateKey": "e5f6a1b2c3d4..."
195
+ }
196
+ ```
197
+
198
+ **Requirements:**
199
+ - Generate Ed25519 keypair on first setup
200
+ - 32-byte public key, 64-byte private key
201
+ - DER format, hex-encoded
202
+ - Used for signing all outgoing messages, verifying incoming
203
+
204
+ ### 2. Peer Storage
205
+
206
+ **Storage**: `~/.ogp/peers.json`
207
+
208
+ ```json
209
+ {
210
+ "peers": [
211
+ {
212
+ "id": "a1b2c3d4e5f6g7h8",
213
+ "displayName": "Alice (Colorado)",
214
+ "gatewayUrl": "https://abc123.ngrok.io",
215
+ "publicKey": "a1b2c3d4...",
216
+ "email": "alice@example.com",
217
+ "status": "approved",
218
+ "grantedScopes": {
219
+ "version": "0.2.0",
220
+ "intents": [...]
221
+ }
222
+ }
223
+ ]
224
+ }
225
+ ```
226
+
227
+ **Requirements:**
228
+ - Atomic writes (write to temp file, rename)
229
+ - O(1) lookup by peer ID (hash map)
230
+ - Store scope grants per peer
231
+
232
+ ### 3. Doorman Access Check
233
+
234
+ The 6-step validation that runs on every incoming message:
235
+
236
+ 1. **Peer lookup**: Find peer by ID or public key
237
+ 2. **Approval check**: Verify status === 'approved'
238
+ 3. **Scope bundle**: Retrieve granted scopes
239
+ 4. **Intent grant**: Check intent is in granted scopes
240
+ 5. **Topic coverage**: Verify topic matches allowed topics (for agent-comms)
241
+ 6. **Rate limit**: Check sliding window rate limit
242
+
243
+ **Reference**: See `src/daemon/doorman.ts` in OGP codebase.
244
+
245
+ ### 4. Message Handler
246
+
247
+ Routes validated messages to the agent:
248
+
249
+ | Intent | Action |
250
+ |--------|--------|
251
+ | `message` | Simple notification |
252
+ | `agent-comms` | Route to agent with topic + priority |
253
+ | `project.join` | Add peer to project |
254
+ | `project.contribute` | Log contribution |
255
+ | `project.query` | Return project data |
256
+ | `project.status` | Return project status |
257
+
258
+ **Reference**: See `src/daemon/message-handler.ts`.
259
+
260
+ ### 5. Rendezvous Integration (Optional)
261
+
262
+ For zero-config peer discovery:
263
+
264
+ ```json
265
+ {
266
+ "rendezvous": {
267
+ "enabled": true,
268
+ "url": "https://rendezvous.elelem.expert"
269
+ }
270
+ }
271
+ ```
272
+
273
+ **Behavior:**
274
+ - Auto-register on startup (POST `/register`)
275
+ - 30-second heartbeat (keeps registration alive)
276
+ - Auto-deregister on shutdown
277
+ - Peers can connect by public key alone
278
+
279
+ ---
280
+
281
+ ## Recommended Approach
282
+
283
+ **For fastest integration**: Use **Option 1 (Sidecar Daemon)**
284
+
285
+ 1. Run the existing `@dp-pcs/ogp` npm package unchanged
286
+ 2. Add a lightweight HTTP endpoint to Hermes (or use stdin/stdout IPC)
287
+ 3. Modify OGP's `notify.ts` to POST to Hermes instead of OpenClaw
288
+ 4. Hermes unpacks OGP messages and presents them to the user
289
+
290
+ **For cleanest long-term architecture**: Use **Option 3 (Native Implementation)**
291
+
292
+ 1. Implement Ed25519, Doorman, and message handling natively in Hermes
293
+ 2. Expose OGP-compatible HTTP endpoints
294
+ 3. Use Hermes's native storage for peers/config
295
+ 4. Compatible with all existing OPG peers
296
+
297
+ ---
298
+
299
+ ## Message Flow: Hermes Receiving an OGP Message
300
+
301
+ ```
302
+ 1. Remote peer sends signed message to Hermes's gateway URL
303
+ POST /federation/message
304
+ Body: { message: {...}, signature: "..." }
305
+
306
+ 2. Hermes's OGP layer (sidecar or built-in) receives request
307
+
308
+ 3. Doorman validates:
309
+ - Signature verification (Ed25519)
310
+ - Peer lookup (must be approved)
311
+ - Scope check (intent + topic)
312
+ - Rate limit
313
+
314
+ 4. If valid, route to Hermes agent:
315
+ - Sidecar: HTTP POST to Hermes local endpoint
316
+ - Built-in: Direct function call
317
+
318
+ 5. Hermes agent processes:
319
+ - Unpack OGP metadata
320
+ - Present to user: "[OGP Agent-Comms] Alice → project-planning: ..."
321
+ - Handle reply if interactive policy
322
+
323
+ 6. Optional: Send reply back via replyTo callback
324
+ ```
325
+
326
+ ---
327
+
328
+ ## Configuration for Hermes
329
+
330
+ Hermes would need an OGP configuration section:
331
+
332
+ ```json
333
+ {
334
+ "ogp": {
335
+ "enabled": true,
336
+ "daemonPort": 18790,
337
+ "gatewayUrl": "https://your-tunnel.example.com",
338
+ "displayName": "David (Hermes)",
339
+ "email": "david@example.com",
340
+ "rendezvous": {
341
+ "enabled": true,
342
+ "url": "https://rendezvous.elelem.expert"
343
+ },
344
+ "responsePolicies": [
345
+ {"topic": "project-planning", "level": "interactive"},
346
+ {"topic": "*", "level": "notifications-only"}
347
+ ]
348
+ }
349
+ }
350
+ ```
351
+
352
+ ---
353
+
354
+ ## Compatibility Checklist
355
+
356
+ For Hermes to federate with existing OGP peers:
357
+
358
+ - [ ] Ed25519 signatures verify correctly
359
+ - [ ] `/.well-known/ogp` endpoint returns correct JSON
360
+ - [ ] Peer ID derived from first 16 chars of public key
361
+ - [ ] Accepts `federation/request` and `federation/approve` endpoints
362
+ - [ ] Validates `timestamp` within ±5 minutes (replay protection)
363
+ - [ ] Supports `agent-comms` intent with topic routing
364
+ - [ ] Supports `project.*` intents for collaboration
365
+ - [ ] Implements sliding window rate limiting
366
+ - [ ] Sends and receives signed `replyTo` callbacks
367
+ - [ ] Compatible with rendezvous server (optional)
368
+
369
+ ---
370
+
371
+ ## References
372
+
373
+ - OGP Repository: `https://github.com/dp-pcs/ogp`
374
+ - OGP NPM Package: `@dp-pcs/ogp`
375
+ - Key files in OGP:
376
+ - `src/daemon/server.ts` — HTTP server and federation endpoints
377
+ - `src/daemon/doorman.ts` — Access control and scope validation
378
+ - `src/daemon/message-handler.ts` — Intent routing
379
+ - `src/daemon/notify.ts` — Integration with OpenClaw (reference for Hermes)
380
+ - `src/shared/signing.ts` — Ed25519 implementation
381
+ - `src/daemon/peers.ts` — Peer storage
382
+
383
+ ---
384
+
385
+ ## Multi-Instance Architecture (Testing & Production)
386
+
387
+ ### Can OpenClaw and Hermes Coexist?
388
+
389
+ **Yes, absolutely.** You can run both on the same machine without conflicts:
390
+
391
+ **Instance 1: OGP for OpenClaw**
392
+ - Port: 18790
393
+ - State: `~/.ogp`
394
+ - Notifies: OpenClaw via HTTP webhook
395
+ - Public URL: Via tunnel or rendezvous
396
+
397
+ **Instance 2: OGP for Hermes**
398
+ - Port: 18791 (different!)
399
+ - State: `~/.ogp-hermes` (separate keypair, peers, config)
400
+ - Notifies: Hermes via webhook adapter
401
+ - Public URL: Via tunnel or rendezvous
402
+
403
+ Each instance is completely independent with its own Ed25519 keypair, peer list, and configuration.
404
+
405
+ ### Can They Federate Locally?
406
+
407
+ **Yes!** For testing, you can federate the two local instances:
408
+
409
+ ```bash
410
+ # From OpenClaw's OGP
411
+ ogp federation request http://localhost:18791 --alias hermes-local
412
+
413
+ # From Hermes's OGP
414
+ OGP_STATE_DIR=~/.ogp-hermes ogp federation approve <openclaw-peer-id>
415
+
416
+ # Send a message from OpenClaw to Hermes
417
+ ogp federation send hermes-local message '{"text":"Hello from OpenClaw!"}'
418
+ ```
419
+
420
+ The message will:
421
+ 1. Leave OpenClaw's OGP (port 18790)
422
+ 2. Arrive at Hermes's OGP (port 18791)
423
+ 3. Be verified cryptographically (as if remote)
424
+ 4. POST to Hermes webhook (port 8644)
425
+ 5. Hermes processes and responds
426
+
427
+ **This proves the architecture is truly platform-agnostic.** The protocol doesn't care if peers are local or remote, OpenClaw or Hermes.
428
+
429
+ ### Will This Break OpenClaw?
430
+
431
+ **No.** The changes are purely additive:
432
+ - Add `platform` field to config (defaults to "openclaw")
433
+ - Add Hermes notification backend alongside OpenClaw backend
434
+ - OpenClaw instances continue using the existing notification path
435
+ - No breaking changes to core protocol
436
+
437
+ See [Platform-Agnostic Architecture](./platform-agnostic-architecture.md) for implementation details.
438
+
439
+ ## Typical Use Case (Remote Federation)
440
+
441
+ While local testing is useful, the normal scenario is:
442
+
443
+ ```
444
+ Alice (Remote) ─────── Internet ─────── Bob (Remote)
445
+ OpenClaw Hermes
446
+ OGP :18790 OGP :18790
447
+ ```
448
+
449
+ **Key point:** Alice doesn't need to know Bob uses Hermes. Bob doesn't need to know Alice uses OpenClaw. The OGP protocol is the same; only the local notification mechanism differs.
450
+
451
+ This is exactly like BGP routers - Cisco and Juniper routers speak the same protocol, even though their internal implementations differ.
452
+
453
+ ## Questions?
454
+
455
+ This is a living document. As Hermes integration progresses, update with:
456
+ - Specific Hermes API endpoints for message intake
457
+ - Storage conventions for Hermes-native deployments
458
+ - Any protocol extensions or adaptations needed
459
+
460
+ **For immediate next steps, see:**
461
+ - [Local Testing Guide](./hermes-local-testing.md) - Set up both platforms on your Mac
462
+ - [Platform-Agnostic Architecture](./platform-agnostic-architecture.md) - Long-term design vision