Brian Warner dropped by today and we spent a good chunk of the day speccing out New PB. The New PB will resolve pretty much all the security issues I've come up with in the long purgatory of implementation-less contemplation of my previous work, plus it gives us a good place to define all *kinds* of wacky transport semantics that would otherwise have made the old infrastructure blow up.
In brief, every object that you want to publish remotely will have a schema
or interface that specifies how it is serialized or referenced remotely. We
will be trying to produce arbitrarily publish-able objects that have both
state and methods, where you can say how you want to send things by default,
but you can also switch it up in different situations without defining a
The only lack of convenience is that we are going to spit out a
near-continuous stream of warnings if you try to go for the "arbitrary
graphs of objects" behavior that the previous version allowed. Sorry, folks,
but that's just not safe in python and it can never be made safe :).
However, we will still allow it for prototyping purposes, and maybe even add
a mode where the system spits out an example schema after you run "trial"
over unit tests that invoke the PB serializer on a particular set of
We also discussed his "Pet Mail" project, which is a replacement for SMTP.
It got me thinking about how poorly defined our shared vision for Q2Q is.
We've really only started the very basic design discussions. Brian's project
is a really good example of the kind of straightforward crypto work that we
haven't had any time or inclination to do. However, it's (explicitly) got no
deployment considerations, so if we can leverage some of the planned
features of Q2Q and Quotient to get the base PetMail protocol widely
deployed, we can establish a shared, clear basis for verified personal
communication. Divmod can build more interesting applications on top of
that, but it would give us a simplified transport layer to sell to other
ISPs so that we don't need to spend all our processing power and disk on
brute-force spam filtering.