Tags: xfn

43

sparkline

Tuesday, June 28th, 2016

<A>

The opening keynote from the inaugural HTML Special held before CSS Day 2016 in Amsterdam.

It’s all starting to come together.

The world exploded into a whirling network of kinships, where everything pointed to everything else, everything explained everything else.
— Umberto Eco, Foucault’s Pendulum

A is for Apophenia

Apophenia is the name for that tendency in humans to see patterns where none exist, to draw connections, to make links.

Every conspiracy theory is an example of apophenia. But you don’t have to be a conspiracy theorist to experience it. We do it all the time. We see shapes in the constellations in the night sky. We see faces in just about everything.

Stars

Today, I would like to engage the apopheniac in you.

A is for Anchor

An anchor is an odd device to represent a link. I can even remember seeing anchor symbols used in the interfaces of rich text editors. If it wasn’t an anchor, it was a chain. I suppose that was meant to represent a link …because chains have links.

Anyway, why A? Why Anchor?

It goes back to how the A element was originally used. When I say originally, I mean originally. Let’s look at the first A element in the first web page at the first URL.

<A NAME=0 HREF="WhatIs.html">
hypermedia
</A>

This looks pretty familiar to us today. There’s an A Element with opening and closing tags, some text in between, and an HREF attribute for the destination. But there’s also a NAME attribute. This has since been deprecated—now we can just use an ID attribute on any element. The idea was that A elements could be used to create destinations for inbound links. They were, if you like, anchors within a page that other pages could tether themselves to. Each anchor is given a unique identifier (unique within the page, that is). Here, the identifier is simply the number zero, because this page was created by a programmer and in the mind of a programmer, counting begins with zero.

This use of the A element—using NAME attributes to create in-page anchors—never really took off. But the other attribute, the HREF attribute, that spread like wildfire. It’s short for hypertext reference, and in this particular instance, the reference is to another page in the same directory on the same server. It’s a page about hypertext.

Hypertext is text which is not constrained to be linear.

The term was first coined by Ted Nelson. He didn’t just talk about text either. He also coined the term hypermedia. He coined lots of interesting words. He talked about things being deeply intertwingled. He also coined the term teledildonics, but that is not directly relevant to hypertext or hypermedia.

If hypertext is text which is not constrained to be linear, how did we ever manage with good old-fashioned non-hyper text and non-hyper media? We used archives.

A is for Archive

In 1965, JCR Licklider was commissioned to write a report on Libraries Of The Future. He—and his company Bolt, Beranek and Newman—would prove to be instrumental in creating our modern interconnected hypermedia world. More on that later. For now, let’s look at this report. It has two parts:

  1. Concepts and Problems of Man’s Interaction with the Body of Recorded Knowledge
  2. Explorations in the Use of Computers in Information Storage, Organization, and Retrieval.

I love the scope of that first part, looking at the body of recorded knowledge.

It’s interesting that he talks about knowledge, not information, not data, but knowledge. How does data become information? How does information become knowledge?

The Library Of Babel

The Library Of Babel is a short story by Jorge Luis Borges, who I think of as the poet laureate of hypertext . He imagines a vast library that is filled with data, but frustratingly short on knowledge …because this library contains not only all the books ever written, but all the books that could ever possibly be written, with every possible permutation.

Here’s how it works:

The universe (which others call the Library) is composed of an indefinite, perhaps infinite number of hexagonal galleries… The arrangement of the galleries is always the same: Twenty bookshelves, five to each side, line four of the hexagon’s six sides… each bookshelf holds thirty-two books identical in format; each book contains four hundred ten pages; each page, forty lines; each line, approximately eighty black letters.

Let’s figure out how many books are in the Library of Babel. First, we need to know how much data each book holds.

  • There are eighty symbols (or letters) per line, and
  • 40 lines per page.
  • There are 410 pages in each book.

Multiplying 80 by 40 gives us 3200, the number of symbols on each page. Multiply that by 410 and we get a total number of 1,312,000 symbols in each book.

We have two other pieces of information to work with. Borges tells us:

The orthographic symbols are twenty-five in number.

That’s 22 letters, the comma, the period, and the space.

Here’s the crucial bit of information that ensures that the library has boundaries:

In the vast library there are no two identical books.

Knowing that, we can calculate the number of books in the library. It’s the number of symbols (25) raised to the power of the number of symbols in each book (1,312,000).

25 to the power of 1,312,000 expressed in base ten is 10 to the power of 1,834,097. Remember that’s just the number of books: a figure that’s over 1,834,097 digits long. That number wouldn’t fit inside one book in the library (which, if you remember only holds 1,312,000 symbols).

So the number of books in the Library of Babel is not infinite …but it is really, really, really big. To give you some idea of just how big 10 to the power of 1,834,097 is, it has been calculated that the observable universe contains approximately 10 to the power of 80 atoms. There are more books in the Library of Babel than there are atoms in the universe.

And yet, thanks to the World Wide Web, you can theoretically peruse every single one of them.

Jonathan Basile has created libraryofbabel.info—an online representation of Borges’s creation. It contains all possible text. You can browse by hexagon, then shelf, then row, then book, then page. Or you can search for a specific piece of text, because—of course—that text must be in there somewhere.

The very words I am speaking now must be somewhere in the library.

There’s also a plug-in for Chrome so you can highlight any piece of text on the web, and then find its corresponding page in the Library of Babel.

This library has every possible piece of data …but it’s sorely lacking in information (although the online version helps).

A is for All

Having all the data isn’t enough. It needs to be organised—turned into information—for us to make use of it (and hopefully further transform that information into knowledge).

There have been many attempts to organise information. When those attempts are limited to a subset of data—instead of trying to create a Library of Babel—then they can be quite successful.

Carl Linnaeus organised the natural world using a naming convention for describing species—binomial nomenclature.

Charles Messier catalogued astronomical objects.

Melvil Dewey created the Dewey Decimal System to help librarians organise their collections. But this was a proprietary system, not an open standard. So the Belgian librarian Paul Otlet devised a Universal Decimal Classification system. I think it’s fair to think of him as the father of information architecture.

The crazy old uncle of information architecture would be bishop John Wilkins, who in 1668 wrote An Essay towards a Real Character and a Philosophical Language. Centuries later, this would pique the interest of Borges who described Wilkins’s madcap idea in an essay called The Analytical Language of John Wilkins. The idea was that the world could be classified into sounds.

He divided the universe in forty categories or classes, these being further subdivided into differences, which was then subdivided into species. He assigned to each class a monosyllable of two letters; to each difference, a consonant; to each species, a vowel. For example: de, which means an element; deb, the first of the elements, fire; deba, a part of the element fire, a flame.

It didn’t scale well.

Gottfried Wilhelm Leibniz—inventor of calculus and nemesis to Newton—had a similar idea to Wilkins, but whereas Wilkins was trying to classify information using sounds, Leibniz wanted to use symbols: characteristica universalis. His leap of genius was to realise that if you could do this—represent the world with symbols—then you could perform calculations on those symbols. He described the conceptual framework for performing such operations as a Calculus ratiocinator. Centuries later, Norbert Wiener, the creator of cybernetics would say:

The general idea of a computing machine is nothing but a mechanization of Leibniz’s calculus ratiocinator.

A is for Ada

Leibniz’s calculus ratiocinator was an idea, rather than a real machine. Charles Babbage was a Victorian inventor and entrepreneur who was given seed funding by the British government to create his Difference Engine: a machine for computing logarithmic tables …a computer, if you will.

The Difference Engine

The Wozniak to Babbage’s Jobs was Ada Lovelace, the daughter of the notorious Lord Byron. Ada’s mother did everything in her power to steer her daughter away from following in her father’s footsteps of becoming a poet. Instead Ada immersed herself in the world of mathematics. It was through mathematics that Ada hit upon the same insight as Leibniz—if we can perform calculations upon symbols, and those symbols don’t have to just represent numbers, then we can perform calculations on anything …maybe even poetry.

In enabling mechanism to combine together general symbols in successions of unlimited variety and extent, a uniting link is established between the operations of matter and the abstract mental processes of the most abstract branch of mathematical science.

The Difference Engine was abandoned in favour of an even more ambitious project: The Analytical Engine. Finally, the world would get a mechanical machine capable of performing calculations on symbols that could represent concepts or thoughts—a thinking machine!

As with so many start-ups, Lovelace and Babbage never quite managed to make it to market. But at least they did genuinely have an incredible journey before going broke.

A is for Alan

The Analytical Engine, like the calculus ratiocinator, remained an idea. It would be another century before we’d get a real nuts’n’bolts computing machine, thanks to the brilliant Alan Turing.

But as well as having a hand in creating the world’s first physical computer, he also presented us with an imaginary machine. This theoretical machine was described as having:

…an infinite tape marked out into squares, on each of which a symbol could be printed.

Like Leibniz’s calculus ratiocinator, a Turing machine would operate on symbols. How many symbols are we talking about here? Remember the Library Of Babel had twenty five symbols to work with.

Two. Two symbols. One and zero. On and off. True and false. With an infinitely long piece of tape and infinite amount of time, two symbols are enough to calculate literally anything.

This reduction of the world into its smallest pieces was the brainchild of Claude Shannon. He coined the term "bit" to describe this indivisible unit of information.

By the way, Turing himself referred to his theoretical machine as an automatic machine, or a-machine. A is for A-machine.

A is for Atlantic

There’s another imaginary machine that serves as a wonderful conceptual prototype for working with hypertext and hypermedia. In 1945 Vannevar Bush published an article in the Atlantic Monthly called As We May Think. In this article, Bush describes a machine called the Memex, a contraction of Memory Index.

Memex

The Memex is built into a desk. Screens and switches on the surface of the desk allow the user to interact with huge amounts of information stored within the desk on microfilm. This would provide an "enlarged intimate supplement to one’s memory."

Because everyone’s mind is different, no two people would use the Memex in quite the same way. Bush described these individualistic approaches to linking concepts together as associative trails:

Wholly new forms of encyclopedias will appear, ready made with a mesh of associative trails running through them, ready to be dropped into the memex and there amplified.

The information stored in the Memex is the same for everyone, but the associative trails created by the user in navigating this information are unique. Bush also proposed that these associative trails could be shared. Users of the Memex could follow the breadcrumbs left by others.

This is hypertext.

A is for Augmentation

So many ideas about hypertext confined to the imagination! When do we get a working demo?

Ladies and gentlemen, on December 9th, 1968, we get the mother of all demos, courtesy of Douglas Engelbart. Six years previously, he had set out his goals for human-computer interaction in a work entitled Augmenting Human Intellect: A Conceptual Framework. To achieve this aim of augmenting humanity, he created a working demo of his oNLine System, abbreviated to NLS.

Oh, and for this demo he just happened to invent video conferencing, the graphical user interface, and the mouse. He also implemented hypertext.

With Bush’s Memex and Engelbart’s NLS, concepts could be linked together, turning them from text storage devices to hypertext storage devices. But for hypertext to reveal its true power, we need a network greater than anything seen up to this point. Towards the end of the mother of all demos, we hear the first rumblings of just such a network.

A is for Arpa

ARPA stands for the Advanced Research Projects Agency.

This government agency turned to our old friend JCR Licklider, author of Libraries Of The Future. His company—Bolt, Beranek and Newman—set about designing a communications system that used this new-fangled packet switching that Leonard Kleinrock was so excited about. With packet switching, information was broken down into discrete chunks, routed around a network independent of each other, and then re-assembled at the destination.

At the same time, this idea of packet switching was independently discovered by Paul Baran at the Rand Corporation, who was trying to find a resilient network architecture capable of surviving nuclear attack.

The packet-switching idea was put to the test with the creation of a new network called the ARPANET. The very first message sent over the ARPANET was at 10:30pm on October, 29th, 1969. It was the command: LOG IN.

The message was sent and… the system crashed after the first two characters. Fittingly, then, the real first message sent over this proto-internet was "LO".

But they fixed the bugs and they kept working on making the system better as it grew bigger. It morphed from being a single network, the ARPANET, into being a network of networks, or an Inter-network, soon shortened to simply Internet.

For this internet to work, it was essential that all the individual networks connecting to it were using the same protocols to communicate. That’s what really makes the internet the internet—regardless of what kind of hardware is being used, there’s an agreement on how to switch those packets around. That’s really all a protocol is: an agreement. They’re more like treaties than code.

Bob Kahn, Vint Cerf, Jon Postel

Bob Kahn and Vint Cerf were the statesmen crafting the internet’s protocols, and Jon Postel was the diplomat ensuring adoption went smoothly. They wanted a robust network, resilient not to nuclear attack, but to any kind of top-down control. They set out to create a protocol that would work for a network with no centre.

Together they crafted TCP/IP: the Transmission Control Protocol and Internet Protocol. TCP/IP is a deliberately dumb set of protocols. The protocols care not a whit for the contents of the packets being switched around the network. It’s a simple low-level agreement. They used to joke that you should be able to implement TCP/IP using two tin cans and a piece of string.

You can then create more complex protocols on top of this simple, low-level, dumb foundation. You can create protocols for sending and receiving email, protocols for telnet, gopher, file transfer protocols that sit atop TCP/IP. Best of all, you don’t need to ask anyone for permission. If you want to create a new protocol today, you can just go ahead and do it. All you need is rough consensus and running code. It turns out that running code isn’t the hard part. The hard part is convincing people to use your protocol. Otherwise you don’t benefit from Metcalfe’s Law:

The value of a network is proportional to the square of the number of connected users of the system.

Think about it. The first person to own a telephone had a completely useless object. As soon as one other person had a telephone, it suddenly become exponentially more useful. That was the challenge facing the creator of a new protocol at the start of the 90s: that protocol was HTTP—the HyperText Transfer Protocol.

HTTP is one part of a three-part stack: HTTP is the protocol, URLs are the identifiers, and HTML is the format. Together they form the World Wide Web project.

The project was the brainchild of a young computer scientist named Tim Berners-Lee. This wasn’t his first attempt at creating a hypertext system.

In the 1980s, he created a system called ENQUIRE. It was named after a Victorian book of manners called Enquire Within Upon Everything, which I always thought would be a great name for the web.

Enquire didn’t work out in the end, but it would influence the design of the World Wide Web project.

Another influence on the design of the system was the place where Tim Berners-Lee was working. CERN—the European Centre for Nuclear Research. It’s an amazing place. The greatest experiment in the history of our species is being conducted beneath the border between Switzerland and France. In the 16-mile wide ring of the Large Hadron Collider at CERN, human beings are recreating the conditions from the start of our universe. Protons are smashed together at velocities approaching the speed of light. It’s a truly awe-inspiring endeavour.

CERN

When I visited CERN, I expected to be blown away by the science, and I was. I also expected to be blown away by simply being at the birthplace of the web, and I was. But what I wasn’t expecting was to be blown away by how things get done at CERN. There is very little hierarchy. People from all kinds of backgrounds—from Nobel prize winning physicists to students on a Summer internship—collaborate on experiments for pure scientific research.

Trying to manage the flow of information in this collaborative but chaotic place was the challenge that Tim Berners-Lee was trying to solve. You can’t just mandate a particular operating system or piece of software—people at CERN can and will use whatever they want. In the same way that the internet is a network of networks, what CERN needed was some way of allowing all these different computers with different operating systems to share information with each other.

Tim Berners-Lee submitted a paper to his supervisor, Mike Sendall. It had the uninspiring title Information Management: A Proposal. Well, Mike Sendall must have seen some potential, because he scrawled across the top:

Vague, but exciting.

The proposal described:

…a solution based on a distributed hypertext system.

Tim Berners-Lee was very familiar with previous hypertext systems. All of these fed into his project:

  • Vannevar Bush’s Memex,
  • Douglas Engelbart’s oNline System,
  • Ted Nelson’s Xanadu, although it was still vapourware at this point,
  • Apple’s Hypercard system for the Mac,
  • and his own Enquire project.

But just creating the code wasn’t enough. He—and his colleague and collaborator, Robert Cailliau—needed to convince the scientists at CERN to use this technology. To start with, they needed a catchy name.

For a while, they floated the idea of calling it the Mesh.

Then they kick around the idea of calling it The Information Mine. But Tim Berners-Lee wasn’t keen on this one. He knew that, whatever name they chose, it would end up getting abbreviated, and he was worried it would look a bit egotistical.

And so they settled on World Wide Web. You have to admire the chutzpah of calling it World Wide Web when, at that point, it only existed on one person’s computer.

Sure enough, it did end up getting abbreviated. Except in this case, there are actually more syllables in the so-called abbreviation—WWW—than there are in the full name.

WWW

They even made a logo. Graphic designers they are not. But there is a reason for the green colour of the Ws. Robert Cailliau is a synesthesiac—he “hears” the W sound as the colour green.

And so the web was born. Good job!

Where the web was born

Learning from the lessons of TCP/IP, Tim Berners-Lee made sure to keep the individual parts of the system as simple as possible (but no simpler). The World Wide Web didn’t succeed because the technology was the best; far from it. It succeeded because the technology was just simple enough—but also powerful enough—for people to get started with straight away.

Take HTML, for example. There was no official Version 1 specification for this hypertext markup language.

Instead there was a document called simply HTML Tags, presumably written by Tim Berners-Lee. This document listed the entirety of HTML, which was a grand total of 21 elements.

Most of those elements weren’t even invented by Tim Berners-Lee. Instead, he borrowed the vocabulary already being used by scientists at CERN. They were used to writing documents in GML, which is supposed to stand for Generalised Markup Language, but was coincidentally created by three people whose last names were Goldfarb, Mosher, and Lorie: G, M, and L.

There was one element that was completely new to HTML:

A

This one single element is what enables the HT part of HTML. With this element, and its href attribute, anyone could link to anything on the web. It is brilliant in its simplicity.

Pleased with the way their project was progressing, Tim Berners-Lee and Robert Cailliau submitted a proposal to present their World Wide Web at a hypertext conference.

They were rejected. Hypertext experts thought the World Wide Web was stupid.

As Ted Nelson put it:

Today’s one-way hypertext—the World Wide Web—is far too shallow. The Xanadu project foresaw world-wide hypertext decades ago, and endeavored to create a much deeper system. The Web, however, took over with a very shallow structure.

He’s not wrong. Hypertext on the web is shallow. It is stupid. Like TCP/IP, it is not smart.

The thing is, if you’re hoping to get mass adoption, being smart is a bug. Being stupid is a feature.

Just about every other hypertext system embodied the idea of two-way linking. There was an awareness at both ends of the link. If the resource being linked to were to move or change, the link could be updated. It’s robust, but it’s complicated.

On the World Wide Web, by contrast, links only work in one direction. If the resource being linked to ends up moving or changing, well, tough luck. The result is link rot. That’s the price we pay for a very simple hypertext system.

But, now that the web has been around a couple of decades, there is a sort-of, kind-of implementation of two-way linking.

It uses the humble rel attribute.

Rel is short for relationship. The value inside the rel attribute describes the relationship of the linked resource to the current document.

<a href="…" rel="…">

Some rel values were officially canonised in HTML.

rel="prev" means that the linked resource has the relationship of being the previous document to the current document.

<a href="…" rel="prev">

rel="next" means that the linked resource has the relationship of being the next document after the current document.

<a href="…" rel="next">

rel="author" means that the linked resource has the relationship of representing the author of the current document.

<a href="…" rel="author">

You get the idea.

Incidentally, there was once a corresponding rev attribute that described the reverse relationship. In other words, the relationship of the current document to the linked resource.

<a href="…" rev="…">

So you could simultaneously say the current document has a relationship of being the previous document to the linked resource and that the linked resource has a relationship of being the next document to the current document.

<a href="…" rev="prev" rel="next">

Confused? Well, that’s why the rev attribute was eventually dropped from HTML. It was just too complicated.

There was an attempt to use the rev attribute in an early microformat called vote-links. This was proposed way back in 2004. Blogs were hot. Political blogs were very hot indeed: Bush Jr.—no relation to Vannevar—was running for re-election in the States, and John Kerry was the challenger. There was much blogging and gnashing of teeth.

The problem was the rise of PageRank, the algorithm that drove Google’s search engine. The fundamental premise of PageRank was that linking to something counts as an endorsement. But there were many bloggers linking to articles that they disagreed with very strongly.

By using a rev value of “vote-for”, authors could explicitly say that this document is a vote for the resource being linked to.

Or by using a rev value of “vote-against” they could make it clear that this document is a vote against the linked resource.

It never really took off because, as I said, the rev attribute was just too hard to grok.

And that’s okay. The whole point of microformats is that they are the very embodiment of the motto of the Internet Engineering Task Force: rough consensus and running code. There just wasn’t enough take-up of vote-links for it to thrive.

Another early idea—that actually preceded the official creation of microformats—was XFN, which stood for XHTML Friends Network: the most Web 1.0 format name ever.

XFN built on existing behaviour. Bloggers would often have a list of links in their sidebar pointing to other bloggers they had some kind of relationship with. If you assume that a URL can represent a person, then the rel attribute is perfect for encoding that relationship information.

I can link to a friend’s website and say that the person represented by the linked resource has a relationship of being a friend to the person represented by the current document: me!

<a href="…" rel="friend">

Or I can link to a colleague’s website and say that they have a relationship of being a colleague to me.

<a href="…" rel="colleague">

And because rel values—like class values—can be space-separated, I can combine rel values into one attribute. I can link to someone and say that they are both a friend and a colleague.

<a href="…" rel="friend colleague">

I still have XFN values in the sidebar of my blog, but again, it never really took off.

Except for one value, that seems at first glance to be completely pointless:

A rel value of "me": the linked resource has a relationship of being …me?

<a href="…" rel="me">

A is for Adactio

My website is adactio.com. I love my website. Even though it isn’t a physical thing, I think it might be my most prized possession.

It’s a place for me to think and a place for me to link.

But my web presence isn’t limited to adactio.com—I have profiles on lots of different sites: Twitter, Facebook, Instagram, Medium, Dribbble, Flickr, Tumblr, CodePen …the list goes on.

None of those places are as important to me as my own website, but they are representations of me.

I link out to these profiles from my own website using that rel value of "me". That’s me on Twitter. That’s me on Github. That’s me on Flickr.

<a rel="me" href="https://twitter.com/adactio">
<a rel="me" href="https://github.com/adactio">
<a rel="me" href="https://flickr.com/adactio">

Nothing unusual there. These are regular one-way hyperlinks.

What’s interesting is that many of those profiles on other websites provide a URL field where I can enter my own website. These third-party profiles then link back to my website also using a rel value of "me".

<a rel="me nofollow" href="https://adactio.com">

(They also use a rel value of "nofollow" to discourage spammers. The phrase "nofollow" makes absolutely no sense as a rel value—you can’t have a relationship of "nofollow" to anything—but it was invented by Google. We don’t get to argue with the 900 pound Google gorilla.)

Anyway, the result of having these reciprocal links, both using rel="me" means that we’ve kinda, sorta got two-way linking on the World Wide Web.

But …so what?

A is for Authentication

Some of those third-party profiles I’m linking to—Twitter, Github, Flickr—have something in common. They allow third-party authentication using OAuth.

If I can log into my Twitter, or Github, or Flickr profile using OAuth, and those profiles have two-way links with my website, then I can “borrow” that authentication flow for my own site.

That’s the idea behind IndieAuth. I enter the URL of my own website. It finds the links from there to my other profiles using rel="me". Then I can choose which one of those profiles I want to authenticate against. Once I’ve authenticated with that service, I’ve also authenticated my own website.

Just by adding a short rel value to some links, I can use my website as a log-in.

My website also has a small write API. The API is called micropub. By combining IndieAuth and micropub, I can log into somebody else’s posting interface using my website, and then use that interface to post to my own website.

These building blocks—microformats, IndieAuth, micropub—have emerged from a small but dedicated group of people.

We gather together at fun little events called Indie Web Camps.

An Indie Web Camp takes place over two days. The first day is split into discussions of technology and design. The second is all about implementing what we’ve discussed on the first day. I’m always amazed by how much gets done when you’re in the same space as like-minded people.

Still, the technologies being discussed and implemented aren’t the real focus of Indie Web Camp. The core tenet of Indie Web Camp is an idea. It’s a very simple idea, that at one point would have been uncontroversial. That idea is that you should have your own website.

But who’s got time for that? Especially when it’s so much easier to write and share and link using platforms like Twitter, Facebook, and Medium. That’s a good point. A lot of the time at an Indie Web Camp is spent reverse-engineering what those services are doing so well, and applying them to personal websites.

Also, we don’t necessarily want to stop using those services. After all, that’s where the people are (for now). Instead we want to figure out ways of making use of these services, while still keeping the canonical versions of what we create under our own control.

There’s a fantastic little Indie Web service called Brid.gy that allows you to not only post from your own site out to third party networks, but also receive replies, and likes, and retweets back at your own site, using another Indie Web building block called webmention.

In a way, webmentions allow a kind of two-way linking. I can cross-post something from adactio.com to Twitter, or Instagram, or Facebook. Then when someone replies on Twitter, or Instagram, or Facebook, I get notified with a ping back to my own site.

All of this is possible because I’ve verified the identity of those third-party profiles using nothing more than a simple rel attribute on a hyperlink.

The Indie Web uses a grab-bag of deliberately simple technologies that combine to create something so much more powerful than the sum of its parts …just like the web itself.

We often talk about places like Facebook, or Instagram, or Medium as walled gardens. Walled gardens are as old as the web itself. AOL was a well-cultivated walled garden back in the day.

To The Garden

There’s nothing wrong with walled gardens. They’re safe spaces. They take care of your enjoyment and entertainment, so you don’t have to.

But there also a bit boring. I certainly don’t relish the idea of spending my days within the boundaries of someone else’s vision.

There’s a different kind of garden. It takes its name from another short story by Borges.

The Garden of Forking Paths. It is uncontrolled. It is full of possibilities. It’s a bit scary. It takes more dedication to explore. You might get lost. But is that so bad? When was the last time you were truly lost on the World Wide Web, when you clicked through link after link—no cheating by opening new tabs, now—until you ended up somewhere, blinking and asking yourself “what I was looking for?”

I would like us all to spend more time in the garden of forking paths. I would like us all to continue to grow this garden of forking paths. Add your own website to this garden of forking paths. Use it to make more links.

On your website, you can link to this thing over here and that thing over there, and in doing so create an entirely new forking path.

Remember, the web, like the internet, has no centre. In theory I could start from any single A element, and by following all the forking paths, traverse the entire World Wide Web.

That opening hyperlink could be on your own website. One single A element can be the portal to an entire universe of knowledge.

Thursday, December 30th, 2010

FUMSI Article: Microformats: Digging Deeper into the Web

A nice, neat, short introduction to microformats from Ben.

Tuesday, October 26th, 2010

Qwerly: API Documentation

It's down for me right now, but this API from Qwerly looks like a great addition to complement Google's Social Graph API — it finds rel="me" links from a Twitter username.

Tuesday, December 1st, 2009

Enhance User Profiles with Google’s Social Graph API [Ruby & Rails]

Some Ruby on Rails code for enhancing sign-up forms using Google's Social Graph API, inspired by Huffduffer.

Tuesday, October 6th, 2009

Ident Engine

Glenn has taken Google's Social Graph API, YQL and various parsers, and he's wrapped it all up in one JavaScript library. The demos are mind-boggingly impressive.

Sunday, April 19th, 2009

Identify: Google People With Two Keystrokes - ReadWriteWeb

A nice overview of Glenn's XFN Firefox plug-in.

Thursday, April 9th, 2009

Portal Me

A person-specific portal generated using Google's Social Graph API. And it's less than 5K!

Wednesday, March 11th, 2009

Identify - Firefox entension | Madgex Lab

Okay, I know I said "holy freakin' crap!" the last time I linked to one of Glenn's Social Graph API experiments but now he's gone and created a Firefox plug-in: press alt-i and you can see the social graph for anyone's site. Holy freakin' crap!

Friday, March 6th, 2009

Social Graph Explorer | Madgex Lab

Holy freaking crap! Glenn's Social Graph Explorer is bloody brilliant!

Friday, January 16th, 2009

Styling XFN and rel-license links - Opera Developer Community

Christopher Schmitt shows how to style XFN links using attribute selectors.

Wednesday, September 10th, 2008

Getting Semantic With Microformats, Part 1: rel ~ A Blog Not Limited

A great article by Emily Lewis on the microformats that make use of the rel attribute (rel-tag, rel-license, XFN, etc.).

Thursday, July 3rd, 2008

XFN Activity - David Singleton

This is seriously brilliant. Starting from a single URL (adactio.com), a lifestream is creating based on XFN rel="me" links. David Singleton wins the internet.

Digital Web Magazine - Portable Social Networks, The Building Blocks Of A Social Web

Ben has written a superb article outlining the hows and whys of distributed social networks with hCard and XFN, finishing with an inspiring call to arms.

Saturday, June 21st, 2008

Creating Portable Social Networks With Microformats

A presentation from XTech 2008 in Dublin.

Hello. Fáilte romhabh go léir.

I’m going to talk about, supposedly, creating portable social networks with microformats. It’s a very grandiose title for something that’s actually very, very simple.

Hands up: who was in David Recordon’s keynote yesterday? He had about a two-minute segment there where he showed himself on his own blog having rel="me" in links, and then he showed the OpenSocial thing. That’s pretty much it, really. So, he did it in two minutes and I’ve been given 45. We’ll go into a little more detail, but there really isn’t that much to it. It’s pretty straightforward.

So what this is about is all these different social networks—and there are quite a few of them now. I’m on quite a few social networks myself, and I want to see which ones you guys are on as well. So, a show of hands for any of these:

Pownce, anybody on Pownce? Okay, one or two. Magnolia? Magnolia, a few—like del.icio.us, but with more of the whole social aspect going on. Anybody know a site called Edenbee? No? Social network site for environmental stuff. It’s based out of Dublin, which is why I thought I’d mention it. Upcoming, for events—who uses Upcoming? Okay, quite a few. Last.fm? Music? Okay, good, good, lots of Last.fm-ers. Twitter. Oh, I’m surprised not to see every single hand in the room go up for Twitter. But how about Flickr? Okay, most people are using Flickr.

Alright, so, we’ve got a lot of different social networks here, and on each one, you have to sign up, and you have to enter your details when you sign up—and then you have to go and find your friends on each one, and you have to say, “Yes, I know that person, yes, I want to share my photos with that person, yes, I want to share my music with that person.” And by the fourth or fifth social network, it gets a little bit tiring having to through all this, right? I see some nodding heads—yes, yes, we’re fed up with this.

So, this is one angle of the whole idea of portable social networks: this idea of social network fatigue. But, to be honest, that’s not really such a big problem. It’s kind of something that’s going to affect those of us who use a lot of these social networks, but maybe we’re sort of canaries in the coalmine, and this isn’t really an issue that’s going to affect the average user.

But it’s about much more than that. This isn’t really about the whole social network fatigue thing. It’s about being able to move freely. It’s freedom of travel, the idea that you should be able to seamlessly move between these social networks and not have to deal with the hassles of having to fill in another form or go through another process of finding all your contacts.

And when I talk about social network portability, I’m not talking about, “I’m leaving this social network, I’m taking all my friends with me, and I’m going over to this new social network that everybody’s raving about.” It’s not that kind of portability. It’s more about ease of movement. It’s the idea that I can have as many social networks as I want, and the ease of getting into it and setting it up is nice and simple, and it’s not complicated. So that’s the reason why there’s a lot of different people, very smart people, trying to tackle this problem. It’s really a question of interoperability more than portability.

The ways that people have tried to tackle this problem of trying to make it easy to sign up to a site and then to get all your contacts listed on that site… Well, something that people have been doing for a while is to ask you for your user name and your password—for instance, from a webmail client you might use, like Google Mail or Yahoo Mail or Hotmail.

Short hiatus while Jeremy is rickrolled by Aral

Aral just rickrolled me, the bastard!

Audience member: That was antisocial networking.

Jeremy: Yeah. It’s always me! Is everybody familiar with the concept of rickrolling? Okay. Sorry, I just got live-rickrolled, and I think it’s going to be on the Internets in a few minutes.

Where was I? Oh yes, user name and password for third-party sites. So you sign up to a new social network and it says, “Do you use Google Mail, Gmail? Do you use Yahoo Mail? Well then, why don’t you just give us your user name and your password.” Now, crucially here, they’re asking for your Gmail password not on Gmail, they’re asking for it on example.com. They’re asking on the latest social network site that’s probably disemvoweled and ends with the letter “r” without the letter “e” attached.

This is just wrong. This is something that gets referred to as the password anti-pattern, because essentially what you’re doing here is you’re teaching users how to be phished. You’re telling them that it’s okay for you to throw around your password on any site. So instead of saying, “Only ever enter your Gmail password on Gmail,” this is saying, “It’s okay to throw around your Gmail password willy-nilly.” And in the long term, this is really, really harmful.

And it’s just really, really insecure. How do you trust this site? How do you know it’s not going to spam all your friends? How do you know it’s not going to go into your inbox and use that account that is also the same account you use for Google Checkout, if you use Google Checkout.

To get around that, what people have been doing is using APIs, which is a much more secure way of dealing with this issue, where you can authenticate, give authorization to a site like, say, Gmail or Yahoo Mail or whatever. This combination of using an API together with some kind of authentication is much safer and much more secure, and this is why you see this combination of some sort of API and some sort of authentication, like OAuth, or like BBAuth, or AuthSub—there’s all these different kinds of authentication things.

Now, for instance, with Gmail you can do this; there’s a Google Contacts API. So in this case, you say, “Hey, do you have a Gmail account?” They say, “Yes.” “Well, okay, click this button to start importing friends.” And you get sent off to the Google domain—and there you might have to input your user name and password, but that’s an order of magnitude better than doing it on a third-party site. The flow works much better.

OAuth is aimed at making this flow work the same for all these different social networks and sites so that you don’t have to write a different API call for every different social network. And it’s pretty much based on the Flickr model. If you’ve ever used some desktop application that uses the Flickr API, you know that first you have to authorize it, and that involves going to the Flickr site and saying, yes, I give permission to allow this application to look at my photos, or maybe I give it permission to also upload photos. You set the permissions. So this is good. This whole combination of some sort of authentication, like OAuth, and some sort of API works really, really well.

But it is quite complex. That’s not a bad thing for us; we’re all pretty smart developers, and we can implement this kind of stuff. But there is a certain barrier to entry with getting this stuff done. It’s not something you can do overnight.

I would say this is generally the best way if you are trying to get, say, email addresses out of an address book. Whether that really defines who your friends are is another question again. I don’t know how it is for you, but for me, email is no longer really the defining factor of whether somebody is my friend, somebody I know. I’m very good friends with a bunch of people and I don’t even know their email addresses. I might know them on Twitter and Flickr and Last.fm and all these other places, and if I stopped and thought about it and I wanted to write them an email, I’d think, actually, I don’t even know their email addresses. So if you think of email as this way of getting at contacts, then this way works pretty well. But like I said, I’m not even sure that an email address is still an identifier for having a friend.

There’s this other way which kind of complements all these other methods like APIs, which is to use microformats. Microformats are not very full-featured, not a very complex way of transferring information or storing data. It’s really all about being lazy, frankly. There’s a couple of microformats principles, and they’re all pretty much based on being really quite lazy.

Hands up if you’re familiar with microformats. Okay, good, that’s good. I was kind of assuming that I wouldn’t have to go into much detail. But just to give a quick overview of the philosophy behind microformats, and this philosophy of laziness: They’re built on the idea of reusing. At all costs, avoid reinventing the wheel. If somebody’s already solved the problem and there’s some kind of standard out there, steal it. Just take it verbatim, use it. And they’re deliberately simple, they deliberately don’t try and solve every problem. “Avoid boiling the ocean” is one of the principles.

There’s this idea, the Pareto principle—which comes from economics, the Italian economist Pareto—also called the 80/20 principle. I think what he noticed was that 80 percent of the wealth was with 20 percent of the population. These numbers show up in quite a few different places, and the Pareto principle applies to microformats in the sense that if we can hit 80 percent of the use cases with 20 percent of the effort, that’s good enough. Because as soon as you get into that extra 20 percent, the edge cases, the effort required to cover those edge cases gets exponential. So whereas other formats will aim to hit 100 percent of the possible use cases—that you should be able to encode absolutely any possible, conceivable scenario—the formats tend to get kind of complex, because the effort required to design a format that can cover all those scenarios increases exponentially.

With microformats, the idea is, “You know what? There are some cases where this just won’t work.” There’s an event microformat, for instance—hCalendar—and you might have a situation where you say, “Aha, but what about this kind of event, where it starts here and it’s in a leap year on a full moon, and how does the hCalendar microformat cope with that?” Well, it doesn’t. Basically, we’re not even going to try. You’re falling into that 20 percent edge-case stuff, and you’ll need a different format.

Again, it’s kind of being lazy. There’s this whole idea—I think was Joel Spolsky who said that good programmers were lazy programmers because you just always look for the simplest solution, and that’s the sign of a good programmer. That’s definitely the philosophy behind microformats. It’s like, “Aww, you mean we have to work on this stuff? Can’t we just steal somebody else’s work?” Because that’s what we do: just reuse, borrow, steal, build on existing formats. That’s a key thing: to not try and come up with something brand new, to always build on what’s already out there.

Crucially, as well, when deciding what needs formatting, what should be a microformat and what shouldn’t, is look at what people are publishing. Not what we think people should be publishing—we’re not trying to encourage people to publish this kind of data or that kind of data. It’s much more about what kind of data are people publishing anyway that could do with being formatted a bit better.

If you look at the language that people are publishing in, the existing language, that is very much HTML on the World Wide Web. It’s far more popular. Theoretically, you can put a Word document on the Web, a PDF, you can put all sorts of things on the Web. But HTML is the lingua franca of the Web because it’s a good, simple markup language.

There’s this idea that microformats, because they’re in the HTML, people are coming to this idea that because we’re publishing these microformats in the HTML—and HTML on the World Wide Web is kind of like a RESTful interface because you’ve got a URL, and at that URL there’s a Web document which happens to be HTML rather than XML or JSON, but still, it’s an addressable document—could your website be your API? Could you point at a URL and say, “Extract this data.” And to a certain extent, you can with microformats, though it’s very much a read-only API, whereas with a fully-featured API you can read and you can write.

With microformats, it’s kind of possible to build a super-simple, almost dumb, read-only API. Because if you look at what’s being published inside the HTML, you’ll find there’s a bunch of different stuff. On a social network site, there will be a page that has my details. So that data is already being published. This isn’t something we need to encourage social network sites to publish; they’re publishing it already. Who my contacts are on a social network site—that’s already there, that’s already in the markup at a publicly available URL. And then the details of those contacts are also being published in the same way that my details are.

So each one of these is being published, but if they’re just being published in regular HTML, there’s some semantic fidelity being lost because there are no elements in HTML to say this is a human being and this is that human being’s contact. We’ve got a nice set of elements in HTML, but they don’t provide quite that level of semantic fidelity.

Let’s go through these. For my details, somewhere on a social network site—how do we identify a person? To do this, we have the hCard microformat, which is essentially an HTML version of vCard. vCard is the address book format that you’ll find on your desktop in Outlook Express, you’ll find it on your mobile phone in your address book there, you’ll find it anywhere where addresses are used. So that whole idea of being lazy and reusing existing formats very much applied to the creation of hCard, where, when we were deciding what values should be in hCard, it was every single value that’s in vCard—and that’s it, we’re done. Game over.

Let’s say on a social network site, I’ve got a link like this that’s linking off to my profile. This social network site, example.com, has got a profile page for me. My user name on this site is adactio, because my user name is adactio on pretty much every social networking site. I can wrap that with some kind of containing element—in this case it’s a span, but it could be any element, we don’t mandate what elements you need to use—and this is going to be an hCard. The reason it why says vCard rather than hCard is because, as I said, we took all the values from vCard verbatim. Because vCard begins with the root element of “vCard”, it’s always called vCard in hCard. And I say, “This is the formatted name and the nickname, and this is the URL.”

There’s actually a whole lot of optimization going on here, because technically in vCard, you must a formatted name—or “name” is the only required value, I think. There are all these optimization rules, like, if you see “fn” and “nickname” together, that means, “This is the nickname and it’s the formatted name because we don’t have the full name.” And for the URL, it knows to look in the href rather than in the text between the opening and closing tags.

There are just a couple of classes there, and, of course, the great thing about the “class” attribute is the fact that you can space-separate values. And I could be throwing on my own classes there and that would be absolutely fine; I could be putting in non-hCard values: fn, nickname, url, user name, profile—any of my own class names are absolutely fine.

What this does is that it basically says: this is a human being, these are the contact details for a person, and this is that person’s nickname, and this is a URL that represents that person—just with the addition of a few class names.

This is something that I think people sometimes forget with hCard. If you’re familiar with hCard, the usual way it’s sold or pushed is that, well, it’s like vCard, so you put up your contact details and then people can translate it to vCard. There are plug-ins for Firefox, there’s a Technorati service that will convert hCard to vCard. So people wonder sometimes: what’s the point of putting up an hCard that’s only got this much information? Because here you’ll see that there’s no email address, there’s no telephone number, there’s no street address—none of these kind of real contact details are in there. All this really does is identify one piece of string on a page as being a person as opposed to some other piece of string which is just a text.

So, there is value in using really, really simple hCards. If you converted this to a vCard, it wouldn’t be much use. You’d have that in your address book, but you couldn’t call me, you couldn’t email me—it’s not much use. But there is still value in identifying this piece of text as being a human being.

What we’re doing here is essentially making up for the fact that there is no “person” element in HTML. The elements I’ve had to use are things like “span” or “a”—like I say, use whatever elements you want. But the great thing about HTML is that we are provided with our own semantic building blocks, like the “class” attribute, which, as the spec said, is for general-purpose processing by user agents. So it there for you to add your own semantics. It kind of got co-opted by CSS for many years, where people thought that the only reason you ever used classes was for CSS. But that’s not true. There is a CSS class selector, but you can use classes as hooks for Javascript, as hooks for whatever you want. It’s for adding your own semantic data.

On this page on this social network site, it’s linking off to a profile page that represents me. And if we go to that profile page, I’d probably have another hCard there. In this case, the element might be h1, say, because now we’re on the page that is about this person. Like I say, you can use whatever element you want. And I’m saying, this is the URL, and it’s linking off to my other URL, my homepage, my blog or whatever. And here I’m saying “fn”, formatted name—here we’ve actually got my full name rather than just my user name, so there’s more information being added here. And this is the kind of stuff that a lot of social networks are publishing anyway.

So, this is useful; we’re getting a lot of different bits of data about me pulled together. But what’s really nice is to tie together the fact that, okay, this page we’re on, on example.com, this represents me, this is a page about me—but this other site as well, adactio.com, that’s also a URL about me. It’s a URL representing a person. So, by adding one value, rel="me", we make that explicit. We say, that URL is me also.

So, the rel attribute you’re probably mostly familiar with from using in the link element at the top of your pages when you link off to a stylesheet; you’ll say link rel="stylesheet". And what that is doing is saying, this document I’m linking off to is a stylesheet for the current document. So it’s the relationship—the relationship of the linked document is “stylesheet”. Here, what we’re saying is the relationship of the linked document—the value in the href—is “me”. There’s a relationship being established.

Audience question: Why do you need the URL in the class anymore?

Jeremy Keith: What’s happening here is the fn and the URL are for the hCard, and this rel=”me” is part of XFN. So now what we’ve done is that actually we’ve got two different microformats going on. So: fn, URL, hCard, rel="me", XFN. And that’s one of the other nice things about microformats: you can mash them up. You can have an hCard and an hCalendar and XFN. They lend themselves well to being built Lego-style and put together like this. That explains why they’re all there: there’s two different microformats here.

So, XFN is this other microformat. I say it’s a microformat, but it’s actually kind of a proto-microformat in that it existed before microformats did. Microformats have to go through this whole Process before you have a finished microformat. It takes a while and, like I say, it has to fulfil all these criteria, it has to solve a real problem, it has to be using stuff that people are already publishing.

XFN didn’t do any of that. XFN was kind of born fully-featured by a bunch of people who got together—it was Tantek Çelik, Eric Meyer, Matt Mullenweg who got together and said, okay, we want to have a whole bunch of values for defining relationships between people. They did base it on what people were publishing, because around that time—this was a good few years ago—blogs were taking off and getting very popular, and what you’d have a lot in blogs was you’d have a sidebar with a blogroll. It’s always Americans who call it blogroll. Nobody over here seems to call it blogroll because I think it sounds too much like bogroll. There it sounds like logroll, but here it sounds like bogroll.

Anyway, what that means is you’ve now got something for representing the idea of contacts, which was the second part of what we were talking about—the kind of data that’s already being used on social networks.

Let’s say that on my profile page, I might have a list—an unordered list, an ordered list, whatever—of people who are contacts of me. I’ll mark them up as hCards as well—might as well, there’s no harm in there—but I will also add an XFN value, in this case “contact”. So here the relationship is the linked resource has the relationship of being a contact of the current resource.

XFN actually has a whole bunch of values—13, 14 values I think—but really, contact is enough. This is something that Chris Messina talked about recently after we had a panel discussion at South by Southwest, that instead of trying to convince people that you’ve gotta use XFN, you’ve gotta use XFN, it was like, well, actually, you’ve gotta just put these few characters into a link, rel="contact". That’s actually enough.

There’s a whole bunch of XFN values like friend, sweetheart, crush, co-worker, colleague, all these things. But I think for social networks, you don’t need them. I think on a personal site, it’s still good to have that. When I’m writing a blog post and I link off to someone, I like to have the ability to say I’ve met that person and I consider them a friend and they work in the same industry, so they’re a colleague. I think that level of fidelity is nice to have on personal publishing sites, but for social networks it can actually be really dangerous to programmatically try and say, “You are friends with that person.” That’s something that a person should be deciding for themselves. So I kind of agree with Chris that, at least in the case of social networks, rel="contact" is plenty. That’s enough.

If you have a social network that’s, say, a dating site, then maybe you would want to use rel="crush" or rel="sweetheart". But that’s kind of an edge case. Or if you have a professional site like LinkedIn, then there’s a use case for rel="colleague", rel="co-worker", these kinds of things. But, mostly, rel="contact".

So, essentially, out of XFN, two really, really useful values are rel="me" and rel="contact". And that’s it. There are a whole bunch of other values, but you don’t have to worry about it, I would say. For the purpose of building a social network, at least, don’t worry about them.

I’ve probably got a whole bunch of friends like this, and I’m linking to all of them: this is a contact, this person is a contact, and they’d all be marked up as hCards and all that. What happens a lot of the time is that I’ll have so many friends ‘cause I’m so popular that it’ll go on to more than one page. It’ll paginate. This is how it works on Flickr and on Twitter; you’ve got a page full of twenty contacts, click “Next” to see the next twenty and the next twenty and the next twenty. What you can do there is that you can semantically attach some more data here to say, okay, we’re continuing on. So this is another page representing me, and we use the rel="prev" and rel="next" values that have actually been baked into HTML for quite a while. They’d be used more in the “link” element, but there’s no reason why you can’t use them in the “a” element as well. So this works really well for pagination. This is another page representing me, the next page, and the previous page representing me as well.

So, again, this rel="me" thing is very handy. And, like the “class” attribute, the “rel” attribute can take multiple values, space-separated. Very, very useful. So there are few little things in HTML that are incredibly powerful. Incredibly powerful.

Finally, you’ve got their details. And that’s really just the same as what you did for your own details. In the same way as I had my page that was marked up with hCard and XFN, any one of my contacts—in this case, my friend Brian—he’s got his own profile page, and that’s got his hCard on it, and it’s linking off to his URL, and that’s tied up using rel="me". So, if every one of my friends has something like this, that’s quite a large network of friends.

And that’s pretty much it as regards what you need to do to add that extra bit of semantic goodness in there, to make it clear that this is a person, this is a contact of that person, here’s another page of contacts of that person. It’s just using hCard and XFN. Not even a full hCard, a very simple hCard, and not even many XFN values. Two values we’re talking about here, really: “me”, “contact”. “Prev” and “next” aren’t even XFN values, they’re just values. And we’re talking about two attributes of HTML—not even elements, attributes. Not new, custom attributes that we’ve invented; these are attributes that have been in HTML for quite a while.

It isn’t a replacement for an API. I’m not saying you don’t have to worry about making an API. But this makes a nice complement: the fact that, until you get around to building that API, why don’t you just add a few class and rel values and you’ve got a nice, simple, read-only way of allowing people to get at that data.

And generally I would also say: allow people to get at your data in as many formats as possible. So if you are building an API, of course you’ll export in XML, say, but you’ll want to export in JSON as well because developers want to have that format. Well, why not do this as well, so that if that’s what they want, rf they want to get at it in this hCard or XFN format, give them that option too. Basically, you can’t have too many data formats as far as developers are concerned. Give them anything you possibly can.

As regards publishing this stuff, it is that simple. It is that two-minute thing that David showed in his keynote yesterday: rel="me", rel="contact", some hCard values where applicable.

What about parsing this stuff, though? What if you want to consume this information from a social network that is publishing XFN and hCard? That’s tricky, because that’s hard work. Parsing can be tricky, parsing an HTML page—you’d usually have to run it through something like HTML Tidy to get it all cleaned up so you can then parse it as a well-formed document, because most HTML is actually pretty messy out there. Then what’s even harder than parsing is spidering, having to follow all those links, all those rel="next", all those rel="contact". Following all of those, programmatically, that’s actually a lot of work to do.

Fortunately for us, Google have taken care of it for us. This is kind of exactly the thing that Google are good at, because to do this spidering and parsing, you kind of need to have a copy of the World Wide Web stored somewhere on you server—which they happen to have, which is really handy. There’s a video of Brad Fitzpatrick talking about how they did this, and it’s basically, “Well, we took all the links on the World Wide Web and threw away all the ones that didn’t have rel values.” But that’s pretty much what they can do.

So, we can use what they’ve done. They’ve provided an API, the Social Graph API, which, again, David was demonstrating yesterday. And this will spider rel values—it’ll spider rel="me", it’ll spider rel="contact", it’ll spider all that stuff, it’ll spider the previous and next values—and it will send back a JSON file of what it finds. You can also use this to parse FOAF files, and it will follow all the FOAF files. What it does is it actually takes the FOAF files and converts them to XFN, so it always ends up as XFN right before the end anyway.

Let’s say you’ve got a new social network site, and you’re trying to get sign-ups, you’re trying to get people to join your site, and you want to make it as easy as possible. Give them the option to provide a URL somewhere else, and then use this Social Graph API to spider that URL and look for contacts, and look for other URLs that represent this person, and look for contacts over there. And then you’ve got to try and do some matching and figure out if you’ve found a contact for this person. This isn’t a Boolean thing, this isn’t a one/zero kind of thing where you can say, “Oh, that person on that social network is the same person as this person over here on this social network.” We don’t have any kind of unique identifier for this, but you can use some fuzzy logic here, I think.

If you’ve got a formatted name, which is the fn name in hCard, and it’s the same value over here as it is over here, that’s a pretty good chance. Not 100 percent, as I say, there are edge cases. But if there’s a Jeremy Keith on that site and there’s a Jeremy Keith on your site, it could well be the same person.

You’ve got the nickname, because a lot of people use the same user names on a lot of different sites, so that’s something to check out. If you get a combination of the two, that’s looking really good. And actually, URL is something that people identify with a lot, so when you allow people to put in a URL on a website—it’s usually their blog or something—and if you find a match for that, that’s looking pretty good.

None of these are 100 percent, absolute certainty things to say, “Yes, that is definitely the same person as that person over there.” But with a combination of matching this kind of stuff, you could probably make a pretty good guess.

What you don’t get is email, generally, because this isn’t something that’s generally published on the public Web because of the spam we’ve had to deal with for years. So most social networking sites, on your profile page, they will not display your email. And rightly so; that’s information you wouldn’t necessarily want published. So when it comes to parsing this stuff and matching values, you don’t have access to email, usually, whereas you would if you were doing the whole address book API thing.

But I think you can get by pretty well with what you’ve got. And email is often used as a unique identifier, but I’m not even sure that that’s a safe bet to make.

So, what I’m saying here is, basically, you don’t get 100 percent accuracy, you get maybe, about, 80 percent. So we’re kind of back to this 80/20 principle. You’ll probably get about 80 percent of the people where you say, “I think they’re pretty much the same person,” and you might get some edge cases that fall through and it doesn’t match them up, or you get false matches and say, “Ah, that person isn’t actually the same person.” But that’s pretty much it as regards parsing.

To anticipate some of the questions you might have and pre-empt some of them, questions that get asked a lot include: what about trust? How can you believe the assertion that this person is that same person over there on another social network. I’m signing up to your social network and it says, “Give me a URL,” and I put in a URL. How do you know that’s really my URL? I could be putting in your URL or your URL. How do we trust this input?

Well, we can’t. Or at least, that’s not something that microformats can solve. But this question of trust is something that’s true of everything on the Web. How do you trust any piece of information you read on the Web? And it’s different for every person. You can try and solve this programmatically—you’ve got secure certificates and things like that—but generally, this is actually a problem of just publishing on the Web anywhere.

Some people will read a Wikipedia article and they will trust that source because it is on Wikipedia. Other people will read a Wikipedia article and they will not trust that source because it is on Wikipedia. What I’m saying is that it’s different for every person. So you can’t make any assertions about the veracity of a claim just using the format. However, there are other technologies out there that do aim to solve this. So, OpenID aims to solve this one, to say you can authenticate the fact that that person claiming to reside at that URL really does reside at that URL.

By mashing up microformats for the formatting and OpenID for the authentication, then you can be pretty secure. But the whole idea of trust and authentication is not something to be solved at the formatting level. That is something to be solved at the protocol level.

Now, what about walled gardens? Because everything I’ve been talking about has been publicly published information, and I would say that this whole idea of hCard and XFN does work best on public websites. If you are running a walled garden like Facebook—Facebook does not allow much in the way of public access to profile information or friends lists, contact lists, all that kind of stuff—what do you do in that case? Well, I still think there’s no harm in publishing hCard and XFN because it only takes a few seconds to edit a template and put in those values. But, of course, the Social Graph API or other spiders can’t get to that information because you’ve locked it up in a walled garden behind a user name and password.

Again, some kind of mashup with an authentication layer like OpenID or SSL or password authentication would allow access. But generally, for walled gardens, you’re probably going to be relying on a more complex solution to get at that data: an API together with something like OAuth, or we saw the Open Social building-new-widgets thing and doing all that. But generally, for walled gardens, things get more complex. It’s just the way it is. For stuff that’s public, it’s generally straightforward.

So, who is publishing this stuff on the public Web? Well, every single one of those sites that I asked you about earlier on, every single one of those sites is publishing hCard and XFN. And you could plug one of your profiles on those sites into the Social Graph API and get back a whole list of contacts that you could then suck into another website. So there are a lot of people publishing.

Who’s parsing this stuff? Not many. Surprisingly few, considering how relatively straightforward it is now using the Social Graph API. Although the Social Graph API has only been around since the end of February, start of March. So, okay, that’s not very long. It’s not that surprising. Dopplr is doing some nice stuff, where you enter a URL and it tries to find people who are already on Dopplr who are on some social network site over there. Get Satisfaction does something interesting; it doesn’t have a friends list, a contact list or anything like that, but it does have a single-field sign-up which is really nice. The first question—you can fill in the whole form, saying what’s your name, what’s your email address, all this kind of stuff, or you can fill in a form over here which is one field, which is: What’s your URL? And if that URL is encoded as an hCard, it will suck out the hCard data. But it’s not yet doing the whole friends list stuff.

So there is room for some innovation here, for you people to get in there and start doing this stuff and get a leap. So the future is looking good. Like I said, this idea of one form field for sign-up. And actually, David mentioned this yesterday, and I didn’t even realize that Plaxo and Pulse were doing this, that it asks you for an OpenID URL, a URL that represents your OpenID, and while it’s got that URL, it says, “You know what? I’ll just run this through the Social Graph API and see if I find any rel links that I can match against people who are on my social network and see if you’ve got any friends here.”

So it’s this idea that I can come to a new social network site, and instead of filling out a long form with my contact details and then going through the whole process of saying that these are my friends, I could least try at the start to say, look, here’s my URL, you do the work. Don’t make me do the work. You go find who my friends are, you go find my contact information. Again, you won’t get 100 percent accuracy, but you’d get maybe 80 percent and you’d do pretty well.

So what you can do, certainly, is start publishing this stuff. The parsing, like I said, is pretty hard, but certainly publish this stuff, because it’s so easy to add these rel values and it’s so easy to add these class names.

But I would say that the real challenge here—because from a technological point of view, it’s really simple—the real challenge is in design. How do you design this stuff to flow nicely, how do you design it to not be creepy? That you make this flow nice… Some of the things would be: don’t use jargon. Don’t ever mention microformats or hCard or XFN or any of that stuff. People don’t care, and nor should they. They shouldn’t know what the technology is.

And don’t make assumptions. You’ve got an 80 percent match, you think that person is the same person as this person, we’ll make them friends on my network—don’t assume that. Always allow people to explicitly make that connection. So you might provide a list of names with checkboxes and allow people to check or uncheck those names. Don’t assume anything like that.

Should you notify people? When you’ve stored their network from over here, and now when a friend of theirs from over there joins a week later, do you let that person know? Do you send out an email saying, “Hey, your buddy from Flickr just joined our new social networking site!” Or is that creepy? These are kind of design challenges.

And what about allowing people to subscribe to it: rather than a one-time import, store that URL. So you say, “Do you have a URL on some other social network?” “Yeah, here’s my Flickr URL.” Instead of throwing that away once you’ve spidered it for XFN values, hold on to it, and every couple of days, spider it again and see if there’s any new people? In other words, allowing people to subscribe to a contact list somewhere else rather than just import. Again, design challenges, trying not to be creepy, that can be tough.

What I would say is that the technological side of things is super simple. It really is just a couple of attributes. The real challenge here is design. Big “D” design thinking sort of stuff. But that’s why we have designers. They’re going to help us solve this.

So, my website is adactio.com, I’ll post these slides up there and blog about this later. And microformats.org is where you can go to learn more about microformats, but you pretty much got everything you need from that little session there.

Thank you very much.

Sunday, June 8th, 2008

XEN

I’ve published a transcript of the panel I moderated at South by Southwest this year. The subject was Building Portable Social Networks and I had a blast moderating, mostly due to my great co-panelists, Chris Messina, Leslie Chicoine, David Recordon and Joseph Smarr.

During the panel, I made reference to an ongoing joke by Brian and myself to do a negative version of — an XHTML Enemies Network. I always thought of it as a frivolous idea but sometimes I wonder if there might be the occasional real-world use case.

Suppose, for instance, that I wanted to link to Mike “The Dick” Arrington’s latest bit of bollocks over on TechC*nt? Well, now I can add some extra semantic richness to that link by throwing in the appropriate rel value.

I give you the XEN 1.0 profile.

Please note the fine print:

XEN is not a microformat. It is a joke.

Building Portable Social Networks

A panel I moderated at South by Southwest Interactive 2008. My fellow panelists are Chris Messina, Leslie Chicoine, David Recordon and Joseph Smarr.

Jeremy Keith: Welcome to the Building Portable Social Networks panel. I’ll be your moderator. My name is Jeremy.

A little bit of housekeeping first. Obviously you don’t have to switch your phones off, but if you could switch your phones to silent, please, so we don’t have any interruptions, because—don’t make me come down there. I swear to God, I will shove it up your orifice if I hear one ringtone during this panel.

[laughter]

Jeremy: So, we’re here to talk about portable social networks. I kind of want to know what social networks you guys use so I’m going to ask. I’m going to list some social networking sites, and if you have an account with this site, you should raise your hand. If you have built or are an employee of the builders of the site, then you’ve got to whoop and cheer, because there’s a good chance, at South by Southwest, that that’s entirely possible.

So let’s take a random sampling. Who has an account at Dopplr? Okay. And I don’t hear any cheering, but that’s a good amount.

Joseph: Dopplr’s broken out. That’s pretty clear.

Jeremy: Who’s got a Pownce profile?

[whooping from audience]

Jeremy: A bit of whooping? Great. All right. Cool. Last.fm?

[whooping from audience]

Jeremy: Yeah. And there’s some whooping. There’s some whooping. Excellent. Digg?

[whooping from audience]

Jeremy: Wow. Lot of Digg. All right. Let’s see how many hands we get for this: Twitter.

[loud whooping from audience]

[laughter]

Jeremy: Nice.

Leslie: Nice. [laughs]

Chris: Was that a howl?

[laughter]

Joseph: No werewolves…

Jeremy: Yeah, we’re not playing werewolf here. And finally, let’s see Flickr.

[loud whooping from audience]

[laughter]

Jeremy: All right. Now, on each one of those accounts, you had to enter your details every time. And on each one of those accounts, you had to find your friends, contacts—call them what you want—on those accounts, and you had to say, “Yes, I know this person; yes, I want to share my photos, trips, music, whatever, with those people” every single time. Please raise your hand if that got really annoying after a while.

[whooping from audience]

Jeremy: All right.

[laughter]

Jeremy: [laughs] that’s what we’re here to talk about today. And to talk about this, I have assembled a crack team for my panel. And I’m now going to ask them to introduce themselves…

Chris: Why’s it never a marijuana team?

[laughter]

Jeremy: Okay. We’re going straight to the crack. I’m going to ask them to introduce themselves. They’ve got about 60 seconds to introduce themselves. And points will be awarded for creative and interesting facts. Points will be deducted for blatant pimping of companies. So I’ll start over here. Chris, do you want to go first?

Chris Messina: Sure. So my name is Chris Messina. I won’t do any affiliations, but a couple of interesting facts. One is that I don’t like olives. The second is that I’m from New Hampshire. And third is that my alter ego online, Factory Joe, is actually from a “1984”-esque dystopian comic that I drew in high school.

Leslie Chicoine: Nice. Hello. My name is Leslie Chicoine. And let’s see, interesting facts. I was suspended from high school. I have a game design degree. And—oh, my God, everyone’s looking at me.

Jeremy: You can name your company. It’s Okay.

Joseph: Yeah. You should really say where you work for.

Leslie: Oh. I work for Get Satisfaction.

Jeremy: Minus one point.

[laughter]

Leslie: Oh! That was trickery! Did you see that?

Joseph: This is a tough panel.

David Recordon: I’m David Recordon. I’ll take the one-point hit right now. I work for Six Apart. But I’m repping two other companies right here. I’ve got the Blogger glove on, since the whole idea of portable social networks—like our blogging software, their blogging software—should connect, yeah?

[laughter]

David: But, on the other wrist, I’ve got the Facebook wristband. So, also pimping the Facebook. But it’s locked on; can’t get that off.

[laughter]

[applause]

Leslie: Har har.

David: Yeah. So, two interesting facts. I technically have five names, and I’m the only Fajuen that I know of.

Chris: Fajuen?

Joseph Smarr: Wow. So I’m Joseph Smarr, from Plaxo. And I’ve been working on trying to help open up the social Web, by helping you stitch together all the content you’re sharing on these different sites and helping find your friends. And in my spare time, I like to play electric guitar, as many of you may have found out through Valleywag.

Jeremy: Okay. Good. I think Chris is winning so far. He’s leading with the points.

Chris: Sweet.

Jeremy: All right. Down to brass tacks. We just got a show of hands there that people are a bit annoyed, it seems, with having to re-enter this data and having to reconnect with all these people on all these different services. But, let’s face it: this is a gathering of geeks here at South by Southwest. Is this even an issue for most folks? Are we the canaries in the coal mine? Who wants to take this one?

Leslie: Okay, I’m going to jump on that right away. I feel that this framing is actually taking away from this battle that’s being had. The idea that network fatigue is the reason that we need to connect all these networks? I don’t know. That’s such a small subsection of the people. There are so few people who have that issue; I actually think that you guys can be much more creative about your reasoning about why we need to connect our services.

I kind of see it that it’s not about network fatigue. It’s about this sort of burgeoning coalition of services, and making it easier for people to move between those services and pull what types of information they want, what kind of data from each service that they want, into the next service.

So it’s not necessarily even about friends lists. It’s about documents that I’ve created, photos that I’ve taken. And I just sort of don’t really think the framing is a positive way to get things done.

Joseph: Well, I do think we’re canaries in the coal mine, though, in the sense that I think what we’re seeing is that the whole Web is becoming sort of socially aware and socially enabled, and that we’re finding that it’s amazing the number of services that get better when they know who you know. Right?

So, if you think about the evolution of Web 2.0, you think about the evolution of social networks and Facebook platform and all of that, there’s all these things about: photos work better when they’re social; bookmarks work better when they’re social; travel works better when it’s social. And if you think about it, almost everything could be made better when it’s social.

But the problem is if you think about the explosion of the Web itself, once you sort of had those open protocols, everybody could just sort of build a great Website. But when you want to build a new sort of social experience, you don’t just need the protocols; you also need that data of who am I and who I know. And right now, because that data’s not flowing, people have to start over every time. And that’s where that fatigue is coming on.

And that is a universal problem, right? I mean, if you think about when we all came to this conference, those of us who knew each other beforehand didn’t have to re-meet each other at this conference, right? We already had that past relationship. And that’s why we’re able to build on our experiences over time. And right now, every Website acts like you’ve never used another Website before in your life. And that, to me, is a universal problem, and a universal opportunity to make everybody use all of this stuff a lot more.

David: Yeah. I think, combining what Leslie said and Joseph said, in terms of that idea that it’s not just about the people that you know and wanting to have portability in terms of who you’re interacting with, but that all of the things that you’re doing because of Web 2.0, of creating technologies, of community collaboration, that’s what really requires the social features.

And so far, it’s been really poor user experience and poor starting point of, you sign up for a service, and it starts out with: “Who do you know?” And being able to sort of lower that barrier—which I think is why the Facebook platform’s been so successful—of, all of a sudden, you create a new application, there are many people who can go and use it quickly, is important. But it’s also important to remember that the Web is really successful because it’s not siloed.

Chris: I would also add to that, one of the important ways to think about this—and David’s sort of getting to this point a little bit—is what you can take for granted when you’re building Web applications. And I think, more and more, people are taking the social component for granted.

But the experience is, first of all, not universal, and secondly, it has a lot of friction to it. So, insomuch as there’s a great opportunity to reduce friction in using a new application, that’s extremely important.

And so it’s not just about not finding your friends over and over again and having that process be really crappy, because it isn’t that you want all the same friends on all the different services that you use, but that when you actually want to reach out and touch someone, it should be as easy as that—as opposed to having to go through a whole process in getting them to be invited into the service which, we were sort of saying, if I even have 10 friends that I commonly invite to new services, and let’s say I use 50 services, if I’m berating them with 50 new invites every five days, they’re probably not going to be my friend for that much longer. So it’s also about the imposition that you’re putting on other people, the more services you’re using.

For example, I probably have 364 application invites on Facebook. I mean, it’s kind of stupid. So figuring out a way of improving that process, for me, so that I can play Scrabulous without having to worry about going through this arduous process, I think, is also important.

Leslie: Yeah. I think you actually kind of hit on it right there. It’s about being able to move between the services in sort of a free-flowing manner, because right now, everything is siloed around—every service has its own gateway. And so, if we can knock down those gateways, then that means that all these services can actually start working together, and we can have that kind of puzzle-piece, snap-together Web that we keep talking about.

Chris: Or even better, it’s sort of more about competition and choice, being able to, let’s say, have most of my friends really like Facebook, but then I have a number of friends who are on MySpace. Being able to message them between networks is sort of something that’s really important. I mean, email accomplished this a long time ago; you can go from server to server. Well, why can’t you do the same thing with social networks? It’s stupid. But that’s the way it is.

Joseph: And I think what you’re all hearing here is this is not about my ability to abandon one social network entirely and go somewhere else. It’s much more about me being able to have these different tools work together so that I can use them more so that the friction comes down so that more users can take advantage of them. Right? It’s about making each of these apps part of a rich social ecosystem, where hopefully the pie should get a lot bigger and everyone should be able to win. And I think that’s something everybody can get behind.

David: And from a future perspective, I think Facebook NewsFeed was probably one of the really successful other ways to frame this question of, you’re really interested in seeing what are your friends doing online. And this has shown to be really true by the number of startups right now who are going and trying to compete in this space. You had Socialthing launch yesterday, I think, and it dominated Twitter this morning.

And so I think that feature, even though it’s not necessarily the problem of “My data is all in one place,” or “My friends are in one place,” or “It’s hard to get started,” but allowing that feature of just the philosophy that people exist in multiple places around the Web, and are sharing things and creating things all around the Web, is really important.

Jeremy: So, what I’m hearing here is it’s all about reducing friction. So, social network portability is essentially the Vaseline of the World Wide Web.

[laughter]

Jeremy: Which is good.

Chris: You said it first.

Jeremy: But we are still the uber-geeks. And even Mark Zuckerberg, just today, in an interview at ReadWriteWeb, was talking about throwing open his API, and nobody’s particularly interested in using this feature. As he said, “We threw an API and nobody came.” So maybe we are still a bit niche.

Should the reasons for doing this be more business-related, rather than it’s good for the future, it’s going to build the next stage of the Web? Are there business benefits to opening up? Or is it the opposite, that, from a business perspective, you actually want to keep people locked and you want to keep people closed in?

Joseph: We’ve certainly seen a lot of positive business benefits from it because, like I said, as much excitement as there’s been with any of these services, you just think about it: we are just at the very beginning. I mean, most people out there are not sharing rich content with each other.

Think about how many people you know who have a digital camera but you’re not seeing their photos. Think about how many people are doing interesting things that you’re not hearing about, right? Think about how many of your parents are communicating with you in that kind of way, or your extended family.

And so, when you unlock barriers and you make things interoperate, everybody starts using everything a lot more. And we’ve certainly seen that in Plaxo and Pulse; everybody’s creating stuff and sharing it, from their blogs and their photos and everything else, right? And just by being able to go in and sync your address book and find all the people who are sharing this information and connect you to me, even though ultimately you’re going out to the other sites, just that ability to sort of reduce friction has been incredibly good for our business.

And I think for all the other businesses, too, we’re driving them traffic, we’re getting more users. So I certainly don’t think we’re at the stage yet where there’s a zero-sum game, where people have to fight over a piece of the pie, because the pie’s just going to get a lot bigger.

Jeremy: Now, you’re talking specifically about address books. You’re talking about getting people’s information out of their address books so they can move it around from service to service. Is that not kind of a special case? Because when we talk about data wanting to be free, we’re usually talking about “my photographs.” I want my photographs to be mine, even if I’m storing them on Flickr, “my music”, whatever my content is.

But the contact details of my friends, do I own that? I own the fact that I am friends with a person, but do I own their email address now? Does that give me the right to put email addresses around? So address book portability is—I don’t know.

David: And that was something that I think was really the crux of the issue with the Facebook-Scoble-Plaxo…

Jeremy: Debacle.

David: …debacle—thank you—earlier this year, where it was sort of like, what was that fine line there between the information that Plaxo and Scoble were taking out of Facebook, of “Did that belong to Scoble?” Was going and taking that step of having OCR images to get email addresses actually beyond what was socially acceptable or not?

Chris: That’s not even the point. I mean, I think the point there should really be about whether or not you have the ability to contact someone when you want to contact them. And I think that the whole matter was confused by data geeks who care about data and not so much about people who care about people who care about solving real problems or problems in the while.

So, if I’m out and about, and I have this person in my phone, and I want to contact them, I should have some mechanism to do so, whether it’s by their phone number or their email or whatever—it shouldn’t really matter so much as if they’ve given me permission to contact them.

And I think that we’ve been architecting our thinking about this from a very sort of protocol and data perspective, as opposed to thinking about, “Well, what are we actually doing for people?” Why do people want to get this data out of the networks, when the reality is they want to contact someone, they want to talk to someone, they want to share something with them?

Leslie: I think that’s a great framing of it, actually, because the point isn’t really how; it’s what they want to do. So, in this case, there’s got to be a way. For example, if you don’t have the right to have someone’s email address, but these sites are linked, why can’t you, from the technical side, link up the sites so that I never actually see the email address that I’m using but I know that my message gets through? Now, I don’t have ownership of that email address, but I still get what I want.

David: Focusing on the feature, like Chris said, I think is really important. We put sort of a life-streaming concept, called ActionStreams, into Movable Type. And instead of going and focusing on the “Oh, by the way, bloggers, you’re also now adding XFN to all of your blogs and supporting Atom and things like that,” what we did was “Oh, you want to go and share with people that read your blog what you’re doing around the Web?” and focused on that, really, as the feature, building that feature. And now, as a side effect, all these people have XFN links to their accounts around the Web.

Joseph: Yeah, I totally agree with that. That was the thing to start with. It’s like how do you find what your friends are doing, and how do you start getting connected to that, and then how do you start wanting to share yourself?

And when these technologies work well, you don’t even realize that you’re using them, right? You see Yahoo deploying OpenID for all their users, where, when you come to Plaxo, there’s a button that says, “Sign in with my Yahoo ID.” You don’t even know that you’re using OpenID; you just know, “Hey, I already have a Yahoo account. I shouldn’t have to create a new account from scratch.” Those are those signs of progress that real users can get.

Jeremy: Yes. So this is an interesting point. And we’re talking about framing the discussion. If we get bogged down in techy terms, we’re going to put people off. It’s not so much fun. And when we talk about portable social networks, it’s kind of already a kind of techy term. And there’s another term out there that sounds even more off-putting, which is “the social graph.”

David: I’m sorry.

[laughter]

Jeremy: Does somebody want to defend that position? I don’t like that term. Anybody here want to say that they do?

Joseph: I just think we needed something that wasn’t “social network,” because we already think of those as like MySpace and Facebook.

Jeremy: What about “super-best-friends club”?

[laughter]

Joseph: I mean, ultimately, it just becomes a sign.

Leslie: I feel like the whole thing is, again, kind of strange, because the focus then is on…

Chris: Terminology.

Leslie: Well, terminology. And also, it’s really about people’s relationships. But the Web is way more than that. I mean, of course, when things are social, it makes it more fun, it makes it more interesting, there’s a lot more information that you can share and find. But there’s also just being able to move between services freely, whether or not that’s with your friends.

Jeremy: Okay. You keep saying “friends.” Now, this brings up an interesting point as well. Are they friends? Are they contacts? On Dopplr, they very specifically say, “You share trips with these people.” It says “your fellow travelers.” That’s an interesting term. Do we want to be using terms like “friends”? Are we really diluting the English language at that stage? The MySpace definition of friend is pretty broad. [laughs]

Joseph: Including Captain Morgan and what have you, right?

[laughter]

David: A few years ago, I worked on LiveJournal, and this was a huge problem we had, where users were friending each other. And it first started out in terms of how the site evolved, of just a small group of people using it, and they were their friends. But it was also, at the same time, pulling together, reading people’s content, trusting other people with your content. It was very hard, and the LiveJournal still hasn’t gotten away from the concept of friends.

Leslie: It’s hard once you’ve installed your system that way. Once you’ve trained people to think of it that way, it’s really hard to back out. So anyone that works with me knows that I’m incredibly adamant against using the word “friend.” And I think it’s really important to frame things up front in all sorts of interesting ways. So I really respect the way that Dopplr has done their work because they’re very careful about making sure that it’s around an action—so it’s a person that you do an action with, a person that you share a trip with, a person that you want to share photos with.

Joseph: And I think that speaks to another important point, which I think one of you alluded to earlier, which is, just because you want to be able to go to a new site and find who you know there, of course, it doesn’t mean you necessarily want to be friends with everybody on every site or share things with everybody on every site, right?

So, just like we don’t want people to think that to make your data portable, it has to be public, we also want people to able to think that just because you can go find people somewhere doesn’t mean you’re still not going to choose the type of relationship that’s appropriate…

Jeremy: That’s very true. I mean, I have friends on Flickr because I like their photography. But then they might want to friend me on Last.fm. But if they’ve got lousy taste in music, there’s no way I’m making them my friends.

Joseph: [laughs]

Jeremy: Now, we’re going to get on to the technologies required, because the building blocks are there today. But first of all, it seems like, is this not all a solved problem? Because, Joseph, you talking about moving your data from one address book to another service, and it seems like we can actually do that, because I sign up to new services and it says, “Hey, do you use Gmail? Do you use Yahoo Mail? Do you use Hotmail? Great. Well, just give me your user name and your password for that third-party service, and away we go.”

Chris: Well, they are trustworthy…

Joseph: That seems like a loaded question.

Jeremy: Yeah.

[laughter]

Jeremy: Okay. To give some background, I did bring this issue up at the Social Graph Foo Camp, and named and shamed a lot of services in this regard, because I think it’s pretty bad personally because it’s teaching users how to be phished, and that is wrong.

Joseph: And just beyond that, because that sort of issue, I think, we’ll hear about with OpenID and OAuth and things like that addressing it. But I think the other thing that’s really important for people to realize is that that kind of one-time import is really not capturing the sort of dynamic nature of people’s relationships.

I mean, just in South by Southwest, I have met a whole bunch of new great people, right? And I think any site that you slurp down your Gmail address book and try to find people: A. it’s only finding people by email address, whereas increasingly we know people, not be email address but through other social network. So, maybe I know your Twitter name maybe I know your Facebook ID or whatev

Wednesday, June 4th, 2008

reboot10 - Jeremy Keith talks about Soul

Wandering around the site for the Reboot conference in Copenhagen, I came across this video of my talk from last year. I had forgotten how much I enjoyed this talk.

Friday, March 14th, 2008

4 Technologies for Portability in Social Networks: A Primer - ReadWriteWeb

A nice summary of the technologies presented at my SXSW panel.

Thursday, February 21st, 2008

XFN encoding, extraction, and visualizations - Opera Developer Community

Brian has written an excellent article that not only explains how to write XFN but also how to parse it.

Friday, February 1st, 2008

Google Code Blog: URLs are People, Too

This is great news! Brad Fitzpatrick and Kevin Marks have built a new Google API that will spider XFN links.