"Link could not be validated due to unresolved dependencies"

Technical Discussion
#1

Hello!
I’m running into the above error when agent B is trying to a hold a link that’s based on agent A’s agentId.
I’m using tryorama in singleconductor mode and I can see in the logs that agent B is querying for the agentId but doesn’t find it. I believe its doing a local search, hence the empty result.
Could it be that the test is running in mirror DHT mode and thus agents will never get to see other agents’ private entries? I don’t remember how public links from/to private entries are suppose to work.
Maybe there is a way to disable link validation?

#2

Hey @ddd-mtl!

Yes, when using the singleConductor middleware, the conductor runs with in-memory networking – which isn’t as actively maintained as sim2h, and what you found might be a bug. Probably better to use a local sim2h server for the most correct behavior.

#3

also, sim2h should fallback to “offline mode” if it can’t connect and it will just trust itself for all queries, so you might not even need a local server

#4

Thanks guys. I figured out my problem. You actually can’t link private entries in holochain. It seems you’d get the validation error I shared in the title. I hope you can change that in a future release, as I have a use case for that, and I’m sure I won’t be the only one.

#5

Hum interesting, what does that use case look like? I didn’t think there was any valid scenario for that.

#6

I’m building a simple email happ where an agent stores locally private emails it received and than can commit and send privately an acknowledgement receipt for a received email. I need to link those two private entries: The private mail to the private receipt.
(Another use case could be to link an entry to itself as a way to add metadata.)

Here is the DNA design

1869×1323 122 KB

Linking private entries
#7

Hum okey, I don’t think holochain core will support this in the future, since links are mainly a way to add metadata to entries in the DHT, and private entries do not exist in the DHT.

This can be implemented also with a new kind of private entry, or maybe better, querying all your source chain and figuring out which acknowledgements correspond to which mails (I’m assuming the acknowledgements contain the address of the mail).

But I might be wrong, maybe in the future it will be supported.

#8

querying all your source chain and figuring out which acknowledgements correspond to which mails

I’d do that as a workaround but not as the preferred solution as it is quite CPU intensive and bug prone since you need to write more code than just using the link feature.