Supporting IBC Casting #759
Replies: 10 comments 19 replies
-
Two more folks: @AdityaSripal, @dckc. |
Beta Was this translation helpful? Give feedback.
-
Seems related to IBC queries. |
Beta Was this translation helpful? Give feedback.
-
I agree that it is related, to IBC queries. Let me explain the differences:
I could implement pubsub as an application on top of queries, but only if not polling, and if the pubsub application could provide predicates to filter the acceptable query answers. For this reason, I see pubsub as closer to a connection protocol than to a polling one-shot query. @zmanian do you personally think it makes sense to add supporting features to ibc query? |
Beta Was this translation helpful? Give feedback.
-
I've figured out two orthogonal but composable features for Interchain Queries that would enable IBC PubSub to be built as an application: Implementation is opt-in for relayers. Worst case, a relayer would poll periodically to see if new data arrives. If the source chain can raise on-change events for query results, that can help a relayer or other off-chain follower to satisfy the query more promptly/efficiently. Here's a suggestion for change events:
The |
Beta Was this translation helpful? Give feedback.
-
I'm working on a PR at Agoric/agoric-sdk#5466 ! You're welcome to join. |
Beta Was this translation helpful? Give feedback.
-
Interesting idea. What I would like to ask is the delivery semantics, which is one of the trickiest details of any messaging bus. IBC channels guarantee "at most once" delivery. But also work hard to ensure that a response or timeout will eventually arrive on the sender, if the channel/connection remains alive (and push any liveness requirements to that lower level). What about pubsub? If I am a subscriber, can I assume that I will get all messages published after my subscription is registered on the remote chain, until their is a liveness issue on the connection? If there are messages [A, B, C, D] published, and a subscriber connects and receives B as the first message - will it ever see A? Is it possible for it to receive only [B, D] and not C? Are there any ordering guarantees? These are very important semantics to define before implementing anything. I am not sure what the right choices are to support the most applications, but for me allowing |
Beta Was this translation helpful? Give feedback.
-
Thanks for the idea @michaelfig! Agreed with @zmanian that we should try to merge efforts here with Interchain Queries. A couple questions for my understanding.
Unlike current Interchain queries, it should be noted that this will require changes to be implemented on the Publishing (Queried) chain since they must also store the height at which value updates as well as height of previous update. Note that we can build a unidirectional PubSub on top of the bidirectional channel abstraction. We do something vey similar for ICA, where messages flow in one direction |
Beta Was this translation helpful? Give feedback.
-
This is very cool, will see how we can merge this with any ibc query efforts |
Beta Was this translation helpful? Give feedback.
-
I've updated the concepts document linked from the description to feature use cases prominently. |
Beta Was this translation helpful? Give feedback.
-
Inviting @albertchon to the conversation! |
Beta Was this translation helpful? Give feedback.
-
Motivation
The goal of IBC Casting is to support the model of:
Implementations
x/vstream
implementation Agoric/agoric-sdk#5466)IBC PubSub Discussion History
This is the unchanged initial post made by @michaelfig introducing IBC PubSub
I had an idea for a new IBC-based feature grounded in actual use cases on the Agoric chain.
Could we make a new connection primitive (other than the bidirectional "channel") for publish/subscribe applications? The API I envision is for a source host* to be able to publish messages on a given topic, and another host/client** to subscribe to that topic.
Unlike IBC channels, a pubsub would be unidirectional and not have any means to send data from the subscriber to the publisher (not even to handshake). Here are some loose requirements I'm thinking of:
*
IBC host = chain or solo.**
including relayerless client libraries like CosmJS.I believe the provable data needed to store on the publishing side is per-host, per-topic, and consists of information about the last block that published something:
Thoughts?
Tagging: @dtribble, @erights, @jackzampolin, @JimLarson, @warner, @zmanian for moral support.
Beta Was this translation helpful? Give feedback.
All reactions