1. I wrote a blog post called Please Send Wicked Simple Email inspired by the jaw-dropping great messages T.Rob Wyatt was sending to the VRM (Vendor Relationship Management) and personal cloud mailing lists. I lobbied for T.Rob’s thoughts to be going onto his excellent blog for easier & longer term sharing.
2. Today T.Rob does just that and puts up a killer blog post about why we need VRM from a privacy and personal data rights standpoint that argues the case as strongly as anything since John Kelly’s killer talk on personal clouds at Gartner Symposium or Doc Searls book The Intention Economy.
3. I read T.Rob’s post and realize he’s nailed it so well that he explains exactly why we needed to define the Respect Trust Framework before we could build the Respect Network.

Here is the paragraph where T.Rob nails it:

VRM, or Vendor Relationship Management, is a new approach to conducting business in which the missing physical constraints [for protecting privacy and personal data] have been replaced by technological and policy constraints that restore the balance of power between individuals and their vendors, and perhaps to some extent also their governments.

Now read this purpose statement from the first line of the Respect Trust Framework:

The purpose of the Respect Trust Framework is to define a simple set of principles and rules to which all Members of a digital trust network agree so that they may share identity and personal data with greater confidence that it will be protected and only used as authorized.

Separated at birth…and I don’t know if T.Rob has even seen the Respect Trust Framework.

Given the depth of his knowledge and research, I wouldn’t be surprised—I just haven’t heard him mention it yet. But no matter—he came to exactly the same conclusion as those of us founding the Respect Network: the privacy-invading technology genie is out of the bottle and there’s no stuffing him/her back in. So the alternative is to “restore the balance of power” a different way, with an opt-in network where everyone agrees to play by a new set of rules.

I can hardly wait to get the network fully operational—all I can say is that the 24 Respect Network Founding Partners are working like mad to get there. If you want an in-depth progress report, come see us at the next Internet Identity Workshop coming up in Mountain View May 7-9.

#1: Treat the Subject Line as a Tweet

Despite all it’s faults, Twitter has taught the importance of brevity. In particuar, the 140 character limit has forced us to figure out how to filter messages in that short space. Apply these learnings to email!

1. If you want a particular person to read/respond to a particular email, put his/her name directly in the subject line—just like a Twitter @reply.
2. If you want to signal that an email is about a particular topic, put a #hashtag in the subject line (especially helpful for mailing lists).
3. If you want to signal that an email is time-sensitive, put the date/time requirement in the subject line.

#2: No Sigs

Over the last year, I began dropping my sig on more and more of my emails, and I noticed others doing it too. I suspect it’s spreading from Facebook messaging, where no one uses a sig. In any case, here’s why it’s a good idea:

1. Unless you have your sig auto-attached to every message (a stupendously bad idea—please stop immediately), it saves at least a few keystrokes every email even if all you’re adding is your first name or initials.
2. For 99% of the messages you send, it’s extraneous anyway. Pure dead weight. Your recipients know who you are or can easily find out.
3. Eliminating sigs makes messages less formal, more conversational, and more immediate—all encouraging them to stay short and lightweight.
4. In many cases it’s not even needed to signal the end of your message. If yours is the first message in a thead, just stop when you are done. If you are replying inline (below), just add your replies and delete the rest of the message.
5. Most importantly, it interrupts the flow of inline replies. Read on….
   

#3: Reply Inline Whenever Possible

Modern email clients default to putting each reply in a thread above the previous one. Thus started the biggest time-suck in email history. Why?

1. The context is already there in the previous message. You don’t need to repeat one word.
2. Replies can extremely short and precise. Just add your reply at the exact point needed. Don’t wait until the end of a paragraph—or even the end of a sentence. Just pick the precise spot where you need to respond, click Enter, and type.
3. The thread remains clear—right down to the “voice” of each sender, which can be much more important than you think.
4. Deep threads are discouraged! Read on….

#4: Hold Deeply Threaded Conversations Elsewhere

We’ve all learned it by now: email sucks for deeply threaded conversations. It always will. So:

1. Avoid going more than three levels deep—four at the most. Beyond that, start a new thread (following rule #1 above).
2. Even that only works if responses stay short – preferably a few sentences.
3. For anything else, use a real threaded conversation forum—a blog, wiki, Basecamp, social network discussion group, etc.

#5: One Screen Max

20 years has taught me one simple lesson: if it’s longer than one screen, don’t send it as an email. In fact if it takes more than a paragraph or two it probably shouldn’t be an email. Why?

1. If it’s got that much thought in it, it should be reusable—and linkable. Email is where thoughts go to die.
2. Longer writing should use real writing tools—headings, bulleted lists, images.
3. People don’t like to read long emails. They want to process their email quickly to determine how to prioritize the rest of their time.

So if what you want to communicate is more than one screen, do this: type it up as blog entry, Google doc, social network group post, Basecamp post, or anywhere your recipients can read, refer, and respond to it (i.e., have that threaded conversation). Then send a short email with a link and an executive summary explaining why recipients should read it. The summary is really important—many folks get far too many links to read, so give them a few bullet points about why to read yours. And, of course, make the subject line of that email the tweet you would (or will) send to share it on Twitter.

Footnotes:

1. This blog post started as an email I wanted to send to members of a mailing list I’m on that’s experienced a recent sharp increase in volume. Then I applied rule #5 and here it is.
2. The one place where it is natural to use a sig is on an introduction email, just like you would a written letter. So use it there and leave it out everywhere else.
3. When joining a new thread, I may still add my first name as a sig at the end of my reply just for context. But in future replies it’s usually not needed.
4. I left out one other golden rule of email—never send an emotional email—because that’s a different subject altogether. But it’s still a rule I recommend very strongly.
5. My good friend Victor Grey adds one more tip: always assume that the recipients of your email will forward it on to anyone else that you mentioned.
6. Another good friend Steve Greenberg suggests another guideline: Ask only one question per email.

[UPDATE: See the detailed writeup on this meetup (including highlights from all 7 talks) posted to the Respect Network website.]

The first Personal Cloud Meetup in San Francisco last month was so successful that the second one is upon us already. Hosted by Orange Silicon Valley, it’s next Tuesday night from 6-9PM at their offices at 60 Spear Street between Mission and Market in downtown SF.

There’s already a full lineup of speakers, including Kaliya “Identitywoman” Hamlin, Executive Director of the Personal Data Ecosystem Consortium; Miten Sampat of Neustar; T.Rob Wyatt of IBM; and Joe Johnston of Respect Network.

Respect Network CEO Gary Rowe and I will both be there, and with crowds converging for RSA next week as well, it should be a ripe opportunity for personal cloud connections.

Signup on Eventbrite.

But just in the last few weeks—since the first Personal Cloud Meetup in San Francisco last month—the answer has started screaming at me: the killer app IS the personal cloud!

What does this mean? Read this (about having all my digital gear stolen). And then this (about having Facebook access turned off). And then this (Phil Windley’s latest blog post about the Tesla car spying fiasco). And then answer me: do you have a place to safely store all of your personal and household digital assets (files, photos, receipts, contacts, calendars, financial records, medical records, product usage data, etc.) where you know:

1. They will always be safe, even if your house burns down or you lose all your devices?
2. You, your spouse, or your family’s access to them cannot be turned off by a third-party service provider because of its own terms-of-service provisions?
3. If you permission apps or services to store data there, you alone will control the rights to access and share that data (like you do on your own computer)?
4. You can share any of your digital assets with any party you want on your own terms?
5. All of your personal digital assets are all fully portable, and ideally mirrored across multiple independent service providers?

If your answer is yes, please tell me more. If your answer is no, now you know why the personal cloud—a truly PERSONAL cloud that can deliver all of the above— is the killer app.

My latest favorite example is the Book as API post from Alistair Croll’s Solve for Interesting blog. It’s about a talk he and Hugh McGuire gave at O’Reilly’s Tools Of Change conference about the future of the book. It describes how havng an API can unlock the value of the intellectual energy in every book the same way a user interface unlocks the power of a software program.

Read it and you will never look at a book the same way again.

In my case, reading this post through my XDI lens, I saw something even deeper: the future format of books. It starts with the point Hugh makes on slide 97 of his and Alistair’s 100 slide presentation:

Books are made of stuff that can be named.

Hugh then goes on to say in slide 98:

If you name your stuff in HTML (while indexing!), then we can (easily) build new uses/interfaces for our books…

Of course he’s right. The “indexing” Hugh refers to is semantic HTML as explained earlier in his presentation (slides 59-73). But if you “name your stuff” in XDI, then it’s not just semantically understandable, the book and all its contents are globally addressable and composable and semantically reusable (subject to the relevant XDI link contracts) anywhere else it can provide value.

Alistair ends his post:

The killer feature of the book [of the future] is it’s API.

I would go a step further: the killer feature of the book of the future is that it’s an XDI graph.

(Update 2013-02-12: I’m halfway through the book now and it’s only getting better.)

Setting a new precedent here – blogging about a book even before I’ve finished reading the first chapter. But I’m reading Trillions at the recommendation of several close friends in the industry (Phil Windley, Peter Vander Auwera) who believe it’s highly relevant to where we are going with personal clouds and XDI. And just the introduction makes so much sense that I know I’m going to savor every chapter.

If you want to see why, just watch this brilliant 3-minute video from MAYA, the company behind the book.

The closest analogy is the atom — what seems so simple at a conceptual level turns out to have oceans of complexity swirling beneath it when you ask the devil for the details.

So in this field I especially prize clear thinking and modeling (I would go so far as saying that XDI would be impossible without it.)

For a shining example, look no further than Anil John’s new blog entry, A Model for Separating Token and Attribute Manager Functions. I especially like how the model reveals key differences between four different real world identity systems, including the currently popular social login model.

[Update: for the ideas leading to his model, Anil credits Andrew Hughes, Ken Dagg, David Wasley and Colin Soutar from the Kantara Identity Assurance Working Group.]

But rarely have I seen technologies that work so well together as KRL and XDI. Besides their uncanny synergy in personal cloud architecture, recently Phil has done two blog posts about PDOs (“persistent data objects”):

• Programing the Cloud With Persistent Data Objects
• Building a Blog with Personal Clouds

As I read each of these points, every place I see the term “PDO” I read “XDI graph”. XDI is a way to have universal interoperability and portability of PDOs. (This doesn’t mean that every PDO must use XDI, just that XDI is a way to have widely interoperable PDOs.)

That immediately explains the synergy between XDI and KRL: as a rules language and CloudOS, KRL provides a way to write programs to work with PDOs anywhere in the cloud, and XDI is a way to address, serialize, and exchange those PDOs.

If you start from a conventional object-oriented perspective (hmmm, I remember back when object orientation was the radical new perspective ), here’s another way to think about it: if XDI provides interoperable data abstraction, KRL provides interoperable method abstraction.

In other words, KRL provides a rules-based mechanism that enables a developer to apply a method (“action”) to any PDO that satisfies the necessary conditions (“event”) to fire that method.

No wonder KRL and XDI are digital chocolate and peanut butter.

So I’m updating the diagram I posted in August just to make sure it’s still clear: a personal cloud is to a personal data vault what a personal computer is to a file system.

In other words, while logical aggregation and secure sharing of your personal data is important — just as file management is important to a personal computer operating system — it is vastly more useful if you can run trusted applications to create, manage, and use that data. That’s what a personal cloud does. It’s an operating system for a virtual computer in the cloud, and the apps it runs communicate cloud-to-cloud to do tasks that are not feasible with either personal computers or smart phones — most importantly, to manage communications via personal channels (a whole ‘nother topic — read the paper for the full scoop).

To repeat one other key point from the earlier post, the other concern I have about either the term “personal data vault” or “personal data store” is that it gives the perception that all the personal data you may aggregate and store lives in one location. That’s neither practical nor desirable. What you really want is a single point of control — a secure dashboard — for your personal data no matter where it may be stored, either on your local devices or on the Web (your bank, your doctor, your insurance company, your car dealer, your school). Yes, in some cases you will want your personal cloud to store a backup of data that lives elsewhere, but that doesn’t need to apply to all data you touch.

Filiberto was introduced to me by Respect Network advisor Chris Carfi, so unlike Jeff, Filiberto and I had talked on the phone. Then he read the Respect Network papers on personal clouds and personal channels. But his rationale tells the story in a different and powerful way — and makes it clear how relevant it will be to social CRM (which I’m convinced is going to morph into VRM at a certain point).