All the users from Alpha 1 have been archived, so no need to rejoin unless you just want to try out the tech.
The new alpha doesn’t scan every trx and only broadcasts on demand after doing an ICRC-2 TransferFrom. We’ll get back to ledger scanning soon, but we wanted something up so you could browse the dapp we are building for network topography and introspection. You can find that here: ICP + Vite + React
Let us know if you have need of pub/sub and would like to be an alpha tester.
Pan Industrial is no more. The code is with ICDevs. The canisters are still up and running. Let me know what you need and I can support it. We need beta testers to harden the protocol.
Cool, can I ask what the delivery guarantees are - is it at least once delivery (possible duplicates), exactly once, at most once or something else?
Also in terms of trust assumptions, what’s the plan regarding decentralisation/blackholing?
Also how does cycles/funding work?
I was thinking about how I’d implement this myself while waiting for a response and I think my use case may be a bit simpler than what @PanIndustrial has made this to support. I think a simpler design might lend itself better to blackholing while still providing exactly once delivery.
I’d prefer to use and support something someone else is building though if it delivers what I need already. I just need a service to promptly notify canisters when funds have arrived in specific subaccounts rather than each of them needing to rapid poll even during quiet periods.
Delivery is optimistic. But ICRC-SomethingSomething allows you to request missed messages…you send payment along for them…you can replay from index 0 on an event a-la firebase if you’re willing to pay for delivery.
Current plan will be to put it under ICRC-137 governance(NNS Veto - slows upgrades but provides some guarantees that the operators won’t run for ole Mexico) until we get the tokenomics worked out and can find a DAO system that works and can avoid capture. (There are some hopeful tokenomics already planned that should support a robust ecosystem and make the system self-sustaining, but a few more infrastructure pieces need to be built)
Cycle funding takes care of itself! When you are delivered a message, you get an invoice, and when you confirm receipt, you send cycles back or you don’t get the next message!
The subscriber component needs to keep track of what messages it has received and if it misses one then it needs to request. As a restart mechanism or post upgrade I’d check for the latest message Id and proactively kick off a request.
I don’t think there is a public ledger at this point…it would be a lot of data. I think the orchestrator has a ledger for recording the assignment of broadcasters to publishers and subscribers, but the publishers start relaying to broadcasters and relays and there is no central point that all messages pass through. When you request a replay you’re actually sending that to the source service that emitted the event and they are replaying from their store…so it would be the source application’s responsibility to determine if they wanted a ledger or not.
Cool, I’m sure this design would work well for specialised use cases. I have some ideas about an alternative implementation that may be quite a bit simpler. Would love to discuss more once I’ve spiked a PoC.
Do you know if the working group still runs and if there’s anyone else developing event utilities for the IC? I’d be interested in joining the working group and sharing my thoughts.
@Ang would you be a dear and reinstate this thread please? Maybe just reinstate all of them to save the time?
It was actually designed to be as generalized as possible. If you read the ICRC 72 spec, there’s not very much that it is opinionated on and leaves it pretty open to interpretation. You can use the same standard to build a private pub sub network that’s just one to many or a multi subnet one such as was intended with ICaiBUS. The hope was with a well fine standard. You could use a bunch of the same components to build all kinds of different networks, but with some standard conventions like name spaces, payments, message structure , etc.
This is what I mean, it looks like it’s intended to be so flexible as to support most pub/sub use cases you can imagine, but flexible almost always leads to incidental complexity (as far as specific use cases are concerned). I’m sure this is very suitable for projects that want to take advantage of most or all of the what it has to offer.
I think the majority of cases (or at least the case that I need a solution for) can use something much simpler and with significantly fewer trust assumptions as a result (because simple things are better candidates for blackholing).
This has been one of the biggest problem we’ve had with the Internet computer since Genesis. Everyone wants to re-roll everything. Until we have common components that are plug-And- play, that can be trusted, and where the implementation is simpler than trying to re-roll your own, we won’t have the developers we need.
It is an incredibly difficult tension because at the same time there is reality that you have a limited amount cycles for a round to deal with, and sometimes, with a sufficiently difficult problem, you have to squeeze every last cycle with code.
If you have a closed system, it’s gonna be super easy to just write your own implementation where you keep track of all the subscribers and send them a message. ICRC 72 can be maxed out in an environment where you don’t know who your subscribers will be, don’t want to have to roll your own registration, your information is valuable, and you may want to create a market for that. And it can scaled down to just a small set of known receivers…but if that latter scenario is you, there may be some overhead in the default components. I’m fairly certain the framework and interface is a solid foundation.
I agree that that’s a problem. From my perspective this project appears to perpetuate that phenomenon rather than simply being a victim of it.
The IC already has plenty of message buses, at least one of which is governed by the NNS itself. All that was needed for most use cases is an event trigger to prompt subscribers to pick up messages from the bus - job done (instead of everyone rapid polling independently they can slow poll as a fallback while the happy path is to recieve a simple poke from one shared notifier that rapidly polls the message bus on everyone else’s behalf and issues best effort pokes to subscribers interested in picking up those messages - a simple enough job for blackholing).
If I see a solution that delivers on what’s needed (trust-minimised, simple and no incidental complexity) I’ll happily use it and do whatever I can to support the DAO or protocol that facilitates it. If I don’t see such a solution, I’ll do my best to deliver one instead.
I’ve almost finished a prototype. I’d be interested in your feedback if you’re willing to take a look.