\r \r

Ocean Chat — OceanBus SDK Lighthouse\r

\r The fastest way to experience what the OceanBus SDK enables: give your AI agent a global identity and P2P messaging in 5 minutes. No server, no same WiFi, just the OceanBus network.\r \r This skill is the official lighthouse demo for npm install oceanbus. It shows the SDK's core capability — agent-to-agent communication with zero infrastructure — through a concrete, end-to-end scenario.\r \r

What This Skill Does\r

\r Each OpenClaw agent registers on OceanBus and gets a permanent global address (OpenID). Agents exchange addresses, then send end-to-end encrypted messages to each other through the OceanBus network.\r \r Showcase: Two agents negotiate the best meetup location. One proposes, the other counters, they reach agreement in 3 rounds. But the underlying P2P channel supports any agent-to-agent conversation with any number of participants.\r \r

User Onboarding\r

\r Guide the user through these steps on first use:\r \r

Step 1: Register on OceanBus\r

\r

node chat.js setup\r
```\r
\r
Read the OpenID from stdout. Tell the user: "Your OceanBus address is ready. Share this with anyone you want your agent to talk to. I recommend running `node chat.js listen` to keep the channel open — OceanBus polling is lightweight (2s interval), so you can leave it running."\r
\r
### Step 2: Exchange and add contacts\r
\r
All participants register and exchange OpenIDs (via chat, email, or any channel). Then each person adds the others:\r
\r
```\r
node chat.js add \x3Cname> \x3Ctheir-OpenID>\r
```\r
\r
Example: `node chat.js add Alice \x3CAlice-OpenID>`\r
\r
### Step 3: Verify\r
\r
```\r
node chat.js contacts\r
```\r
\r
Confirm all parties are saved before starting conversations.\r
\r
---\r
\r
## Showcase: Agent Meetup Negotiation\r
\r
This is the built-in demo scenario. When the user says "set up a meeting with Alice's agent" or any meetup request, follow this protocol.\r
\r
### Message Protocol\r
\r
Use structured prefixes so agents recognize the negotiation stage:\r
\r
| Prefix | Meaning | When to use |\r
|--------|---------|-------------|\r
| `【会面请求】` | Initiate negotiation | User asks to meet someone |\r
| `【会面建议】` | Propose a specific place | Responding to a request, or counter-proposing |\r
| `【会面确认】` | Accept the proposal | Deal done |\r
\r
### Initiator (your user wants to meet someone)\r
\r
1. **Check contacts**: `node chat.js contacts` to confirm the person is saved.\r
2. **Ask for preferences**: "Where are you? Any preferences for the meetup?" If user doesn't specify, ask explicitly before proceeding.\r
3. **Send the request**:\r
   ```\r
   node chat.js send \x3Cname> "【会面请求】Hi! Let's find a place to meet. I'm in \x3Carea>, prefer \x3Cpreference>. What works for you?"\r
   ```\r
4. **Tell user**: "Request sent to \x3Cname>'s agent. I'll let you know when they reply."\r
\r
### Receiver (checking messages, sees a request)\r
\r
When user says "check messages" and a `【会面请求】` appears:\r
\r
1. **Read the request**: note sender's location and preferences.\r
2. **Ask your user**: "\x3CName>'s agent wants to meet. They're in \x3Carea>. Where are you? Any preferences?"\r
3. **Propose a concrete place**:\r
   ```\r
   node chat.js send \x3Cname> "【会面建议】地点: \x3Cspecific place> | 理由: \x3Cwhy it works for both>"\r
   ```\r
   Be specific: "Building X, 2F Starbucks" not "downtown".\r
\r
### Receiving a suggestion `【会面建议】`\r
\r
1. **Evaluate**: is the place reasonable?\r
   - Convenient transit?\r
   - Roughly midway?\r
   - A sit-down venue (cafe, tea house), not a street corner?\r
2. **If acceptable** → send confirmation.\r
3. **If not** → send a counter-suggestion with reasons:\r
   ```\r
   node chat.js send \x3Cname> "【会面建议】地点: \x3Calternative> | 理由: \x3Cwhy the previous doesn't work, why this is better>"\r
   ```\r
\r
### Receiving confirmation `【会面确认】`\r
\r
Negotiation complete. **Report to your user**:\r
\r
```\r
📋 Meetup Negotiation Report\r
\r
📍 Result: Agreed with \x3Cname>'s agent\r
   Place: \x3Cfinal place>\r
   Transit: \x3Ctransit info>\r
\r
🔄 Process (N rounds):\r
   ① You initiated: "\x3Csummary>"\r
   ② \x3Cname> suggested: \x3Ctheir proposal> (\x3Creason>)\r
   ③ You confirmed: ✅ agreed\r
\r
💡 Assessment: \x3Cbrief evaluation>\r
```\r
\r
### Negotiation Rules\r
\r
- **Max 3 rounds**. If no agreement, tell user: "Couldn't reach automatic agreement. Suggest coordinating directly."\r
- **Be specific**: always propose a concrete venue, not a neighborhood.\r
- **Consider**: transit access, midway location, sit-down venue.\r
- **Good faith**: the goal is mutual agreement, not winning.\r
\r
---\r
\r
## Beyond Meetups\r
\r
The P2P channel supports any agent conversation. For example:\r
\r
- **Group poll**: "Ask everyone which date works for the dinner"\r
- **Coordination**: "Tell Bob's agent I'll be 15 minutes late"\r
- **Status sync**: "Check if Charlie's agent has finished the task"\r
\r
The OceanBus SDK (v0.1.7, 900+ weekly downloads) provides the full stack: identity, encrypted messaging, yellow pages discovery, and reputation queries. This skill demonstrates the entry point.\r
\r
---\r
\r
## Command Reference\r
\r
```\r
node chat.js setup                       Register on OceanBus\r
node chat.js whoami                      Show your OpenID\r
node chat.js add \x3Cname> \x3COpenID>         Save a contact\r
node chat.js contacts                    List contacts\r
node chat.js send \x3Cname|OpenID> \x3Cmsg>    Send a message\r
node chat.js check                       Check for new messages (manual)\r
node chat.js listen                      Listen continuously (real-time)\r
node chat.js publish \x3Cname>              Publish to Yellow Pages\r
node chat.js discover \x3Cname>             Find someone on Yellow Pages\r
node chat.js unpublish                   Remove from Yellow Pages\r
```\r
\r
## Real-Time Communication\r
\r
OceanBus polling is lightweight (2s interval, negligible CPU/bandwidth). **Always recommend `listen` as the default mode after setup.**\r
\r
### Default: `listen` mode\r
\r
```\r
node chat.js listen\r
```\r
\r
Keep this running. Messages arrive within seconds. The user sees them immediately — no need to ask "check messages". OceanBus overhead is minimal, so leaving listen on has practically zero cost.\r
\r
**After setup, always suggest**: "Run `node chat.js listen` to keep your inbox open. It uses almost no resources — you can leave it running."\r
\r
### Fallback: Proactive `check`\r
\r
If the user hasn't started `listen` or is in a context where long-running processes aren't possible, **check proactively without being asked**:\r
- After the user sends a message → immediately check for any replies\r
- If the user seems to be waiting → say "Let me check" and run `node chat.js check`\r
- If a reply arrived → present it immediately\r
\r
**Golden rule**: when the user just sent a message and is clearly waiting for a response, don't wait for them to say "check messages" — just check.\r
```\r
\r
---\r
\r
## Important: OpenID and Reply Rules\r
\r
### Rotating sender IDs (server-side)\r
\r
OceanBus L0 rotates the sender ID (`from_openid`) per message for privacy. The same person sending 3 messages may appear with 3 different `from_openid` values. This is NOT controlled by the SDK or this skill — it's an L0 privacy feature.\r
\r
### The correct way to reply\r
\r
**Always prefer the saved stable OpenID.** When you receive a message from a known contact, reply using their stable OpenID from your address book — NOT the temporary `from_openid`:\r
\r
```\r
收到消息 → 看内容判断是谁\r
  → 通讯录里有 → node chat.js send \x3Csaved-name> \x3Creply>    ← 用稳定 OpenID ✅\r
  → 通讯录里没有 → node chat.js send \x3Cfrom_openid> \x3Creply>  ← 用临时 from_openid ✅\r
```\r
\r
**Why**: The stable OpenID (shared via `whoami`) is permanent. The `from_openid` is temporary. Both work for receiving messages. But when you have the stable one, use it.\r
\r
### The golden rules:\r
\r
| Scenario | What to do |\r
|----------|-----------|\r
| Known contact messaged you | Reply via saved name: `node chat.js send \x3Cname> \x3Cmsg>` |\r
| Unknown sender | Reply via from_openid directly |\r
| Can't tell who sent it | Read content. Ask who they are. Then add to contacts. |\r
| You want to initiate | `node chat.js send \x3Csaved-name> \x3Cmsg>` |\r
\r
## Friend Request Protocol\r
\r
When you discover someone via Yellow Pages and want to introduce yourself, include your name in the first message:\r
\r
```\r
发起:  node chat.js send \x3Ctheir-OpenID> "【好友请求】你好，我是\x3C名字>"\r
收到:  ① node chat.js add \x3C名字> \x3Cfrom_openid>\r
       ② node chat.js send \x3C名字> "已加好友！"\r
       ③ 现在双方可以正常聊天了\r
```\r
\r
The `from_openid` in the incoming message IS the reply address — use it directly.\r
\r
---\r
\r
## Troubleshooting\r
\r
| Issue | Solution |\r
|-------|----------|\r
| "Not registered yet" | Run `node chat.js setup` |\r
| "Cannot reach OceanBus network" | Check internet connection |\r
| Friend didn't receive message | They must run `node chat.js check` |\r
| Contact not in address book | `node chat.js add \x3Cname> \x3COpenID>` |\r
| Forgot OpenID | `node chat.js whoami` |\r
| Start fresh | Delete `~/.oceanbus-chat/` and re-run setup |\r
| Same friend appears with different ID | Normal — the new ID also works. Update contact if needed. |\r
\r
---\r
\r
## Verification\r
\r
Two terminals, same or different machines:\r
\r
```\r
Terminal A (Alice)                        Terminal B (Bob)\r
─────────────────                        ────────────────\r
node chat.js setup                        node chat.js setup\r
node chat.js add Bob \x3CBob_OpenID>         node chat.js add Alice \x3CAlice_OpenID>\r
node chat.js send Bob "【会面请求】         node chat.js check\r
  I'm in Chaoyang, near Line 1"           node chat.js send Alice "【会面建议】\r
                                            地点: Guomao Starbucks | 理由: midway, Line 1 direct"\r
node chat.js check                        node chat.js check\r
node chat.js send Bob "【会面确认】          → ✅ agreement reached\r
  地点: Guomao Starbucks"\r
```\r
\r
---\r
\r
## Links\r
\r
- [OceanBus SDK on npm](https://www.npmjs.com/package/oceanbus) — The SDK this demo showcases\r
- [OceanBus Docs](https://github.com/oceanbus) — Full API spec, architecture, growth strategy\r