Category: Workshops (page 1 of 5)

We’re done with Phase One

Here’s a picture that’s worth more than a thousand words:


He’s with MAIF, the French insurance company, speaking at MyData 2016 in Helsinki, a little over a month ago. Here’s another:


That’s Sean Bohan, head of our steering committee, expanding on what many people at the conference already knew.

I was there too, giving the morning keynote on Day 2:


It was an entirely new talk. Pretty good one too, especially since  I came up with it the night before.

See, by the end of Day 1, it was clear that pretty much everybody at the conference already knew how market power was shifting from centralized industries to distributed individuals and groups (including many inside centralized industries). It was also clear that most of the hundreds of people at the conference were also familiar with VRM as a market category. I didn’t need to talk about that stuff any more. At least not in Europe, where most of the VRM action is.

So, after a very long journey, we’re finally getting started.

In my own case, the journey began when I saw the Internet coming, back in the ’80s.  It was clear to me that the Net would change the world radically, once it allowed commercial activity to flow over its pipes. That floodgate opened on April 30, 1995. Not long after that, I joined the fray as an editor for Linux Journal (where I still am, by the way, more than 20 years later). Then, in 1999, I co-wrote The Cluetrain Manifesto, which delivered this “one clue” above its list of 95 Theses:


And then, one decade ago last month, I started ProjectVRM, because that clue wasn’t yet true. Our reach did not exceed the grasp of marketers in the world. If anything, the Net extended marketers’ grasp a lot more than it did ours. (Shoshana Zuboff says their grasp has metastacized into surveillance capitalism. ) In respect to Gibson’s Law, Cluetrain proclaimed an arrived future that was not yet distributed. Our job was to distribute it.

Which we have. And we can start to see results such as those above. So let’s call Phase One a done thing. And start thinking about Phase Two, whatever it will be.

To get that work rolling, here are a few summary facts about ProjectVRM and related efforts.

First, the project itself could hardly be more lightweight, at least administratively. It consists of:

Second, we have a spin-off: Customer Commons, which will do for personal terms of engagement (one each of us can assert online) what Creative Commons (another Berkman-Klein spinoff) did for copyright.

Third, we have a list of many dozens of developers, which seem to be concentrated in Europe and Australia/New Zealand.  Two reasons for that, both speculative:

  1. Privacy. The concept is much more highly sensitive and evolved in Europe than in the U.S. The reason we most often get goes, “Some of our governments once kept detailed records of people, and those records were used to track down and kill many of them.” There are also more evolved laws respecting privacy. In Australia there have been privacy laws for several years requiring those collecting data about individuals to make it available to them, in forms the individual specifies. And in Europe there is the General Data Protection Regulation, which will impose severe penalties for unwelcome data gathering from individuals, starting in 2018.
  2. Enlightened investment. Meaning investors who want a startup to make a positive difference in the world, and not just give them a unicorn to ride out some exit. (Which seems to have become the default model in the U.S., especially Silicon Valley.)

What we lack is research. And by we I mean the world, and not just ProjectVRM.

Research is normally the first duty of a project at the Berkman Klein Center, which is chartered as a research organization. Research was ProjectVRM’s last duty, however, because we had nothing to research at first. Or, frankly, until now. That’s why we were defined as a development & research project rather than the reverse.

Where and how research on VRM and related efforts happens is a wide open question. What matters is that it needs to be done, starting soon, while the “before” state still prevails in most of the world, and the future is still on its way in delivery trucks. Who does that research matters far less than the research itself.

So we are poised at a transitional point now. Let the conversations about Phase Two commence.











VRM at MyData2016


As it happens I’m in Helsinki right now, for MyData2016, where I’ll be speaking on Thursday morning. My topic: The Power of the Individual. There is also a hackathon (led by going on during the show, starting at 4pm (local time) today. In no order of priority, here are just some of the subjects and players I’ll be dealing with,  talking to, and talking up (much as I can):

Please let me know what others belong on this list. And see you at the show.


At last, a protocol to connect VRM and CRM


We’ve been waiting a long time for a protocol to connect VRM (customers’ Vendor Relationship Management) with CRM (vendors’ Customer Relationship Management).

Now we have one. It’s called JLINC, and it’s from JLINC Labs. It’s also open source. You’ll find it at Github, here. It’s still early, at v.0.3. So there’s lots of opportunity for developers and constructive hackers of all kinds to get involved.

Specifically, JLINC is a protocol for sharing data protected by the terms under which it is shared, such as those under development by Customer Commons and the Consent and Information Sharing Working Group (CISWG) at Kantara.

The sharing instance is permanently recorded in a distributed ledger (such as a blockchain) so that both sharer and recipient have a permanent record of what was agreed to. Additionally, both parties can build up an aggregated view of their information sharing over time, so they (or their systems) can learn from and optimize it.

The central concept in JLINC is an Information Sharing Agreement (ISA). This allows for—

  1. the schema related to the data being shared so that the data can be understood by the recipient without prior agreement
  2. the terms associated with the data being shared so that they can be understood by the recipient without prior negotiation
  3. the sharing instance, and any subsequent onward sharing under the same terms, to be permanently recorded on a distributed ledger of subsequent use (compliance and analytics)

To test and demonstrate how this works, JLINC built a demonstrator to bring these three scenarios to life. The first one tackled is Intentcasting , a long-awaited promise of VRM. With an Intencast, the customer advertises her intention to buy something, essentially becoming a qualified lead. (Here are all the ProjectVRM blog posts here with the Intentcasting tag.)

Obviously, the customer can’t blab her buying intention out to the whole world, or marketers would swarm her like flies, suck up her exposed data, spam her with offers, and sell or give away her data to countless other parties.

With JLINC, intention data is made available only when the customer’s terms are signed. Those terms specify permitted uses. Here is one such set (written for site visiting, rather than intentcasting):


These say the person’s (first party’s) data is being shared exclusively with the second party (the site), for no limit in time, for the site’s use only, provided the site also obey the customer’s Do Not Track signal. I’m showing it because it lays out one way terms can work in a familiar setting

For JLINC’s intentcasting demonstration, terms were limited to second party use only, and a duration of thirty days. But here’s the important part: the intentcast spoke to a Salesforce CRM system, which was able to—

  1. accept or reject the terms, and
  2. respond to the intentcast with an offer,
  3. while the handshake between the two was recorded in a blockchain both parties could access

This means that JLINC is not only a working protocol, but that there are ways for VRM tools and systems to use JLINC to engage CRM systems. It also means there are countless new development opportunities on both sides, working together or separately.

Here’s another cool thing:  the two biggest CRM companies, Salesforce and Oracle, will hold their big annual gatherings in the next few weeks. This means JLINC and VRM+CRM can be the subjects of both conversation and hacking at either or both events. Specifically, here are the dates:

  1. Oracle’s OpenWorld 2016 will be September 18-22.
  2. Salesforce’s Dreamforce 2016  will be October 4-7.

Both will be at the Moscone Center in San Francisco.

Conveniently, the next VRM Day and IIW will both also happen, as usual, at the end of October:

  1. VRM Day will be October 24.
  2. Internet Identity Workshop (IIW’s XXIIIth) will be October 25-27.

Both will take place at the Computer History Museum, in downtown Silicon Valley. And JLINC, which was launched at the last VRM Day, is sure to be a main topic of discussion, starting at VRM Day and continuing through IIW, which I consider the most leveraged conference in the world, especially for the price.

If all goes well, we’ll have some examples of VRM+(Oracle and/or Salesforce) CRM to show off at Demo Day at IIW.

Love to see other CRM vendors show up too. You listening, SugarCRM? (I spoke about VRM+CRM at SugarCon in 2011. Here’s my deck from that talk. What we lacked then, and since, was a protocol for that “+”. Now we have it. )

Big HT to Iain Henderson of both JLINC Labs and Customer Commons, for guiding this post, as well as conducting the test that showed, hey, it can be done!






IoT & IoM next week at IIW


(This post was updated and given a new headline on 20 April 2016.)

In  The Compuserve of Things, Phil Windley issues this call to action:

On the Net today we face a choice between freedom and captivity, independence and dependence. How we build the Internet of Things has far-reaching consequences for the humans who will use—or be used by—it. Will we push forward, connecting things using forests of silos that are reminiscent the online services of the 1980’s, or will we learn the lessons of the Internet and build a true Internet of Things?

In other words, an Internet of Me (#IoM) and My Things. Meaning things we own that belong to us, under our control, and not puppeted by giant companies using them to snarf up data about our lives. Which is the  #IoT status quo today.

A great place to work on that is  IIW— the Internet Identity Workshop , which takes place next Tuesday-Thursday, April 26-28,  at the Computer History Museum in Silicon Valley. Phil and I co-organize it with Kaliya Hamlin.

To be discussed, among other things, is personal privacy, secured in distributed and crypto-secured sovereign personal spaces on your personal devices. Possibly using blockchains, or approaches like it.

So here is a list of some topics, code bases and approaches I’d love to see pushed forward at IIW:

  • OneName is “blockchain identity.”
  • Blockstack is a “decentralized DNS for blockchain applications” that “gives you fast, secure, and easy-to-use DNS, PKI, and identity management on the blockchain.” More: “When you run a Blockstack node, you join this network, which is more secure by design than traditional DNS systems and identity systems. This  is because the system’s registry and its records are secured by an underlying blockchain, which is extremely resilient against tampering and control. In the registry that makes up Blockstack, each of the names has an owner, represented by a cryptographic keypair, and is associated with instructions for how DNS resolvers and other software should resolve the name.” Here’s the academic paper explaining it.
  • The Blockstack Community is “a group of blockchain companies and nonprofits coming together to define and develop a set of software protocols and tools to serve as a common backend for blockchain-powered decentralized applications.” Pull quote: “For example, a developer could use Blockstack to develop a new web architecture which uses Blockstack to host and name websites, decentralizing web publishing and circumventing the traditional DNS and web hosting systems. Similarly, an application could be developed which uses Blockstack to host media files and provide a way to tag them with attribution information so they’re easy to find and link together, creating a decentralized alternative to popular video streaming or image sharing websites. These examples help to demonstrate the powerful potential of Blockstack to fundamentally change the way modern applications are built by removing the need for a “trusted third party” to host applications, and by giving users more control.” More here.
  • IPFS (short for InterPlanetary File System) is a “peer to peer hypermedia protocol” that “enables the creation of completely distributed applications.”
  • OpenBazaar is “an open peer to peer marketplace.” How it works: “you download and install a program on your computer that directly connects you to other people looking to buy and sell goods and services with you.” More here and here.
  • Mediachain, from Mine, has this goal: “to unbundle identity & distribution.” More here and here.
  • telehash is “a lightweight interoperable protocol with strong encryption to enable mesh networking across multiple transports and platforms,” from @Jeremie Miller and other friends who gave us jabber/xmpp.
  • Etherium is “a decentralized platform that runs smart contracts: applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third party interference.”
  • Keybase is a way to “get a public key, safely, starting just with someone’s social media username(s).”
  • ____________ (your project here — tell me by mail or in the comments and I’ll add it)

In tweet-speak, that would be @BlockstackOrg, @IPFS, @OpenBazaar, @OneName, @Telehash, @Mine_Labs #Mediachain, and @IBMIVB #ADEPT

On the big company side, dig what IBM’s Institute for Business Value  is doing with “empowering the edge.” While you’re there, download Empowering the edge: Practical insights on a decentralized Internet of Things. Also go to Device Democracy: Saving the Future of the Internet of Things — and then download the paper by the same name, which includes this graphic here:


Put personal autonomy in that top triangle and you’ll have a fine model for VRM development as well. (It’s also nice to see Why we need first person technologies on the Net , published here in 2014, sourced in that same paper.)

Ideally, we would have people from all the projects above at IIW. For those not already familiar with it, IIW is a three-day unconference, meaning it’s all breakouts, with topics chosen by participants, entirely for the purpose of getting like-minded do-ers together to move their work forward. IIW has been doing that for many causes and projects since the first one, in 2005.

Register for IIW here:

Also register, if you can, for VRM Day: That’s when we prep for the next three days at IIW. The main focus for this VRM Day is here.

Bonus link: David Siegel‘s Decentralization.




VRM Day: Let’s talk UMA and terms

VRM Day and IIW are coming up in October: VRM Day on the 26th, and IIW on the 27th-29th. As always, both are at the Computer History Museum in the heart of Silicon Valley. Also, as always, we would like to focus  VRM day on issues that will be discussed and pushed forward (by word and code) on the following days at IIW.

I see two.

The first isUMA-logo UMA, for User Managed Access. UMA is the brainchild of Eve Maler, one of the most creative minds in the Digital Identity field. (And possibly its best singer as well.) The site explains, “User-Managed Access (UMA) is an award-winning OAuth-based protocol designed to give a web user a unified control point for authorizing who and what can get access to their online personal data, content, and services, no matter where all those things live on the web. Read the spec, join the group, check out the implementations, follow us on Twitter, like us onFacebook, get involved!”

Which a number of us in the #VRM community already are — enough, in fact, to lead discussion on VRM Day.

In Regaining Control of Our Data with User-Managed Access, Phil Windley calls VRM “a perfect example of the kind of place where UMA could have a big impact. VRM is giving customers tools for managing their interactions with vendors. That sounds, in large part, like a permissioning task. And UMA could be a key piece of technology for unifying various VRM efforts.”

For example, “Most of us hate seeing ads getting in the way of what we’re trying to do online. The problem is that even with the best “targeting” technology, most of the ads you see are wasted. You don’t want to see them. UMA could be used to send much stronger signals to vendors by granting permission for them to access information would let them help me and, in the process, make more money.”

We call those signals “intentcasting.”

Yet, even though our wiki lists almost two dozen intentcasting developers, all of them roll their own code. As a result, all of them have limited success. This argues for looking at UMA as one way they can  substantiate the category together.

A large amount of activity is going into UMA and health care, which is perhaps the biggest VRM “vertical.” (Since it involves all of us, and what matters most to our being active on the planet.)

The second topic is terms. These can take two forms: ones individuals can assert (which on the wiki we call EmanciTerm); and truly user- and customer-friendly ones sites and services can assert. (Along with truly agreeable privacy policies on both sides.)

At last Fall’s VRM Day, we came up with one possible approach, which looked like this on the whiteboard:

UserTerms1This was posted on Customer Commons, which is designed to serve the same purpose for individual terms as Creative Commons does for individual artists’ copyright terms. We can do the same this time.

Lately Meeco has come out with terms individuals can set. And there are others in the works as well. (One in particular will be of special interest, but it’s not public yet. I expect it will be, by VRM Day.)

So be sure to register soon. Space is limited.

Bonus links/tweets: here and here.



Preparing for the 3D/VR future

Look in the direction that meerkatMeerkat and periscopeappPeriscope both point.

If you’ve witnessed the output of either, several things become clear about their evolutionary path:

  1. Stereo sound is coming. So is binaural sound, with its you-are-there qualities.
  2. 3D will come too, of course, especially as mobile devices start to include two microphones and two cameras.
  3. The end state of both those developments is VR, or virtual reality. At least on the receiving end.

The production end is a different animal. Or herd of animals, eventually. Expect professional gear from all the usual sources, showing up at CES starting next year and on store shelves shortly thereafter. Walking around like a dork holding a mobile in front of you will look in 2018 like holding a dial-phone handset to your head looks today.

I expect the most handy way to produce 3D and VR streams will be with  glasses like these:


(That’s my placeholder design, which is in the public domain. That’s so it has no IP drag, other than whatever submarine patents already exist, and I am sure there are some.)

Now pause to dig @ctrlzee‘s Fast Company report on Facebook’s 10-year plan to trap us inside The Matrix. How long before Facebook buys Meerkat and builds it into Occulus Rift? Or buys Twitter, just to get Periscope and do the same?

Whatever else happens, the rights clearing question gets very personal. Do you want to be broadcast and/or recorded by others or not? What are the social and device protocols for that? (The VRM dev community has designed one for the glasses above. See the ⊂ ⊃ in the glasses? That’s one. Each corner light is another.)

We should start zero-basing the answers today, while the inevitable is in sight but isn’t here yet. Empathy is the first requirement. (Take the time to dig Dave Winer’s 12-minute podcast on the topic. It matters.) Getting permission is another.

As for the relevance of standing law, almost none of it applies at the technical level. Simply put, all copyright laws were created in times when digital life was unimaginable (e.g. Stature of Anne, ASCAP), barely known (Act of 1976), or highly feared (WIPO, CTEA, DMCA).

How would we write new laws for an age that has barely started? Or why start with laws at all? (Nearly all regulation protects yesterday from last Thursday. And too often its crafted by know-nothings.)

We’ve only been living the networked life since graphical browsers and ISPs arrived in the mid-90’s. Meanwhile we’ve had thousands of years to develop civilization in the physical world. Which means that, relatively speaking, networked life is Eden. It’s brand new here, and we’re all naked. That’s why it’s so easy anybody to see everything about us online.

How will we create the digital equivalents of the privacy technologies we call clothing and shelter? Is the first answer a technical one, a policy one, or both? Which should come first? (In Europe and Australia, policy already has.)

Protecting the need for artists to make money is part of the picture. But it’s not the only part. And laws are only one way to protect artists, or anybody.

Manners come first, and we barely have those yet, if at all. None of the big companies that currently dominate our digital lives have fully thought out how to protect anybody’s privacy. Those that come closest are ones we pay directly, and are financially accountable to us.

Apple, for example, is doing more and more to isolate personal data to spaces the individual controls and the company can’t see. Google and Facebook both seem to regard personal privacy as a bug in online life, rather than a feature of it. (Note that, at least for their most popular services, we pay those two companies nothing. We are mere consumers whose lives are sold to the company’s actual customers, which are advertisers.)

Bottom line: the legal slate is covered in chalk, but the technical one is close to clean. What do we want to write there?

We’ll be talking about this, and many other things, at VRM Day (6 April) and IIW (7-9 April) in the Computer History Museum in downtown Silicon Valley (101 & Shoreline, Mountain View).

Designing the VRM future at IIW

A veteran VRooMeriiwxx tells me a design fiction would be a fun challenge for VRM Day and IIW (which will run from April 6-9 at the Computer History Museum in Mountain View, CA).

He describes one as “basically a way of peeking into the near future by demonstrating an imaginary product that doesn’t exist, but could. For example, instead of talking about a possible VRM product, one instead would create a marketing brochure, screen mockups or a fake video advertisement for this imaginary product as a way to help others understand where the world is headed and possibly even further the underlying technologies or driving concepts.”

Coincidentally, the subject of VRM Day (and a focus for the three days that will follow at IIW) is a maturity model framework that will provide every VRM developer the same single sheet (or set of them) on which to show where they stand in developing VRM capabilities into their company, product, code base or whatever else they’re working on. Work has already started on it, and those doing the work will present a first draft of it on VRM Day.

You know the old saying, “all singing from the same song sheet”? The VRM maturity model framework is it. Think of it as a musical score that is starting to be written, for an orchestra will come together. When we’re done with this round, we’ll at least know what the score describes, and give the players of different instruments enough of a framework so they know where they, and everybody else, fits.

By the end of IIW, it should be ready to do several things:

  1. Provide analysts with a single framework for understanding all VRM developers and development, and the coherencies among them.
  2. Give VRM developers a way to see how their work complements and/or competes with other VRM work that’s going on — and guide future developments.
  3. Give each developer a document to use for their own internal and external purposes.
  4. Give CRM, CE. CX and other vendor-side systems a clear picture of what pieces in the VRM development community will connect with their systems, and how, so buyer-side and seller-side systems can finally connect and grow together.

While we do this, it might also be fun to work out a design fiction as a summary document or video. What would the complete VRM solution (which will surely be a collection of them) look like? How would we present it as a single thing?

All of this is food for thinking and re-thinking. Suggestions invited.

VRM Day and IIW XX

The most important weeks on the VRM calendar are those when IIW — the Internet Identity Workshop — takes place. There are two per year, in Spring and Fall, and they are hosted by Kaliya Hamlin,  Phil Windley and myself at the Computer History Museum in Silicon Valley.

The next is April 7-9. Leading into it is VRM Day, which is on April 6.

IIW is an unconference, which means there are no speakers or panels, and sponsors (which we appreciate hugely) just cover our meals, snacks and barista. All the topics of the workshop are vetted and posted the start of each of IIW’s three days, and every topic is discussed in breakout sessions spread across the venue’s many rooms and tables.

IIW is ideal for pushing topics and dev work forward. VRM has many topics, of course: intentcasting, personal data management (aka clouds, vaults, lockers, stores, services, etc.), VRM-meets-CRM (including CX, CE and other two- and three-letter acronyms), IoT, intelligent assistants, the Indie Web (and indie everything), emerging and wannabe standards and shared code bases, and all the other kinds of things listed on the ProjectVRM wiki development page.

This next one will be our XXth. All of them are important, but this one will be especially so, because we will be sorting out how various VRM projects fit together, compete, support each other, and engage systems on the big vendor and enterprise side.

In fact that topic will be the main focus of VRM Day, where we will vet a VRM framework document based on a maturity model that will give everybody a way to show how far along they are in different development areas.

This is the document VRM developers will share with analysts, enterprises and big vendors who need to know how real VRM is becoming, and who plays what roles in the emerging market space.

Here is the link to register for VRM Day.

And here is the one for IIW XX.

Look forward to seeing you there.

The answer is #CFT: Clouds For Things

My last post asked, How do you maximize the help that companies and customers give each other? My short answer is in the headline above. Let me explain.

The house where I’m a guest in London has clouds for all its appliances. All the clouds are physical. Here they are:

House cloud

Here is a closer look at some of them:

House cloud closeup

Each envelope contains installation and instruction manuals, warranty information and other useful stuff. For example, today I used an instruction manual to puzzle out what these symbols on the kitchen’s built-in microwave oven mean:


Now let’s say I didn’t have the directions handy. How would I find them? Obviously, on the Web, right? I mean, you’d think.

So I went to the site of Atag, the oven’s maker.  From eyeballing the microwave, I gathered that the one in the kitchen is  this one: the Combi-Microwave MA4211B. On the Atag website I found it buried in Kitchen Appliances —> Collection —> Microwaves, where it might also be the MA4211A or MA4211T. Hard to tell. Directions for its use appeared to be under Quality and Service —> Visit ATAG Service Support. There I found this:


When I clicked on “Download the User Manual,” I got this:


For “type number” I guessed MA4211B, entered it in the search field and got this:


I got the same results clicking on both:


Nothing actually downloaded, and the Acrobat Reader information was useless to me. So I clicked on “No.” That got me this:


I then hit “I want to stop.” That looped me back to the search panel, three screenshots up from here.

In other words, a complete fail. Since the copyright notice is dated 2007 — eight years ago — I assume this fail is a fossil.

There are three reasons for this fail, and why its endemic to the entire service industry:

  1. The company bears the full burden of customer service.
  2. Every company serves customers differently.
  3. There is no single standard or normalized way for companies and customers to inform each other online.

What’s missing is a way to give customers scale — for the good of both themselves and the companies they deal with. Customers have scale with cash, credit cards, telephony, email and many other tools and systems. But not yet with a mechanism for connecting to any company and exchanging useful information in a standard way.

We’ve  been moving in that direction in the VRM development community, by working on personal data services, stores, lockers, vaults and clouds. Those are all important and essential efforts, but they have not yet converged around common standards, protocols and customer experiences. Hence, scale awaits. What this house models, with its easily-accessed envelopes for every appliance, is a kind of scale: a simple and standardized way of dealing with many different suppliers — a way that is the customer’s own.

Now let’s imagine a simple  digital container for each appliance’s information: its own cloud. In form and use, it would be as simple and standard as a file folder. It would arrive along with the product, belong to the customer*, and live in the customer’s own personal data service, store, locker, vault, cloud or old-fashioned hard drive.  Or, customers could create them for themselves, just like the owner of the house created those file folders for every appliance. Put on the Net, each appliance  would join the Internet of Things, without requiring any native intelligence on the things themselves.

There, on the Net, companies could send product updates and notifications directly into the clouds of each customer’s things. And customers could file suggestions for product improvements, along with occasional service requests.

This would make every product’s cloud a relationship platform: a conduit though which the long-held dreams of constant product improvement and maximized customer service can come true.

Neither of those dreams can come true as long as every product maker bears the full responsibility for intelligence gathering and customer support — and does those  differently than every other company. The only way they can come true is if the customers and their things have one set of standard ways to stay in touch and help each other. That’s what clouds for things will do. I see no other way.

So let’s get down to it, starting with a meme/hashtag representing Clouds For Things : #CFT.

Next, #VRM developers old and new need to gather around standard code, practices and protocols that can make #CFT take off.  Right now the big boys are sucking at that, building feudal fiefdoms that give us the AOL/Compuserve/Prodigy of things, rather than the Internet of Things.  For the whole story on this mess, read Bruce Sterling‘s e-book/essay The Epic Struggle for the Internet of Things, or the chunks of it at BoingBoing and in this piece I wrote here for Linux Journal.

We have a perfect venue for doing the Good Work required for both IoT and CFT — with IIW, which is coming up early this spring: 7-9 April. It’s an inexpensive unconference in the heart of Silicon Valley, with no speakers or panels. It’s all breakouts, where participants choose the topics and work gets done. Register here.

We also have a lot of thinking and working already underway. The best documented work, I believe, is by Phil Windley (who calls CFTs picos, for persistent compute objects). His operating system for picos is CloudOS. His holdings-forth on personal clouds are here. It’s all a good basis, but it doesn’t need to be the only one.

What matters is that #CFT is a $trillion market opportunity. Let’s grab it.

* I just added this, because I can see from Johannes Ernst’s post here that I didn’t make it clear enough.






What would a VRM social network be?

The Big Bang of Social Networking 128px-Emoji_u1f4c7.svgis a piece by Jim Dwyer in The New York Times that will likely be a subject of a session today or tomorrow at IIW. So here are a few thoughts of my toward that discussion…

  1. All of us had social networks before Facebook, Diaspora and Ello existed. We still do. They’re in our heads, hearts, contact lists and address books.
  2. Facebook, Diaspora* and Ello are silo’d commercial services. They do serve many social purposes, of course, and a few very well, or they wouldn’t be so popular.
  3. If we want real social networks online, we need to start with our own genuine personal ones.
  4. To be VRM, they need to support independence and engagement. They should also be substitutable in the same way that, say, browsers and email apps and services are substitutable.

It is essential to start outside the box of thinking that says everything needs to be a service. Inside that box we risk thinking only of other calf-cow solutions to calf-cow problems.

Facebook and Ello are both cows. Even though one doesn’t advertise at us, we’re still calves in its fenced farm.

Unless, of course, we can take our social graphs away with us, to use on our own, or with some substitutable service.

VRM social network solutions to the problems of calf-cow designs need to be first person technologies. At that link, I explain,

Only a person can use the pronouns  “I,” “me,” “my” and “mine.” Likewise, only a person can use tools such as screwdrivers, eyeglasses and pencils. Those things are all first person technologies. They were invented for individual persons to use.

I suggest we start with address books and calendars. Those could not be more personal, yet more social. And, far as I know, nobody has yet done them in a way that’s useful for scaffolding the successor to Facebook on top of them. But that shouldn’t stop us.

* [Later…] This was a copy/paste/rush error.  In fact Diaspora is quite VRooMy. The Wikipedia  entry makes that clear.



Older posts

© 2016 ProjectVRM

Theme by Anders NorenUp ↑