Yep, you can already get around this via using the POC beaker browser. Only thing with that is that you’ll need to manually build it for now.
But then you can browse safe: sites without a proxy! (I have removed mine entirely).
Though right now you’ll need to convert links to safe:// and drop the .safenet on the end of them. A small inconvenience until we get the majority of people browsing through a SAFE browser!
I don’t know how many vaults were in this test initially but wonder if churn would naturally drop off faster than the number of vaults added… so, with twice as many vaults, would there be substantially less churn? If there was a minimum standard for a vault, then doubling the number of those; or halving them, might give a sense of where the limit for balance between churn and vaults# lies.
Certainly my impression is that performance drops, if I’m running a local vault… that’s a reasonable home connection but perhaps is then not large enough bandwidth to be backbone vault. Seeing others running vault on Android, I wonder cannot help and perhaps some limit is needed that sees weak nodes stall… or just tick over with an indicator that bandwidth is not sufficient to be useful.
We found a couple of issues (this is what tests are for). It seems that the routing refactor (which is ongoing) has probably caused this issue. What we have seen is requests with no reply, which points to routing or at least the network. We will now confirm this specifically. To resolve that, what we will do immediately is
1: We will stop this current TEST7 network for now.
2: Backport routing to latest stable + a few cherry picked fixes.
3. Randomise the bootstraping of clients. They were ddosing the seed nodes, basically as all nodes were bootstrapping from only the first few nodes, which was a bug.
So we will keep all the client code as is (it will need recompiled with crust/routing though) and continue to test the client code (safe_core/launcher/demo_app). I am happy about that as those guys worked through the night for this test to happen. They deserved their sleep.
So we will restart this network as TEST7b and not give out vaults initially. This will allow the test of all the new client code to continue. We will then issue vaults after a short time to just check this was a routing issue (With lots of smaller nodes).
As this happens it lets the team, who are mostly working in routing refactor to continue and get that completed and allow us to get the routing table changes and data chains in place much sooner. This is something we do not want to push back.
Life in the fast lane at the bleeding edge Seriously though we said we will roll out as fast and often as possible and we will continue to. It’s critical to success.
Thanks again folks , hopefully you will get the clients back today.
From routing’s side, we’ll probably stick to the 0.23 branch for the test networks and the first alpha networks: The code is very much in flux due to the reorganisation and it doesn’t make a lot of sense to use it for live networks like this. Instead, we plan to finish the refactoring (almost done), implement RFCs 30 and 37 and possibly even data chains, then doing some smoke testing on droplets and only then update the vaults binaries that we use for live networks.
In the meantime, testing will focus on the frontend and any newly identified routing issues will be backported to routing 0.23.
Okay I created a new account and tried uploading the whole website folder, which resulted in a timeout (my traditional Blindsite Quote page which has always worked before). So I get a partial upload, which is the folders got created and the index html got uploaded. So I’m manually uploading the remaining files 1 by 1 because a) Puts are not refunded after a delete. and 2) I’ve had glitches in the past when trying to delete and reupload. So the first 2 pics upload fine but the third keeps giving me a timeout when uploading. I know it’s not the pic. Remember I know all these files upload fine as I’ve uploaded the whole site before under the 25mb limit. Actually I think it even worked under the 5mb limit. So I think repeated timeouts at 99% would be a client/network issue somewhere.
And in case you’re wondering my launcher reports I’m at 23/500 PUTS.
Update: I just got another error and reloaded my public data folder. Apparantly what little I did manage to upload has all gone poof. It’s not there anymore. Data loss.
Update 2: Now I can’t even reupload because of an error whining about “No such data.” What do you mean no such data! It’s on my computer for you to upload. And my public files folder is apparantly empty. How can there be “no such data.” Arg!
Anyone still remember TEST 2? It ran for 24 hours. It started on May 6th. So we went from TEST 2 (people running Vaults from home for the first time) to TEST 7 within 3 months . And look what we got over that period. New GUI’s, new routing, new Vaults, and what more. Devs are doing an amazing job here.
And people are bitching about it taking 2 years to come out with the network? Look what’s been built in the last few months. This is a construction project not a bloody last minute release. Still can’t wait for the actually final network to be up and running.
So nodes are not being ranked by the network yet correct? As that as I understand will happen with data chains. How about message priority? These features should really help with the smaller nodes with slow connections. I think test 7 was a success already as well. I got to try out the changes to launcher and demo app and I see no need for further changes. I like the way it works, the sequential encryption has done wonders for the progress bar. Now there’s a cancel upload button, it looks even more spiffy, there are both public and private folders now, and I love the account secret idea. Account secret is very personalizable and creative so a great solution imo. Cheers team, great job!