@dirvine Are the vaults on the network all the same, or do some of the Maidsafe droplets have special abilities?
What Iām driving at is, would a userās test network, consisting of the latest safe_vault software and a customized config file to get it talking, be capable of receiving registrations of the launcher and the full range of functions of the apps demo?
Haha, I was thinking the same thing. As a community we put some Satoshiās together and run 1 Droplet of our own to test and play and have fun. See how far we can get without the support of 200 Maidsafe nodes. Iām quite curious. Although I wouldnāt mind waiting some days to test TEST 3. This community is over excited I think .
Yes they are, for a seed node you want to set itās port in the config, so it starts on same port each time. The default is for nodes to listen on 5483 (live)
So add the ip of a droplet in your config file with port 5483 and give teh config to a few folks and your off. We will enable bootstrap cache again soon to make it simpler.
I downlaoded the vaults, launcher and demo app but Iām a bit confused as to the sequence to start them up and use them. Is the vault a prereq for the launcher or vice versa? I canāt seem to register an account on the network via the launcher and the vault keeps giving me errors.
Also isnāt the vault supposed to be an executable on linux? Itās not functioning as such on my distro. Iām on Fedora 21 here.
Listening to David the last few days there have been a few contributing factors that have enabled the engineers to iterate so quickly over what we could have expected 1 year ago:
Significantly simplified and smaller code base
Rust
Improved team
More collaborative and organised way of working - all day H/Os and daily catch ups
These versions are also useful to avoid accidental interconnections of compatible but separate networks. It is only a bullet point in a long list, so its importance can be missed but it allows:
The running of an independent local network without risk of interference with the global network
And, more importantly, the coexistence of several competing global networks
These versions are not just numbers. By looking into crust code, I can determine that one of these versions is given by NETWORK_VERSION environment variable at build time and could be any string. In my understanding this is the variable that must be defined to launch an independent network.
In theory we donāt need versions to manage several networks if seeds files are handled carefully, but errors happen easily and an interconnection between two independent networks could create damages to both of them. So this version control seems essential to me.
I wanted to say that I very much appreciate the way SAFE network is being built. Mainly from the aspect of goals and deadlines. As I understand the safe network will be ready and delivered to āliveā public use exactly when it is ready for that. Meaning that it will not be squeezed in or rushed to reach a launch data or something like that. I think that way too many projects fail because of lack of time and resources.
I watch and admire how safe network is being build!
Keep up the great work guys!
Whether or not people have to wait for the next official test, or are late to the party, all comes down to your config file, which isnāt hard to work out. I suggest that people publish customized config files here (or as part of a fork on Github) in order to create and continue their own SAFE nets. @dirvine said above that even a couple of nodes was enough to initialize a network.
This has been on my mind for 2 weeks, is this a non issue seeing as it was somewhat passed over except for one comment by seneca⦠it keeps bugging me.