Intention Pulse Transfer Protocol (IPTP) is a protocol released from IntentixLab, developing IntentionSpace.
:-
1.Why rethink communication?
Most systems today communicate using:
endpoints (/orders/create)
payloads (JSON)
implicit meaning
We encode what we mean indirectly.
But what if we made intent explicit?
- The core idea
IPTP defines a message as:
Signal = Intention + Pulse set
Example:
{
"intention": "order:create",
"pulses": [
{"name": "user_authenticated", "value": "Y"},
{"name": "cart_valid", "value": "Y"}
]
}
This is not just data.
It is:intent (what is being attempted)
state/context markers (what qualifies the intent)
bundled into a single unit.
- TCP is not enough
TCP gives:
reliable delivery
ordering
retransmission
But TCP is a byte stream, not a message protocol.
So IPTP adds:
✔ Framing
Each signal is transmitted as a bounded message:
MAGIC | VERSION | FLAGS | LENGTH | PAYLOAD
✔ Checksum
Each envelope carries a checksum for integrity verification.
- One envelope = one intention
A strict rule:
Each envelope carries exactly one intention.
It may contain multiple pulses, but:
no batching of intentions
no partial signals
no merging
This keeps the protocol composable and predictable.
- Optional Protocol ACK
IPTP supports an optional flag:
RequireProtocolAck
Important distinction:
Protocol ACK confirms structural acceptance, not semantic correctness.
An ACK means:
frame parsed
checksum valid
envelope structurally accepted
It does NOT mean:
business logic passed
workflow accepted
any higher-level condition satisfied
- ACK is just another signal
No new abstraction is introduced.
ACK:
{
"intention": "iptp:ack",
"pulses": [
{"name": "ack_for", "value": "msg-1"},
{"name": "status", "value": "accepted"}
]
}
NACK:
{
"intention": "iptp:nack",
"pulses": [
{"name": "ack_for", "value": "msg-1"},
{"name": "reason", "value": "checksum_failed"}
]
}
Even control flow remains:
Intention + Pulse set
- Clean layering
There are three levels of acceptance:
Level Meaning
TCP bytes delivered
IPTP valid envelope received
Application meaning accepted
IPTP deliberately stops at level 2.
- Multiplexing without breaking semantics
IPTP supports multiple in-flight envelopes over a single TCP connection.
This is purely a transport optimization.
Each envelope still carries:
exactly one Intention + its Pulse set
Multiplexing does not:
merge intentions
split signals
introduce shared state
It simply allows multiple independent signals to travel concurrently.
Think of it as:
one connection carrying many independent semantic units
- Example: concurrent signals over one connection go run ./cmd/iptp-send -to localhost:9000 -id batch -intention order:create -ack -multi 5
This sends:
batch-0
batch-1
batch-2
batch-3
batch-4
Each:
is a complete signal
has its own pulses
receives its own ACK
No extra ordering constraints are introduced beyond TCP.
- Running the demo
Start receiver:
go run ./cmd/iptp-recv -port 9000
Send without ACK:
go run ./cmd/iptp-send -to localhost:9000 -id msg-1 -intention order:create
Send with protocol ACK:
go run ./cmd/iptp-send -to localhost:9000 -id msg-2 -intention order:create -ack
- What is fundamentally different?
Typical systems:
endpoint-driven
payload-centric
implicit state
IPTP:
intention-driven
state expressed explicitly (pulses)
communication unit is semantic, not structural
- A different mental model
IPTP treats communication as a stream of independent, self-contained intentions.
Concurrency happens at the transport level.
Meaning stays local to each signal.
- Where this leads
At this level, IPTP is just a protocol.
But this structure enables:
event-driven systems
composable workflows
perception-first computation models
without enforcing them.
- Closing thought
TCP guarantees delivery of bytes.
IPTP guarantees delivery of meaningful units.
And that unit is:
Intention + Pulse set
Repo
👉 https://github.com/spicecoder/iptp-pipe
Why I wrote this
I’ve been exploring a simple question:
Can we make communication and workflows explicit enough that coordination becomes predictable — even across independently running systems?
IPTP started as a small experiment in that direction. By treating each message as a self-contained Intention + Pulse set, it becomes possible to move meaning across systems without relying on shared hidden state or tightly coupled APIs.
What makes this interesting to me is how naturally it extends beyond a single process.
For example, imagine:
independent services running as Docker containers
deployed across different machines or regions
each reacting only when specific pulse conditions are satisfied
Instead of orchestrating them through centralized workflow engines or implicit contracts, you can coordinate them through semantic signals — where each step is triggered by explicit state carried in the message itself.
This is still an early exploration, but I’m particularly interested in how this approach could:
simplify distributed workflow coordination
reduce hidden dependencies between services
make system behavior easier to inspect and reason about
I’m sharing this to get feedback from others building distributed or event-driven systems — especially where coordination and state management become difficult to manage over time.
My hope is that making intent and state explicit at the protocol level can reduce the gap between how we design workflows and how they actually behave in distributed system
About IPTP and Intention Space
IPTP originates from the Intention Space project.
Intention Space explores a different foundation for software:
Perception comes before logic, and Intentions define the context in which perception becomes meaningful.
In this model:
Intentions act as context makers
Pulses capture perceptual state
computation emerges from their interaction rather than predefined control flow
IPTP is a minimal, transport-level expression of that idea —
a way to communicate using Intention + Pulse sets without requiring the full Intention Space runtime.
P.S - I have put a small demo to illustrate the scenario how iptp can play a role when the processes are distributed , this demo puts the idea in a single process though - https://github.com/spicecoder/iptp-pipe/tree/c0945090864fae357acb769b77e440480f655703/IPTP_Demo/semantic-pulseflow-coordination-demo
Learn more at: https://Intentixlab.com
Top comments (5)
Let me say I have my doubts ...
The best and brightest minds have worked to create TCP/IP, HTTP, REST etcetera - and it works pretty well for a gazillion sites and apps ...
I think we should just continue to build on these foundations, instead of creating a huge amount of confusion and distraction for the sake of introducing something which I think would be just a marginal improvement over what we have (and probably not even that).
It's giving me "pie in the sky" vibes, and "a solution in need of a problem" ;-)
That’s a fair concern — and I agree with the premise that TCP/IP, HTTP, REST are extremely successful foundations. I’m not proposing replacing them. In fact IPTP can run directly over TCP for full control, or be used as a message model over HTTP/REST
What I’m exploring here is a much narrower question:
can we make the unit of communication more explicit in terms of intent and state, rather than just payload?
In most current systems:
meaning is inferred from endpoints + payload structure
coordination often relies on shared assumptions or implicit workflow.
IPTP doesn’t try to compete with HTTP/REST — it sits at a different layer of concern. It enforces that each message is a self-contained “intention + state markers”, which makes certain kinds of coordination more explicit.
Whether that’s useful or not really depends on the context. For simple CRUD-style systems, I’d agree it’s unnecessary.
Where I’ve found it interesting is in cases where:
multiple independent components/Docker containers going through large datasets need to coordinate,state transitions are hard to track,
behavior becomes implicit over time
That said, I completely agree this is exploratory — and it needs concrete use cases to prove itself.
Appreciate you calling that out.
Well, in most cases you don't need to make intention explicit, because "provider" and "consumer" have been developed as one and are tailor-made for each other - so, the understanding is "built in" or implied, to put it like that ...
So where I can see a protocol like this being useful is in much more "open ended" systems, where both ends were developed independently, and then need metadata to query each other's capabilities - AI (agents etc) comes to mind, and probably also data science/data pipelines ...
But yeah, essentially it's "metadata" :-)
P.S. I really cannot (at this point) comment meaningfully on the merits of these ideas - I'd have to explore them more deeply, or (better) see concrete examples of it bring put to practical use ...
agree -- One small clarification — while it can look like “metadata”, I’m thinking of it slightly differently:
the pulses are not just descriptive, they act as explicit conditions that drive behavior
So instead of:
metadata describing a message -
it becomes: state markers that determine whether something should execute
That’s where I see a potential difference — especially in workflows where coordination logic otherwise gets spread across code, configs, or orchestration layers.
Completely agree on the need for concrete examples - let me work on that.
this small demo shows the semantic resolution that iptp can bring in a distributed process - github.com/spicecoder/iptp-pipe/tr...