ICaiBus - Internet Computer AI Bus - PubSub made Easy on the IC

Hello everyone,

We’re excited to announce the alpha release of ICaiBus (Internet Computer Artificial Intelligence BUS)(pronounced I-KY-Bus)—a new messaging bus platform for the Internet Computer, developed by Pan Industrial with support from a DFINITY Developer Grant!


What is ICaiBus?

A messaging “bus” in computing provides a simpler way to handle events between different components in a system. Rather than connecting each service to every other service that needs to know about its events, the bus allows publishers to “announce” events once and subscribers to independently “listen” for those events.

Why does this matter?

  • It drastically simplifies development: You no longer need to coordinate external systems to confirm how events are delivered, as long as you stick to the published interface.
  • It supports real-time data and monetization: ICaiBus makes it easy to handle streaming events and even monetize them if your dapp chooses to.

A Big Thanks to the Event Utility Working Group

We couldn’t have built this platform without the help of the Event Utility Working Group. Their collaboration and contributions have been integral, and contributors to that group will be considered co-developers of ICaiBus. We’ll be reconvening this working group now that we have sample libraries ready, and we invite everyone interested in the next steps to join us. (See the end of this message)


Architecture Overview

1. Orchestrator

The Orchestrator is our system’s “command center.”

  • Manages which publications (event streams) are available.
  • Keeps track of who has subscribed to each publication.
  • Coordinates with Broadcasters to ensure messages are relayed to the correct subscribers.

2. Broadcasters

The Broadcasters live on each subnet:

  • Responsible for delivering messages to subscriber canisters on their subnet.
  • Relay messages across subnets if the target subscriber is on a different subnet.
  • They collate and batch messages to reduce traffic (rather than sending them one-by-one).

3. Publisher

The Publisher:

  • Declares what messages it will send and who is allowed to send them.
  • Collates and broadcasts event streams.
  • Allows you to emit a single event, leaving ICaiBus to handle distribution to all subscribers.

4. Subscriber

Any canister on the IC can be a Subscriber:

  • Subscribes (permissionlessly) to published events.
  • Can apply filters (e.g., ignore certain messages, skip messages, etc.) to manage bandwidth.
  • Will soon have the option to recover missed messages if a canister goes offline.

Monetization and Future Features

  • Instant monetization: Publishers can optionally log to an ICRC-3 ledger, offering private feeds or tiered/prioritized access to public streams or maintain a private stream and charge a subscription.
  • Security and encryption: Once the local replica enclaves are available, we plan to enable end-to-end encrypted enterprise-grade messaging and logging.
  • Utility token: We’re exploring a network issued, team supporting, fair-launched, utility token model to foster network growth and community involvement.
  • AI synergy: ICaiBus aims to support AI agents (on-chain or off-chain), enabling them to interact in a cryptographically secure and self-sustaining economic environment.

Demo and Alpha Release

We’re launching our Alpha with a simple demo publishes the ICP transaction stream and allows for creating a whitelists of funding addresses and splitting ICP payments across that list:

  • Broadcasters are running on two different subnets.
  • Anyone can subscribe to the ICP transaction stream.
  • Subscriptions require you to send back cycle costs as you receive messages. A provided Motoko subscriber component handles this automatically—just supply minimal boilerplate and you’re set!

How to Get Added to the Alpha Tester List

If you send at least than 100,000 e8s of ICP (0.001 ICP) to the address

e9dc3bbbcb45479709e8ef512f6c8a66d6593cbb1b8621ff9cdbde917d6da9aa 

(Alternate principal: 2rssh-v35xr-d2rhf-kw3pb-eh5ah-vfywx-rdbhr-odnlx-un77i-lujm7-tae)
you will be added to our alpha tester list on both subnets.

If you send ICP to the address

fdf2951f98f74c82737153dfdfacff0ede58a827578777e0ad7c8cfbd16c6e81 

(Alternate principal: arnqk-riaaa-aaaae-qakmq-cai)
your ICP will be distributed evenly across everyone on the list.

Demo Canisters (for reference):

  • Orchestrator: wtiga-eaaaa-aaaae-qajxa-cai
  • Watcher (Publisher): w5kli-7qaaa-aaaae-qajwa-cai
  • Broadcaster Subnet 1: w2ln4-siaaa-aaaae-qajwq-cai
  • Broadcaster Subnet 2: e4qhd-faaaa-aaaac-ah2ba-cai
  • Whitelist Subnet 1 (Subscriber): wujau-jyaaa-aaaae-qajxq-cai
  • Whitelist Subnet 2 (Subscriber): e3rbx-iyaaa-aaaac-ah2bq-cai
  • Splitter (Subscriber): arnqk-riaaa-aaaae-qakmq-cai

You can interact with the demo at the ICDevs.org’s ICRC-75 browser.

The publisher, “Watcher,” emits a single message. It flows through the Broadcasters to both subnet subscribers. When your transaction is detected, you’re added to the alpha tester list, and a new ICRC75 list tracks each contribution. The canisters on each subnet should be eventually consistent.

The ledger is scanned every 30 seconds, and broadcasts also happen roughly every 30 seconds. Expect ~60 seconds of delay for your event to fully propagate.

Under the hood, we use NTN DAO’s DeVeFi ledger software for the ledger scanning functionality.


Example Subscriber Code (Motoko)

Below is a version of the Motoko code that subscribes to the ICP transaction stream. Once you configure it using the ICRC-72 standard subscription, ICaiBus handles the rest:

let subscribeResult = await* icrc72_subscriber().subscribe([{
  namespace = "com.icp.org.trx_stream";
  config = [
    (ICRC72Subscriber.CONST.subscription.filter, #Text("$.to == e9dc3bbbcb45479709e8ef512f6c8a66d6593cbb1b8621ff9cdbde917d6da9aa")),
    (ICRC72Subscriber.CONST.subscription.controllers.list, #Array([
      #Blob(Principal.toBlob(thisPrincipal)),
      #Blob(Principal.toBlob(_owner))
    ])),
  ];
  memo = null;
  listener = #Async(func <system>(event: ICRC72Subscriber.EventNotification) : async* {
    // ... code that handles the event, checks the amount, 
    // and updates the membership and data tracking ...
  });
}]);

This snippet shows how straightforward it can be to start receiving events. Simply set the filter, designate controllers, and provide a listener function.


Cycle Costs and Next Steps

  • Cycles: We currently have a high multiplier on request costs to ensure we don’t run out of cycles mid-demo (around 99 million cycles per notification, or ~$0.00013).
  • Each notification needs to be confirmed (our subscriber component does this for you). If your cycle balance runs too low, you’ll stop receiving messages.

We expect these costs and methods to be refined as we exit alpha. If you want to test a feed or run your own publisher, please reach out.


How You Can Help

  1. Build a service that listens to the ICP data stream. We’ll be happy to whitelist your canister (future versions will be permissionless).
  2. Publish your own events in the alpha. If you have a feed you’d like to share, let’s talk about onboarding you.
  3. Rust contributors needed: The Event Utility Working Group is searching for a Rust engineer to create a publisher/subscriber component in Rust.

The Code:


Join the Event Utility Working Group

We’re reconvening on January 29th to discuss alpha implementation details and next steps. If you’re interested:

We look forward to your feedback, questions, and contributions!

—The Pan Industrial Team
Supported by a DFINITY Developer Grant

12 Likes

I thought ic already built inter subnet communication in protocol level
How is this different
Does it bypass conssus to overcome latency

This is built onto of the IC and uses that intersubnet communication, but presently, if you want your canister tell 16 canisters that you are ‘ready to receive messages’ you have to make 16 different calls to each individually. And you need to trust those canisters as any one of them could make your canister un-upgradeable if it is malicious and you don’t use one-shot calls.

With this framework you can emit a ‘ready’ event and the ICaiBus framework will make sure they get there. The subnet navigation is a strategy around reducing cycle costs. Each open call reserves and spends cycles while the call is open. If your sixteen canisters are on a remote subnet you will open 16 individual calls and pay for the max open reserved memory for a full possible 2MB response for each. With our framework those messages are collated and sent in batch messages to broadcasters on each subnet that can then do on-subnet calls that typically finish within the same round.

In summary: IC developers are not supposed to have to think about subnets, but in reality they do because crossing a subnet barrier increase latency and cost. Our framework abstracts that away and reduces the problem to just cost(we do account extra cycles if you are relayed to another subnet, but it is consistent and more ‘even’ than the unknown of the current system.

2 Likes

It seems the original post didn’t mention an important feature: This system uses one shot calls so you can broadcast to canisters that you do not own safely without risk that they can block your upgrades. This solves one of the oldest issues with intercansister calls that we’ve been dealing with since genesis. Watch out for foot guns with canister upgrades - #9 by nomeata

Publish calls from your publisher to the broadcaster are regular calls but always return quickly. The ICaiBus broadcasters send one-shots to subscribers to make sure they can always be upgraded. You can now send messages to undoxed bots, degens, nere-do-wells, and rapscallions.

2 Likes

Nice job! I’ve been working for one of the DAOs on ICP for about a year writing Rust canisters. I’d like to help if you’ll accept me.

Thanks

1 Like

What are the use cases for AI services? It sounds like ICaiBus would be great for handling events to various AI agents that need the same events.

I guess the use cases can be endless here; I am just curious why name it ICaiBus.

1 Like

Thanks for this @PanIndustrial. A messaging bus for the IC will be a very beneficial piece of infrastructure, I’m sure. I’ll be keeping tabs on this. Very exciting! :slightly_smiling_face:

It’s great to see a whole event management platform take shape on the IC to support more message passing modes beyond simply request-response calls.
Having a payment for service option included in the message payload will surely find many good use cases in projects who implement with ICaiBus

Lovely work @PanIndustrial !

IC - Internet Computer
AI - Artificial Intelligence
BUS - Bus (computing) - Wikipedia

We’ve been looking at building an Enterprise Bus for the IC since the beginning as we knew it was necessary for enterprise grade development. AI seems to be here now and with our work with enterprise we can see where this is going. Enterprise will be mostly AI agents. When those agents begin to speak across enterprise boundaries they lose trust. Communicating over a trustless protocol with sufficient consensus can drastically increase can provide the trust necessary to allow those AIs to execute commerce, negotiations, data exchange, etc with trust.

So we went with AI and ICentBus went out the window :slight_smile:

As you mention this is a great tool for:

  1. AIs that want to publish their ‘decisions’ or ‘actions’ to to other canisters on the IC. If you want your dApp to have one-line integrate opportunities and one-line monetization opportunities by agents running on the IC then publishing ICaiBus events will be much easier than telling them to query an endpoint over and over (which get converted to an update call and costs cycles every time your canister wakes up) and much easier than deploying infrastructure to AWS to query from outside the IC and then building a trust layer back into your on-chain agent.

  2. AIs that want to listen and respond to 3rd party events occurring on the IC. This becomes much easier because a) Publishers no longer need to trust that you’ll respond in a timely manner and b) Publishers don’t need to know who you are or write their own notification engine. It saves devs. time and operators cycles. In a @bobdotfun world where subnets can get clogged it is also nice to not have to pay for reserved compute and know that you canister will only be woken up when it has some work to do. With proper architecture devs can maintain a low cost footprint even on busy subnets.

And, yes, beyond that the use cases are endless and prior art says there might be something here. ICaiBus is the MuleSoft of the IC.:

warning subject to hallucination and not verified

Here’s a list of well-known Enterprise Service Bus (ESB) companies along with their software offerings, estimated license costs, and estimated annual revenue based on historical knowledge up to 2023:

Current Enterprise Service Bus (ESB) Companies

Company ESB Software Offering Estimated Cost for a License Estimated Annual Revenue
MuleSoft MuleSoft Anypoint Platform $80,000–$250,000/year (varies by scale) $1 billion (acquired by Salesforce)
IBM IBM App Connect (formerly IIB) $100,000–$250,000/year $5 billion+ (IBM Middleware Division)
TIBCO TIBCO ActiveMatrix BusinessWorks $150,000–$300,000/year $1.5 billion (estimated middleware revenue)
Oracle Oracle Service Bus $50,000–$200,000/year $1 billion+ (Fusion Middleware)
Software AG webMethods Integration Server $100,000–$300,000/year $1 billion+
Microsoft Azure Service Bus $1,000–$10,000/month (cloud-based) $200 billion+ (Microsoft overall)
Red Hat (IBM-owned) Red Hat Fuse (formerly JBoss Fuse) $10,000–$20,000/year (open-source model) Part of $1 billion Red Hat division

Historical ESB Software and Acquisitions

Historical ESB Software Acquirer Acquisition Amount
MuleSoft Salesforce $6.5 billion (2018)
JBoss ESB Red Hat $350 million (2006)
BEA Systems (including AquaLogic Service Bus) Oracle $8.5 billion (2008)
Progress Sonic ESB Progress Software Estimated $100 million
Cape Clear ESB Workday Undisclosed
SeeBeyond (eGate Integrator) Sun Microsystems (later Oracle) $387 million (2005)
TIBCO Vista Equity Partners $4.3 billion (2014, private buyout)

These costs and revenues are approximate based on prior knowledge of ESB industry trends and acquisitions and may be completely made up by an AI.

1 Like

Yes! We have discussed this as an ICRC add on to the ICRC-72 protocol in the Event Utility Working Group. You can find the issue here and we’d love your contribution: Financial Value · Issue #45 · icdevs/ICEventsWG · GitHub

1 Like

Please join the working group call this Wednesday if you can and we can have the WG authorize the issuance of our WG Token for the work. Feel free to reach out privately with your GitHub and I can add you to the repos so you can see what the current publish/subscribe modules look like.

2 Likes

Thank you for the thorough explanation; it would be cool if you could explore the use cases mentioned.

A few areas that come to mind:

  1. A collaboration with @zensh that would allow agents built on Anda to send data to a subscriber canister.

  2. ICaiBus could serve as an AI agent “log.” The AI agent does an action and posts it into a stream.

  3. Showcasing an AI agent reacting to the ICP transaction stream.

Please let us know if you pursue any of these or need to find developers to pursue them.

2 Likes
  1. Would be great to put together. @zensh I’m guessing the models are running in cpp or rust? Is there a wrapper around them. We will hopefully have a rust publisher/subscriber soon and then it is just a matter of wiring the two up. What is the best place to get started deploying a model canister and what does the interface to it look like(candid?).

  2. Yes. And this extends even to external models that want to transact in some way. By giving them an identity and having them communicate with some kind of on-chain wallet that can emit these events you’d be able to start to tie identities to these off-chain agents.

  3. As soon as we can figure out how to get an agent up and running and have capture it’s output we can set this up as a simple demo.

Great tech. I’d imagine smth like Telegram channel broadcast could be built on top of this. A way for personal and organizational broadcasting systems, with full ownership of the network.

1 Like

This ICAIbus sounds very interesting and could be pretty useful and solve a lot of problems for developers in the community. I hope that DFINITY supports it fully and gets this thing out there to make building on the Internet Computer easier so that we can have even better applications for users.

1 Like