GnuBucks Follow-up

[C.J. Collier]

Heya Richard and lists,

I've spoken with all of the recipients of this email recently about some
of my suggestions for personal information exchange and/or theories
about distribution of load and information.

If you feel like this email is rambling and doesn't apply to the lists
I've posted it to, you're probably right.  But have faith.  Finish the
email.  It all comes together in the end.

First of all, in terms of Karma Points (Heretofore, GnuBucks), I
apologize for using the GNU moniker without asking the GNU project first
for permission.  I was not aware this was a faux pas.  I guess that's
what I get for being young, idealistic and naíve.  Knowing it now, I
will avoid making such a step in the future.

The Karma Points project was intended as a global karma transfer and
notation system; but I also want it to evolve eventually to a spendable
currency, hence the 'bucks' portion of the previous name.  After
speaking with others about the project, I stepped back a bit and looked
at my goal from a different angle:

Two years ago, I started planning the development of a community
database project. Recently, I've been seeing other projects that have
similar goals, but don't quite hit the mark.  I've taken a bit of
inspiration from the things these projects have so far gotten right and
the mistakes they have made.  Some examples are LiveJournal,
friendster.com, Karma Points, the GNU project, and bugzilla.  They all
involve making the global community a smaller entity by providing easy
ways to network with other members in your community.

Since frendster.com is not a Free Software project, I've decided that
the idea should be re-implemented (as Free Software, without those
frickin' adds, and DISTRIBUTED, damnit ;).  My working name for this
potential project is 'acquaint.'  The purpose of 'acquaint' is the
replacement of friendster.com as the most visible representation of this
online community.

Here's a basic idea for implementation:

ISPs provide an interface to their local acquaint database through a URI
similar to this:

http://foo.com/acquaint

When an acquaint client is asked for information about a user at
foo.com, it issues an HTTP request for a URI similar to this:

http://foo.com/acquaint?foreign_user=bar@baz.com&local_user=cjcollier&command=get_friends

If http://foo.com/ responds with a 400 error, the client that issued the
request contacts a WHOIS database and asks for the technical contact for
the domain foo.com.  The client sends this technical contact an email
explaining what the acquaint project is and that there is demand for a
acquaint service to be installed on the domain.  It explains a bit about
the aims of the project, and also tells the administrator where to get a
few implementations of the acquaint protocol.  The goal here is that if
the admin gets enough of these requests, they will decide that they
should either not issue 400 responses for /acquaint or they should
actually install the software and add one more valuable service to their
ISP.

(on a side note, the same approach could be applied to /livejournal,
/ecalendar, /karmapoints, /bugzilla, and others.)

acquaint itself would provide services to store, list and link to
'friends,' 'mentors,' 'teachers,' 'lovers,' 'family members,' 'sworn
enemies,' 'neighbors,' etc.  These acquaintences would be indexed by
email addresses.  The database could potentially store information about
each user's person including photographs, testimonials, biographies,
autobiographies, interests, pets' names, etc. It would of course be good
to design flexibility into the protocol to allow for additional features
in the future. But I'm not a protocol engineer.  Anyone want to field
this?  If I do it, I'll probably get it wrong ;)

Compare LiveJournal's user info page:
http://www.livejournal.com/userinfo.bml?user=cjcollier

and friendster.com's user info page:
http://www.friendster.com/user.jsp?id=69291

I intend to build a UI to wrap around the LiveJournal, acquaint and
Karma Points protocols.  There should also be support for a distributed
calendaring system, web-based email, project management, and other
Personal Information.  All of these can be indexed by an email address. 

Which brings us to Evolution.

Evolution is a Personal Information Management tool.  All of these are
personal information.  If Evolution were made modular, I would write
modules (or help to write modules :) to access each of these services. 
How many more bug reports would be filed if it were as easy to file bug
reports (and attach incentive) as it was to write email?  How fast would
e-money (or e-karma) catch on if you could use the same tool you used to
keep track of your calendar and email to transfer funds?

Some food for thought.  Thanks for bearing with me!

C.J.