[Offline] Update 08 December, 2022: A wild testnet appears!

It’s testnet time! Yes folks - it’s time to dust off those terminals and fire up those clients once again, testnets are back in town. We don’t expect this one to be perfect and there are a few issues we’re working through with client-elder communications, but we’d really appreciate your help with testing a few things including data retention, and timeouts. To avoid complications, we have removed section split functionality for now, so we’ll be testing one big section. @joshuef explains more below.

General progress

The whole team has been working on getting the testnet up and running in the past week, but of course other work continues in the background.

@bochaco has been digging into a client connection/reconnection issue where messages seem to be getting dropped. It may be a quinn/qp2p issue, but further digging is required. Hopefully this will be fixed for the next testnet.

Meanwhile, @roland has been working on the implementation of the SectionTree, the record of all section keys back to genesis that proves users are on the right network.

The implementation of the ABBA consensus protocol is also going ahead, with Mostafa and @davidrusu making some final tweaks. Once implemented, the next step will be to integrate VCBC with ABBA to arrive at the full MVBA (Multi-Value Byzantine Agreement) consensus protocol.

@oetyng has been tidying up a few operations, including how we report storage at adults (a PR which also paves the way for avoiding nodes ever becoming full), and @chriso is looking into forwarding node logs for ELK, the main observability stack we use to monitor what’s happening at node level.

A new testnet

As we mentioned in the last update, we’ve been down in the trenches for a while, but are now starting to look at things holistically once more. And we want to do that involving the community as much as possible.

So we’ve got a 25 node testnet up. Each node has 50GB of space. We’re aiming to:

  1. Ensure that we’re not losing data until nodes are full. (We’re working on how to deal with full nodes). Until then, our current tests have shown data sticking around quite happily as long as we’re not filling up nodes. (So full nodes will herald the end of this run).
  2. Have no nodes join. We’ve limited this in the nodes themselves to remove one testnet variable. (We’re also aware - and have a pending fix for - some AE issues post-split, so don’t want to dive in there just now).
  3. Get a better handle on certain timeouts. Elder->Adult bi-directional comms timeout after 7s just now. Client->Elder in 45s. We want to see how relevant those values are under load.

Getting involved

As noted above, we’re not looking to check out node joins just now, as we have a blocker post-split that we need to test more before we can get the fix in.

As such, it’s only safe client and PUT/GET data that we’ll be checking out. We’re asking folk not to upload more than 10mb at a time to see how things go there.

Sadly we’ve not full-release as yet. (We’re changing up our test flow to check all PRs going into main on their own testnet now; once that’s in, releases from main should be much smoother). So we’ve manually created one and uploaded safe binaries here:

Note: macOS will not run the binary because it can’t verify the developer. To circumvent this, run xattr -d com.apple.quarantine ./safe. Then make sure it can be executed with chmod +x ./safe . Then the CLI can be run with ./safe.

To get involved:

  • remove ~/.safe
  • download your relevant safe bin from the release and store in /usr/local/bin on mac/linux or %USERPROFILE%.\safe\cli in windows.
    • Note for Windows users - you may wish to add the bin directory above to PATH, alternatively you can use ./safe when run from the directory for all proceeding safe cmds.
  • run safe --version to make sure you’re on the correct version (0.67.0 of the CLI).
  • run safe networks add wild-testnet https://sn-node.s3.eu-west-2.amazonaws.com/testnet_tool/main/network-contacts
  • safe networks switch wild-testnet

And you should be good to go :tada: :beers:

Example: Upload a file

The simplest thing we can do is upload a file using the files put command:

$ safe files put ./to-upload/file1.txt
FilesContainer created at: "safe://hyryyryynamznbfsgn7ccfquqmx6y8yzhq6tn7uzz775hrkyj4g8ipcy3ke6yeuy?v=h9jxxwwpy1cwf3pnb86ahkfk5ju8eb3miegnuehc99f5r5x83d9go"
+  ./to-upload/file1.txt  safe://hy8oycyyb7jfqswhktzn9ahhk1hnz53dhfnrfp6h34emgrmjzggro75eikpoy

This will create a container with a single file. The safe:// URLs assigned here refer to the container and the file, respectively. This means the file is addressable using either safe://hyryyryynamznbfsgn7ccfquqmx6y8yzhq6tn7uzz775hrkyj4g8ipcy3ke6yeuy/file1.txt or its direct URL.

Read more about how to upload files, in the CLI docs.

What’s helpful and reporting issues

Right now, keep uploads small. < 10MiB / file.
There is a temporary limit added, and you will get an error if surpassing 10MiB. The error is not informative currently, but you will know by the size that it’s due to surpassing this temporary file size limit.

You may well see issues around Cmd Ack Validation timeout, (our timeouts need to be dialled in better, see above), this means the network is probably under load, so have another go in a few minutes. Your data may well have been stored, just not as fast as we expect right now.

If you are consistently seeing issues PUTting data, or retrieving data you have PUT. Please run your command with RUST_LOG=sn_client prefixed to it (on Ubuntu/Mac at least). The output there, and MsgIds that have been sent/failed will be key to debugging.

We’ll try to report back stored data sizes at nodes as we go, so we can see if there’s a correlation between capacity and reliability.

The network is up on the back of a slightly less reliable (client-connectivity-wise) testnet that we’ve had up all week. Data retention has been fine there, so :crossed_fingers: hopefully that will continue here (or a bug will be highlighted :muscle: )

Most of that’s junk test data, but there is a small set of jpgs uploaded at the following xorurls for anyone wanting to pull some data (e.g. safe cat safe://hygoygym7tsj5hhyyykd1aqpw3djxea6om6xku568ahm7hy7gfn6q5gy7xr > 1.jpg):

This is what we’re using to verify data-storage just now.


Useful Links

Feel free to reply below with links to translations of this dev update and moderators will add them here:

:russia: Russian ; :germany: German ; :spain: Spanish ; :france: French; :bulgaria: Bulgarian

As an open source project, we’re always looking for feedback, comments and community contributions - so don’t be shy, join in and let’s create the Safe Network together!




Thx Maidsafe devs :exploding_head:


No decentralization.

With almost no load.

Will it fail?


One thing at a time :slight_smile:

Well, isn’t that the question of all testnets?

You can see the listed aims of this testnet.

If we can do this, then it will not have failed.


(I’m writing first, and only then thinking)
Better question: how many limits needs to be added to stop network from failing?


We will soon know. The idea here is a good one. Stop trying to test the whole thing and get a solid base (it will fill up and fail, don’t worry). Then release a little bit more. We have all the bits, and there have been bugs, so this way, we step forward a bit at a time. I would think you prefer this approach as it’s more logical and measurable.

yip 100% for this test we are centralised.


Of course, this approach is correct.
But at this point test subject is more like shadow of what it should be.


Now this is an early Christmas gift.


Thank you.

Got to go and dust off my safe box.


I download and open this, but nothing happen, its normal?


Right-click on the downloaded zip file, choose the folder where to extract it, then press OK.

We have suggested that you move the extracted safe binary to %USERPROFILE%.\safe\cli in windows.
So, check if you have the .safe dir, and add cli dir to it. Then you can move the safe binary there.

Then run it.

You do that by opening a cmd prompt, type in cd %USERPROFILE%.\safe\cli, and hit enter.

After that you can execute the example cmds found in the above OP, from that cmd prompt.


Working for me in Linux. Will switch to Windows now see how that goes.


Yaaay - testnet!!!

Why do I feel targetted by this line?
I’ll have youse know, I just spent 30 mins zipping up a bunch of old projects to form a 7.5Gb test file… - curses-

try this cock pic instead

FilesContainer created at: "safe://hyryyry1ct6mcfy5csjzuxeoa7bjkzqn4tuojxemhdocoybz9o784np9emhnra?v=hhmhtrmoa6sysu4mjuq99i6z1i16ydy54eyez3tit1j5nfjjwujey"
| + | /home/willie/cock01.jpg | safe://hygoygyqzr1t99g38e5orf6o6ts4cja8ck7wo1hnn1rqcte4b19shnpbqeh |

Great Christmas gift.
Thank you MaidSafe.


@aatonnomicc will be miffed - BegBlagetc is too big… but my cock isn’t. Now its me thats miffed…

willie@gagarin:~/.safe$ safe files put ~/BegBlaga.mp3 
FilesContainer created at: "safe://hyryyry1jakc43duyi51wqk59w3sn8m4fiaqpxkpum3h14xtkpfpcu6bo7cnra?v=hnrijhg7qx435iejzzjm1i5oc3qgw3s3b36ej9r7wwe8nmgxjnfey"
| E | /home/willie/BegBlaga.mp3 | <ClientError: Too large file upload attempted (15766382 bytes), at most 10485760 bytes allowed currently. Try storing a smaller file.> |

its works now but I am not succesfull with uploading a file

I should first create here this folder and put file into in and then run command?

$ give me error

And now my internet doesn’t work it can be caused by this work on testnet?



Don’t include the $ at the start of any of the instructions, that’s just to indicate that the instructions should be typed into cmd prompt :+1:

EDIT - also forgot to say re your internet issues - none of this should have any effect on your internet at all!


Note for macOS users - the instructions work for M1 macs, I don’t think it will for intel macs though