Re: [LEDE-DEV] [OpenWrt] Project proposal: The GNUnet of autonomous Things

2016-12-06 Thread Drasko DRASKOVIC
Hi Daniel,
Very interesting project!

On Thu, Nov 17, 2016 at 12:39 PM, Daniel Golle  wrote:
> Project schedule
>
> (I)
> As a first step towards better integration of typical IoT USE-cases
> into OpenWrt/LEDE, a ubus service allowing access to low-bandwidth
> peripherals shall be created. It's modular design shall allow for
> plugins providing access to various different APIs and low-level
> busses. Plugins may expose read and write access to datastructures
> and emmitt event notifications.
> The ubus API shall be sound and well-documented. Sample plugins
> including verbose comments utilizing and demonstrating that
> infrastructure shall be implemented.

Do we really need this phase? I.e. is ubus the best solution?

We at WeIO (http://we-io.net) used something that we called  IoTPy
(https://github.com/nodesign/weio/tree/master/IoTPy),
but I think today besto solution is to use Intel's MRAA
(https://github.com/intel-iot-devkit/mraa) in combination with UPM
(https://github.com/intel-iot-devkit/upm).

This way user get a bunch of drivers for various sensors and actuators
in different language bindings.

>
> (II)
> Once sensors and actores are available via the local ubus instance,
> a ubus rpc proxy which operates as a GNUnet service shall be implemented
> to allow secure and privacy-aware pairing of OpenWrt/LEDE devices and
> remote access to ubus using GNUnet.

Looks like a sane solution to me. I have started some months ago
working on a centralized solution called Electrolink -
https://github.com/projectiota/electrolink.
It uses MQTT or CoAP to pack and send RPC messages in JSON or CBOR.

Currently we are working on MRAA<->Electrolink integration.

For decentralization - this is worh loking:
https://safenetforum.org/t/maidsafe-and-gnunet-comparison/2779.

Maybe some of scalable blockchain solution (Tendermint? Blockstack?)
are also worth investigating.

Telehash (http://telehash.org/) looks like a great candidate also.

BR,
Drasko

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


Re: [LEDE-DEV] [OpenWrt-Devel] TR-069 for OpenWrt

2016-05-27 Thread Drasko DRASKOVIC
Hi Karl,

On Fri, May 27, 2016 at 1:55 PM, Karl Palsson  wrote:
>
> David Lang  wrote:
>> On Thu, 26 May 2016, Delbar Jos wrote:
>>
>> > We are conscious of the fact that together with the proposals made by 
>> > Felix,
>> > Luka and Wojtek we are now looking at many "competing" proposals. As a next
>> > step, we recommend to organize a workshop, at a practical location and 
>> > time,
>> > where we put everything on the table and define the most appropriate path
>> > forward to the benefit of OpenWrt as a whole.
>>
>> nothing wrong with supporting many different remote management
>> daemons.
>>
>> > TR-069 is a complicated remote management system and in order to make this
>> > initiative a success, we must ensure that the complexity is handled in an
>> > elegant way and with respect for OpenWrt's core architecture. More than on 
>> > the
>> > protocol itself, we believe that we should focus on the architectural
>> > enhancements required to support remote management in general.
>>
>> What is it that you think is needed to "support remote
>> management in general"?
>>
>> It's worth pointing out that many people are remotely managing
>> OpenWRT devices, Ansible/Salt/Puppet/Chef/etc are all common
>> tools for the job.
>
> Really?  python, python, ruby, ruby.  None of those are really fun enjoyable 
> tasks on _my_ openwrt/leded devices.
>
>> now, those are all tools aimed at managing Linux Servers, not
>> networking gear, but OpenWRT is a server.
>>
>> So I'd suggest starting off by creating a daemon that talks
>>  and just stores the stuff it's sent in some
>> simple files so that it can return the info when queried.
>
> Did you read the intro to Delbar's mail, describing that they
> already have a complete tr069 project, for managing openwrt
> devices, that they want to open source, and want to collaborate
> on making it more useful for all, and perhaps see if there are
> common pain points that can be resolved by handling things
> differently on the lede/openwrt side, rather than working around
> on the tr069 side?
>
> I think it's exciting and I'd love to hear more about it.
> ansible/salt/puppet/chef have been far too heavy to run, and
> openvpn servers granting remote shell access is far too tedious
> for daily use.

I am very interested to see TR-069 solution. IMHO what is really
useful in it is Amendment 5, NAT traversal based on XMMP. Both AllJoyn
and Iotivity seem to push this approach to managing CPEs - naturally,
it has been proven and widely used. For the reference, here is an
interesting discussion I had with Thiago Macieira from Iotivity:
https://lists.linuxfoundation.org/pipermail/iotivity-dev/2015-October/002867.html

However, I would personally look more at OMA LwM2M - it would be much
lighter and more fun to implement ;). NAT traversal is not so
straightforward, but it would be interesting to investigate it. Then
clients will be ultra-light.

BR,
Drasko

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev