[tahoe-dev] Idea for a Publish/Subscribe Message System on Tahoe-LAFS

[David Reid]

On Sat, Feb 11, 2012 at 11:08 AM, darrob <darrob at i2pmail.org> wrote:
> Hi everybody,

Hi!

>
> I'd like to discuss my idea for a messaging system on Tahoe with you. As
> far as I know there is currently no such thing.

I'm also very interested in the idea of building messaging systems on
top of Tahoe-LAFS, and I'd like to share some of those simple ideas
with the list.

I've so far considered the problem from a fairly email centric point
of view.   My ideas also require the so far non-existant append-only
capability and draw inspiration from systems like StubMail[1] and
Internet Mail 2000[2].

You see an email address, is capability in it's own right.  It's a
transferable (practically) non-revocable append-only capability for a
message queue that is directly linked to your attention span.  At this
point I should hope that the negative properties of an email address
are obvious.

Now imagine a world where instead you give a tahoe append-cap out.
Now, this append-cap is to your inbox (the ability to have many
inboxes say, one for a mailing list, and one for normal people, or one
of that new startup that might want to send you some messages, is
quite a powerful property and likely much nicer than heuristic mail
filtering in most cases.).  So how does alice send bob an email.

Alice has bob's append-cap.
Alice creates a new message on the grid.
Alice takes the read-cap for that message and writes that (perhaps
with other metadata) into bob's append-cap.

Bob then uses the read-cap to his inbox to look at all the message
metadata and download the messages he wants to read.  This is where
the system resembles Internet Mail 2000, in a grid with accounting the
cost of storing the unread sent message is pushed to the sender.  In
addition to this lazy fetching of messages Bob could very well use a
client which aggressively copies messages into some directory under
his control for archival purposes.

I also expect to see some backwards compatibility with existing mail
systems.  Instead of having Web Gateways you can have SMTP Gateways
that are publicly available (and perhaps consume caps of the form
append-cap at internetdomain.com) and local SMTP & IMAP gateways which
can be used to connect mail clients to the system.

My ideas sort of hinge on something which is not quite possible in
Tahoe today, the revocable append-only capability.  Sadly I don't even
feel I have a good understanding of how hard it is.  But if it existed
it would be an incredibly powerful primitive for all sorts of
applications.  You could build this system with non-revocable
append-only capabilities but then it would be only very slightly
better than existing email.

Revocability really allows you the power to choose who can send you
mail.  You could create a cap for each mailing list you wanted to
subscribe to, as well as for individuals and companies you sign up for
to send you email.  Later when you lose interest or decide that they
are consuming too much cognitive bandwidth you could delete their cap
and they would no longer be able to send you mail.

Of course, I leave the UX model of interacting with these long random
cryptographic URLs as address for contacting people as an exercises
for the reader.

[1] https://en.wikipedia.org/wiki/StubMail
[2] https://en.wikipedia.org/wiki/Internet_Mail_2000

-David