To clarify, my issue is that examples in node.js can easily rely on libraries that are hard to understand or get working in other languages, and a build system that is complicated and can be a challenge to get (and keep) working in itself. These are useful things to learn, but barriers to people who are not already familiar with them.
These barriers can be much reduced, and the examples made more widely understandable by building them around applications that work in just a standard browser. So I wasn’t wanting another language, but rather a less elaborate system of modules, library and build system, but all still in JavaScript.
This is not to say MaidSafe should have done this, just what I was hoping for given my own difficulties getting the API working without having node.js available, while the code fragments provided in the documentation included node.js library calls (in the old encrypted 0.5 API). MaidSafe are doing a great job and many others will already have the skills to hit the ground running based on node.js, or have less difficulty translating code to none-node JavaScript, or to other languages, than I did.
My wish is also to make the API accessible to people who have not been building with these systems: people from the browser client/GUI side of things, amateurs, none programmers inspired by SAFE to have a go.
I do also agree with the point about npm being a security risk. I’ve not looked into this, but on the face of things I’m concerned about trading convenience for security. I can imagine certain organisations loving the opportunities created by that ecosystem.
This is an issue as is shared libraries in general. Some node packages for example can have 10’s or more dependencies. Something everyone needs to me more careful with. npm gems cargo etc. can all pin a version though or even better download and include the version yourself after auditing.
A much better attack for gvmt sponsored agencies though is also the compilers themselves. It’s an area gnu works well at with haskel/c/c++ etc. as the gnu community are spread far and wide. However, there was a crazily good attack on the c compiler there to introduce a rootkit and it worked really well as an example attack.
Then the hardware, man oh man, it all seems so hard, but killing each vector at a time is critical. So I agree with pinning / local dependencies etc. Also remember sourceforge were injecting adds in software downloads so it’s not only active attackers to watch it is also lazy profiteering as well.
Making it possible (if it isn’t already) for people to just send regular SAFE emails with names like “WhiteOut@yahoo.com” instead of regular “WhiteOut” like we’ve been doing…
…and then kicking that into HIGH GEAR with some sort of SAFE userstyles (themes) for SAFE Mail that makes the app look like Yahoo / Hotmail / Gmail etc.
So it LOOKS & FEELS exactly like those services above, BUT WITHOUT THOSE COMPANIES OWNING ALL YOUR EMAILS & DATA!!!
When an app try to revoke its token by itself, the launcher revoke it but doesn’t remove the access block in the Account tab, resulting in a crash if you click on it.
It’s a different kind of “tutorial” than I’m used to as well. I guess it’s more of an example of how things (can) work under the hood and how you can tweak/add stuff.
If you didn’t find out how to get the SAFE Mail app to work you can use this:
maybe explain that you cannot use it yet to send emails and that you have to make use of a list of names that are in use?
I coincidentally found 1 name
