Trails near me

I stayed this week at the Embassy Suites in Bellevue, Washington [1, 2]. Normally when visiting Microsoft I’m closer to campus, but the usual places were booked so I landed here. I don’t recommend the place, by the way, and not because of the door fiasco, that could have happened in any modern hotel. It’s the Hyatt-esque atrium filled with fake boulders and plastic plants that creeps me out. Also the location near the junction of 156th and route 90. Places like this are made for cars, and I want to be able hike and run away from traffic.

A web search turned up no evidence of running trails nearby. So I went down to the gym only to find people waiting in line for the treadmills. Really? It’s depressing enough to run on a treadmill, I’m not going to queue for the privilege. So I headed out, figuring that a run along busy streets is better than no run at all.

Not far from the hotel, on 160th, I found myself in a Boeing industrial park alongside a line of arriving cars. As I jogged past the guard booth a guy leaped out at me and asked for my badge. “I’m just out for a run,” I said. “This is private property,” he said, and pointed to a nearby field. “But I think there’s a trail over there.” I crossed the field and entered part of the Bellevue trail network. The section I ran was paved with gravel, with signs identifying landmarks, destinations, and distances. I ran for 45 minutes, exited into the parking lot of a Subaru dealership near my hotel, and congratulated myself on a nice discovery.

Later I went back to the web to learn more about the trails I’d run. And found nothing that would have enabled a person waiting in line for a treadmill at the Embassy Suites to know that, within a stone’s throw, there were several points of access to a magnificent trail system. The City of Bellevue lists trails alphabetically, but the name of the nearby Robinswood Park Trail had meant nothing to me until I found it myself. Nor did I find anything at the various trails and exercise sites that I checked — laboriously, one by one, because each is its own silo.

I knew exactly what I wanted: running trails near me. That the web didn’t help me find them is, admittedly, a first world problem. What’s more, I like exploring new places on foot and discovering things for myself. But still, the web ought to have enabled that discovery. Why didn’t it, and how could it?

The trails I found have, of course, been walked and hiked and cycled countless times by people who carry devices in their pockets that can record and publish GPS breadcrumbs. Some will have actually done that, but usually by way of an app, like Runtastic, that pumps the data into a siloed social network. You can get the data back and publish it yourself, but that’s not the path of least resistance. And where would you publish to?

Here’s a Thali thought experiment. I tell my phone that I want to capture GPS breadcrumbs whenever it detects that I’m moving at a walking or running pace along a path that doesn’t correspond to a mapped road and isn’t a path it’s seen before. The data lands in my phone’s local Thali database. When I’m done, the data just sits there. If there was nothing notable about this new excursion my retention policy deletes the data after a couple of days.

But maybe I want to contribute it to the commons, so that somebody else stuck waiting in line for a treadmill can know about it. In that case I tell my phone to share the data. Which doesn’t mean publish it to this or that social network silo. As Gary McGraw once memorably said: “I’m already a member of a social network. It’s called the Internet.”

Instead I publish the data to my personal cloud, using coordinates, tags, and a description so that search engines will index it, and aggregators will include it in their heat maps of active trails. Or maybe, because I don’t want my identity bound to those trails, I publish to an anonymizing service. Either way, I might also share with friends. I can do that via my personal cloud, of course, but with Thali I can also sync with them directly.

For now I have no interest in joining sites like Runtastic. Running for me is quiet meditation, I don’t want to be cheered on by virtual onlookers, or track my times and distances, or earn badges. But maybe I’ll change my mind someday. In that case I might join Runtastic and sync my data into it. Later I might switch to another service and sync there. The point is that it’s never not my data. I never have to download it from one place in order to upload it to another. The trails data lives primarily on my phone. Anyone else who interacts with it gets it from me, where “me” means the mesh of devices and personal cloud services that my phone syncs with. I can share it with my real friends without forcing them to meet me in a social network silo. And I can share it with the real social network that we call the web.

How Thali could make the Smallest Federated Wiki even smaller

Thanks to my friend Mike Caulfield, an educational technologist who’s been digging into Ward Cunningham’s Smallest Federated Wiki, I’ve now got a much clearer idea of how SFW and Thali could play together and why they should.

Mike’s recent series on SFW is the best review and analysis of Ward’s newest creation that I’ve seen:

http://hapgood.us/2014/06/12/student-curation-in-smallest-federated-wiki/

http://hapgood.us/2014/06/11/letting-lots-of-people-host-your-stuff-in-their-collections-is-a-good-survival-strategy/

http://hapgood.us/2014/06/10/the-answer-to-project-based-work-in-moocs-is-federation/

I had dipped a toe into the SFW water but there’s a learning curve and Mike climbed it before I could. Today he jumpstarted me by setting me up with a node of an SFW federation he’s hosting on AWS. Here I am participating in a wiki federation with some friends in the ed-tech tribe. We are able to do this because Mike provisioned SFW instances for each of us.

What’s the Thali connection? Well, in the first few seconds of http://screencast.com/t/fRlahVd0EK5 you see Mike provisioning a node in a federation he’s hosting on AWS. That’s the minimum bar for SFW: you need an instance of the server. Most people can’t or won’t leap over that bar.

But the server’s a pretty small piece of the pie. Most of SFW runs in the browser. There’s a lot there, and it’s well-architected for growth.

A server implementation for Thali would enable lots more people to create and participate in Wiki federations, by running SFW on their own devices and syncing opportunistically with peers on friends’ devices. Since the existing Sinatra-based SFW is CouchDB-aware, Thali — based on Couchbase Lite — should provide a comfortable home.

Why would people want to use SFW? Mike’s posts and screencasts point to a world in which GitHub-like collaboration breaks out of the geek ghetto and becomes a natural way for all kinds of teachers and learners to collaborate.

Ward points to that possibility and others in a series of SFW screencasts at http://vimeo.com/channels/wiki. I’d seen a few, tonight I went back and watched the rest. Some highlights:

On forking and comparing

An inline calculator plugin (in 25 lines of CoffeeScript!)

Visualization of in-page data

These demos really capture the idea of the universal canvas (http://www.infoworld.com/d/developer-world/we-need-universal-canvas-doesnt-suck-130) that I’ve dreamed of for a long time.

My 2006 InfoWorld article said, by the way,

Here’s the best definition of the universal canvas: ‘Most people would prefer a single, unified environment that adapts to whichever environment they are working in, moves transparently between local and remote services and applications, and is largely device-independent — a kind of universal canvas for the Internet Age.’

You might expect to find that definition in a Google white paper from 2006. Ironically, it comes from a Microsoft white paper from 2000, announcing a “Next Generation Internet” initiative called .NET.

You never know how things will turn out.

Mapping the decentralization movement

“Right now we’re experiencing a moment of maximum centralization,” says Scott Rosenberg in his introduction to a new effort that combines “a tech-industry beat I will cover; a cultural investigation and conversation I will undertake; and a personal-publishing venture I am kicking off now.”

We’ve been here before. The Internet was a peer-to-peer network until it wasn’t. Likewise the Web. Some have forgotten, and most never knew, that Tim Berners-Lee’s original browser could write and publish as well as read pages. By the early 2000s the pendulum had swung so far toward centralization that, as it began to swing back, we called the “two-way web” one of the pillars of “Web 2.0.” Personal publishing flourished for a while, then the pendulum swung again toward centralized social media. If Scott’s right, and I hope he is, the pendulum is about to swing back toward a more distributed Web.

Thali is one project moving in that direction, there are many others. When we compared notes with Jeremie Miller the other day, he pointed us to a long list of fellow travelers. Another observer, Doc Searls, periodically issues updates with pointers to related (and some of the same) efforts.

It behooves all of us to sort out how these efforts are similar or different along various axes. Some are peer-to-peer, others not. Some bind identities to public keys, others don’t. Some skew toward messaging and social networking, others toward bulk data exchange or publishing. Some consider themselves personal data stores, others don’t. Many are “friend-to-friend” networks with peer-to-peer trust models, some aren’t. There are platforms, protocols, overlay networks, and apps in the mix.

In order to reason about these axes of comparison I loaded up a bunch of links into Pinboard, made a common tag (redecentralize) to unite all the links related to this exploration, and began tagging. Here’s what I’ve got at https://pinboard.in/u:judell/t:redecentralize/ so far:

What else belongs on this list? What are core attributes? What are the best axes along which to compare? The tag cloud is suggestive but it’s only my lens on the list, I’d love to see other lenses applied to the same (evolving) list.

Note that Pinboard (as with del.icio.us long ago) such lenses can be applied — and in a decentralized way! You could import my redecentralize feed into your own Pinboard account and tag the links according to your world view. We could compare one anothers’ views, and see a combined view at https://pinboard.in/t:redecentralize/. While that’s a very cool way to do collaborative mind-mapping, it’s not likely to happen in this case. But comments here (or elsewhere) will be welcome.

A world without hearsay

If you received email from me in the early 2000s, it would have arrived with an attachment I routinely added to my messages. The attachment was my digital signature, the output of an algorithm that combined my message with the private half of my cryptographic key pair. If you had acquired my public key as part of a prior communication, and if your email client supported the protocol, you were assured that the message had been “signed” by me. Since those two conditions rarely applied, though, you were more likely to be puzzled or annoyed.

Why did I do this? As I look back, I think it had a lot to do with my experience in the early blogosphere. Back then blogs didn’t support comments. To comment on something you wrote, I’d write a blog post referring to your post. You could reply in the same way. The conversational thread didn’t exist in any one place, but in practice links wove the discussion together well enough. And because all our writing appeared on our own blogs, we owned our words. Discourse was typically much more civil than in discussion forums, or in the comment areas that blogs later evolved.

I liked the idea that my digital output was bound in some way to my identity. In the case of blogging, that identity was associated with a website that I controlled. Why not extend that idea to email? In that case, my identity was associated with a key pair, the private half of which I controlled. Signing messages was a way to say: “I own and stand behind these words.” And to say: “You should distrust a message ‘from’ me that isn’t properly signed.”

When I abandoned my digital signature experiment I chalked it up to a failure of technology adoption. It was, I thought, a good idea that never took off because people didn’t understand why it was a good idea, or because popular software didn’t make it accessible enough.

Now a hugely popular email program, Gmail, is about to make the idea more accessible than it’s ever been. Google is preparing a Chrome extension called End-to-End for encrypting (and signing) email[1]. I should rejoice! But Yaron Goland thinks otherwise. He argues here that routinely binding our identities to our messages is a really bad idea.

Imagine, for a moment, what your world would look like if every time you had a conversation with someone a permanent record was made of the conversation. The record would be fully authenticated and suitable for use in the court of public opinion and/or law.

In this world our everyday lives, our conversations, our exchanges, with anyone about anything become little permanent records that follow us around forever.

This is exactly the world we create with technologies like S/MIME and PGP Mail. Or, more generally, the world we create when we use digital signatures. A digital signature is intended to be an authenticator, a way for someone other than us to prove that we did/said something. When we use digital signatures for momentous things that should be on the public record, like mortgage documents perhaps, then they serve a good purpose. But with PGP Mail we suddenly sign… well… everything[2]. It’s like having a notary public walking behind you all day long stamping every statement, note, mail, etc. as provably and irrevocably yours.

I don’t think we want such records to exist. I think we want a much more ephemeral world where the bulk of what we do just quietly vanishes into the ether leaving as little of a trail as possible. The open source experiment I’ve spent the last year or so working on (and why I haven’t been blogging much, I’ve been insanely busy) is called Thali and we are trying to build that ephemeral world.

Yaron calls the dystopian vision he conjures “a world without hearsay” and Thali rejects it. When you communicate with a Thali peer, you and the peer strongly authenticate one another. But the data you exchange bears no trace of those identities. At least not by default. Thali applications will, of course, often need to add markers of identity to the documents they exchange. But the Thali system won’t do that automatically.

If email were exchanged directly among peers, rather than through relays, then I might never have felt the need to bind identity to individual messages. Since email travels through relays, though, I would still like to assure you that email “from” me really is from me, as well as protecting it from the prying eyes of intermediaries and servers. But I find Yaron’s argument persuasive. The potential harm to me may outweigh the benefit to you.


[1] End-to-End isn’t, by the way, a Gmail-only thing. You can use it in any text entry field in the Chrome browser to compose a signed/encrypted message. I don’t use Gmail but was able to use End-to-End to send a protected message from Outlook.com. That entails copying and pasting though, which presumably won’t be necessary if End-to-End is integrated into Gmail.

[2] Signing and encryption aren’t necessarily joined at the hip. Depending on how the technologies are implemented, it may be possible to sign without encrypting, encrypt without signing, or sign and encrypt. I tried the End-to-End extension and found that it doesn’t do bare signatures but does encrypt with or without signatures. So you could use it to protect messages without binding your identity to them.

Can we tether email to “the truth”?

“I wish we had trackback for emails.” – Robert Scoble, circa 2006

My source for that quote is Jeff Sandquist, who hired both Robert Scoble and me to work at Microsoft. We are a company with a deeply-rooted email culture. Robert was bemoaning the lack of peripheral awareness that blogging culture had taught him to appreciate. In the blogosphere, as in later forms of social media, you are (mostly) guaranteed to discover responses to things you have written. In email culture there is no such guarantee, and that’s a bug.

I’m always on the lookout for ways to collaborate in shared spaces, and lately I’ve been getting good mileage out of Office 365 and OneDrive for Business. It’s a combination of hosted SharePoint, lightweight web apps, full-strength Windows apps, and sync among my various PCs, tablets, and phone. The pieces have come together in a way that reminds me of the excitement I felt when I first began experimenting with what we once called groupware.

But where email culture runs deep, it’s a challenge to build bridges between inboxes and shared spaces. Yesterday, for example, I sent an email with links to documents in my shared space on Office 365. One respondent advised me to use attachments rather than links. Another argued that links are superior because the reader is guaranteed to get the latest version. Both make valid points. You don’t want to hit a dead link if you’re reading email offline. But you don’t want to read a stale document if you’re online.

Why not do both? Use a link that resolves as an attachment when the email is sent, but retains its identity as a link. If the email is read offline, it functions as an attachment. But if the email is read online, it can function as a link too. Benefits include:

– If the document changed, the reader gets the current version

– If the document didn’t change, the reader knows it didn’t

– When the link resolves, the author sees a trackback

More broadly this idea reflects one of the core tenets of Thali. In distributed systems with copies of things floating around, there ought to be a canonical instance of each thing. “We call it the truth,” says Thali’s creator Yaron Goland. To the extent possible, we all need to be the source of truth for our own stuff, and we need to hold it as closely as we can.

Joint custody of data

Benjamin Mako Hill has long hosted his own email server. In Google Has Most Of My Email Because It Has All Of Yours, he rethinks that strategy after this conversation:

A few years ago, I was surprised to find out that my friend Peter Eckersley — a very privacy conscious person who is Technology Projects Director at the EFF — used Gmail. I asked him why he would willingly give Google copies of all his email. Peter pointed out that if all of your friends use Gmail, Google has your email anyway. Any time I email somebody who uses Gmail — and anytime they email me — Google has that email.”

Benjamin goes on to analyze his email archive and arrives at this sobering conclusion:

Despite the fact that I spend hundreds of dollars a year and hours of work to host my own email server, Google has about half of my personal email!

How could we manage our hosted lifebits in a way that enables our bits to commingle without loss of control? It’s easy in principle, though hard in practice. Here’s the easy-in-principle approach. An email is not a bag of bits that I send to you. It’s a bag of bits that I park in my own personal cloud, which is a cloud service that I trust, and/or a set of devices I own. I don’t send you the bits, I send you a link. Access to the bits, via that link, is governed by permissions I set.

You, conversely, authorize me to follow links that invite me to access your messages and replies. We both end up with archives of our conversational threads. Yes, of course, there’s nothing to prevent either of us from violating trust and sharing those threads with the world. But there’s no intermediary, we communicate directly, and we have joint custody of our mutual data in what Groove called a shared space.

There are, of course, all sorts of reasons why this is hard-in-practice and may never happen. But are they good reasons?

Multi-persona architectures, then and now

Thali is, among other things, a powerful reminder of just how far ahead of the curve Groove was back in 2000. The other day I spoke with Omer Eiferman and Oren Ladaan about Cellrox, an isolation technology for Android that virtualizes the operating system’s kernel for multiple user spaces. It’s aimed at the BYOD (bring your own device) business market and driven by IT security. IT doesn’t, for example, want Facebook commingling with the corporate email client. But where end-user privacy is becoming paramount, especially in Europe, there’s grassroots demand as well. “You can’t put Facebook on a Blackphone,” says Omer Eiferman, “and you can’t swipe it at Starbucks to buy a latte.”

Each virtualized compartment is a configurable persona. One might run only corporate apps, another only Facebook. If a keylogger found its way into the Facebook persona, it would not be able to eavesdrop on the corporate persona. Conversely, users’ private personae can be configured without corporate MDM (mobile device management) controls.

Where had I heard this before? Groove. For a chapter on Groove security in the O’Reilly Peer to Peer book, I did extensive interviews with Ray Ozzie and his security team. Groove’s strong multi-persona architecture was one of its underappreciated features. Your personal, business, and gaming personae were cryptographically walled off from one another. It wasn’t obvious, to most people at the time, why that would matter. Now it starts to make sense.

Fellow travelers: Thali and telehash

Thali isn’t the only software project that wants to connect people and devices securely and directly. One of our fellow travelers is telehash, which Jeremie Miller describes as “a secure wire protocol powering a decentralized overlay network for apps and devices.” I caught up with Jeremie yesterday on a talky.io video chat to compare notes.

Jeremie’s roots as a networking innovator run deep. In 1999 he launched Jabber (now XMPP) along with the first Jabber server. Then came The Locker Project, a personal data store based on a vision of ownership and control that also guides Thali and other fellow travelers.

The Locker Project focused on data, expecting the right mechanisms for connecting lockers and exchanging the data would arrive. Telehash wants to hasten that arrival. And it’s ambitious. The goal, Jeremie says, is a networking stack that supports always-secure peer-to-peer networking over any available transport — Wi-Fi, 3G/4G, BlueTooth, you name it — and that uses local discovery to find the path of least resistance.

“Networking at the edge is blossoming,” Jeremie says, “there’s crazy growth that isn’t yet widely recognized.” What I’m hearing from potential Thali developers aligns with that perception. The cloud-first pattern dominates, and for many good reasons, but people are noticing that the devices on their desks and in their pockets are equipped not only with ever more powerful processors and capacious storage, but also with ever more robust (and diverse) network pipes. Those pipes connect us to the cloud. They also can and will connect us directly.

Could Thali use telehash? In theory, yes. Both use mutual authentication, both bind user identities to self-asserted public keys. Thali for now builds upon existing TLS machinery. Telehash aims to become an alternative to TLS that’s simpler, more flexible, and built from the ground up for decentralized use. For now we travel parallel roads but we would happily see them converge.

The P in P2P is People

When Groove launched somebody asked me to explain why it was an important example of peer-to-peer technology. I said that was the wrong question. What mattered was that Groove empowered people to communicate directly and securely, form ad-hoc networks with trusted family, friends, and associates, and exchange data freely within those networks. P2P, although then much in vogue — there were P2P books, P2P conferences — wasn’t Groove’s calling card, it was a means to an end.

The same holds true for Thali. Yes it’s a P2P system. But no that isn’t the point. Thali puts you in control of communication that happens within networks of trust. That’s what matters. Peer networking is just one of several enablers.

Imagine a different kind of Facebook, one where you are a customer rather than a product. You buy social networking applications, they’re not free. But when you use those apps you are not in an adversarial relationship with a social networking service. You (along with your trusted communication partners) are the service, and the enabling software works for you.

Thali, at its core, is a database that lives on one or more of your devices and is available to one or more apps running on those devices. Because you trust yourself you’ll authorize Thali apps to mesh your devices and sync data across that mesh. The sync happens directly, without traveling through a cloud relay, and is always secured by mutual SSL authentication. You can, of course, also push to the cloud for backup.

Communicating with other people happens the same way. You exchange cryptographic keys with people you trust, you authorize them to see subsets of the data on your mesh of devices, and that data syncs to their device meshes. The default P2P mode means that you don’t depend on a cloud relay that wants access to your data in exchange for the service it provides.

For cloud services that don’t monetize your data, by the way, Thali delivers a huge benefit. Apps like Snapchat and Chess with Friends incur bandwidth costs proportional to their user populations. If users can exchange photos and gameplay directly, those costs vanish. And there’s no penalty for the user. Sending your photos and chess moves directly costs you no more than sending through the cloud.

But the key point is one that Dave Winer made back when P2P was in vogue: the P in P2P is people. With handheld computers (we call them phones) more powerful than the servers of that era we are now ready to find out what a people-to-people web can be.

Shiny old things

We’ve lived in New England for 25 years. It’s been a great place to raise a family but that’s done, so we’re moving to northern California. The key attractors are weather and opportunity.

Winter has never been our friend, and if we had needed convincing (we didn’t) the winter of 2013-2014 would have done it. I am half Sicilian, my happy place is 80-degree sunshine, I am not there nearly enough. Luann doesn’t crave the sun the way I do, but she’s ready to say goodbye to icy winters and buggy summers.

The opportunity, for Luann, revolves around her art. Ancient artifacts inspired by the Lascaux cave are not exactly in tune with the New England artistic sensibility. We think she’ll find a more appreciative audience out west.

For me it’s about getting closer to Seattle and San Francisco, the two poles of my professional life. Located between those two poles I’ll still be a remote employee, but I’ll be a lot less remote than I am here. That matters more than, until recently, I was willing to admit.

Earthquakes don’t worry me too much. I was in San Jose for the ’89 Loma Prieta quake. We were at an outdoor poolside meeting, heard it rumble toward us, watched the ground we had thought solid turn to liquid, got soaked by the tidal wave that jumped out of the pool, heard it rumble away. What impressed me most was the resiliency of the built environment. Given what I heard and saw I’d have expected much more to have broken than did.

What does worry me, a bit, is the recent public conversation about ageism in tech. I’m 20 years past the point at which Vinod Khosla would have me fade into the sunset. And I think differently about innovation than Silicon Valley does. I don’t think we lack new ideas. I think we lack creative recombination of proven tech, and the execution and follow-through required to surface its latent value.

Elm City is one example of that. Another is my current project, Thali, Yaron Goland’s bid to create the peer-to-peer web that I’ve long envisioned. Thali is not a new idea. It is a creative recombination of proven tech: Couchbase, mutual SSL authentication, Tor hidden services. To make Thali possible, Yaron is making solid contributions to Thali’s open source foundations. Though younger than me, he is beyond Vinod Khosla’s sell-by date. But he is innovating in a profoundly important way.

Can we draw a clearer distinction between innovation and novelty? That might help us reframe the conversation about ageism in tech.