kragen-tol is a mailing list rather than a blog for a couple of reasons. The first was that, when I [set up the list and made my first post][0], (about prisons, crime, policing, democracy, and humanity), it was November 12th, 1998. Some people had blogs; I read some blogs; but it wasn't yet the default means of publication that it has become now. There's a blog version of the list at <http://bentwookie.org/blog/kragen-tol/>, but because it's not primary, I haven't made the formatting on it work well.
The second was that I want my list mail to serve as prior art to stop obvious patents from being granted, or to revoke them or the obvious claims in them in court. (Re-examination didn't exist yet, if I recall correctly.) Some examples: I posted [a simple system architecture for MMORPGs] [1], [an article about networked automated fabrication] [4], and [some thoughts on interactive kinematic modeling] [2] that month. Later that year, I wrote about [uses for ubiquitous computing] [3], [ballistic transport in evacuated tunnels] [5], [a technique for transparent CPU virtualization] [6], [fault-tolerant distributed computation on untrusted CPUs] [7], [a technique for time-travel debugging] [8] (which Michael Elizabeth Chastain implemented around the same time as mec-replay), and [a lightweight device for stopping bullets] [9]. In order for this to work, though, there needs to be a record of these things having been published at a particular time; things published after a patent application has been filed are not "prior art" and do not invalidate patent claims. My thought was that publishing these things on a mailing list, rather than merely on the web, would create a number of distributed copies in different subscribers' mailboxes, each timestamped with the time that it had originally been received. This way, there would be more than just my word to go on. A number of people with different interests would have records of the publication. There are some big disadvantages to publishing in mailing-list form. It's not very observable (what mailing lists are your friends on?), so it doesn't spread very fast; the formatting sucks unless you send HTML email; reading the archives is a pain; and I have to waste my time trying to get my domain un-categorized as a spam source in order for people to get the mail. [0]: http://lists.canonical.org/pipermail/kragen-tol/1998-November/000296.html [1]: http://lists.canonical.org/pipermail/kragen-tol/1998-November/000300.html [2]: http://lists.canonical.org/pipermail/kragen-tol/1998-November/000303.html [3]: http://lists.canonical.org/pipermail/kragen-tol/1998-December/000307.html [4]: http://lists.canonical.org/pipermail/kragen-tol/1998-November/000299.html [5]: http://lists.canonical.org/pipermail/kragen-tol/1998-December/000309.html [6]: http://lists.canonical.org/pipermail/kragen-tol/1998-December/000313.html [7]: http://lists.canonical.org/pipermail/kragen-tol/1998-December/000314.html [8]: http://lists.canonical.org/pipermail/kragen-tol/1998-December/000315.html [9]: http://lists.canonical.org/pipermail/kragen-tol/1998-December/000316.html A better solution? ------------------ I wonder if there's a better solution today. For example, if I put all this stuff into a Git repository, then I could add new articles, other people could add new articles too, I could edit existing articles without losing the records of the old versions, and everybody who edited it would have a copy that was protected from external corruption. Unfortunately I don't think there's a good way to prove when somebody first received a particular thing using Git. Git commits are authored and dated, but there is no authentication of the author or the date. Git supports cryptographically-signed tags, but it doesn't create them in its normal workflow, so typically only a few people make them; they're used for things like major software releases. So the threat model is something like this. It's 2025. FooCorp is suing BarCorp for patent infringement; tens of millions of dollars are at stake. BarCorp wants to show that the supposedly infringed patent claims are invalid because they were published openly in 2012 on my git-based equivalent to Halfbakery, four years before the patent was filed in 2016. BarCorp presents the publication of this technique as evidence, along with the Git commit in which they were created and the commits since then, by a variety of authors, and shows that the same commit history is found in several different contributors' replicas; they explain how Git's content-based blob store prevents tampering with the history of any commit. FooCorp has branched from a very old commit, set their computer clock back to 2010, added an article with that 2010 date describing a well-known celebrity scandal of 2023, and then constructed a similar, but fake, commit history with a variety of imaginary authors, over the next fifteen years. (As it happens, `git rebase` can be used to do this fairly easily, but if it didn't exist it would be easy to write it yourself.) Sometime in 2025, during this court case, they managed to get some legitimate contributor somewhere to merge their branch in, and that contributor's branch got merged into the cloud of the popular versions of the repository. So in the very same commit history that BarCorp presented to the court, the FooCorp lawyer locates this obviously recent article supposedly from 2010, dated to 2010 using the same techniques that BarCorp was using to prove that the publication of the patented technique happened in 2012 and not 2022. Consequently, the court ignores BarCorp's evidence and finds in favor of FooCorp. Any ideas? Is there some feature of Git or the court system I'm not familiar with that makes this scenario implausible? Or provides a way to prevent it? By contrast, the Received: line on people's email would probably stand up, if you could find half a dozen people whose mail was stored in different places. -- To unsubscribe: http://lists.canonical.org/mailman/listinfo/kragen-tol
