[Freedombox-discuss] Messaging, the email 'availability' issue.

Chris Hall bitmonki at gmail.com
Sun Mar 24 20:06:27 UTC 2013


In my initial post concerning Erlang, I neglected to mention a couple
other reasons I think it might be a big help.

These are: messaging middleware via RabbitMQ, and CouchDB.

I read a few of the discussions concerning the (possible
non-)availability of an intended email recipient, the last one mentioned
UUCP, i.e., having the message 'hop' closer and closer to its intended
recipient.

IIRC, uucp was developed during the very early arpanet days, when
inter-machine links were more down than up, and the chances for a
complete, direct path from machine to machine at any given point in time
were slim, so such 'hopping' of a message closer and closer made sense.

Today's networks are different though I think -- when  a machine is on
there is almost certainly a complete path to it available, i.e., no down
links.

But the initial question was: what happens when the recipient's machine
is not available?

I'm thinking that message queues on the source machine might help deal
with this.

When a recipient's mail delivery agent is not available, the message is
place in an 'outgoing' queue.

If the recipient/contact is part of the FBx network, i.e., running the
FBx suite, goes offline and then comes back online, and we (the sender)
are in its contact list, then *it* should contact *us* for messages it
might have missed.

If the recipient is not in our contact list or is but not participating
in the FBx network, then as per current industry practice, periodically
our messaging system/mail transport agent should re-attempt delivery, etc.

This addresses the intermediate storage issue.  Further, ideally it
would be encrypted with the public key of the recipient, which I think
would prevent even the sender from reading it.

Additionally, IINM, RabbitMQ implements the STOMP protocol, used by
'Pubsubhubbub', the underlying mechanism for Google Reader and other
'publish/subscribe' systems, including some OpenSocial implementations,
I think.

IIUC, when one subscribes to feed, one provides a 'callback' address,
where the publisher can send the content when something new becomes
available.  This efficiently provides 'push' publishing to interested
parties.

This seems very useful to me.

CouchDB I'm not too familiar with (yet).  But its got a very good
pedigree -- a Lotus Notes developer left IBM and self-funded it for 2
years in order to create a database designed for the 'web'.  Stores data
in JSON, for starters.

My point being CouchDB, while not needed at present,  is another option
made available by using Erlang.

So short-term and long-term, i.e., strategically, an investment in
Erlang would seem very useful to a project of this sort.




More information about the Freedombox-discuss mailing list