Discourse safe: link removal

I just noticed as I was perusing via the new SAFE Beaker Browser builds, discourse is currently parsing/removing safe: protocol links. such that when you add:

[some link](safe://thelinkonSAFE)

What you actually get on the page is:

<a>some link</a>

With all href info removed. :frowning:

Can we disabled this sanitation?



I can do it :slight_smile: But , testing with Beaker shows , they aren’t executed , no idea why

1 Like

In my browser (currently in chrome), the link you posted doesn’t have a href, so clicking it doesnt go anywhere (neither in the Safe beaker browser) :frowning:

1 Like

I’m on Chrome on OSX 10.9.5 , I have the blue link href but obviously in Chrome this protocol string isn’t executed , only proxy works with http:// and .safenet ending , I wonder what keeps Beaker from executing the hyperlink , they work in the address field but not inside the safenetforum page … must be a small detail .

Further Beaker is the only Browser that renders my page correctly , that is fully animated

I’m on chrome on mobile now, and it’s showing the link as clickable.

@frabrunelle said discourse is updating their servers (which this forum is hosted on) which may be why it’s giving you errors on older versions of chrome (for example, I just had to update my Chrome just to even be able to connect to this forum page).

EDIT: he just corrected me on this. Looks like we actually don’t know why it’s doing this. Hopefully he can chime in :slight_smile:

Right now what happens is that anything other than http, https or mailto gets removed.

But there should be a way to add exceptions.

I’ll contact the Discourse team about this :slight_smile: maybe they could add a feature that would let us whitelist certain protocols (e.g. safe)

1 Like

Yeh, it appears clickable, but the link is removed by discourse, as @frabrunelle notes below. (on which, awesome if they have a whitelist, @frabrunelle :thumbsup: )

As for the animation question @000, @hdastwb had a likely explanation for this here .


I just realized that an option to allow additional URL schemas has been added to Discourse :tada:

safe:// links are now clickable :smiley:

e.g. safe://frabrunelle


That’s great news!!!

I was just thinking about that again today. Great news for us!!!

Testing - safe://fake.website

Hmm, not working when I post this on mobile, maybe I need the desktop option that let’s you add a link. Will try when I’m home

Do these links open in beaker?

1 Like

not currently, but it should be possible :slight_smile: SAFE Browser / Beaker just needs to register itself as a protocol handler for safe://

the way to do this is a bit different depending on the operating system. I think it might be useful to look at the source code of webtorrent-desktop (it’s an Electron app, just like Beaker) to see an example of how to implement this.

Here’s the code that registers a protocol handler for magnet and stream-magnet (it works on Windows, macOS and Linux):

See also the Electron documentation:


1 Like

Have anyone managed to set safe:// protocol to be open with Beaker in GNOME? @frabrunelle or @joshuef?

I added an entry to the mimeapps.list and created the corresponding .desktop file, and when I click on a safe:// link it triggers the Beaker browser but it doesn’t open the URL.

1 Like

This is an important thing to get working, and I hope we do. I love how magnet: links open automatically in your BitTorrent client when clicked, and hope we get this functionality built into the browser for safe:// links.

Programs usually ask if you want to set it as the default for certain types of files / links, and in my opinion a finished SAFE Browser should definitely be expected to do this.

Clicking a safe:// link on this forum or anywhere should automatically open it in SAFE Browser, ultimately

I have not. My dev setup is limited to OSX and an occasional (slooooww) VB.

I was using the built in protocol registration with electron-builder: https://github.com/electron-userland/electron-builder/wiki/Options#Protocol

From what I researched so far, the .desktop file it generates is fine (this file is used by GNOME to launch it), but for some reason the URL passed as parameter to the Exec command (which correctly contains the %U at the end) is not taken by the browser when it opens. I’ll keep researching.