[wuug-list] Collaboration Projects?

[Matt Draisey]

I am disappointed that no one has come forward with any ideas for
collaboration projects so here a few things I have been mulling over.



1. An RFC for a replacement for SMTP.

A conceptual rather than a strictly programming project.

Email is developing in ways that I don't care for.  All this verifying
of servers, secure DNS stuff takes away from the simplicity of the
protocol and erects all sorts of barriers to implementing your own email
transport.  My idea is to have servers accept mail for published email
addresses from anyone but to make it sufficiently computationally
expensive for the sender that spamming isn't cost effective.

Unlike SMTP mail this would be one-to-one not one-to-many.  For each
mail sent their would follow a challenge/response handshake between the
sender and recipient server.  The recipient machine would demand a
battery of spam filters be applied.  The sender would be required to
apply the filters (computationally expensive) and return all the
resulting scores.  The recipient could verify a subset of these to
verify that the sender isn't cheating and if the scores are low enough
accept the mail straight away.  If the spam scores are too high the
recipient would challenge with another battery of tests.  The number of
challenges would decrease geometrically (but slowly) so there will be an
eventual finite (but large) number of challenges before the recipient
machine gives in and accepts the mail anyway.

If at any point the sender is learnt to have cheated on the spam scores
the mail would not be accepted.  Somebody would have to look at this
from a game theoretical point of view to determine the best strategy to
avoid cheats.  I haven't done such an analysis but my gut instinct is
that it shouldn't be too expensive for the recipient.

Presumably there would need to be a standard interpreter in which the
spam filters would run so that execution on the sender and recipient
would yield identical results.  It needn't be an efficient interpreted
language as the computational cost is the whole point.  Inputs would be
restricted to the mail itself, the script, and some ancillary data tied
to the script (e.g. a dictionary).  It would need to be carefully
sandboxed so as not to be able to compromise the sender's server and to
be able to throttle scripts that aren't terminating.  As part of the
handshake the recipient's machine would send a reference to the text of
a particular script in a public repository; the scripts would be
retrieved by reference: maybe an url or a SHA through a domain name
lookup?  They might even be cryptographically signed for soundness.




2. A shell that would have support delimited continuations

Delimited continuations are a pet interest of mine lately.  They seem an
ideal fit for a simple shell programming language.  Something much
simpler than scheme.  This is a real pie-in-the-sky project.
Potentially very interesting though.




3. Anything on the web with Ruby on Rails.

Ruby on Rails is fun to develop with.  Can't vouch for the utility of
the result however.  Ruby is a slow language.




4. Writing a Drupal 6 module

Drupal is a great php CMS.  I've been using drupal for several years
without knowing how the code works or having written a line of php.  I'm
interested in learning.  Maybe a drupal theme too.




5. Writing a practical programme in Haskell

Probably impossible.




6. Finish my rsync like downloader that runs over http.

This is a combination of zlib file compression and a differential
downloader that works with files that are prepared beforehand and made
available by a static http server that supports byte range downloads
(practically all of them).

The code is a horrible mish-mash of perl and C++ and I have been
planning on finishing it for years.  This was meant to be a one-week
project in perl.  Ha.  Perl was too slow for the algorithm.  And the
actual downloading routine sprouted unexpected complexity.  Surprisingly
the code actually works quite well even if installing it is a pig.

One day I may learn how to write code elegantly in C++.  Or maybe not.




7. Finish my trivial prolog interpreter.

I wrote a proof of concept in java about 10 years ago, and a simple port
to C++ about 5 years ago.  It runs but is mostly useless.  I was
learning the intricacies of C++ at the time so the code is incredibly
crufty and portability is a distant dream.




I hope that this might initiate an email thread.  These are just things
I have been wanting to itch.  Other people's itches might yield better
project ideas.

Matt