SAFEr Browser(s) Proposal

@dirvine could you please pass comment on this issue, do we not have a chance for a fresh start?

Considering were headed towards a fully semantic system, I would have thought entering mranderson in the address bar would drop down a contextual list of public resources associated with that tag, giving priority to any resource associated with the public id: mranderson

The browser should be a resource directory to all public data…not just websites


The current POC doesn’t default to safe:, but I don’t see any reason why we couldn’t do this.

The problem arise if we have a ‘switch’ for regular http: access. BUT. There’s no reason we can’t still default to safe: and you have to specify http if you want to go clearnet. That would make sense :thumbsup:

So you’d only type MrAnderson and you’d be on safe. But would get you to the clearnet. I like this :thumbsup:

Interesting! Could be fun to explore how useful this is (probably quite?!) :thumbsup:



Since we are building a SAFEspecific browser, why do we need anything other than the domain? No SAFE:(//) and no **.safenet.

Visual feedback: no need to type it, granted, but showing it is useful feedback.


I’ve updated the POC just now with safe:// being added by default. So now you can type your domain test.bluebird (which is still up), and you’ll automagically be routed to safe://test.bluebird.

That way, if you want to copy/share a domain, it’s got all the info you need and wont be confused with http / clearnet links.


I was on a break, just resuming today.

@cretz got it right. Authorisation tokens are tokens specific to a launcher session on a device. But the data stored by the app is in the network available globally for that user.


What would be great is to be able to download one app that allows me to login to SAFE and browse SAFE sites. I would hope that the launcher and SAFE Browser would become synonymous.

Would a built in app store be asking to much :wink:


Better error handling would be welcome:

Get requests through commandline wget see a clear HTTP error code, whereas Firefox and I expect others, suggests an error message that isn’t not so clearly stamped with the usual HTTP codes. I don’t know if then the SAFE browser can help users by at least declaring the HTTP code as header before barfing over them with SAFE-dev speak and cryptic network detail. From memory it’s just 404 and 410 that are most common replies and those from where subdomains and PublicID’s don’t exist. Something like “404 Not Found”; “410 Domain does Not Exist”, would do.

Edit: this should have suggested 400 not 410 ==HTTP Error 400 Bad request

1 Like

All this excitement about creating a new prefix. It still makes me worried it’ll create compatibility issues. If I code my site to use safe:// links or safe: links instead of http:// links even if everything is all on the SAFE network this may still cause issues for someone that isn’t using the SAFE browser. To me it’s less about security and more about audience compatibility. Most people will still be using firefox and chrome and won’t be going that extra mile to download a special SAFE Browser. I think if we do decide on a federated protocol we should also build addons for other browsers that would allow them to interpret it. That or make sure the pac file and launcher can handle it. Whatever works.

1 Like

I guess the solution will be that http://test.bluebird.safenet == safe://test.bluebird where that safe:// is supported.

If everyone writes their links as the usual http:// then the SAFE browser can present then in a SAFE-centric way perhaps without confusion.

safe:// could be suggested as one step beyond https:// and http:// is misleading for the level of security being provided.


I don’t think so. There needs to be a clear separation between which network you use.

While this is possible, and something I’ve toyed with. It’s only possible as long as .safenet doesn’t exist as a domain on the clearnet. Then we’d be just hijacking a Top Level Domain. Which is bad. It’s not something I think we should be looking to use, as it’s not future proof.

It’s important to remember that the current setup was for convenience of testing (at least as I understood it).

I think this is key. And something that has already been put forward and at least tested to some degree as I’ve seen by the MAID team.

Ideally, work done on this browser implementation should setup rules and patterns (and indeed code) that can be easily used to create these extensions (where the browsers allow it).

If a browser doesn’t allow, and it’s deemed acceptable, then hijacking a TLD could be one way around it. But I think it’s important to know what content is SAFE and what is not. Anonymity is a key feature of the SAFE network, and pages loading content from both protocols are no longer anonymous (there are many many ways of tracking a user via a simple HTTP request).


I’ll answer in this way, though not convinced and expect you are correct…
Normal URLs I wonder already fall within .earth and in zones where others like .mars are used, that extension becomes visible. So, I was thinking not that .safenet is the usual earthbound URL top-level domain but one step beyond that… indicating that it is a different network.

For example, bluebird.safenet could be and then a clearnet site but bluebird.safenet.SAFE would never be confused with the clearnet network; in the same way that bluebird.safenet.mars would not be confused with

I wonder that SAFE is not just a new protocol like https:// that can be applied to any and all websites; it is as you’ve noted a different network. However, it would be great, if safenet addressing could fall within the URL protocol.

Another likely bad idea, would be that the URL protocol that .safenet uses could be one using a forbidden character, so that it fails as a normal URL - but as suggested I think that’s a bad idea.


.safenet is in itself a workaround for clearnet browsers (where a custom protocol isn’t possible cough chrome cough). Right now my aim is for a set of standards of how SAFE access would ideally be.

.safenet may be a solution for accessing SAFE via an extension in one of those browsers, it’s not itself a reason to complicate what could be a set of standard ways of addressing SAFE content: safe:.

In that same way, any extension of clearnet browsers could easily parse safe: links and replace them with https://.....safenet. Which would, as I understand, address some of @Blindsite2k’s concerns about maintaining sites.

I think if it’s wanted, then it’s relatively trivial to setup for an extension to do this. But the gold standard should be distinctive and clear. It should be (IMO) how we want the SAFE network to be, which is secure at its base level.

As such, for an immediate SAFE browser, I lean towards safe: as a solution for identifying network content, and if that’s accepted / standardised, then the extension ecosystem of other browsers could (would/should) allow for this.


I don’t know how feasible this is. But supporting both safe: and safe:// would be nice. Some might get confused by only the : even while the // don’t really add a thing from a tech point of view.


Totally! When I’m writing safe: it’s comparable to http:, the rest of the URL structure remains.

The // as it stands right now in the POC, is totally optional.

Sorry for the confusion!


I’ve think you’ve got it right, whichever way it’s considered. :thumbsup:

It seems to fall well within the URI Syntax, which suggests that the two slashes are optional for schemes. safe: then is just new scheme.

There is then no more a risk of confusion with use of single colon for :port than ever there was.

Normal browsers will work with any link because they are within an anchor not because they are of a certain format.

It’s all good :smiley:


Not sure if I’ve read this entire thread, but are you building in a Launcher? So people will only need your browser to browse & PUT to SAFE?

EDIT: I see it now. It’s a stretch goal of 20,000 MAID. Definitely hope this is achieved! Will make the browser much stronger

@whiteoutmashups Yeh, the initial stretch I’ve described would be to enable anonymous browsing, at least.

It’s not yet clear if a fully-fledged launcher, in the browser is desirable. But right now full auth / permissions / logs etc is out of the stretch scope (though I’m not averse to adding it if there is demand). I figured we’d be better placed to know how this will be used down the line. Though if you have thoughts as someone who is developing apps, please let me know!


Just to clarify a point I saw over here from @Anders, right now this proposal is for desktop browsers only. More specifically, I’ll be looking to get as much as I can into a fork of this repo.

My intention is for all work to be easily portable to any other browsers, such that an android implementation would be much simpler. But I’m not well versed in android or iOS dev, so I just want to be clear and up front that android brave development should not be expected from this proposal.


This post was flagged by the community and is temporarily hidden.