Hello there, I will be more specific, at 2:56 you said:
You see, the way you say it, you are implying that Rust is a language that “can’t tackle things from a Operating system perspective”, so at the time you made that video it seems that you thought Rust was more like an interpreted language or a script or anything high-level.
Rust is very much a system programming language, ie. “operating system perspective”, it is “c level” by definition.
The SAFE Network is designed with IoT in mind, and it could be implemented in embedded systems.
There are some threads in this forum that discuss specifically about IoT.
In fact I personally think it is the only platform capable of achieving a reliable and secure IoT without bottlenecks for scalability.
Very good video, you have a good understanding of many things related to the SAFE-network.
I did not persive negativity against rust as @piluso did. It was a little unclear to me if you mentioned that alpha 2 runs on controlled servers until secuirty against hacks are done and that alpha 3, which hopefully comes very soon, will be running from the users computers. SafeandSolid was mentioned well, which is good, wish you showed a little more of Patter. Great job of inviting new developers as you showed functionality and how to get started. You mentioned that you would like the option to manually allow clear-net sites which is a nice and interesting thought that comes with good and bad things which deserves to be thought about and see it from different angles.
Could wish you mentioned Maidsafe coin and the swap to Safecoin in the future with the disclaimer of the trademark issue with another project who last year did a hostile move to try and leach of Maidsafe, so it is still a little unclear if the name Safecoin can be used when future network launch. Overall very good video.
I’ve been running through much of the dev intro material on my own and it’s good to see some of the quirks show up. It’s good for my patience with the learning curve.
Thanks for dedicating the time. Much appreciated.
@jimmyhacksthings Your in-depth review is an honor to this project. Thank you. I thought your video was fun and in good spirits.
Thank you for the valuable critique. Good timing actually because those points are informing our next steps to reform authentication flow.
I’d agree that embedded dev is not in a ready state.
To prime the pump for your interest in embedded development in C, take a look at these exposed FFI operations here, here, and here, which is how our Node.js library, safe_app_nodejs, utilizes our core Rust client library. Shared libraries are available at https://s3.eu-west-2.amazonaws.com/safe-client-libs. For example, https://s3.eu-west-2.amazonaws.com/safe-client-libs/safe_app-mock-0.9.0-win-x64.zip.
All this needs documentation.
As it stands each IoT device need it’s own logged-in authenticator process. Is this practical for deploying and managing a multitude of devices?
If multiple app instances are to be run on a single device, a dev would have to implement their own IPC strategy to communicate with authenticator process.
This is a larger issue that we as a community needs to tackle.
@Dimitar created a post about it in a more specific sense yesterday.
Personally I see it going two ways. Either we do nothing now and once we launch Maidsafe will naturally take a more backseat type approach to what is happening at the forefront of marketing etc or we do something about it now to clarify better.
I dont think @jimmyhacksthings made a mistake, I think its our issue and we need to correct it.
One thing that could be better communicated is that the SAFE Network has never actually been based on a browser. Previously a fork of the Mozilla, then Beaker and others have been put forward by the dev team as an access platforms. Current version of the SAFE browser is being developed as a means of having a secure experience without leakage to the clear net. Anyone who wants can eventually build whatever browser they want for access, or none at all for access via IOT. Just need to use the network protocols to connect and read/write.
EDIT: No, don’t take it down. Maybe do a follow up on some points, but leave it regardless. Will do much good, either way, I think.
Even though the access of the SafeNetwork from ‘clearnet’ browsers through extensions/add-ons sounds like it may be practical and functional to the initial popularization of the SafeNetwork… the fact is that it would undo the security advantages of the unique design of the SafeNetwork.
In short it would be an enormous security risk.
We have enough phishing on the clearnet, let’s keep the SafeNetwork Safe.
Thinking out loud here, it seems like the best way to protect against malicious/fake third-party extensions for SAFE Net (or extension takeovers) would be for MaidSafe to provide and market its own. Otherwise a very convincing-looking fake one will inevitably appear and trick a lot of people. As I understand it though, maintaining an extension is a lot of work, especially across multiple browsers.
We could strongly caution users not to download extensions for SAFE at all, but you know some people will be tempted by the convenience, or see it as a new form of VPN service. Then they’ll get pwned. Again, just my opinion.
I’m inclined towards extensions because of the potential to off-load a significant amount of browser logic development and cross-platform concerns. I’d like to hash out the security issues that are unique to extensions and which do not apply to our current browser software.
Using the webRequest API, a SAFE extension could intercept HTTP/S requests and prevent fulfillment. The question is whether this is acceptable according to Add-on Policies. If this behavior violates extension policy then the rest doesn’t even matter.
As far as difficulty of development, the Firefox team makes their API’s in common with Chrome and Opera, with some minor differences in the prime configuration file. So cross-browser support would become our concern instead of cross-platform support with much less effort, iff we didn’t need what extensions call Native Messaging.
Leading into the next issue: relying on dynamically linked libraries, which we do in safe_app_nodejs and the browser to call safe_app, safe_authenticator and system_uri operations.
We’d need an executable running natively, which the extension can communicate with using Native Messaging, to call operations exposed by our dynamically linked libraries.
This wouldn’t be difficult just time-consuming to rework communication and authentication flow, let alone the the QA to ensure that the extension correctly handled installation and registration of native binaries according to platform. Although the time spent may balance out by time saved from offloading onto Firefox and Chrome.
I’m also inclined to conclude that we shouldn’t put time and effort into extension development at this particular time because I think the time would be better spent on things like low-level data migration and management tools, improving the RDF API, and in general support for developers over end-users.
Just a quick thought from me. I think that an add-on could have potential to ease entry to the SAFE-network and become like a “entry drug” before regular people will become addicted to the SAFE-browser. So even though it might not be optimal in every way regarding security, it might be very important for SAFE-network adoption rate, if a minimum level can be achieved, like choosing if to allow http requests and so on.
I am not a developer so my comment here will probably not make any sense (if it every does : ))
but since the formal release of beta may still be sometime away, isnt is too quick to advertise development on SAFE. Is there a chance that many developers come excitingly, get disappointed and do not return?
Also - even if the beta gets released in 2019 and does not see any adoption right away - request to SAFE team is to stay committed on its course as adoption will ‘eventually’ follow. May even take a year after full launch. Things take time to spread out and gain momentum.
If we position the APIs and network appropriately, and therefore set expectations, then we should be ok. We do still need people using the tools we provide so they can be continually improved so we should encourage development, but do so in our usual open way.