search

decentralized-identity / didcomm-messaging

https://identity.foundation/didcomm-messaging/spec/
Apache License 2.0
167 stars 57 forks source link

Has anyone thought about how to extend the DIDComm service endpoint block to support multiple transports? #189

Open kdenhartog opened 3 years ago

kdenhartog commented 3 years ago

This just popped in my head. Has anyone thought about how we'd list multiple URLs in order to send different DIDComm Messages. I'd suspect we could go two ways. Either provide multiple service endpoints within the services Array of a DID Document or we could potentially list multiple URLs within a single service endpoint object.

We should figure out at least a rudimentary way to make this possible. Similarly we'll want to consider the differences between a URL being updated frequently (e.g. what happens when bluetooth rotates MAC addresses quickly) vs URLs that are quite static (common mediator URL that's shared by many people)

nickreynolds commented 1 year ago

I've been thinking about this a bit, not sure if there's been any other discussion on the topic recently, but I think it's worth revisiting.

I think I would prefer declaring multiple services, rather than including multiple URLs in a single service, but either way I think there needs to be a way for the owner of a DID to specify some preference of how they'd like senders to attempt to send them messages. Perhaps they prefer to be contacted via libp2p dialProtocol because they run their own libp2p node but if that fails, they don't mind if you try to send the message to their Mediator.

Maybe these preferences need to be in the form of their own Service declaration... type DIDCommMessagingPrefs? This service could either contain an array of service_ids or a URI that returns an array of service_ids...

Or maybe this could be handled through a DIDComm Protocol? If it's the first time you're sending a message to a DID you can send a DIDCommMessage with type https://didcomm.org/request-preferences/1.0...

mwherman2000 commented 1 year ago

Use the array of types you can specify for a service endpoint? For example, in Web 7.0, we support type keywords like [ "loadbalanced", "roundrobin" ] for supertyping an array of service endpoint URLs. Use the same idea (reserved type keywords) for transport names/tags.

mwherman2000 commented 1 year ago

We're also using a similar technique for defining the nearest neighbors for each DIDComm Network Message Router Agent in each agent's DID Document ...used by each agent for building dynamic message routing (forwarding) tables.