Create tutorial for agent-agent interactions #515

tegefaulkes · 2023-03-20T01:24:47Z

Specification

With Mercury's interest in Polykey, we need to create a guide for how to use Polykey to ultimately pull or clone a vault. During this process we should asses usability of the process. We can also test functionality of agent-agent interaction across networks.

All testing of these features so far have been on the same loopback device. Ideally we can test this across machines on the same local network. As well as machines between networks. I don't foresee these cases not working but it's good to be sure.

But for the tutorial, we need to show the following examples.

Starting 2 agents with static ports.
Adding an agent's connection information to one of the agents to seed the nodeGraph.
Having the nodes ping each other.
Having the nodes trust each other.
setting up a vault on one of the nodes.
Cloning a vault from the other node
pulling changes from a vault

Stretch goals

Setting up a private root node for forming a network
Having nodes discover each other within the private network
Explaining the limitations of said network. For example, the network is ad-hoc and not strict. In terms of discover-ability, two networks will implicitly join together if they share any node connections.

Additional context

Tasks

Create a blog style tutorial detailing how to use Polykey in agent-agent interactions.
Test that the examples work. Even better if we can verify local network communication and separate network communication
Detail how a private ad-hoc network can still form with discovery even if nat-busting doesn't fully function currently. This is detailed by the stretch goals.

The text was updated successfully, but these errors were encountered:

tegefaulkes · 2023-03-20T06:00:45Z

I was commenting about this on Issue #514. This is my mistake, i'll move the comments here.

tegefaulkes · 2023-03-20T06:01:04Z

nodes ping can be used to ping a node if you provide the NodeId. This requires the node to already be within the node graph.

I'd expect a feature where you can specify the NodeId, host and port that you want to ping. This is useful in two ways.

You can verify that a host and port is in fact the node you expected.
You can check for nodes before adding them to the node graph. Pinging a node this way would add the node to the node graph. This can be a shortcut for adding nodes and checking they're online at the same time.

tegefaulkes · 2023-03-20T06:01:35Z

There seems to be a bug with the nodes getall command. I'll have to check it out later.

[nix-shell:~/matixWorkspace/gitRepos/Polykey]$ npm run polykey -- nodes getall --node-path tmp/nodeA

> polykey@1.0.1-alpha.0 polykey
> ts-node src/bin/polykey.ts "nodes" "getall" "--node-path" "tmp/nodeA"

ErrorPolykeyRemote: Remote error from RPC call - Cannot read properties of undefined (reading 'host')
  cause: TypeError: Cannot read properties of undefined (reading 'host')

tegefaulkes · 2023-03-20T06:01:50Z

I've written a first blush of the guide. I'll comment it here in parts.

tegefaulkes · 2023-03-20T06:02:09Z

Setting up nodes

For two agents to communicate with each other we need two agents to be running. For this example we're going to run two Polykey nodes on the same machine and have them communicate over the loop-back device.

First we want to start the first node. Since we are going to run two nodes on the same machine, we need to keep them separate. For this we need to override the node-path to a directory we want the Polykey node to be created in. for this example we're going to use a temp directory tmp. We're also going to set a static port value for the proxy.

Run the following command

npm run polykey -- agent start --node-path tmp/nodeA --proxy-port 55551

If this is the first time creating the node you should be prompted for the password twice. After that some information about the node should be printed.

✔ Enter new password … ********  
✔ Confirm new password … ********  
pid     476567  
nodeId  "vfjqk9v06k6p1tnuc4444irt0krasjmi1btmmf7ptaqg477em9390"  
clientHost      "127.0.0.1"  
clientPort      50617  
agentHost       "127.0.0.1"  
agentPort       35629  
proxyHost       "0.0.0.0"  
proxyPort       55551  
forwardHost     "127.0.0.1"  
forwardPort     38331  
recoveryCode    "drill video walnut message stone exhibit render snack comic maze deposit decline bless unit crater correct stool remain legend problem egg lecture approve normal"

Note the NodeId here as vvrijg034ie10dnn05mv0b2lfo1g7nhv6kb63c03lh7qcc4eqo79g. This will differ for your node.

Now create a 2nd node using the same method, this time with the node-path of tmp/nodeB and port 55552. You should see the same password prompt and status read-out. For our example the 2nd node has a NodeId of vd2nmd13qqj718ivke8n8si6cgdsd6ufgche84moofr2fhh9vj2jg.

tegefaulkes · 2023-03-20T06:02:36Z

Connecting and trusting nodes

Normally when a Polykey node is started, the first thing it does is automatically contact a seed node to join the network. In the absence of seed nodes to act as an entry point for a network. We we can tell a node how to find other nodes directly.

First we need to tell NodeA how to contact NodeB. For this we need to know the NodeId, host and port of NodeB. If we read the status output of NodeB when we started it up, we can see the following information.

nodeId  "vvrijg034ie10dnn05mv0b2lfo1g7nhv6kb63c03lh7qcc4eqo79g" 
...
proxyHost       "0.0.0.0"  
proxyPort       55551

Using this we give NodeA NodeB's information using the following command.

npm run polykey -- nodes add --node-path tmp/nodeA vd2nmd13qqj718ivke8n8si6cgdsd6ufgche84moofr2fhh9vj2jg 127.0.0.1 55552

This will add the NodeB's connection information into NodeA's node graph. Now whenever we refer to NodeB via it's NodeId of vd2nmd13qqj718ivke8n8si6cgdsd6ufgche84moofr2fhh9vj2jg, NodeA will know where to connect to. Note that this step is only needed because both nodes do not share a network. If they did share a network then they could query nodes within the network to find each other.

To verify if this information is correct and a connection can be made, we can ping NodeB using the following command.

npm run polykey -- nodes ping --node-path tmp/nodeA vd2nmd13qqj718ivke8n8si6cgdsd6ufgche84moofr2fhh9vj2jg

If a connection can be made then you should get Node is Active. as the response. Otherwise you will get No response received.

When a connection is made between two nodes then they learn about each other. So when NodeA pinged NodeB, NodeB learned how to connect to NodeA. You can verify this by pinging NodeA from NodeB.

npm run polykey -- nodes ping --node-path tmp/nodeB vfjqk9v06k6p1tnuc4444irt0krasjmi1btmmf7ptaqg477em9390

Node is Active.

Now if NodeA wants to do anything more complex than pinging NodeB, we need to make NodeB trust NodeA. We can do this with the trust command. This will allow NodeB to receive notifications from NodeA, otherwise NodeB will just ignore them.

npm run polykey -- identities trust --node-path tmp/nodeB vfjqk9v06k6p1tnuc4444irt0krasjmi1btmmf7ptaqg477em9390

We should also have NodeA trust NodeB.

npm run polykey -- identities trust --node-path tmp/nodeB vd2nmd13qqj718ivke8n8si6cgdsd6ufgche84moofr2fhh9vj2jg

tegefaulkes · 2023-03-20T06:03:04Z

Sharing vaults

Creating a Vault

A core feature of Polykey is sharing secrets between nodes. This is done by sharing the vaults that contain the secrets. In order to do this we need a vault to share. Start by creating a vault on NodeB. We can do this with the vaults create command, doing so will return a unique VaultId to identify that vault.

npm run polykey -- vaults create --node-path tmp/nodeB someVault

Vault zRMeFutQmJErPNR5rAE1LmN created successfully

Vaults and generally be referenced by it's name, here it's someVault. Or it's VaultId, here as zRMeFutQmJErPNR5rAE1LmN. An empty vault Is not very useful so let's add some data to it.

echo "this is a secret" > tmp/someSecret

npm run polykey -- secrets create --node-path tmp/nodeB tmp/someSecret someVault:someSecret

We should be able to see the secret in the vault now.

npm run polykey -- secrets list --node-path tmp/nodeB someVault

someSecret

Sharing a Vault

The next step is allowing NodeA to clone a vault from NodeB. This is done with the vaults share command. This will give NodeA permission to clone and pull this vault and send a notification to NodeA.

npm run polykey -- vaults share --node-path tmp/nodeB someVault vfjqk9v06k6p1tnuc4444irt0krasjmi1btmmf7ptaqg477em9390

NodeA should be able to clone the vault now. This is done with the vaults clone command.

npm run polykey -- vaults clone --node-path tmp/nodeA someVault vd2nmd13qqj718ivke8n8si6cgdsd6ufgche84moofr2fhh9vj2jg

If this completed with no errors, we should be able to see the vault in NodeA now.

npm run polykey -- vaults list --node-path tmp/nodeA

someVault:              zEsnWCGvgBqSuuu8r2SscSQ

We can access the secret as well.

npm run polykey -- secrets list --node-path tmp/nodeA someVault

someSecret

npm run polykey -- secrets get --node-path tmp/nodeA someVault:someSecret

this is a secret

Pulling vault changes

Vaults can be updated. If we wanted these changes then we can pull the vault. If a vault was cloned from another node then it keeps track of where it came from. So pulling a vault is pretty simple.

First we need to add a new secret to NodeB's vault.

npm run polykey -- secrets create --node-path tmp/nodeB tmp/newSecret someVault:newSecret

npm run polykey -- secrets list --node-path tmp/nodeB someVault

newSecret  
someSecret

Now we can tell NodeA to pull the changes from NodeB with Vaults pull.

npm run polykey -- vaults pull --node-path tmp/nodeA someVault

And see the changes

npm run polykey -- secrets list --node-path tmp/nodeA someVault

newSecret  
someSecret

npm run polykey -- secrets get --node-path tmp/nodeA someVault:newSecret

This is a new secret

CMCDragonkai · 2023-03-20T07:19:50Z

This is all on the RPC migration branch right? So we just have to finish review and get that merged.

tegefaulkes · 2023-03-20T23:24:08Z

Yep. I'll get client migration done today.

tegefaulkes · 2023-03-24T03:53:51Z

There may be a bug with cloning a vault and then immediately accessing it.

[nix-shell:~/matixWorkspace/gitRepos/Polykey]$ npm run polykey -- secrets list --node-path tmp/nodeA someVault

> polykey@1.0.1-alpha.0 polykey
> ts-node src/bin/polykey.ts "secrets" "list" "--node-path" "tmp/nodeA" "someVault"

ErrorPolykeyRemote: Remote error from RPC call - Cannot read properties of undefined (reading 'isLocked')
  command       vaultsSecretsList
  nodeId        v0000000000000000000000000000000000000000000000000000
  host
  port  0
  timestamp     Fri Mar 24 2023 14:50:04 GMT+1100 (Australian Eastern Daylight Time)
  cause: TypeError: Cannot read properties of undefined (reading 'isLocked')

Otherwise, just restarting the agent and trying the command again works.

I'll look into the problem.

CMCDragonkai · 2023-03-24T04:02:04Z

Is this a regression?

CMCDragonkai · 2023-03-24T04:02:26Z

Regression caused by RPC migration?

tegefaulkes · 2023-03-24T04:03:22Z

I don't think so, The error is coming from inside the handler. I won't know for sure until I dive into it.

tegefaulkes · 2023-03-24T04:40:38Z

The error is coming from the js-async-init CreateDestroyStartStop.ts @ready decorator

TypeError: Cannot read properties of undefined (reading 'isLocked')
    at VaultInternal.readF (/home/faulkes/matixWorkspace/gitRepos/Polykey/node_modules/@matrixai/async-init/src/CreateDestroyStartStop.ts:189:30)
    at Object.listSecrets (/home/faulkes/matixWorkspace/gitRepos/Polykey/src/vaults/VaultOps.ts:254:22)
    at f (/home/faulkes/matixWorkspace/gitRepos/Polykey/src/client/handlers/vaultsSecretsList.ts:37:39)
    at /home/faulkes/matixWorkspace/gitRepos/Polykey/src/vaults/VaultManager.ts:1012:14
    at async withF (/home/faulkes/matixWorkspace/gitRepos/Polykey/node_modules/@matrixai/resources/src/utils.ts:24:12)
    at async constructor_.withVaults (/home/faulkes/matixWorkspace/gitRepos/Polykey/src/vaults/VaultManager.ts:1005:12)
    at async /home/faulkes/matixWorkspace/gitRepos/Polykey/src/client/handlers/vaultsSecretsList.ts:33:14
    at async withF (/home/faulkes/matixWorkspace/gitRepos/Polykey/node_modules/@matrixai/resources/src/utils.ts:24:12)
    at async VaultsSecretsListHandler.handle (/home/faulkes/matixWorkspace/gitRepos/Polykey/src/client/handlers/vaultsSecretsList.ts:22:21)
    at async wrapperDuplex (/home/faulkes/matixWorkspace/gitRepos/Polykey/src/rpc/RPCServer.ts:324:9)

It's pretty odd. Even weirder that it only happens after cloning the vault and not after restarting the agent. It's likely due to the different methods of constructing the VaultInternal that is the root cause.

Cloning a vault constructs the VaultInternal with the cloneVaultInternal method. After restarting and accessing it, it would be constructed via the usual createVaultInternal method.

I'll compare the two to see if any differences in creation could be causing it.

tegefaulkes · 2023-03-24T05:20:52Z

Yeah, I don't know about this one. Reviewing how a vault is created when accessed vs cloned, even looking at how the VaultManager handles it. Noting leaps out at me that could be the cause.

I checked and there is a test where we clone and immediately access a vault. and it runs fine. So it's not something that was missed in testing.

Given the fact that the error is related to life-cycle decorators. It seems possible It could be another problem relating to SWC and decorators.

tegefaulkes · 2023-03-24T05:27:41Z

The bug does not happen when using the node dist/bin/polykey.js to run the agent. So it's a problem with using npm run polykey.

CMCDragonkai · 2023-03-24T05:29:18Z

When using ts-node it uses swc. Can you run check the compiled code difference between tsc and swc for the file in question? 24 Mar 2023 00:27:55 Brian Botha ***@***.***>:

…

The bug does not happen when using the *node dist/bin/polykey.js* to run the agent. So it's a problem with using *npm run polykey*. — Reply to this email directly, view it on GitHub[#515 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AAE4OHOZUPIGGRMCXXCMORLW5UWFRANCNFSM6AAAAAAWAOX5PI]. You are receiving this because you commented.[Tracking image][https://github.com/notifications/beacon/AAE4OHM4F25PIFXQ4DE2M7TW5UWFRA5CNFSM6AAAAAAWAOX5PKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSYLGWJO.gif]

tegefaulkes · 2023-03-24T05:55:49Z

I'll have to investigate the differences between code compiled with SWC and TSC and possibly post an upstream issue.

For now the tutorial works fine if you use node dist/bin/polykey.js or restart the agent after cloning a vault.

CMCDragonkai · 2023-03-26T19:39:21Z

Hey @tegefaulkes you said that it's not a problem when using node dist/bin/polykey.ts.

Can you compile your guide in the above 3 comments into a single one that can be used on the staging branch without using ts-node. We can solve the ts-node issue in a different issue.

I just want this to be ready to send to Mercury.

In the previous demo, we created some diagrams @amydevs, where did we post these? I forgot and cannot find them, as well as the commands to be executed. I know that we eventually turn that into the demo CLI gif on the README.md, but I want something like that for this part of the interaction.

tegefaulkes · 2023-03-26T23:56:59Z

I can combine the guide in to a single comment and update it. Is there a better place to put it besides the comments here? It's pretty bulky already.

For now I'll put it in a comment with a details block.

CMCDragonkai · 2023-03-27T00:10:56Z

It should go into the wiki. @amydevs where did you put all the demo materials last time?

amydevs · 2023-03-27T00:14:05Z

@CMCDragonkai previous demo material was in this pr: #504

tegefaulkes · 2023-03-27T00:33:53Z

nodes agent interaction tutorial

This tutorial assumes that you are working in the Polykey project's directory and you have successfully built it using npm run build.

Setting up nodes

For two agents to communicate with each other we need two agents to be running. For this example we're going to run two Polykey nodes on the same machine and have them communicate over the loop-back device.

First we want to start the first node. Since we are going to run two nodes on the same machine, we need to keep them separate. For this we need to override the node-path to a directory we want the Polykey node to be created in. for this example we're going to use a temp directory tmp. We're also going to set a static port value for the proxy.

Run the following command

node dist/bin/polykey agent start --node-path tmp/nodeA --proxy-port 55551

If this is the first time creating the node you should be prompted for the password twice. After that some information about the node should be printed.

✔ Enter new password … ********  
✔ Confirm new password … ********  
pid     476567  
nodeId  "vfjqk9v06k6p1tnuc4444irt0krasjmi1btmmf7ptaqg477em9390"  
clientHost      "127.0.0.1"  
clientPort      50617  
agentHost       "127.0.0.1"  
agentPort       35629  
proxyHost       "0.0.0.0"  
proxyPort       55551  
forwardHost     "127.0.0.1"  
forwardPort     38331  
recoveryCode    "drill video walnut message stone exhibit render snack comic maze deposit decline bless unit crater correct stool remain legend problem egg lecture approve normal"

Note the NodeId here as vvrijg034ie10dnn05mv0b2lfo1g7nhv6kb63c03lh7qcc4eqo79g. This will differ for your node.

Now create a 2nd node using the same method, this time with the node-path of tmp/nodeB and port 55552. You should see the same password prompt and status read-out. For our example the 2nd node has a NodeId of vd2nmd13qqj718ivke8n8si6cgdsd6ufgche84moofr2fhh9vj2jg.

Connecting and trusting nodes

Normally when a Polykey node is started, the first thing it does is automatically contact a seed node to join the network. In the absence of seed nodes to act as an entry point for a network. We we can tell a node how to find other nodes directly.

First we need to tell NodeA how to contact NodeB. For this we need to know the NodeId, host and port of NodeB. If we read the status output of NodeB when we started it up, we can see the following information.

nodeId  "vvrijg034ie10dnn05mv0b2lfo1g7nhv6kb63c03lh7qcc4eqo79g" 
...
proxyHost       "0.0.0.0"  
proxyPort       55551

Using this we give NodeA NodeB's information using the following command.

node dist/bin/polykey nodes add --node-path tmp/nodeA vd2nmd13qqj718ivke8n8si6cgdsd6ufgche84moofr2fhh9vj2jg 127.0.0.1 55552

This will add the NodeB's connection information into NodeA's node graph. Now whenever we refer to NodeB via it's NodeId of vd2nmd13qqj718ivke8n8si6cgdsd6ufgche84moofr2fhh9vj2jg, NodeA will know where to connect to. Note that this step is only needed because both nodes do not share a network. If they did share a network then they could query nodes within the network to find each other.

To verify if this information is correct and a connection can be made, we can ping NodeB using the following command.

node dist/bin/polykey nodes ping --node-path tmp/nodeA vd2nmd13qqj718ivke8n8si6cgdsd6ufgche84moofr2fhh9vj2jg

If a connection can be made then you should get Node is Active. as the response. Otherwise you will get No response received.

When a connection is made between two nodes then they learn about each other. So when NodeA pinged NodeB, NodeB learned how to connect to NodeA. You can verify this by pinging NodeA from NodeB.

node dist/bin/polykey nodes ping --node-path tmp/nodeB vfjqk9v06k6p1tnuc4444irt0krasjmi1btmmf7ptaqg477em9390

Node is Active.

Now if NodeA wants to do anything more complex than pinging NodeB, we need to make NodeB trust NodeA. We can do this with the trust command. This will allow NodeB to receive notifications from NodeA, otherwise NodeB will just ignore them.

node dist/bin/polykey identities trust --node-path tmp/nodeB vfjqk9v06k6p1tnuc4444irt0krasjmi1btmmf7ptaqg477em9390

We should also have NodeA trust NodeB.

node dist/bin/polykey identities trust --node-path tmp/nodeB vd2nmd13qqj718ivke8n8si6cgdsd6ufgche84moofr2fhh9vj2jg

Sharing vaults

Creating a Vault

A core feature of Polykey is sharing secrets between nodes. This is done by sharing the vaults that contain the secrets. In order to do this we need a vault to share. Start by creating a vault on NodeB. We can do this with the vaults create command, doing so will return a unique VaultId to identify that vault.

node dist/bin/polykey vaults create --node-path tmp/nodeB someVault

Vault zRMeFutQmJErPNR5rAE1LmN created successfully

Vaults and generally be referenced by it's name, here it's someVault. Or it's VaultId, here as zRMeFutQmJErPNR5rAE1LmN. An empty vault Is not very useful so let's add some data to it.

echo "this is a secret" > tmp/someSecret

node dist/bin/polykey secrets create --node-path tmp/nodeB tmp/someSecret someVault:someSecret

We should be able to see the secret in the vault now.

node dist/bin/polykey secrets list --node-path tmp/nodeB someVault

someSecret

Sharing a Vault

The next step is allowing NodeA to clone a vault from NodeB. This is done with the vaults share command. This will give NodeA permission to clone and pull this vault and send a notification to NodeA.

node dist/bin/polykey vaults share --node-path tmp/nodeB someVault vfjqk9v06k6p1tnuc4444irt0krasjmi1btmmf7ptaqg477em9390

NodeA should be able to clone the vault now. This is done with the vaults clone command.

node dist/bin/polykey vaults clone --node-path tmp/nodeA someVault vd2nmd13qqj718ivke8n8si6cgdsd6ufgche84moofr2fhh9vj2jg

If this completed with no errors, we should be able to see the vault in NodeA now.

node dist/bin/polykey vaults list --node-path tmp/nodeA

someVault:              zEsnWCGvgBqSuuu8r2SscSQ

We can access the secret as well.

node dist/bin/polykey secrets list --node-path tmp/nodeA someVault

someSecret

node dist/bin/polykey secrets get --node-path tmp/nodeA someVault:someSecret

this is a secret

Pulling vault changes

Vaults can be updated. If we wanted these changes then we can pull the vault. If a vault was cloned from another node then it keeps track of where it came from. So pulling a vault is pretty simple.

First we need to add a new secret to NodeB's vault.

node dist/bin/polykey secrets create --node-path tmp/nodeB tmp/newSecret someVault:newSecret

node dist/bin/polykey secrets list --node-path tmp/nodeB someVault

newSecret  
someSecret

Now we can tell NodeA to pull the changes from NodeB with Vaults pull.

node dist/bin/polykey vaults pull --node-path tmp/nodeA someVault

And see the changes

node dist/bin/polykey secrets list --node-path tmp/nodeA someVault

newSecret  
someSecret

node dist/bin/polykey secrets get --node-path tmp/nodeA someVault:newSecret

This is a new secret

tegefaulkes · 2023-03-27T00:34:22Z

@amydevs can you run through this and test it?

tegefaulkes · 2023-03-27T00:54:56Z

Created a PR for adding this to the docs at

MatrixAI/Polykey-Docs#19

CMCDragonkai · 2023-03-27T01:54:21Z

This is done. https://polykey.io/docs/tutorials/vault-sharing.

Closing this.

@tegefaulkes can you create a big issue for the problem of vault cloning in ts-node?

tegefaulkes · 2023-03-27T01:58:02Z

Sure thing.

tegefaulkes added the development Standard development label Mar 20, 2023

tegefaulkes self-assigned this Mar 20, 2023

CMCDragonkai mentioned this issue Mar 24, 2023

ci: merge staging to master #474

Merged

2 tasks

tegefaulkes mentioned this issue Mar 27, 2023

feat: adding vaults sharing and cloning tutorial MatrixAI/Polykey-Docs#19

Merged

8 tasks

CMCDragonkai closed this as completed Mar 27, 2023

tegefaulkes mentioned this issue Mar 27, 2023

Accessing Vault after cloning fails #518

Closed

CMCDragonkai added the r&d:polykey:core activity 3 Peer to Peer Federated Hierarchy label Jul 9, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Create tutorial for agent-agent interactions #515

Create tutorial for agent-agent interactions #515

tegefaulkes commented Mar 20, 2023 •

edited

Loading

tegefaulkes commented Mar 20, 2023 •

edited

Loading

tegefaulkes commented Mar 20, 2023

tegefaulkes commented Mar 20, 2023

tegefaulkes commented Mar 20, 2023

tegefaulkes commented Mar 20, 2023

tegefaulkes commented Mar 20, 2023

tegefaulkes commented Mar 20, 2023

CMCDragonkai commented Mar 20, 2023

tegefaulkes commented Mar 20, 2023

tegefaulkes commented Mar 24, 2023

CMCDragonkai commented Mar 24, 2023

CMCDragonkai commented Mar 24, 2023

tegefaulkes commented Mar 24, 2023

tegefaulkes commented Mar 24, 2023

tegefaulkes commented Mar 24, 2023

tegefaulkes commented Mar 24, 2023

CMCDragonkai commented Mar 24, 2023 via email

tegefaulkes commented Mar 24, 2023

CMCDragonkai commented Mar 26, 2023

tegefaulkes commented Mar 26, 2023

CMCDragonkai commented Mar 27, 2023

amydevs commented Mar 27, 2023

tegefaulkes commented Mar 27, 2023

tegefaulkes commented Mar 27, 2023

tegefaulkes commented Mar 27, 2023

CMCDragonkai commented Mar 27, 2023

tegefaulkes commented Mar 27, 2023

Create tutorial for agent-agent interactions #515

Create tutorial for agent-agent interactions #515

Comments

tegefaulkes commented Mar 20, 2023 • edited Loading

Specification

Additional context

Tasks

tegefaulkes commented Mar 20, 2023 • edited Loading

tegefaulkes commented Mar 20, 2023

tegefaulkes commented Mar 20, 2023

tegefaulkes commented Mar 20, 2023

tegefaulkes commented Mar 20, 2023

Setting up nodes

tegefaulkes commented Mar 20, 2023

Connecting and trusting nodes

tegefaulkes commented Mar 20, 2023

Sharing vaults

Creating a Vault

Sharing a Vault

Pulling vault changes

CMCDragonkai commented Mar 20, 2023

tegefaulkes commented Mar 20, 2023

tegefaulkes commented Mar 24, 2023

CMCDragonkai commented Mar 24, 2023

CMCDragonkai commented Mar 24, 2023

tegefaulkes commented Mar 24, 2023

tegefaulkes commented Mar 24, 2023

tegefaulkes commented Mar 24, 2023

tegefaulkes commented Mar 24, 2023

CMCDragonkai commented Mar 24, 2023 via email

tegefaulkes commented Mar 24, 2023

CMCDragonkai commented Mar 26, 2023

tegefaulkes commented Mar 26, 2023

CMCDragonkai commented Mar 27, 2023

amydevs commented Mar 27, 2023

tegefaulkes commented Mar 27, 2023

nodes agent interaction tutorial

Setting up nodes

Connecting and trusting nodes

Sharing vaults

Creating a Vault

Sharing a Vault

Pulling vault changes

tegefaulkes commented Mar 27, 2023

tegefaulkes commented Mar 27, 2023

CMCDragonkai commented Mar 27, 2023

tegefaulkes commented Mar 27, 2023

tegefaulkes commented Mar 20, 2023 •

edited

Loading

tegefaulkes commented Mar 20, 2023 •

edited

Loading