For technical users wanting to experiment.
I do this when I’m trying things out manually now.
The example has a total of 6 “devices” (3 instances on two machines).
Used in the example:
- 2 machines
- An EVM key
- A workspace key (32 byte hex)
- A program folder, in the example
F:\programs\ryyn
– Workspace
In the example I call my workspace wsp-101, so that gives F:\programs\ryyn\wsp-101 as the dir where the devices on this machine will install.
Next workspace when I experiment could be e.g. wsp-102.
– IDs
The machines are m0 and m1, three instances each a0, a1 and a2.
Thus, the instance ids are m0a0, m0a1 … m1a1, m1a2.
– Base dir and install path
The base dir passed to cli is then F:\programs\ryyn\wsp-101\m0a2 etc.
Install path will thus be F:\Programs\ryyn\wsp-101\m0a2\ryyn under which that instance’s files will reside; app.lock, device_id, evm-key.enc, the data dir with dbs etc.
– Drives
Within every instance base dir I place a drive dir, e.g. F:\programs\ryyn\wsp-101\m0a2\drive. That’s where I will create and mount vaults for this specific instance. These are normally placed anywhere; your vaults are created from where your actual files are, and you mount vaults to where you want them replicated on your machine. But this placement structure keeps it cohesive and tidy for trying things out.
– Initiate and start
Each instance is initiated with the line you can see to the left. This registers the id in an index with port for comms with daemon, and stores the key(s) to file, encrypted with the password. Then in the terminal for the daemon the RYYN_PWD env var is set:
This allows for calling cli without having to include the pwd every time (it is used to decrypt the keys from file).
Then we can start the daemon in the terminal to the right; passing the corresponding id (m0a2 here). I do the same on both machines. You can see that the cmd info lists 6 devices.
(Masked in the screenshot:
evm-key and wsp-key. Not only the evm-key, but also the wsp-key bust be kept secret - the wsp-key gives access to all the files in the workspace.)
– Create vault
Create a folder on one of the “drives”, say my-vault, then call .\ryyn.exe m0a2 vault create F:\programs\ryyn\wsp-101\m0a2\drive\my-vault.
(The name/id shown there is a double hex encode of the hex prefixes, by mistake. No extra format of ids.)
And subsequently, other instances (here m1a0, i.e. on machine 1, and m0a0 on machine 0) discover the vault:
– Mount a vault
The other devices only registered the vault, they haven’t mounted it yet.
So, we mount it on say m1a1. We create say vault-at-m0a2 and call
.\ryyn.exe <id> vault mount <vault-prefix> <path\for\your\mount> [any-name]
i.e.:
.\ryyn.exe m1a1 vault mount C:\Users\Public\ryyn\wsp-101\m1a1\drive\vault-at-m0a2 0717d632 v-m0a2
The m1a1 instance receives the cmd and we can see the setup of the mount specific components:
And m0a2 sees it a couple of seconds after the system manifest was updated:
And the instances can see this updated info:
(the application is not filling in all details yet, like the number of mounts of a vault)
– Sync files
Now that we have 2 mounts to a vault, we can try syncing files.
Drag and drop a file to one of the drive folders. See the activity in the daemon terminals.
m1a1, that mounted the vault created by m0a2, adds a file to the mount:
(by green rectangle you can see that there was some substantial delay in processing - some delays can be seen, but this was unusually long)
On m0a2 we pull the first event promptly:
Then, after the unexpected delay (the green rectangle) at m1m1, m0a2 pulls the event with the file version manifest (addresss of all chunks etc), decrypts and assembles the chunks to a local file:
Well, as for basic functionality, that’s pretty much it.