@dp-pcs/ogp 0.2.31 → 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.
- package/README.md +11 -0
- package/dist/daemon/notify.d.ts +20 -0
- package/dist/daemon/notify.d.ts.map +1 -1
- package/dist/daemon/notify.js +165 -48
- package/dist/daemon/notify.js.map +1 -1
- package/dist/shared/config.d.ts +3 -0
- package/dist/shared/config.d.ts.map +1 -1
- package/dist/shared/config.js.map +1 -1
- package/docs/TESTING-HERMES-BACKEND.md +278 -0
- package/docs/extending-to-hermes.md +462 -0
- package/docs/hermes-implementation-checklist.md +448 -0
- package/docs/hermes-local-testing.md +478 -0
- package/docs/hermes-tunnel-setup.md +214 -0
- package/docs/platform-agnostic-architecture.md +472 -0
- package/package.json +3 -2
- package/scripts/install-skills.js +142 -20
- package/skills/ogp-project/SKILL.md +321 -226
|
@@ -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
|