-
Notifications
You must be signed in to change notification settings - Fork 204
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
Add support for WebSockets #250
Comments
@TimoGlastra @JamesKEbert Is there any specification about how a mediation recipient should make a connection with a mediator? I'm asking mainly about the part about how the recipient is supposed to get the connection invitation, the rest is connection protocol of course. |
Not an exact specification. Couple of routes we could take:
I think it would be cool to have the mediator expose a So as a starter maybe just use an invitation config parameter? ACA-Py adds the endpoint to the public did sov after startup. So we should be able to connect using just a DID. However to be able to resolve the endpoint from a did we need to do some extra work. Mainly resolving the did from ledger, retrieving the ATTRIB, so we can read the endpoint. Basically constructing a did document from the did:sov as https://dev.uniresolver.io/ does. |
ACA-Py has a PR open for did:web: openwallet-foundation/acapy#1143 |
Interesting, I hadn't considered using an implicit invitation with a public DID. As of right now the primary method in ACA-Py AFAIK has been generating a multi-use invitation to kickstart the process. This could be a single-use of course as well, but multi-use has been the most well used. My thought process for the methods in which you could make the connection and request mediation with the mediator would be:
So, I think this lines up with @TimoGlastra's thoughts above (let me know if I'm wrong). |
Thanks, guys for your ideas. I'm not sure if I understand "use an invitation config parameter" correctly. Would it work for the edge agent running in a mobile app? I like the idea with did:web and I created a new issue #371 because it's unrelated to WebSockets. We can continue there and I'm closing this one. The rest of the work mentioned in the description of the issue is also being worked on in a separate issue #268. |
I needed to do the following changes (solved by #231):
Addreturn_route
parameter to outbound when there is no inbound connection (there is no service with endpoint other thandidcomm:transport/queue
)Addkeylist-update-response
message and handler, just with naive implementation.ExtractoutboundTransporter
as direct dependency in Agent’sconstructor
.Next steps on the way to support WebSockets transport I would like to do:
Extract also(solved by refactor: extract inbound transporter from agent constructor #245)inboundTransporter
from Agent’sconstructor
. (I can perhaps do it as part of this PR, but the changes started growing and I wanted to share what I have now.)Take outbound endpoint fromDidDoc
.Add WebSocket transporters.Add TransportService to keep info about current transport channels.Next steps I see we will need to do someday in near future but not necessarily before or right after adding the WebSockets (solved by #231):
Update download messages functionality to processbatch
message and to removesendAndReceiveMessage
that is still implemented in the old way relaying on synchronicity of HTTP request-response.The text was updated successfully, but these errors were encountered: