[Status: offline] SAFE Network Testnet - Vaults from home with IGD - Iteration 2

I also noticed that some chunks were fully readable. Which at first did my head in. Then I remembered that public data is not encrypted. (I believe that’s the case)
So it seems the file types of chunks that are not encrypted are somehow still recognized.

That is my take on it, if I am wrong I’d gladly be corrected.

1 Like

I thought everything was encrypted but public data everyone can access the data map. I’d prefer that so even if something nasty that was public was on a hard drive no one would be the wiser. Kind of becomes a slippery slope otherwise imo.


Agreed, I’m totally out of my depth here so I am just guessing. I could see bits of Javascript/HTML that were legible, parts of files… chunks.
Not parts of images or anything like that.
I vaguely remember this discussion in the past so don’t quote me but may have to do with performance.

I’ll post a screenshot in a minute.


I think chunk obfuscation is important foundation of maidsafe. why it is not implemented yet? Its published back in 2010 by @dirvine it may overkill? https://www.google.com/url?sa=t&source=web&rct=j&url=http://docs.maidsafe.net/Whitepapers/pdf/SelfEncryptingData.pdf&ved=2ahUKEwigw4i64tXqAhUNa94KHWNaAV0QFjABegQIBBAB&usg=AOvVaw3WWO3kP0PcIA39SusH6WJx


I believe data obfuscation is on the roadmap at safenetwork.tech in future work AFAIK.

1 Like

Not sure if CRDT change something but the idea is that all data greater than 3 KB. will be chunks where self-encryption could be applied regardless which data type they belong to.

The earliest time of implementation would be post-Fleming


There is something fishy about the “router problem”. I always use the same phone for tethering. Sometimes it works - sometimes I get this:

sascha@Knut-Mint:~$ tail -f ~/.safe/vault/local-vault/safe_vault.log
INFO 2020-07-18T11:17:20.667798070+03:00 [src/bin/safe_vault.rs:114] 

Running safe-vault v0.25.1
INFO 2020-07-18T11:17:30.892900120+03:00 [src/vault.rs:135] Initializing new Vault as Infant
ERROR 2020-07-18T11:18:00.893737680+03:00 [src/bin/safe_vault.rs:169] Cannot start vault due to error: Routing(Network(IgdNotSupported))
ERROR 2020-07-18T11:18:00.893765515+03:00 [src/bin/safe_vault.rs:170] Automatic Port forwarding Failed. Check if UPnP is enabled in your router's settings and try again. Note that not all routers are supported in this testnet. Visit https://safenetforum.org for more information.

thanks digipl it explained a lot.

1 Like

It may be the igd crate has a short timeout. We will check that out @ravinderjangra and @lionel.faber are looking for bugs like this to kill off.


IIRC, it was when the content was public and small enough to fit in a single file with the data map, so it doesn’t get broken up and self encrypted. My memory may be deceiving me though.

It seems a bit of a weakness though.


Yes, I think if it’s under 3KB it doesn’t currently get encrypted. I remember adding a bunch of zeros to an HTML file and experimenting with that, way back when.


The idea being a tiny file would be in a dir, the dir is encrypted as a file and that puts it over the 3Kb so it is unwrapped recursively. i.e. you should never have small file datamaps out somewhere on their own, if part of a filesystem it’s cool. The root dir will always be over 3Kb IIRC.

If there is no choice then the data map itself should be encrypted, but I don’t know where we would need to do this as files are for now part of filesystems. It would be a simple thing to encrypt them though with the users keys if necessary.


That brings up an interesting situation.

I have come across a number of situations where a directory full of small files (like 1KB to 5KB, mostly 1KB to 2KB) and its painfully enough that windows keeps getting slower with each version to just display the file list or work with it. Sometimes thousands of files.

Now if these files are then in the directory file, then that makes for a one large directory file. And what about working with the directory.

Just a thought

1 Like

In these cases the DM should be recursively encrypted to produce a small initial DM.


For those interested in running local testnets, there’s a new browser alpha release available: https://github.com/maidsafe/safe-browser/releases/tag/v0.18.0-alpha.4

Remember, it’s still alpha and may be buggy, so if you’re not comfortable with investigating/reporting bugs this may not be for you! (But if you are, :fire:in :smiley: !)


Noting that the browser already seems to be auto-updating to .5

I’ve yet to understand github for submitting the simplest fixes… so, the text on the abc suggests --test flag
should be --testing


Run a local network for testing: --test

The run-baby-fleming command accepts a --test or -t

Happy now, I have a local network running. :smiley:

The vault seems just to complain about authentication timeouts at the start, which is unfortunate because truly it’s working.
I wonder it could do with declare success initially, to help the user ignore these kinds of output errors:

Setting up authenticator against local SAFE network...
[2020-07-21T19:43:14Z ERROR safe] safe-cli error: [Error] AuthdClientError - Failed to execute authd from '/home/safe/.safe/authd/safe-authd': No such file or directory (os error 2)
Creating a SafeKey with test-coins...
Sending account creation request to authd...
Sending login action request to authd...
[2020-07-21T19:45:19Z ERROR safe] safe-cli error: [Error] AuthdClientError - Failed to establish connection with authd: [Error] ClientError - Failed to establish connection with remote QUIC endpoint: timed out
[2020-07-21T19:45:24Z ERROR safe] safe-cli error: [Error] AuthdClientError - Failed to establish connection with authd: [Error] ClientError - Failed to establish connection with remote QUIC endpoint: timed out

Can you confirm the version of your authd with $ safe auth update? it should be v0.0.11 otherwise you will have issues connecting to it. Also make sure it’s up and running with $ safe auth status

Edit: actually I just saw the error you are getting is '/home/safe/.safe/authd/safe-authd': No such file or directory (os error 2), perhaps you need to install/re-install the authd with $ safe auth install


That was a clean install following the abc that has the install vault ahead of the install auth… but yes auth is v0.0.11

However, on a restart is doesn’t upload
and one more frequent glitch looks to be that it’s not setting balance.

eg: below “Account was created successfully!” but then “No SafeKey found at specified location”… so, I don’t know if that’s important for test network… kind of surprised it was doing that and not waiting for the user just to create an account… but even if I create account, login etc it’s not actioning an upload. I’ll keep at it in case it becomes clearer.

$ safe vault run-baby-fleming -t
Creating '/home/safe/.safe/vault/baby-fleming-vaults' folder
Storing vaults' generated data at /home/safe/.safe/vault/baby-fleming-vaults
Launching local SAFE network...
Launching with vault executable from: /home/safe/.safe/vault/safe_vault
Network size: 8 vaults
Launching genesis vault (#1)...
Genesis vault contact info: [""]
Launching vault #2...
Launching vault #3...
Launching vault #4...
Launching vault #5...
Launching vault #6...
Launching vault #7...
Launching vault #8...
Setting up authenticator against local SAFE network...
Stopping SAFE Authenticator daemon (safe-authd)...
No running safe-authd process (with PID 6662) was found
Starting SAFE Authenticator daemon (safe-authd)...
safe-authd started (PID: 6925)
Creating a SafeKey with test-coins...
Sending account creation request to authd...
Account was created successfully!
SafeKey created and preloaded with test-coins. Owner key pair generated:
Public Key = 832e56f78aee8e0afe1c67a888d6a348b4bed14287df94ef843837b1780240bd7368f24696681ae0c0b759d86ed297f2
Secret Key = e1429cdb40ea65f8ff290cb51ff5a3f850c090810a8d91e2d89f814a66cf3c47
Sending login action request to authd...
Logged in successfully
Authorising CLI application...
Waiting for authorising response from authd...
[2020-07-21T20:23:09Z ERROR safe] safe-cli error: Application authorisation failed: [Error] AuthdError - [Error] AuthenticatorError - Failed to authorise application on the network: Core error: Data error -> Balance does not exist

$ safe keys balance
Enter secret key corresponding to the SafeKey to query the balance from: e1429cdb40ea65f8ff290cb51ff5a3f850c090810a8d91e2d89f814a66cf3c47
[2020-07-21T20:30:15Z ERROR safe] safe-cli error: [Error] ContentNotFound - No SafeKey found at specified location
$ safe vault killall
Success, all processes instances of safe_vault were stopped!
$ safe auth stop
Stopping SAFE Authenticator daemon (safe-authd)...
Success, safe-authd (PID: 6925) stopped!

Right, cool, you are now getting authd working properly there and creating the account correctly. Those other errors are semething different now, which could be what we experience in our CI sometimes and which we still didn’t get to the bottom of. I assume you are running latest vault binary right? Perhaps you can give it a try by first removing the /home/safe/.safe/vault/baby-fleming-vaults folder? I think there was an issue with accounts not being found after the local network is restarted.


yes, I deleted those vault folders, looking for a fresh restart (for no good reason than OCD) and then tried a few times because it wasn’t just working to upload… tail -F on the vault logs shows activity and it acknowledged requests for balance on keys but the upload doesn’t seem to action… and wondering atm if it is on the occasions that there is not balance…but then I’ve also created an account and auth subscribe logged in etc… so, not obvious cause for not doing the safe files put --recursive. works now on the back of initial balance error; so, my experience is 1/5 times it works and I can’t see the difference atm but keeping this instance as it works.