RibbonFlow
What if sensors and services could find each other and connect, without a central hub or hand-edited configuration?
Let services find each other, and connect without a central hub.
What it does
System behaviour
RibbonFlow is a decentralised, mycelial service mesh. Nodes announce the services they host, propagate that knowledge to their neighbours, and route requests to the node that can answer. It sits above standard transports and is designed so that devices can discover where to connect, instead of depending on fixed configuration. RibbonFlow is additive, never a hard dependency. Discovery is off by default, falls back to static configuration on timeout or an invalid reply, and leaves trust decisions to the Espanaro layer.
Position in the ecosystem: Within the Espanaro ecosystem, RibbonFlow is integrated today in three places: an admin-only Consilium plug-in for service-to-service messaging (for example to Pulse Sentinel), sensor self-enrolment, and the Edge Runtime sync path. Each keeps identity and trust decisions at the Espanaro layer rather than in the transport.
Three principles
Decentralised connection, with trust kept where it belongs
Decentralised
No central hub. Nodes announce services and find one another across the mesh.
Discoverable
Systems ask the mesh where a service lives, and fall back to static configuration if no answer arrives.
Verified
Message identity is checked at the Espanaro layer, using device signatures, certificates and revocation, rather than assumed from the transport.
The challenge
Fixed addresses and hand-edited configuration make it hard to move sensors between sites, restart devices or add new services without manual change.
Mixed networks also raise a trust question: a transport that simply carries messages cannot tell you whether the sender is who they claim to be.
Operational value
RibbonFlow delivers:
- Self-enrolling sensors
- Reconnect without re-pairing
- Optional, audited integration
- Identity checked per message
- Transparent fallback
RibbonFlow is at early access: a working prototype, integrated with Consilium, sensor enrolment and edge sync, with hardening in progress. It is suited to evaluation, controlled pilots and integration trials, not yet a production backbone.
Architecture
How it works
RibbonFlow is a decentralised, mycelial service mesh. Nodes announce the services they host, propagate that knowledge to their neighbours, and route requests to the node that can...
Solution in action
See RibbonFlow working
RibbonFlow is at early access. These transcripts are condensed from Espanaro engineering verification records, not a user interface.
$ ribbonnode -socket=/tmp/ribbon-a.sock -listen=0.0.0.0:0 [INIT] ribbon node starting, self_uuid=9d97065f... version=0.2.0 $ ribbonnode -socket=/tmp/ribbon-b.sock -listen=0.0.0.0:0 [INIT] ribbon node starting, self_uuid=298fe7d1... version=0.2.0 [HANDSHAKE] mutual trust established with 9d97065f... [1] Baseline push/ack round trip over the live mesh (node A to node B) PASS : hub acknowledged playbook (device identity verified, not revoked) [2] Disconnect: node B stopped, push sent while it is down PASS : no ack received while node B is down, as expected [3] Reconnect: node B back up under a NEW peer id (d8abadfa...) PASS : mesh re-established, same device identity, no re-pairing needed [4] Revoked-certificate case on the live mesh PASS : hub rejected the validly signed batch from the revoked device Phase 1 and 2 complete: all checks PASSED against the live two-node mesh.
Live two-node mesh verification. Baseline sync, node-down, reconnect and revoked-device checks run against a live two-node mesh.
RibbonFlow, verification summary (engineering record) Consilium RibbonFlow plug-in 23 tests (adaptor, API permissions, listener) Full Consilium test suite 489 passed, 0 failures, 0 regressions Sensor discovery (Request/Announce) 18 passed over real loopback UDP Edge sync transport tests 17 / 17 pass Behaviours exercised timeout with no responder falls back to static config malformed or empty-token reply falls back to static config plug-in disabled (default) every call audited, no network traffic revoked device certificate message rejected at the Espanaro layer
Verification summary. Test counts and behaviours exercised across the Consilium plug-in, sensor enrolment and edge sync. Figures reflect the engineering record, not a production deployment.
Capabilities
What RibbonFlow does
Core functions RibbonFlow delivers in operational environments.
Representative use cases
Where RibbonFlow makes the difference
Sensor self-enrolment
Let a sensor discover where to enrol after being moved between sites or segments.
Edge sync transport
Carry state between edge nodes and recover cleanly when a node goes down and returns.
Service-to-service messaging
Exchange messages between Espanaro solutions through a Consilium plug-in.
Trials and evaluation
Assess decentralised discovery and transport patterns in a controlled pilot environment.
Integration
Data flow and integration
How RibbonFlow connects within the operational environment.
Inputs
Service announcements from nodes, discovery requests from sensors and solutions, edge sync traffic, and messages sent through each node's local socket interface or the Consilium plug-in
Solution
RibbonFlow
Let services find each other, and connect without a central hub.
Connects to
Consilium (admin-only plug-in, off by default), Pulse Sentinel via Consilium, sensor enrolment adaptor, Edge Runtime sync path
Outputs
Messages routed to the node hosting a service, discovery answers telling sensors where to enrol, and an audit log entry in Consilium for every plug-in call
Integration by design
Working integrations with Espanaro solutions
RibbonFlow is integrated today in three places. Each was verified in testing, and each keeps trust decisions at the Espanaro layer rather than in the transport.
| Integration area | Supported approach |
|---|---|
| Consilium plug-in | Registers a service and sends and receives messages, for example to Pulse Sentinel. Admin-only, off by default and audited on every call. |
| Sensor self-enrolment | A sensor asks where to enrol and falls back to static configuration on timeout, a malformed reply or an empty token. |
| Edge sync transport | The Edge Runtime sync path was verified on a live two-node mesh, including reconnect under a new peer identity. |
| Per-message identity | Ed25519 signature, registry certificate and revocation check, enforced at the Espanaro layer. |
| Node interface | A local socket interface with simple send and receive commands for each node. |
Deployment options
Deploy where the mission needs it
Per host
One node per host
Run a RibbonFlow node on each system that should join the mesh.
With Consilium
Optional plug-in
Enable the admin-only plug-in where Consilium needs mesh messaging.
At the edge
Between nodes
Carry edge sync traffic between nodes on the same mesh.
Built for controlled environments
Assurance considerations
Off by default
The Consilium plug-in is admin-only and disabled until enabled. Sensor discovery is also off by default.
Identity at the Espanaro layer
Signatures, certificates and revocation are checked per message, not assumed from the transport.
Known limits
Best-effort delivery with no server-side queue, single-hop discovery, and hardening in progress.
Where it applies
Relevant scenarios
Operational scenarios where RibbonFlow delivers direct capability.
Capability
Engineering capability behind RibbonFlow
Espanaro service lines that support the integration, deployment and operation of RibbonFlow.
Technical summary
At a glance
| Solution type | Decentralised service-mesh transport software. |
| Primary function | Announce, discover and carry messages between nodes. |
| Status | Early access. Working prototype, hardening in progress. Not yet a production backbone. |
| Architecture | Non-hierarchical mesh with a four-step cycle: announce, propagate, request, route. |
| Interfaces | Local socket send and receive interface per node, Consilium plug-in and sensor enrolment adaptor. |
| Delivery model | Best-effort delivery. No server-side message queue, so the receiver needs an open subscription. Discovery is single-hop. |
| Lifecycle | Suited to evaluation, controlled pilots and integration trials. |
How to engage
A straightforward path from first conversation to pilot
Step 01
Discovery
Understand which devices and services should find one another, and on which network segments.
Step 02
Evaluation Workshop
Shape the nodes, plug-ins and trust model around your environment and constraints.
Step 03
Pilot
Evaluate RibbonFlow in a controlled deployment, with the early-access limits understood.
Product Datasheet
Download the RibbonFlow Datasheet
A concise technical overview of RibbonFlow: capabilities, use cases, integration and deployment. Fill in your details and the datasheet unlocks immediately.
- Technical capability summary
- Operational use cases and deployment context
- Integration and ecosystem overview
- PDF, free to download
Discuss RibbonFlow
Discuss how RibbonFlow can support your mission
Tell us about your operational requirement. We will respond with clarity on how RibbonFlow fits your environment and what deployment looks like.