I thought the 'proxy" was the pac file.
So you mean the launcher doesn’t listen to request on the local port 8100 anymore? How does non-browser apps interact with the launcher now?
The pac file is used to configure a browser to route all http traffic through http://localhost:8000 (and that was handled by the proxy that was part of Launcher).
The Launcher continues to respond to SAFE API requests on http://localhost:8100 [oops, I briefly had 8000 instead of 8100 here - now corrected!]
Note: 8100 not equal to 8000 
1 Like
Okay so 8000 was the port for the browser. 8100 is used by everything else and doesn’t response with any special header like the other one. So if the pac file redirect to 8100 instead of 8000 it should work fine, it just won’t response with the extra CSP header that was added to the port 8000, correct?
No, sorry don’t have time to explain, but that’s not correct.
[Edit… now I can explain.]
The two things are entirely different.
The launcher responds only to API requests (localhost:8100).
The proxy just forwards anything on localhost:8000 (passes it through unchanged), unless it is a safe:// or .safenet URL, in which case it’s redirected to the SAFE API as an NFS GET. So safe URLs are retrieved from SAFE, but everything else is retrieved from the clearnet (otherwise using the proxy have prevented normal browsing).
Hope that helps!
1 Like
This question may be better in another thread please feel free to move.
@joshuef If you had no constraints on help, funds or time to build a no compromise browser for SAFE network how would the present SAFE Browser beaker based implementation vary from that one in terms of absolute long term potential? Are you laying down the equivalent of the x86 standard here? You see I suspect global culture and convention will force thinking about the network as some sort of browser because that is all most people know, they just know the network in terms of human interface behavior or the browser as its the direct point of contact and sets the depth of familiarity and conceptualization. I know this isn’t lost on David and crew so the title SAFE Browser is a huge honor.
The culture may only recognize the SAFE Browser. People won’t get that its a different network. It will be like: well the plug-in won’t do, you need the SAFE browser for that or you need “a” SAFE browser for that or at the deepest level: no you can’t do that with that browser because it doesn’t connect to the SAFE network natively, its not native SAFE… they will have to rewrite your favorite browser to be compatible.
@happybeing, please comment too- and as above people know and attach to wrappers- there are probably even some tesla drivers who aren’t clear the car is an electric- you know inductive charge plate in the garage and spouse always gassed the cars.
1 Like
This is too big a question for me at the moment, but I don’t think we risk holding things back with the browser @joshuef is building.
The “x86” analogy is more akin to the network and SAFE API, and the browser is “just another” app on top, albeit one that enables users to use other (web) apps inside it.
Other browsers will be able to work with SAFEnetwork, they won’t need completely rewriting.
Firefox will work with a new plugin (not too hard either I think - but still a task that takes someone willing to put the time in to get out working and then maintain it as the API develops, did bugs etc).
Chrome is a different story and would need internal changes, but beaker is based on the chrome engine so in some respects we already get chrome, and maybe SAFE Beaker could be formed into a Chrome compatible version to pull in some of the Chrome features it lacks. That’s just speculation though, bad on little knowledge!
Having said that I’m going to argue the other way too (because I can 
) and say that in some areas we may risk setting standards that lock out, or make it hard for other browsers to follow.
Here I’m thinking of things that are included in Beaker specially for SAFE such as an App page. So we might want to consider if extensions like that can be done purely as SAFEnetwork web apps (in which case any SAFE compatible browser could have them too) or if their value is such we’re willing to create them with less easily ported code. If the latter, each other browser would be at a disadvantage unless it too implemented a similar features.
But so what? Would that matter? I don’t know.
It needs thinking about - and is perhaps a good reason for us to ask if a Beaker feature (such as an Apps page) could be implemented as a SAFE Website / Web App rather than building it into Breaker itself. Beaker could then just load that App into a built in Apps tab, rather than implement it internally. This decision has pros and cons either way though.
2 Likes
Quite worrying that 2 years later there is still no indication that the network is able to run in the wild.
edit: I was incorrect - test 10 is indeed client only. Seems that vaults from home has been scrapped for now.
… except for test 10, which is a test network that is actually up & running in the wild right now.
If a network running in the wild isn’t a good indication that the network is able to run in the wild, I don’t know what is 
I know it’s not yet reliable, but the problems are known & solutions are being worked on. Progress may be slow, but I don’t see it as worrying.
No progress would be worrying, but a lot of progress has been made over the last 2 years.
2 Likes
yes this is true.
Is Test 10 doing well? I haven’t really been following it
It is not running in the wild, it is running in maidsafe’s controlled environment.
I can see the progress being made, the worrying part is how all estimates are missed as new problems pop up all the time and those have to be tackled before a working implementation can be found. I will be worried until that first test release that won’t have fundamental problems, it will finally prove that the concept is achievable.
2 Likes
edit: I was incorrect - test 10 is indeed client only
Test 10 is largely ‘in the wild’ running from various peoples nodes at home. You can run a node on this network if you want to see it in action.
I think MaidSafe is providing some rented server capacity to this network, but I’m not sure to what degree.
Alpha 1 is the network being run in a fully controlled environment, but that’s a separate network to test 10.
Test 10 is largely ‘in the wild’ running from various peoples nodes at home. You can run a node on this network if you want to see it in action.
I don’t think this is true - you can’t run a vault from home on Test 10.
1 Like
Thanks for the correction, and apologies @reivanen.
I now see that from Test 9 onward, the concept of Alpha + vaults from home network been scrapped.
From the Alpha release thread:
When will I be able to run my own vault?
We will release a separate test network for users who want to try out running their own vault. It will be called TEST 8 and will be enabled on August 23.
I thought the idea was to have 2 branches of the network: a stable Alpha for devs to run against, and an unstable ‘test’ network where people can run vaults to see it working ‘in the wild’. I saw ‘Alpha’ as client only, and ‘Test’ as with vaults for end users.
I now see that from test 9 this approach was dropped, and everything became client only, so test 8 was the last ‘in the wild’ network until issues with poorly performing nodes are sorted.
So the test 9 and 10 networks are seemingly updated versions of the client-only Alpha network, and there are no ‘vaults from home’ networks. Is that correct?
2 Likes
Oh, that’s what I thought too.
Then what’s the point of test 10 again?
API changes in client side that are not available in the Alpha network. We are keeping Alpha networks stable for longer periods than TESTnets at the moment. There was no point putting out vaults as we had not fixed the issue with running very low power nodes form home. It is part of a larger refactor that does not make sense to stop and try and run from home, if that makes sense. The current refactor will include node age and resource proof, then we can run from home. The stage after that is data chains and that is data republish capability (no more having to refresh all data per Alpha/Beta release).
14 Likes
Built in speed test?
1 Like
3 Likes