Alan DeKok's Summary of the Ox Database

Pieces of this document are copied verbatim from messages to the database list.

Consensus items

• The OX database must be public

  Distributing private information is not a good idea. No one wants to read about other people, or make available private information about themselves.

• It must work now, and be extensible in the future

  This requirement forces us to the following conclusion:

  • The database must support fields we do not currently know about.

  Thus, the problems that the NCF has: you have to plan for the future, even if you do not implement everything yet.

• Control must be as distributed as possible

  There will always be SOME centralization, i.e.
  • Michael owns the "ox.org" domain.
  • People with machines and net connections will necessarly have more control over the database than your average 'plain jane' user.

  There isn't anything we can do to avoid these issues. The implicit trust we have now makes a technology solution to these problems pointless.

  The project is be doomed to fail if we create a centralized service. Other systems such as the NCF are already doing a centralized database - what would the purpose of this new service be?

Points of Conflict: What we need to discuss

• Purpose of the Public Ox database

  The big question. In general, the purpose of the public Ox database is to allow distribution and searching of public information about Ox members.

  Some information that may be in the database are:

  • maildomain and mail forwarding.
  • Web pages 'forwarding'
  • Skill sets
  • Hobbies/interests
  • ... any other information you care to make public

  Note: We would ideally allow only the "owner" of the information to update it. This is a very complex problem that may be ignored for now.

• Security and verification

  Implementation is a problem.
  • Mike: Security is a good idea. (i.e. PGP and RSA)
  • Russell: Too many people have trouble with mailboxes, let alone PGP.
  We can work towards a system that doesn't rule out the possibility of expansion to cryptographic means of identification, but starting from there may not be practical.

  Coupled with the extensible requirement above, it may be possible to come up with one scheme to move the data around, and leave verification to another layer of complexity.

• Distributed Database Locking

  If the same name gets applied for from two different hosts at the same time, we will need to arbitrate what to do. A search of the literature (C.U. library and the Web) will be necessary in order to discover if anyone else has run into, and rigorously solved this problem. Simple solutions are not necessary good ones.

  How do we resolve the 'Michael.Richardson@ox.org' problem? Well, that's not a software problem, so let's deal with that one separately.

• Implementation

  Hesoid, DNS, or other techie terms?

  Do we want to roll our own (which may be simple or difficult), or does such a database already exist?

  Does Hesoid do all of what we want? If its limitations conflict with the database requirements, we want to know this NOW.

  Distribute the RAW information using the DNS model - Then use faster 'search tools' such as mSQL that would suck up database information from the DNS system and do funky things with it.

  I've taken a quick peek at Michael's DNS references, and it looks like a lot of similar things are discussed there. My question is: Does DNS do what we want, or is it too complicated/simplistic?