You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The did:sov DID Method is commonly used, but flawed in that the DID doesn't specify the ledger on which the object/transaction exists is to be found. I gather the original idea was that a given client would only ever connect to a single ledger. The did:indy DID Method addresses this by identifying exactly what ledger is being use in the DID.
As a result of that flaw, when using did:sov (or unqualified DIDs), it is common practice to configure a client to know about a number of ledgers and when resolving a DID/object, to check with all the ledgers, and use the one returned (with a defined approach to handling scenarios where multiple transactions are retrieved).
It might be nice to build the "check all ledgers" functionality into the Indy Read Replica code. Allowing a client to request an Object (doesn't make sense when retrieving a specific transaction) without specifying the ledger ID (or specifying multiple ledger IDs) to query, and have the Read Replica check each ledger and return a result.
To be determined is how to allow the Replica to decide what to do if multiple results are returned. Either the client always passes in an ordered list of ledger IDs and the lowest one is selected, or the Replica is configured with an ordered list, the client doesn't pass in an ID and the lowest one is selected. I suspect it makes the most sense to have the client pass in the list on all calls, so that a Replica can handle many networks, but each client could pick a subset of interest.
The text was updated successfully, but these errors were encountered:
The
did:sov
DID Method is commonly used, but flawed in that the DID doesn't specify the ledger on which the object/transaction exists is to be found. I gather the original idea was that a given client would only ever connect to a single ledger. Thedid:indy
DID Method addresses this by identifying exactly what ledger is being use in the DID.As a result of that flaw, when using
did:sov
(or unqualified DIDs), it is common practice to configure a client to know about a number of ledgers and when resolving a DID/object, to check with all the ledgers, and use the one returned (with a defined approach to handling scenarios where multiple transactions are retrieved).It might be nice to build the "check all ledgers" functionality into the Indy Read Replica code. Allowing a client to request an Object (doesn't make sense when retrieving a specific transaction) without specifying the ledger ID (or specifying multiple ledger IDs) to query, and have the Read Replica check each ledger and return a result.
To be determined is how to allow the Replica to decide what to do if multiple results are returned. Either the client always passes in an ordered list of ledger IDs and the lowest one is selected, or the Replica is configured with an ordered list, the client doesn't pass in an ID and the lowest one is selected. I suspect it makes the most sense to have the client pass in the list on all calls, so that a Replica can handle many networks, but each client could pick a subset of interest.
The text was updated successfully, but these errors were encountered: