Ofcourse you can, so long as the launcher is connected to the network you dont have to log into your account to browse sites(unless you have to auth the site, authing the browser is optional).
And yes, the URL scheme was what your saying, i wouldnt get error messages if I was trying http would I? 
Yes I refreshed pages. I closed the browser, etc. I can still access safe://test.aenemic by opening launcher, let it connect to network. NOT log into my account and opening it in safebrowser.
I got you, yes, you are right!
I just tried to open it and I get:
{"errorCode":-1004,"description":"DnsError::ServiceNotFound"}
Well thats certainly good Must be cached in my browser somehow then. Still doesnt explain the weridness of it working when logged in vs not logged in earlier.
I think Iām reproducing it now, I just deleted the service first (without removing the folder), and start experiencing the same thing, logged in/out, connected/disconnected. But then as soon as I delete the folder I cannot access anymore. Iāll report it. Thanks @aenemic!.
Iām guessing the browser is caching the page.
Yeah, the logged in/out thing was the stranges thing though, because as the folder was in the public folder and the dns was mapped I couldnt access it unless I was actually logged in to my account.
I also run on Windows, Iāll see if I can test edge cases on my end for what could be returning an error on your system.
Iād like to get the chat app switched over to using our new client api, so Iāve been spending my free time lately digging into those core files to understand new logic flow.
I wonder Beaker caching is a bug not a featureā¦ itās easy to get confused with it and easier to forget itās there. I donāt know, if thereās been any change to that recently but it seemed a while back that any static site update was liable to not being seen, unless the user deleted manually the Linux:~/.config/SAFE Browser or whatever it is for the OS. ? @joshuef
I started a new vault on Windows 10.
WARN 18:03:46.382839900 [safe_vault::vault vault.rs:181] Restarting Vault INFO 18:03:53.749004800 [routing::states::node node.rs:1240] Node(ebb8f5..()) Requesting a relocated name from the network. This can take a while. INFO 18:09:53.749997100 [routing::states::node node.rs:2334] Node(ebb8f5..()) Failed to get relocated name from the network, so restarting. WARN 18:09:53.749997100 [safe_vault::vault vault.rs:181] Restarting Vault INFO 18:10:00.875501300 [routing::states::node node.rs:1240] Node(758169..()) Requesting a relocated name from the network. This can take a while.
Hmmm. Browser caching is pretty standard behaviour.
Thatās a question as to if we want caching for a SAFE browser at all. (if not, perhaps itās something to opt-in toā¦)
That discussion aside, you have a hard reload to do this on a per-site basis in the browser:
OR, electron has a CLI for disabling cache that would sort this on the app level:
The chat app is working now. I got tipped that I should create a public ID first so I did (only had private data stored) 
.
Is there simple option for sites to declare last updated date in a meta http header tag, that would force refresh?
Otherwise, I wonder caching is a question we need to considerā¦ I donāt know, if the additional traffic is an issue but given that perhaps static content will be the larger fraction, then not seeing updated content surely is a big problem. In the absence of server-side, I wonder that pages with javascriptā¦ perhaps all content is static, as far as the browser understands it?..
@Mods - sorry for off topic.
Is there simple option for sites to declare last updated date in a meta http header tag, that would force refresh?
The standard way of cache busting (what you describe), is to append a url query param onto the end of your resource.
So instead of requesting safe:mysite/js/your.js youād do: safe:mysite/js/your.js?version=<someNumberThatChangesWhenFileIsUpdated>
And so long as that random number/string is different, the browser interprets it as a new resource and will request again.
I have implemented this idea, with a slight modification: the min and max estimated values are not displayed but instead an imprecision is added after the average with a Ā± sign.
I have added a node to TEST 12b with this modification and I get results like:
INFO 18:20:03.648031299 [routing::states::node node.rs:287] -----------------------------------------------------------------
INFO 18:20:03.648123254 [routing::states::node node.rs:288] | Node(d453de..(11)) PeerId(342a9cb9..) - Routing Table size: 84 |
INFO 18:20:03.648209200 [routing::states::node node.rs:289] | Estimated vault count: 121 Ā± 25 (evaluated over 6 sections) |
INFO 18:20:03.648292720 [routing::states::node node.rs:290] -----------------------------------------------------------------
I have proposed a pull request to integrate this in Maidsafe code base.
Yuckā¦ surely we need a better approach than that. Also, itās seems unlikely a static webpage that has been updated, would cater for that.
Can we not get beaker to acknowledge last-modifiedā¦ thatās widely understood and simple to use:
<meta http-equiv="last-modified" content="Thu, 18 Nov 2016 19:11:42 GMT" />
*perhaps those are readable only by serverā¦ I donāt know the limits of beakerā¦ or does that require some server broadcast that doesnāt happen on SAFE?.. perhaps prefile last-updated could be requested from devs if this is a big issue??.. and obviously without time on the network, that could equally be a sha256.
Sorry, youāre talking about a html page or javascript/other resources? What I note above is for other resources like js files or images etc.
beaker is built in electron which is built from chromium, so standard html headers like you note should work as far as I know (for html files). I donāt think thereās anything custom in beaker that would disrupt this.
@davidpbrown probably want you want is Cache-Control no-cache:
<meta http-equiv="cache-control" content="no-cache" />
wohoo !!
Iām in too 
INFO 19:15:37.564574020 [routing::stats stats.rs:241] Stats - User (Request/Success/Failure) - Get: 222/215/0, Put: 0/0/0, Post: 0/0/0, Delete: 0/0/0, Append: 0/0/0, GetAccountInfo: 0/0/0, Refresh: 539
INFO 19:15:53.571138821 [safe_vault::personas::data_manager data_manager.rs:280] Cache Stats: Expecting 8 Get responses. 4231 entries in data_holders.
I also had the same message like @aenemic :
WARN 19:09:49.663455825 [routing::routing_table mod.rs:971] Some sections in the RT arenāt neighbours of our section: RoutingTable {
min_section_size: 8,
our_name: 3e272cā¦ (00111110ā¦01010001),
our_prefix: Prefix(001)
section 0 with Prefix(001): {
272f88ā¦ (00100111ā¦11110111),
34498aā¦ (00110100ā¦00110000),
3e272cā¦ (00111110ā¦01010001),
273edaā¦ (00100111ā¦00111110),
22387aā¦ (00100010ā¦01111001),
2aed5bā¦ (00101010ā¦01100000),
248cadā¦ (00100100ā¦11001100),
23fdd5ā¦ (00100011ā¦10001101),
26fc39ā¦ (00100110ā¦00011100),
24b0caā¦ (00100100ā¦10101000),
22f92bā¦ (00100010ā¦00010000),
3b8b8bā¦ (00111011ā¦11010000),
228bb5ā¦ (00100010ā¦00000110),
31dff4ā¦ (00110001ā¦10111110),
22d167ā¦ (00100010ā¦10000100),
3a5475ā¦ (00111010ā¦01001110)
},
section 1 with Prefix(000): {
},
section 2 with Prefix(0110): {
},
section 3 with Prefix(0111): {
},
section 4 with Prefix(010): {
},
section 5 with Prefix(0101): {
},
section 6 with Prefix(0100): {
},
section 7 with Prefix(101): {
},
section 8 with Prefix(100): {
} $
merging: we false, they false
}
INFO 19:09:49.664159633 [routing::states::node node.rs:971] Node(3e272cā¦(001)) Received invalid prefixes in NodeApproval: RoutingTable(InvariantViolation). Restarting.
then the valut restarted by itself and connected fine.
Things are getting brighter and brighter guys !!
multiple attempts, keep getting the same resultā¦ anybody else having issues opening their public folder?
I can access files quickly from a different account that has more recent activity.
my tos.savage files should be in there but they dont show
tried to upload them again and got
but the site is still available to view.
Yes end of the road for this test. We have been tracking at least 2 bugs this afternoon since 3pm GMT and these have now shown section fragmentation due to accumulation error from a single invalid node. This one node was able to send a message groups believed due to a quorum bug, this amplified over the sections causing route failure. Several pending features would have prevented this, much of which is in a parallel tasks (data chains, node age, signature validation of messages which is in a PR for review).
We will take these off line and for sure kill these bugs in short time for another iteration. It must be said we would not find these bugs without the community testnets. These testnets are a huge help in showing us the impact of many code paths that we simply would take months to try and test internally.
So itās goodnight from me and goodnight from testnet12_b (for now )
Well so long and thanks for all the Testnet12 fish.
Just as I had snapshotted my AWS instance and was ready to launch another 10 just like itā¦
Looking forward to Testnet 12c - or will it be 13?
