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

It looked to me like the Eddystone method relies upon the Google cloud?

The RWW method sought to provide independence as an alternatives?

I note various linked-data-notifications related works,

But is what you're saying mean I'm misunderstanding the Google offer? I
hadn't confidently found a solution that was independeny, which I blamed on
the lack of a RWW like solution to plug it into...

The owner of the device would need a standards based place to store the
data / telemetry, then, I envisage, support ontology orientated
accessible factors...

Re: bootstrapping, agreed.  Perhaps simpler than doing something similar by
loading-up Ubuntu and solid-node-server, to test an alternative POC... ;)

I was planning to get a raspberry PI, adding some solid-state relays and


On Tue., 20 Sep. 2016, 3:18 am Nathan Rixham, <> wrote:

> I looked at something similar, and decided that google's approach to the
> "physical web", using a bluetooth beacon, was probably a very simple and
> quick starting point. Nothing simpler than an android phone acting as a
> beacon for test development, broadcasting an URL and a location - there's a
> bootstrap point right there.
> On Mon, Sep 19, 2016 at 2:34 AM, 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?
>> 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 <> 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]
>>> [2]
>>> [3]
>>> [4]
>>> [5]
>>> [6]
>>> [7]
>>> [8]
>>> 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]
>>> > [2]
>>> > [3]
>>> > [4]
>>> >

Received on Monday, 19 September 2016 17:34:54 UTC