One aspect is that any commands can be verified as to have come from a specific source since messages contain the sender and can only have come from that sender because of SAFEnetwork protocol.
Also IoT devices can store their data in verifiable places.
So hacking has to be done on an account basis and that puts it into much more researched and known arena for security methods. Basically if only the devices (or @bochaco’s gateway device) know the credentials then it’ll take a long long time for any hacker to break it. They’ll have to resort to social engineering or hacking the developer’s and/or installer’s systems before the devices are installed.
Yes, I’ve sent data to thingspeak from one. I programmed it using Arduino IDE and Arduino compatible libraries. Don’t know about other ways of programming it, but there are probably other approaches too. Basically in the Arduino way, there is a setup function that is called on boot, then a function that is repeatedly called while it is up and running. In between these calls, the chip is doing whatever it needs to in order to keep it’s WiFi connection alive. Inside your periodically called function, I think your code can’t be too much of a CPU hog, or you’ll have connection issues.
One aspect is that any commands can be verified as to have come from a specific source since messages contain the sender and can only have come from that sender because of SAFEnetwork protocol.
I haven’t read the whole readme file but this seems powerful: “A SAFEthing can expose a set of topics that other SAFEthings can subcribe to in order to receive notifications upon events.”
A whole bunch of things can listen to each other in different ways. It may be tricky though to detect endless loops where one event triggers a response from another device which again triggers the first device and so on. Although that’s probably something for the developers using the framework to prevent.
That’s correct, and it sounded to me that many of the current IoT protocols use the publish-subscribe pattern, which I think it makes sense since a single device can expose a variety of services and you’d be interested in a subset of events, this is why the filters become a key part of the notification mechanism.[quote=“Anders, post:25, topic:13469”]
It may be tricky though to detect endless loops where one event triggers a response from another device which again triggers the first device and so on. Although that’s probably something for the developers using the framework to prevent.
[/quote]
I think this is a very interesting thing to consider, I haven’t gone to think about it deeply but I agree it could be nice if the framework can help you detect such scenarios, although I doubt it, since you could have several devices in a loop and not just two as you seem to exemplify.
So glad to hear of this project. A couple years ago I would ask about SAFE on IOT and hear it wasn’t light enough. Maybe that changed with RUST?
Also noted Intel was pushing this toll road plan to try to make sure telco could profit from evert IOT transaction instead of cutting them out of the loop with stuff like interference based mesh. Makes me worry for Tesla with Tesla now using intel as the supplier for the Model 3 chipset- at least momentarily. Might have been Intel’s plan, tells Mobile Eye be irrational with Tesla so they boot you, we’ll acquire you for a higher price and then gain a premium from Tesla for setting Tesla back. Do not trust them.
This has been discussed to death in other topics. You will come across many discussions as you read further and get to know SAFE.
There is many reasons for charging to PUT and I’ll pick one that is a show stopper for free PUTs. SPAM Spam will allow every attacker to keep filling up the storage so the network is always full.
For keeping GETs free, its the stated goal of the SAFE project to allow the world’s population free access to information. But also history has shown that people resent paying their ISPs then having to pay again to some other entity for information they can get free on the internet.
Just a heads up, apart from the goal of having an IoT lib, for those like me trying to become proficient in Rust, last week I pushed all the code I have so far (I recently made the changes to upgrade safe_client_libs to latest version, safe_app v0.9.0 and safe_core v0.29.0).
At the moment the lib doesn’t do/provide much really, I’m just trying to get a basic IoT API which creates the abstraction on top of safe_client_libs APIs, all of which is in the core folder/crate: GitHub - bochaco/safe_thing: SAFEthing Framework: Secure Access For Everything
The only thing that can be tried with it so far it’s to run the example /core/examples/printer.rs which makes use of some of the APIs I’ve been working on (you’ll need Rust v1.30.0):
$ git clone https://github.com/bochaco/safe_thing.git
$ cd ./safe_thing/core
$ cargo run --example printer --features "fake-auth use-mock-routing"
If you run it more than once, you’ll need to remove the MockVault file as it tries to create a MD in a hard-coded location everytime it’s executed.
For IOT you really want to be looking at no_std declarators in the libs. libcore is getting better and there are some interesting work on no_std collections etc. Then it means anywhere rust compiles all your code will work and rust is compiling on a lot these days. Check out GitHub - rust-embedded/wg: Coordination repository of the embedded devices Working Group as well for latest info on embedded to.
Thanks for sharing that David, this is definitely one of the main aspects I was trying to learn and move forward with, e.g. last weekend I was able to run that example printer app in a Pi2, but I still didn’t manage to cross-compile it for my Arduino Yun.
Hey @bochaco, this is such a cool project, I remember when I saw it before and first thing I really liked is that it is very neatly structured and documented, nice! And it would be great to see you having time to continue with it. (I guess though that this publish now might be because you don’t know when you’ll have time for it again?)
hey @oetyng, thanks!!
I was trying to move forward with it with some structure that it’s easy to maintain and understand, at the end of the day the main goal is to have an API which is extremely simple to use and for which you don’t even need to know what the SAFE network does or how it does it, you just want a device publishing itself, sending/receiving messages encrypted and secured e2e.
I published the ccode now because I didn’t have time to have the showcase ready, I was originally planing to release the code together with a showcase, so since I didn’t achieve that goal I thought I should just publish the code now at least. I’m definitely pursuing this to happen, I’m just trying to learn with it and moving forward with it slowly but as faster as I can
Excellent work @bochaco !!! I have been thinking a lot about this recently myself (although not in such technical depth). I am currently working for a company that is going IoT very soon and had just left another company that had already gone IoT. This area is HUGE. Have you heard of https://www.thethingsnetwork.org/ I asked the other day if our community members thought it was practical and achievable for SAFE to offer its services to their things network?
Can I share this and perhaps introduce it to people on those things community forums or would you like to?
I think this is quite HUGE because it opens us up to the entire IoT market!!!
Thanks for link @goindeep, I’ll take a look at it, I agree there are so many things that can be done once we have something like SAFE where your devices and data are secured and can assure privacy. Please go ahead and share, ofc you can, you obviously don’t need to ask such a thing! (btw if you do, make sure you share that image with them too )
Edit: I was aware of the LoRa tech/network, I know a local company working with it in Argentina.
)