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
- Build a service that listens to the ICP data stream. We’ll be happy to whitelist your canister (future versions will be permissionless).
- Publish your own events in the alpha. If you have a feed you’d like to share, let’s talk about onboarding you.
- Rust contributors needed: The Event Utility Working Group is searching for a Rust engineer to create a publisher/subscriber component in Rust.
The Code:
- Our Test Suite(In case you’d like a broader view of what the software can do: GitHub - PanIndustrial-Org/mvevent
- The Subscriber Component: icrc72-subscriber-mo
- The alpha subscribers - whitelister and splitter - icaibus_whitelister
Join the Event Utility Working Group
We’re reconvening on January 29th to discuss alpha implementation details and next steps. If you’re interested:
- Check out the working group’s forum thread: https://forum.dfinity.org/t/technical-working-group-inter-canister-event-utility-working-group/29048
- Join our dedicated Discord channel on the IC Community Discord
- Explore our GitHub: https://github.com/icdevs/ICEventsWG
We look forward to your feedback, questions, and contributions!
—The Pan Industrial Team
Supported by a DFINITY Developer Grant