The premise of Dat Simple Directories (DSD) is that organizations such as companies, schools, agencies, and communities can act as the backbone of global identity.
Organizations will typically have the following desirable properties:
- The resources to deploy websites with DNS and SSL
- A need to maintain and publish their membership
- An interest in maintaining their reputation
DSD uses organizations' directories to help lookup and verify user identities.
Trust flows from the global DNS+PKI network. Organizations are expected to create a dat site with a registered domain name and SSL cert. These org dat-sites publish directories of their members.
As an example:
- Blue Link Labs has a website at
bluelinklabs.com. - It would publish a directory which contains
mafintoshandpfrazee - Those users can then be located at
dat://bluelinklabs.com/.directory/mafintoshdat://bluelinklabs.com/.directory/pfrazee
- Directories live in a dat archive under
/.directory - Every entry has an "id" which is its filename.
- Every entry is a mount to the target site.
These rules can be visualized as:
/.directory/{entry-id} -> dat://.../
An example directory which has "mafintosh" and "pfrazee".
/.directory/mafintosh -> dat://mafintosh.com
/.directory/pfrazee -> dat://pfrazee.com
Users can be found using two pieces of information:
- The organization DNS name
- The user's entryname in the organization
For instance, Paul Frazee at Blue Link Labs would be identified by the tuple {bluelinklabs.com,pfrazee}. This spec does not define an encoding or URI for that tuple.
Dat sites store profile-information in /dat.json and a thumbnail at /thumb.(png|jpeg|jpg). Therefore you can fetch a list of profiles and thumbs for all entries by reading the following files:
/.directory/*/dat.json
/.directory/*/thumb.*
Search can be accomplished by using the domain name of the organization and the entryname or title of the user. In the case of title, the /dat.json of the mounted user's dat would be read and matched against.