[wuug-list] Collaboration Projects?

[nebajoth]

All interesting ideas, Matt.  I haven't got anything "in the pot" right 
now, so to speak, but I'd like to add a general characteristic that a 
project would have: that it contribute somehow to the advancement of the 
city of Windsor.  That it be a project with a localized, civic-oriented 
focus.

This could be tied into a ruby or a drupal project fairly readily, I think.

Matt Draisey wrote:
> 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
> 
> 
>