Discussion: safe: or safe:// protocol versus .safenet domain

Yeh, I don’t see there being any reason there can’t be (and why there won’t eventually be) many different launchers (like there are many bitcoin wallets).

Some browser integration might be desirable down the road, equally, a browser could detect/trigger launch of the launcher too, if it’s not running.

I think for an initial browser it’s not necessarily a key feature. (It could be reinstated as a further stretch goal, or we look at this once we get the initial, simpler, browser out).


As @Viv has noted, there’s no direct security benefit of safe: vs .safenet.

What was leaning me towards .safenet was the idea of adoption and a consistent experience across all potential implementations. (Imagining a chrome extension as inevitable.).

I mean adoption not only in chrome etc, but also with the aim of a SAFEr Browser being a user’s main browser. Beaker itself is not as polished as Brave. .safenet is possible in Brave. But perhaps this is going to far at this point? (which does seem to be the case; features can always come later).

As noted, by a few folks, chrome / clearnet browser extensions will be inferior as who knows what else is installed in the browser. We cannot control this.

I also think these extensions will be a given… As noted above, TOR do not recommend extensions to access the network, but extensions exist… Eventually, they will exist for SAFE too.

Any extensions can/could do parsing of links to the preferred format, or trigger SaferBrowser launching with either safe: or safenet links.

The choice is then somewhat… should we be looking to facilitate potential implementations in the name of adoption / a consistent experience? (I’m aware of some sentiment around this already…).


If this is something we decide not to facilitate, the choice of safe: vs .safenet then is somewhat simpler.

2 Likes