Domesday

Domesday* is the name of the software which will run a Mozilla Contributor Directory. (Issues specific to Mozilla's implementation are on a separate page.) This document gives the overall vision and full feature set - the features for the 1.0 release are more limited, and those pages are where the action is at the moment.

Purpose

We aim to build a system where community members can create a simple profile that includes their basic contact information and references to their identities in other systems. In this way, it will associate someone's identity in Bugzilla, Hg, IRC, etc., allowing people who know one to find out the others, and also provide community members with a bit of (opt-in) biographical information about the person they are interacting with.

In addition, it will allow people in the same geographical area to connect up for local events.

The software will be open source, so other groups can pick it up to build their own Domesday servers.

Anti-Purpose

There are some things we are explicitly not doing as part of this project:

• Building an extranet
• Building an 'identity server' or single signon server
• Building an OpenID provider
• Building an authorization system

Data from the system may later help in the construction of one or more of the above, but this is not any of them.

Features

Privacy is a first-class UI design principle in Domesday. One function of the software will be to demonstrate that it's possible to do software which holds personal information in a way which allows all users easy control of the privacy of each individual data item, without overwhelming UI complexity. We want to show the Facebooks of this world how to do it right :-)

There is a UI mockup of one way we could do this.

• Minimum possible set - do one thing well
• Individual profiles
• Profile management - creation, deletion
• Search (by any identifier)
• Tagging
• Configure the privacy level of each item of information

The key way of interacting with Domesday will be via its API - it is expected that most information it serves will be consumed via "plugins" for other apps - mail clients, Bugzilla, IRC clients, SCM web interfaces, etc.

Who's In?

Anyone can create an account But individual Domesday implementations may well make some tags particularly meaningful, either within their communities or as a method of revealing more data (see "Data and Privacy").

If people in the Directory slow or cease their involvement their profiles are not automatically removed, but can be flagged as "inactive".

Use Cases

An initial (and likely incomplete) list of possible use cases for this system:

• Answer the question "who is that?" in various systems.
• Identify a community member by searching for their first name and scanning through photos in the search results.
• Compile a list of people to invite to a Leadership Summit (all currently-active trusted contributors who are team/project leaders or above).
• Find everyone working on a particular project.
• Find all our contributors who live within 50km of Ottawa, Canada.
• Generate a world map of all our contributors.

User Tasks

• Accept invitation
• Log in/out
• Create profile
• Edit profile
• Delete profile
• Reset password

Administrator Tasks

Everything a User does plus...

• Delete profile (at user request only)

Data and Privacy

The directory will be publicly searchable and viewable, but with fine-grained privacy controls so users can control who gets to see what information in their profile. Given that the purpose of the directory is to disseminate information, the key thing here is not to keep everything as private as possible by default, but to set expectations and meet them. The privacy system must be clear.

Each field will have an attached privacy value, so a user can specify who can or cannot see what information. That privacy value is either "Public" (the whole world) or one of a small set of nominated special tags, which are defined on a per-installation basis. (See Mozilla's ideas here.) You have to have that particular tag to see that data. By default, one or two of these might be set up, but installations could remove them and define their own.

So, for example, you could define a "trusted" tag. Then, the server would give everyone a "trusted" box into which they could drag data items, so they could only be seen by people with that tag. (This would not provide much security unless the "trusted" tag were one of those tags which cannot be self-awarded!)

In terms of UI, it could be that the editing screen presents fields in different coloured sections, corresponding to different levels of privacy. If the user wants to change the privacy of a data point, they have to physically move it from one section to another. There is a UI mockup of this idea.

Deleting Profiles

Users should be able to delete their profile completely at any time, with all data being completely removed and no longer available via any interface to anyone, including admins. For practical reasons, copies will remain as part of normal archived backups of the system.

Data Fields

Current suggestions for initial fields are as follows. Only given name, one email address and password are compulsory.

(NOTE: Much of this is Mozilla-specific, so this stuff must be easily changed/customized so other projects can use this code to create their own Directories.)

Tagging

The tags system will be in two parts - public and personal. Public tags are those on you that anyone can see and edit (but see below); personal tags are those you add to other people that are not visible by default. However, anyone who knows who you are and the name of the tag can see the list of people to whom it is added.

So personal tags are for pulling together set of people like "fosdem-invitees". One person may be making the list, but anyone else can see it by querying on domain.com/search?tag=fosdem-invitees&tag_owner=foo@bar.com

Each tag has another tag associated with it, a "bless tag" - which defines who can add or remove that tag. Say tag "sumo" has bless tag "sumo-blessers". Anyone with sumo-blessers can add and remove the sumo tag from any other account. Tags may be their own bless tags, in which case it's an "anyone inside can invite new people in" system. Tags may also have a bless tag of "mozillian", which means that all validated people can add and remove that tag. If a tag has no bless tag, anyone can add or remove it.

Bless tags can be used to restrict changes and so make sure particular data sets remain correct. Uses cases for this include "driver", "trusted", "reviewer" or "mozpaid".

In general, we expect people to maintain their own public tags, but we make it so anyone can edit them because in some cases, keeping data sets current will be much easier if the person caring about the data can fix things rather than contacting everyone concerned. Bad behaviour in removing or adding tags is dealt with by social rather than technical sanctions.

Tags may also be in name:value format, in which case restrictions are defined on the name only. This allows us to have tags like 'module-owner:Places', but have the appointment of module owners restricted to a certain set of people without having to enumerate all the possible modules. Perhaps this might be implemented as: "name:value" tag inherits the bless tag from the "name" tag.

Schedule

The aim was to have something up and accepting registrations by the end of Q1 2011. However, that is looking increasingly unlikely. It'll be done when it's done :-)

Implementation

• Python and Django, because that's what webdev are most familiar with and I want to be able to ask for their help :-)
• Profile and search outputs (via templates) as HTML (with HCard), JSON (perhaps using PortableContacts schema), VCard, XRD (for WebFinger)
• LDAP vs. SQL - tricky. A directory back end means that perhaps it could one day run on top of Mozilla's LDAP authorization infrastructure, using the same database. But I know SQL much better. To be investigated.
  • The Mozilla LDAP also contains lots of sensitive corporate IT details that might be best to keep isolated from a public directory, for what it's worth
• I plan to rip the HTML UI off from the current intranet Phonebook.
• Making it actually happen is more important than the use of any one particular technology.

Resources

• Gerv :-) I'll be writing the code.
• Contributor Engagement are very interested in the project, and are offering help.
• L10n are interested in the project, and can offer help.
• David Boswell has offered to help.
• Design Needs
  • We'll need someone to help design form pages, maybe just the main profile page that allows you to adjust your privacy settings as seen in the Privacy UI Demo.

References

• Deb Richardson's "Sigil/Signa" proposal, from which much of this page is shamelessly stolen (link on Mozilla Intranet)
• Gravatar's new Profile feature (courtesy mhanson)
• gitHub "identity page" (courtesy mhanson)
• Flavors.me profile pages (courtesy mart3ll)

* - OK, so this is about the sixth name this project has had. But what does it mean to write a piece of software if you don't get naming rights? :-)