Re: [projectvrm] Fuse, Carvoyant and Things

[James Pasquale < >]

I have three devices, some which suffered some bumps in the road during the installs.  To be direct one was a diesel truck the other a 1998 deville on the edge of ODB vehicle. Funky things happen to the onboard information centers in both. Most likely a carvoyant thing… 

With a little prodding Phil was able to allow one pico to be managed by two different Kynetx accounts.  In essences two people can look at the same vehicle particularly location, which for an elderly parent is big.  This is also what is a basic need for every device and user in the whole Internet of Me and My Stuff. Sorry for the shameless plug here…  A mixing board that allows user control of signal to noise ratios based on a persons needs, like a sounds engineer creating music, let’s call it a song of life that each and everyone of us wants our own and is different from each other.  Maybe easier said like this, whereas I need to have location services of certain fuse devices for a particular reason, I might not need all the other data that goes along with it. For whatever reason the owner might not want to share it or I might not need it. Being able to do that is Big in my mind, because it is so applicable in so many other scenarios. Phil’s effort is a big step in that direction, or see link below. Although doing the timezone adjustment calculations in the weekly Fuse report is a drag, there is hope it will be addressed soon.

http://www.windley.com/archives/2014/10/fuse_with_two_owners.shtml

It shouldn’t matter where a personal cloud is running from or how… as long as it is adhering to the principles. This is why I continue to believe in personal cloud services of all types under one mixing board umbrella.  Are their major hurdles to overcome, we all know there  are. Can they be accomplished, of course they can.  My belief is that when these things move into the early adopter phase from the innovation one, VRM and the consumer/customer driveling the conversation will be a natural evolution that all companies will want to hitch a wagon to.

We will have accomplished taking the existing business model and making obsolete replacing it with an entirely new and different approach. And the best part…. Companies will think it is their idea to engage. It is a matter of building beach heads and business development of sustainable models for companies building pCloud Services.

2015 is an interesting number… 2015 is mathematically sound. 20 is 4*5 and 15 is 3*5. 2015 is 5*13*31. 13 and 31 are reversed digit prime numbers. In binary 2015 is 11111011111, a palindrome. 2015 is also 3737 in base 8 (octal) and 37 is the most special number of all. For one thing, it’s the best age. For another, it’s the first irregular prime number!

/just jim….

On Jan 6, 2015, at 2:03 AM, =Drummond Reed < " class=""> > wrote:

Bret,

That strikes me as a nice, direct response. Thanks for weighing in.

=Drummond 

On Mon, Jan 5, 2015 at 8:53 PM, Bret Tobey < " target="_blank" class=""> > wrote:

Thanks for the CC. Carvoyant's a little jammed up supporting customers around CES but I'll jump into the discussion as time permits. We're transitioning the site, so the privacy policy may not be back up but our trademark basically says it "Your Car, Your Data, Your Control". Thanks for the catch and I'll check on that in the am. As for the device/agent split, ideally, yes, but not all agents are as virtuous as Phil, so Carvoyant has to assume some of that role since it may not always be present. Longer term, I think the philosophical alignment makes some form of co-opetition more likely than a head on collision. 

Looking forward to the rest of the conversation.

Bret

ᐧ

On Mon, Jan 5, 2015 at 11:42 PM, =Drummond Reed < " target="_blank" class=""> > wrote:

Great response, Phil. You nailed the key issues and are working as hard as anyone on the solutions. More power to you.

On Mon, Jan 5, 2015 at 8:10 PM, Phillip J. Windley Ph.D. < " target="_blank" class=""> > wrote:

Adrian,

Thanks for the note and the discussion. This is helpful and is why I’m interested in Fuse: it’s a chance to experiment with some of this and see what works and what doesn’t. 

Your split into device aggregators (DA) and virtual agent aggregators (VAA) is a good one (there are numerous names for the VAA business, but let’s stick with that for now). 

You may have picked up that Fuse is a name specifically chosen to emphasize the VAA business model and not the connected-car specifically. My vision is that Fuse could serve as a personal aggregation point for any connected thing and even things that aren't connected, but need an online presence (SquareTag was our first experiment in that area). Fuse is designed to be used from multiple hosting providers. Neustar, for example, could provide Fuse hosting services. I'm working now on self hosting so that people don't even have to trust a hosting company if they don't want to. 

The chief problem, of course, is that everyone wants to be in the VAA business because selling devices is so 20th century. Specifically Carvoyant’s roadmap, so far as I understand it, puts Carvoyant and Fuse on a business model collision path. 

Having said that, the business model clash is a long term problem.  We chose Carvoyant because they were a good match philosophically. I don't think Bret Tobey (CEO) is on this list, so I'm cc'ing him.  They used to have a privacy policy, not sure what happened. Carvoyant has also been a great technical partner who is willing to work with us on our needs. 

Adrian points out a big factor in the device aggregator side: encryption. Carvoyant has a (good) API and it's made my life easier.  That means, however that they also hold the data. Because they want to attract you to use their API with various apps, that's critical to their business model.  There's no reason why someone couldn't be in the business of offering the devices, a cellular to Internet gateway, firmware programming, streaming API, etc. as a business, but it's likely low-margin, high-volume. Every telco is fighting to get out of that space. 

As for labeling the device, we made it a Fuse device because no one understands any other model. They expect a silo. Would that they did not. :) On the other hand, I chose, later in the game than when I printed the device labels--I was writing code at this point, to make the Carvoyant relationship explicit because doing otherwise would lead to people having an account they don't know they have, an untenable situation in my opinion. 

My medium term goal (longer than a few weeks, shorter than a year) is to integrate the Automatic API for a few reasons:

1. That will illustrate better than any thing else that Fuse is about the data and using it, not the device.

2. That will force me to root out some assumptions in the code I'm sure are there relating to Carvoyant, try as I may to avoid them. 

3. That will make it more clear why there's a need to link to Carvoyant, Automatic, etc. because Fuse won't be anymore about the device itself. 

4. That will make it so that there was no "Fuse" device necessary.  Just Carvoyant, Automatic, and any other device that comes along with a usable API. 

I'm open to others participating in building that. In fact, I'd welcome it. There's plenty to do to build out this vision.  All the code is open source. 

I believe we have a good model and architecture. We've tried to make it private by design, although I'm sure there are places we could improve. One of the side affects of PbD is that I think, done right, it also leads to greater flexibility.  

For example, this week, I had a Fuse owner who wanted to have a vehicle in more than one fleet (so one of his clients could track just that vehicle without seeing his other 8 vehicles). Because of the pico architecture, that vehicle is isolated and it's relatively easy to create a relationship between it and the client's fleet in addition to the owner's fleet without additional programming.  The ability to parse and use multiple relationships is built into the underlying structure. 

In summary, Adrian has hit on a critical question for the Internet of Things. How will we split the silo so that we are free to use our devices with the data aggregator of our choice? I see Fuse as an experiment in answering that exact question.  

On Jan 4, 2015, at 1:44 PM, Adrian Gropper < " target="_blank" class=""> > wrote:

I finally activated my Fuse and read some of the posts on the Forum. This is a pioneering effort in IoT in a number of ways and worthy of support and consideration.

The post http://www.windley.com/archives/2014/12/fuse_kynetx_and_carvoyant.shtml clearly explains a vision for IoT based on two related aggregator businesses: a device aggregator like Carvoyant and a virtual agent aggregator like Kynetx. Having two cooperating businesses is what makes the Fuse VRM example interesting.

As I see it from a privacy engineering perspective, the device aggregator business (Carvoyant) should have as little to do with people as possible. The virtual agent business (Kynetx) should have as much to do with people as possible. To the extent that both businesses attempt to serve both devices and people, confusion and privacy issues ensue.

In the Fuse example, confusion abounds. As Phil puts it: "Indeed this has been the source of 90% of the support issues I deal with."

Confusion starts with the car API device being labeled Fuse instead of Carvoyant. As far as I can tell, neither Fuse or Kynetx has any control over the device firmware or policies, including privacy policies, of Carvoyant. I could not find any privacy policy on https://www.carvoyant.com/

A business that sells data to other businesses and has no visible privacy policy is what I call a data broker. Carvoyant is better than most data brokers in that they provide me with a login so I can see what they know about me, but this is little solace. Here's an unregulated broker that effectively monitors my whereabouts and presents no privacy policy. Who would knowingly agree to that?

How do we fix this? It probably starts with encrypting the data that leaves my car API with a key that Carvoyant doesn't have. That would take both Carvoyant and some of the cell provider (they can track my car _and_ me in the Fuse setup) out of the picture. The cell provider is regulated so their need for a visible privacy policy is much less than the other businesses in this Fuse story.

Unfortunately, the data broker's business model will not survive encryption. They need the plaintext data to provide the data cleaning services that Fuse needs to keep development costs in check. If all Fuse needed was a $1/mo cellular car API they could buy that directly from the regulated cell service provider.

I want to support Kynetx. I need to support at least one regulated telecom service provider. Is the data broker business model just a transitional artifact of this particular era in the Internet age?

Adrian

--

Adrian Gropper MD
Ensure Health Information Privacy. Support Patient Privacy Rights.
http://patientprivacyrights.org/donate-2/ 

--

Bret Tobey

CEO, Co-Founder, Carvoyant.com

" target="_blank" class="">bret@carvoyant.com

carvoyant.com/blog

Investor Link: angel.co/carvoyant
727 753 8454 - Office
562 233 8035 - Mobile

@batobey

@carvoyant

skype: bret.tobey