Kolabora Interview about Identity Commons

Posted on Published by Eugene Eric Kim

Robin Good interviewed me yesterday for his Kolabora Internet Radio program. We discuss online collaboration — of course! — and the latter half of the conversation is about Identity Commons.    (BGV)

Robin also interviewed me last May, after my manifesto came out. What’s really interesting about doing these interviews — besides the fact that I enjoy talking to Robin — is that Robin is always on top of the latest and greatest Internet conferencing tools. Last May’s conversation was videocast. This interview was recorded over the Internet using a tool called iVocalize. It’s like an online walkie talkie over the Internet — you hold down the control key when it’s your turn to talk. It also removes the pauses that occur when a different person starts talking, which makes the end recording sound very fluid. If you listen to the recording, it sounds like Robin and I are having a very natural conversation, when in reality, it was a bit choppy because of the limitations of the tool.    (BGW)

In any case, I never tire of the fact that I can talk to someone in Italy in real-time for free using my Web browser.    (BGX)

i-names Not Centralized

Posted on Published by Eugene Eric Kim

The Identity Commons i-name fundraiser got Slashdotted today. I haven’t been all that impressed by the comments on Slashdot in the past, but they were useful this time in revealing a fundamental misunderstanding about the Identity Commons infrastructure (and a problem with its messaging). Identity Commons is not centralized. This is not a non-profit version of Microsoft Passport. It was designed from the ground up to be fully distributed. See Fen Labalme‘s post for a deeper explanation and some additional comments on the Slashdot responses.    (7VR)

i-names for Sale

Posted on Published by Eugene Eric Kim

I’ve mentioned Identity Commons over and over again for the past year. (See “Identity Commons: Empowering the Individual” for a detailed introduction.) Identity Commons global i-names are now available, and until January 25, 2005, you can purchase the rights to an i-name for 50 years for only $25. I’ve posted more details at the Watering Hole.    (4QN)

My global i-name is =eekim. (I also have =Eugene.Kim and =Eugene.Eric.Kim.) Join the crowd, and support a very worthwhile project. Buy an i-name today!    (4QO)

E-Advocacy Brown Bag Discussion

Posted on Published by Eugene Eric Kim

Emy Tseng invited me and about 10 others to join her at the Community Technology Foundation in San Francisco for a brown bag discussion of e-advocacy, especially relating to underserved communities. The folks I meet through Emy are always interesting, and I especially appreciated the ethnic diversity of those attending this meeting. I don’t get too caught up with race when it comes to my work, but I’m definitely conscious of the fact that most of the folks in this space are white men.    (2FS)

Some quick takeaways and thoughts:    (2FT)

  • Advocacy tools need better multilingual support. It’s not enough to localize tools; you also have to make them usable.    (2FU)
  • There’s certainly a lot of room for folks in the e-advocacy space to collaborate. But the real problem is not choosing tools, but knowing what online capabilities exist and how they can be integrated into an overall advocacy strategy.    (2FV)
  • Many small to midsize nonprofits struggle simply to keep their computers running and their email working. Transitioning to using more sophisticated tools is a big, big step.    (2FW)
  • Some people brought up issues regarding in-fighting within coalitions over who owns or controls mailing lists. Identity Commons offers an interesting technical solution to this problem, in that it gives control to the individual.    (2FX)
  • Several folks talked about the need for techies to avoid jargon and speak in a language these organizations understand. I disagree. Shared Language is not one over the other; it’s different communities developing Shared Understanding. There’s no one-to-one translation between technical and nontechnical concepts. Techies have to work to understand users, but users also have to work to understand technology. Only then does Shared Language emerge and coevolution becomes possible.    (2FY)

TPVortex: Intro, Call For Help

Posted on Published by Eugene Eric Kim

In my manifesto for collaborative tools, I cited Backlinks as an example of a common, yet oft-overlooked conceptual construct in collaborative tools. Those who know me well know that my strategy for implementing some of Doug Engelbart‘s ideas (which I crafted over three years ago) has always been to create simple, concrete tools that could easily be shoehorned into existing applications. The plan was to start with Granular Addressability (Purple Numbers), then move on to Backlinks.    (247)

For a number of reasons, now seems to be the right time for me to start shifting my technical focus to Backlinks. The strategy for doing this is to implement a generic, Open Source, Backlink database (dubbed “TPVortex” and integrate it into several existing tools: PurpleWiki, blosxom, MovableType, MHonArc. I’m looking for folks who might be interested in participating in this project.    (248)

The motivation for such a tool is straightforward: Backlinks provide useful, contextual information. Most Wikis already implement Backlinks. Some of them display Backlinks on the main page, which is the correct behavior. Others (including PurpleWiki) do not. In order to implement this properly, you need a Backlink database.    (249)

Once you have a Backlink database, you might as well use it for other applications besides Wikis, such as blogs. We have this integration in PurpleWiki (see Wikis As Topic Maps for the resulting benefits), but again, it would be much nicer to display the Backlinks on the page itself rather than requiring a person to click on a link to see them. In order to implement this properly, the database has to store document metadata, such as title and author, not just the Backlink. For this reason, I think that TPVortex should use an RDF database on the backend.    (24A)

Other thoughts:    (24B)

I welcome help in all forms — comments, critiques, and especially coding. I’ve set up a Wiki page at the Collaboration Collaboratory — Collab:TpVortex — to serve as the center of design discussions. If you’re interested in contributing or commenting, please do it there. Feel free to drop me an email as well.    (24F)