CodeCon requires presenters to be active developers of the projects presented and projects must have demonstrably running code. There’s an emphasis on open source and decentralization. This generally makes for interesting presentations. Today was 4/5.

Aura. Case study in how not to give a CodeCon presentation. Talk for a long time about motivations for and very high level problems of reputation systems, which all attendees are surely familiar with. Give almost no specifics about Aura, apparently a peer-to-peer reputation system, including nothing on what differentiates it from other work nor on how or why I’d use it in my own code. Demo stumbles due to display problems, fails due to ill prepared data. One mostly irrelevant bit about Aura’s implementation: it uses SQLite, an embedded, zero configuration, endian neutral SQL database that many projects have started to use recently and tons more will in the near future. I’m certain that SQLite is in my future.

ArX. Very useful presentation on Walter Landry‘s ArX, which began as a fork of the GNU Arch distributed revision control system (both are pronounced ‘arc’). Lists good, bad and ugly of active open source, distributed revision control systems (I agree that any system that does not have those attributes is strictly non-interesting), including GNU Arch/tla, ArX, monotone (also uses SQLite), Darcs, svk, and Codeville. I’ve tried tla a few times but have gotten hung up on what seems to me like uncessary complexity and strange conventions. I’d pretty much settled on using Darcs going forward, but now I’m a little concerned by its reordering of patches in order to solve merge conflicts, which apparently can be very slow and may make the repository’s view of its state at a point in time inaccurate. Not sure whether this is pragmatic, evil, or both, nor am I sure I understand it. See also Zooko’s notes (Darcs row, decentralization column).

Apache CA. A certification authority motivated by the needs of the Apache Software Foundation, which has around 900 developers with commit access working on around 100 projects. Program managers can add committers, but small admin team needs to create shell accounts, add to various text files, creating bottleneck. Solution: all services (most importantly source control — migrate to subversion) eventually use SSL, check for permission based on group membership noted in personal certificates and managed via email by program managers. Sounds like a long term project. “Open CA” feature is an interesting extension — allows anyone who can sign an email with GPG to create groups in the form of user@example.com/groupname. Not sure what the ASF motivation is for Open CA, but I’m sure interesting applications can be built on it.

Off-the-Record Messaging. Messaging using the PGP model (sign with sender’s public key, encrypt with recipient’s public key) can be attacked: the “bad guys” can intercept and store your messages. In the future they can break into your computer, obtain your private key, decrypt your messages and prove that you are the author. Very briefly OTR obtains “perfect forward secrecy” through the use of short lived encryption keys and “refutable authentication” using shared MAC keys — compromise of your long term keys doesn’t allow your messages to be decrypted, and it can’t be proved that you wrote your messages. A toolkit for forging transcripts is even provided to enhance deniability. Details here. This presentation seems to match the one given at CodeCon. They have a GAIM plugin, which I’m now running, and a standalone proxy for other AIM clients. Cool stuff.

RPOW. Reusable Proofs of Work is a system for sequential reuse of hashcash mediated by a server written by the great signal-to-noise enhancer Hal Finney. RPOW has many potential uses — apparently initially motivated by a desire to implement “P2Poker” with interesting “chips” and currently being experimented with in a modified BitTorrent client in which downloaders can pay for priority wit RPOW tokens, possibly encouraging people to leave clients running after completing a download (serving as seeds in BT lingo) in order to earn tokens which may be spent on future downloads. As the BTRP page notes, people could acquire RPOWs out of band, and not contribute more upload bandwidth, or even contribute less. The net effect is hard to predict. If buying download priority with RPOWs proves useful, I expect non-BT filesharing clients, which have far less reason to cooperate, would benefit more than BT clients. Perhaps the most interesting thing about the RPOW system is its great effort to ensure that there can be no cheating, in particular by the server operator. The RPOW server will zero all data if it is physically tampered with, it is possible for anyone to verify the code it is running, and that code can verify that its database in its untrusted host has not been tampered with, using a Merkle hash tree to verify (the secure board only has two megabytes of memory). The RPOW server may be the world’s first transparent server, which could facilitate a world of distributed, cooperating RPOW servers. Presentation slides.

Saturday.