Re: RWW like Implementations of IoT device management (via WoT)

Really helpful format..   Thankyou.

On Tue, 20 Sep 2016 at 07:59 bergi <bergi@axolotlfarm.org> wrote:

> Hi Tim,
>
> well, Rome wasn't built in a day.


Understood. Nonetheless i've got some thoughts around what i believe to be
important factors relating to this field of work.

The nature of purchasing a household appliance that has a subscription that
may stop that thing from working, no matter how sophisticated that
methodology (ie: https://en.wikipedia.org/wiki/Planned_obsolescence )
becomes a relatively straight forward preposition when compared to the
data-interaction layers these devices are designed to support as a means of
IMPROVING THE QUALITY OF HUMAN LIVES. Seems like an important concept, so
i'll make an acronym "IQHL" to denote any-such calc.

Concept of the IQHL calc would include properties have individual, social
and super-social layers to it, (Where the words of Eben Moglen most
resonate with me, in attempting to describe the 'super-social' layers:
https://youtu.be/9zXqHIJJVxk?t=41s ).

Civilisations overtime have evolved and have been lost.  Technological
advancements from past have been lost for a multitude of generations, for
unknown reasons.

In-turn these risks can also be seen today.  We don't have shoeboxes full
of photos anymore. We can author alot more data, yet, the means for persons
to manage their creations, the efforts and the acts produced through
individual energy / time; is increasingly more difficult to manage.

I agree 'rome wasn't built in a day' yet, i'm sure around that same era /
epoch - other examples exist, where the names of those civilisations (and
their technological status / methodologies) are forgotten. An interesting
example is: https://www.youtube.com/watch?v=vyhZzrjEzJk - a project i've
supported for some years.  The implication is that whilst medicines and all
sorts of other 'technology' existed, dating back far beyond the days of
rome; the means to improve communications methodology accessibly to others
with different cultural backgrounds, who for instance - used books, rather
than ceremony; can be improved with technology; or wiped out
https://en.wikipedia.org/wiki/Indigenous_Australians in ways that can be
impossible to resolve from a historical sense; and very difficult to
remediate in a future, present context.

so, my point is - it seems kinda important that whilst we're going about
'building rome' we understand the IQHL calc associated to our efforts and
how they'll impact humans or as many would better consider contextually
'consumers'... (where the semantics denote the underlying predicate to be
human..)


> Usually you don't have access to the
> firmware of IoT devices. As you said, current devices are in the range
> from "pay a monthly subscription for the cloud service & app" over
> "there is a HTTP API on your gateway at home" to "the device implements
> protocol xy".
>
> So how do we get from the current situation to "RWW-ready" open
> firmwares and gatways?
>
> 1. Implement RWW gateways and generic UI
>
> We can bridge different protocols and also wrap HTTP APIs to clean
> Linked Data APIs. This is mainly a software task, so we are very
> flexible, which is very useful to test concepts. The gateway can also
> host a generic HTML interface.
>
> 2. Implement Linux RWW devices
>
> There are already many Linked Data libraries for Linux. The Raspberry Pi
> is already used for some IoT projects. It should be easy to use the
> experience gained from implementing the RWW gateways to make the IoT
> projects "RWW-enabled"
>
> 3. Implement Arduino RWW devices
>
> The Raspberry Pi isn't the best option for battery powered projects. The
> Arduino platform is a better choice for this use case. There are already
> many IoT projects, but we need better RWW libraries.
>
> I'm trying to cover 1. and 2. with Dark Horse and 3. with SmallRDF and
> SmallHydra.
>
> But for most use cases there will be a need for a gateway:
>
> 1. Caching
>
> If an action of one device depends on the status of another device and
> each device must fetch the WebID profile, an action will take a lot of
> time just to fetch the resources. The number of devices will increase
> and also the rules & dependencies will get bigger.
>
> 2. Manage access control
>
> In your AirBnB example, generic rules could be used to grant access to
> all linked devices of the property. These rules would also apply for new
> devices. Also think of the increasing number of devices and how to
> manage them.
>
> 3. Bandwidth and power
>
> WiFi consumes to much power for battery powered devices. Alternatives
> like LoRaWAN must be used, but they have very limited bandwidth. Sending
> packets consumes power, therefore traffic should be reduced to the bare
> minimum.
>

I have some ideas about how to solve this problem... ;)

Therein; the broader consideration (and interest) becomes that of the
Embedded OS Standards and related licensing considerations as to ensure the
device someone purchases is well - purchased.  No Subscription required.
No 'register your device on our website' required.  A means to ensure
someone purchases a door-lock, it's a safe bet. that the electrical devices
won't use more electricity than necessary because of unnecessary/unwanted
'super-social' factors.


> There is already CoAP [1], which can be translated to HTTP, to reduce
> the traffic. But we also need a binary format for triples. EXI could be
> used, but I think RDF/XML is the wrong way. HDT [2] without the header
> and with quad support could be a solution.
>
> bergi
>
> Seems to me that sufficient 'complexity' exists to warrant the production
of some sort of Embedded OS engineering task-force.  This in-turn would
need to be established on the basis of agreed-principles / shared-values.
I don't have alot of time at present; and absolutely no funding to support
the pragmatics of a meaningful approach to solving some of these perceived
problems; perhaps that might change, yet given time marches on,

Any ideas who might be the best group to curate such an effort?

I'll have a bit more of a look.

Thankyou Again,

Timothy Holborn.
skype: sailing_digital

[1] https://en.wikipedia.org/wiki/Constrained_Application_Protocol
> [2] http://www.rdfhdt.org/hdt-internals/
>
> On 19.09.2016 03:34, Timothy Holborn wrote:
> > Hi Bergi,
> >
> > I've been meaning to develop an IoT device simply to build the
> > firmware.  The view is that RWW Styled implementations enable a retail
> > consumer to purchase a product, and that any contract associated to the
> > use of that device (save firmware upgrades, akin to life prior to WWW)
> > is simply optional / unnecessary.
> >
> > In my travels, i've obtained a GPS/WiFi/BlueTooth tracking device
> > marketed for PETS; alongside a Vehicle Device.  I haven't tested various
> > other devices in the marketplace (light globes, etc.) and having worked
> > in past with MFG's in ASIA; i understand that if demand is available,
> > they'll happily produce devices...
> >
> > IMHO; most of these devices are plugged into a particular 'app' that is
> > required to make the IoT / WoT device work.  Having recently been at a
> > conference - the consideration was put forth that perhaps a pace-maker
> > may be 'turned off' if the monthly subscription isn't paid!!  Or the
> > vehicle will not be able to be turned on, perhaps at a petrol station or
> > in a 1 hour parking spot where the vehicle may be towed after a certain
> > time...
> >
> > In some use-cases (ie: domestic violence) i can see use-cases where a
> > 3rd party may have access to the telemetry provided by the device for
> > law-enforcement purposes (ie: geo-fencing an individual subject to an
> > intervention /  restraining order); however these forms of particular
> > use-cases are different to having a particular app you must use for your
> > IoT / WoT door-lock...
> >
> > Within the WoT group (apologies if this exists, but i've not understood
> > or seen it) do we have a means to advertise functions of a device in a
> > manner that allows 3rd party app developers to easily build UX / UI;
> > inclusive of 'REC' surrounding methodologies that result in solutions
> > that are privacy-preserving?
> >
> > My working theory was that a 3d barcode could be used on a device to
> > share the 'private key', which could be stored on the device owners
> > data-space. Perhaps ideally a button could exist to create a new one if
> > needed (ie: relationship breakdown, etc.).
> >
> > Some of this is WoT other parts are outside of scope for W3C?
> >
> > USECASE:  AirBNB
> >
> > An AirBNB Host has WoT enabled their property.  an AirBnB API enables
> > the Property Host to facilitate billing and property management to the
> > tenant for the period of they're stay.  Once the guest/s has gone, the
> > Cleaner is able to access the property also. The next tenants arrive,
> > and he likes to ensure bread, milk and flowers are on the table.  The
> > property host is able to provide directions for where he wants these
> > things delivered, and they are able to access the property to do so.
> >
> > Cameras in the house are triggered for events he feels warrant such
> > actions, and a message is sent to the people in the property stating
> > this is the case with an approve mechanism prior to property access.
> >
> > Access is via approved devices (could be a phone, a card, etc.).  AirBnB
> > do not produce the apps that enable this function to happen, but rather
> > provide an API interface that other developers may build tools to
> support.
> >
> > The Property's smart devices communicate with the property owners RWW
> > data-space.  He is able to enable messaging with third parties.  He has
> > also used the available emergency services credentials as to enable
> > quick access to paramedics should one of his tenants require emergency
> > medical support, and is unable to open the door upon arrival of any-such
> > emergency service persons.
> >
> > ___________________________________________________________
> >
> > I haven't reviewed your links yet.  i will do so asap.
> >
> > Timothy Holborn
> > skype: sailing_digital
> >
> > On Mon, 19 Sep 2016 at 06:29 bergi <bergi@axolotlfarm.org
> > <mailto:bergi@axolotlfarm.org>> wrote:
> >
> >     Hi Tim,
> >
> >     I think most IoT/WoT standards use encrypted networks and
> authentication
> >     is done by sharing a key to that network or a gateway that does the
> >     access control. Encrypted networks can be WiFi or other (proprietary)
> >     protocols. Many gateways transfer the data to the cloud. Usually
> that's
> >     not very transparent.
> >
> >     Because bandwidth and memory can be very limited. The gateway is the
> >     best place to implement authentication with decentralized identities.
> >
> >     Dark Horse [1] will use that approach. It's a Node.js gateway/host
> using
> >     Express. A middleware could handle the authentication. There is
> already
> >     a module [2], but it should be ported to RDFJS spec and Passport [4].
> >
> >     I'm also trying to shift the protocol and data mapping from the
> gateway
> >     to the device. There is SmallHydra[5] for the ESP8266 and I'm
> working on
> >     a solution for RFMxx [6], maybe with LoRaWAN [7] support. OpenThread
> [8]
> >     would be also an option, but I haven't seen an Arduino
> implementation.
> >
> >     bergi
> >
> >     [1] https://github.com/bergos/dark-horse-server
> >     [2] https://github.com/bergos/pubkey-login
> >     [3] https://github.com/rdfjs/representation-task-force
> >     [4] http://passportjs.org/
> >     [5] https://github.com/bergos/smallhydra
> >     [6]
> >
> https://learn.adafruit.com/adafruit-rfm69hcw-and-rfm96-rfm95-rfm98-lora-packet-padio-breakouts/overview
> >     [7] https://github.com/matthijskooijman/arduino-lmic
> >     [8] https://github.com/openthread/openthread
> >
> >     Am 15.09.2016 um 10:19 schrieb Timothy Holborn:
> >     > I'm wondering what reference material may be available for IoT /
> WoT
> >     > device firmware / platform configurations, where the user is
> >     in-control
> >     > of the device.
> >     >
> >     > This in-turn reflects what i'd consider a 'service-centric'
> >     approach vs.
> >     > a 'human centric' approach.  In the 'human centric' approach,
> people
> >     > would purchase a device - much like they did in the years prior
> >     > to/advent of - WWW.  Drivers may be updated to support solving
> >     security
> >     > flaws or updating to newer standards for communications; but
> >     > essentially, the purchase decision does not require any
> >     > data-relationship with the vendor of the product.
> >     >
> >     > I envisage this could in-turn be done via a SoLiD[1] or RWW[2] like
> >     > architecture (perhaps inclusive of improvements to existing
> >     WebID-TLS[3]
> >     > support) with/without credentials[4] use-case support (most likely
> via
> >     > #digitalreceipts #web-payments & server-side interactions?)
> >     >
> >     > I'm interested in further information, links appreciated.
> >     >
> >     > Tim.H.
> >     >
> >     > [1] https://github.com/solid/solid
> >     > [2] https://www.w3.org/community/rww/
> >     > [3] https://en.wikipedia.org/wiki/Subject_Alternative_Name
> >     > [4] https://www.w3.org/community/credentials
> >     >
> >
>