Can you please confirm how you are building and launching the web hosting app? are you packaging it with yarn run package?
The URI scheme currently doesn’t work unless you run the packaged version of the apps.
This is my process, based on documentation above, comments in this thread, and the README for the web hosting manager.
export NODE_ENV=dev
yarn upgrade
yarn
yarn run rebuild
yarn run dev
I’m just now seeing a note about “Authorising against Mock” in the README for the web hosting manager:
To simplify the auth process, as web-hosting can’t received a response when running in dev mode, authorise the application via the safe playground, using the applications own app object (below).
The below part confuses me but I’ll see if it makes more sense when I’m running the playground. This is almost certainly where I’m going wrong.
Yes, try running yarn run package and then run ./release/linux-unpacked/web-hosting-manager
1 Like
Cool! the alpha-2 tag was corrected as well.
Hi, there is a way to run the Safe Mail App example inside browser without electron?
No, because apps are built either to run in the browser (using the SAFE DOM API) or stand alone (using the SAFE Nodejs API). [… or in fact maybe, see Josh’s freely below!]
It would though be possible to create an equivalent compatible mail application that runs entirely in the browser.
1 Like
Actually, with the right set of abstractions, we should be able to run such code in the browser (electron is essentially a custom browser that runs cross platform webapps). The main difference is the API interaction as it stands (safe-node-app vs beaker-plugin-safe-app).
@Diego_M_Rodrigues, I can’t say it’s going to happen for the email app anytime soon, but certainly where we can in the future (ie, where no filesystem interaction is needed), we should probably be making portable code so you’d have the option of either.
4 Likes
@joshuef do you know if there’s a reason MaidSafe have tended to avoid creating web apps and preferred desktop? I think Ben’s video chat was a browser app - but IIRC was created to demonstrate WebRTC - but I don’t recall any others.
I’m interested in the pros and cons of browser v desktop from MaidSafe’s perspective, and whether there are particular issues that lead the team to favour desktop, when the advantages of cross device support and no install lead me to prefer browser, both as developer and user?
Thoughts @Viv?
1 Like
My understanding (and correct me if Im wrong @krishna), is that there’s been no specific target so far, just offering up a selection. (The markdown example is a webapp, for eg).
I think the web hosting and email have been picked up as staple/useful/most interesting for the community, and so they’ve gotten more love recently.
As for pros and cons. I think if you can offer both, it’s not that hard to these days. The email app could be a site. The webhosting could be, but would probably not be as usable…
It all comes down to maintenance really, and on that front I’d say sites are simpler (especially on safe, where there’s only one browser to worry about). But electron apps aren’t that far behind.
3 Likes
Desktop app helps us to test applications on all platforms for cross compatibility. It was easy to start building apps as soon as the safe-app-nodejs was ready. If you remember, the web apis were added only after testing the nodejs API. We had to wait for the API to be stable to avoid rework, hence the focus was on the desktop apps.
The purpose of the apps is to help the devs understand the API. The SAFE API playground covers the complete API for web apps.
However, we can start putting out web examples too once the current refactor is over.
7 Likes
Thanks to both of you for satisfying my curiosity 
Have a great day 
3 Likes
@krishna @joshuef I just read this article that perhaps gives us some other reasons for preferring native (desktop/mobile) over web apps, and also some examples of problems in the browser we might want to check for (see the HEIST link).
- It’s time to kill the web - Mike Hearn
His follow up article is worth a read too because it attempts to redesign the web platform for security (note the comments on URLs!):
- What should follow the web - Mike Hearn
@dirvine you might be interested in Permazen, described in the second article (as not well known), though you are probably way ahead of me 
:
One of the interesting things about Permazen is that you can use ‘snapshot transactions’ to serialise and deserialise an object graph. That snapshot even includes indexes, meaning you can stream data into local storage if memory is too small and do indexed queries over it. It should be clear how this can provide a unified form of data storage with offline sync support. Resolving conflicts can be done transactionally as all Permazen operations can be done inside a serialisable transaction (if you want a Google Docs like conflict-free experience that will require an operational transform library).
5 Likes
Any progress here Josh, or are we reliant on the electron team?
The “What should follow the web” article was really interesting.
Some of the things already fit in with SAFE web apps. SAFE isn’t the web and doesn’t use a web server after all, things like authentication with a single user id that can be user everywhere is already built-in.
The “missing” things is mainly things that can be done on the app side. Basically binary, type safe data structures. Now the APIs for mutable and immutable data are just low level APIs and you can put whatever data there. A storage library that can automatically serialize and deserialize binary data and has some kind of entity model is what we need I think.
1 Like
I think another may be cross origin requests within safe:// (although even moreso when users turn on clearnet access). Much less risky than on clearnet, but still may provide ways to unintentionally leak information.
Again, this is left to the app developer (e.g. applying minimum CORS headers), and that is the nub of the problem Mike Hearn is highlighting: developers needing to pay attention to and knowing how to design for security when this is not a prerequisite for building a useful, slick looking app or delivering a product to market.
Turning on clearnet access shouldn’t be done if you want security.
With SAFE only, there’s no ajax requests and the security model is built around the SAFE api. You’re basically connecting directly to the database and not through a server, so there isn’t really directly CORS is there?
CORS allows you to specify who or what can access your endpoint on the server side, but with SAFE, you do that with MD permissions.
1 Like
Yes, I’m probably worrying about nothing here. I certainly don’t understand security well enough to say one way or another. I’d love to see somebody write about SAFE web app security and show what the possible vulns are and point out how x, y, z etc of clearweb issues don’t apply and why. Not me I’m afraid! Thanks for the comments.
At this point, 'fraid so.
Interesting articles there from Hearn there!
1 Like
Funny, that electron seems to be part of that broken web technology stack Mike Hearn writes about, and then SAFE makes native apps with it. For me it’s double-broken I think it’s C/Java bindings that we need and then make truly native apps with qt, java, whatever.
2 Likes