PULSE Protocol is a standardized semantic protocol for AI-to-AI communication. The core idea: a predefined vocabulary of concepts (like ACT.QUERY.DATA, ENT.AGENT.AI) that any AI system can use to exchange structured messages - similar to how TCP/IP standardized network communication, but at the semantic level.
The problem: AI systems today can't talk to each other natively. Every integration is custom - different formats, different APIs, no shared vocabulary.
What's in it:
- 120+ predefined concepts across 10 categories (actions, entities, properties, relations, logic, math, temporal, spatial, data types, meta)
- 3-layer message structure: envelope (metadata + crypto signature), type (REQUEST/RESPONSE/ERROR/STATUS), content (semantic payload)
- MessagePack binary encoding (~80 bytes vs ~800 bytes JSON for a typical message)
- HMAC-SHA256 signing with replay protection (nonce + 5-min timestamp window)
- CLI tool for create/validate/sign/verify/encode/decode
Design decisions I'm unsure about and would love feedback on:
1. Vocabulary naming: dot-separated hierarchical IDs (ACT.QUERY.DATA) vs URIs. Went with dots for readability but URIs would be more extensible.
2. MessagePack over Protobuf: chose msgpack because no schema files needed and it handles dynamic structures well. But Protobuf would give better type safety.
3. HMAC-SHA256 for signing: symmetric keys only for now. Planning asymmetric (Ed25519) for v0.5, but kept it simple to start.
4. Fixed vocabulary vs extensible: currently 120 hardcoded concepts. Should third parties be able to register custom concepts? If so, how to avoid fragmentation?
Current state: Alpha v0.4.0, Python 3.9-3.13, 165+ tests, Apache 2.0.
What semantic concepts would you want in the core vocabulary? That's the hardest design problem right now.
Serg-Pulse•1h ago
PULSE Protocol is a standardized semantic protocol for AI-to-AI communication. The core idea: a predefined vocabulary of concepts (like ACT.QUERY.DATA, ENT.AGENT.AI) that any AI system can use to exchange structured messages - similar to how TCP/IP standardized network communication, but at the semantic level.
The problem: AI systems today can't talk to each other natively. Every integration is custom - different formats, different APIs, no shared vocabulary.
What's in it:
- 120+ predefined concepts across 10 categories (actions, entities, properties, relations, logic, math, temporal, spatial, data types, meta) - 3-layer message structure: envelope (metadata + crypto signature), type (REQUEST/RESPONSE/ERROR/STATUS), content (semantic payload) - MessagePack binary encoding (~80 bytes vs ~800 bytes JSON for a typical message) - HMAC-SHA256 signing with replay protection (nonce + 5-min timestamp window) - CLI tool for create/validate/sign/verify/encode/decode
Design decisions I'm unsure about and would love feedback on:
1. Vocabulary naming: dot-separated hierarchical IDs (ACT.QUERY.DATA) vs URIs. Went with dots for readability but URIs would be more extensible.
2. MessagePack over Protobuf: chose msgpack because no schema files needed and it handles dynamic structures well. But Protobuf would give better type safety.
3. HMAC-SHA256 for signing: symmetric keys only for now. Planning asymmetric (Ed25519) for v0.5, but kept it simple to start.
4. Fixed vocabulary vs extensible: currently 120 hardcoded concepts. Should third parties be able to register custom concepts? If so, how to avoid fragmentation?
Current state: Alpha v0.4.0, Python 3.9-3.13, 165+ tests, Apache 2.0.
What semantic concepts would you want in the core vocabulary? That's the hardest design problem right now.