-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce Webhooks / Callbacks #167
Introduce Webhooks / Callbacks #167
Comments
the replyTo feels more self documenting as it invites you to consider it as you construct your first message (and the replyTo could itself be a did I guess?). but not basing that on any super deep thinking. |
We should while thinking through this design consider compatibility with DWMsgs/DWNs. HTTP URLs may couple tbDEX to HTTP. |
good point @bradleydwyer - as if its an "alice" sending a message, her replyto/DID could point to a DWN to receive messages in a self-custodial situation. edit: even if they aren't http the terminology "webhook" is probably ok if used (replyto is more explicit in that regard) come to think of it. |
3. Move callback into HTTP APIAnother approach is to move the callback URL up an abstraction into the HTTP API. For ex, we could update the Putting the callback URL into the HTTP API instead of the TBDex message has a couple benefits:
Against DID Service EndpointMy least favorite option is the DID service endpoint approach because:
|
good point! |
@diehuxx i imagine we'd want something like a |
if the replyTo is itself a did URL, then it doesn't have to be coupled to http? then it could remain(?) in the message. I'm not sure about the callback url containing sensitive information, feels like it wouldn't be optimal if it was assumed to be sensitive. |
Exactly. Though, I'm not sure how much we care about keeping the notion of |
I'm not sure if that would work with DWNs currently. Even if that does work, there's transports beyond http and did url that would be excluded.
What's the benefit of doing so?
Not sure I understand what you mean by optimal? |
@diehuxx yeah I might not really get the context here so feel free to ignore me! the idea of using dids as they are universal (but then if the doc is heavy to update then that isn't ideal - but that may be an assumption, and a user can have dids for many purposes). Chanelling @csuwildcat here! (and it would mean you could have another did separate to sender with a service endpoint, but maybe that is too chonky of an idea!). Remaining in the message is related to sensitive information: if there is sensitive information in the url, then isn't that about privacy and or trust, and in one of those cases it is better in the message than out of band? (again just being more general, not sure of specific case here). |
@diehuxx i think I get you now I read it again. If we want it to be “web” hook then pulling replyTo into http api like you said may be simpler and the right thing while still allowing service endpoints at some point in future? |
@diehuxx i'm on board. technically speaking this allows for people to leverage at some point we can explore using |
+1 for proposal 3, although I would suggest naming the request something like @mistermoe and I talked through specifying callbacks at an exchange level rather than at a DID level...in summary, it feels like there could be some potential extra flexibility with how wallets want to leverage the callback URL, for not much of a UX tradeoff (looking at a one off |
@phoebe-lew Making sure I understand. No pushback, just clarifying. By this do you mean we could have a separate endpoint called |
@diehuxx nop, let's just go with proposal 3 and introduce a The We can always change it in future if we decide it's better to register the callback against the DID. |
happy to implement option 3, but can someone tell me the difference between option 3 and option 1? seems like both are suggesting that we add the |
@jiyoontbd Option 1 places |
@diehuxx oooh, i think i am understanding where i've misunderstood. do you mean put |
Doing a little bookkeeping because I often lose track of these things. PRs in progress:
@amika-sq Flagging this issue so it's on your radar for tbdex-swift. See Phoebe's spec change PR for the new design. |
That's mostly right. You're right that Also (as noted in in @phoebe-lew's spec PR), we are changing the name of |
So I hate to come late to the party here and advocate for a pivot, but I feel compelled to articulate a stance for Option 1 actually. With full recognition it may not be worth pursuing, at least at this time, but I want to make the articulation here while it's fresh in my focus (I just came across this ticket). Here's my alternative proposal:
Here are my reasons why I don't like where we landed:
Again, I just wanted to document this for future reference. Not a priority by any means, and can be ignored. |
Motivation
Currently, in order to receive new messages for a given exchange, Alice must poll the respective PFI's http api. A handful of people have brought up adding webhook / callback support.
Two approaches came to mind that may work.
1.
replyTo
propertyWe could consider adding a
replyTo
property torfq.metadata
or more generallymessage.metadata
.replyTo
is a fully qualified URI which effectively acts as a callback URL / webhook. The value ofreplyTo
could either be a DID or just a URL.if
replyTo
is present, a PFI would send any/all new messages for a given exchange to the supplied URL2. DID service endpoint
Alternatively, this could happen implicitly by resolving the sender's DID and looking for a predefined service endpoint type. if the predefined service endpoint is present, a PFI would send any/all new messages for a given exchange to that service endpoint.
In order to support either approach, we'll need to specify how the webhook url works. e.g.
The text was updated successfully, but these errors were encountered: