I noticed in your log that it tries to create the system manifest, that’s what it would do when none exists. It would seem that the second instance is not using the same workspace key. But, when I ran this - manually - I had the exact same result as you did! So, I entered --wsp-key manually. Did you as well?
After that I ran with the default workspace (i.e. derived from the evm-key) and then it worked fine, joined, detected by first instance at the other device etc.
But the automated scenarios always use the custom wsp key, so it’s not that.
I think I remember seeing this cost insufficient peers error when trying to create an existing scratchpad… very odd error msg in that case. Well, I should try that and confirm it.
But it would make sense in so far that you and I have probably used the same wsp key in our second instances, so for some reason they did not consider the workspace as existing, i.e. the scratchpad_check_existence query returned false.. I haven’t seen that yet.
Confirmed now that I did use the exact same wsp key.
I tried starting the second instance of first workspace again, and since there is no re-entering of credentials (starting only requires a pwd and instance id) it is the exact same key etc that is used as the first time. And now it worked. It correctly detected the workspace, joined it, and first instance at the other device saw it joining.
Have you tried just doing “.\ryyn_daemon.exe [id]” again?
To me, this looks like the exists check returned false, and it tried to create a scratchpad that already existed.