Editing Nexus P2P trust network (section)

=== Where do you want to store member profiles? ===
A fundamental design specification is to keep Nexus as lightweight and as fast as possible. An ''identity record'' on Nexus would be not much more than a handle, a set of descriptive tags, a link to a profile on a social website, an expiration date, a public encryption key, and a digital signature.

If applying the public key to the record (less the signature) produces a match to the signature, then it is confirmed that the owner of the private key corresponding to the public key is the individual who created the record. This step is automatically performed by Nexus.

The website profile would include a means of contact (such as email). If an email containing some random data (or just a unique message) is encrypted with the public key and sent to the owner of the profile, and that person responds with an email containing the random data, then the original sender now has a reliable means of contacting the true owner of the Nexus record and has the option of having a private (encrypted) communication with that owner. That owner can confirm that the profile used to contact him is legitimate.

Typically, the owner of a Nexus record would have many profiles on different social websites. That owner would pick one of them to represent his identity to Nexus. He could actually create several independent Nexus identities if he chooses.

The essence of a virtual identity on Nexus is the public key. It can be used to reliably connect to the real person behind the identity as long as that person keeps his private key secret. A virtual identity starts out with no reputation and must acquire one over time. This is done through a second kind of record, a ''reference record''.

A Nexus reference record contains at least a rating code but perhaps also a text [[reference]]. It also contains the handles and public keys of the owner of the reference and the object of the reference, an expiration date, and a signature made from the owner's private key.

Each record stored in Nexus has a search key (probably invisible to the end-user). A search key can have multiple records associated with it. Identity records can be retrieved with keys like ''identity:handle'', reference records with keys like ''reference-for:handle'' or ''reference-by:handle''. Several different identities might use the same handle, so a handle is only a convenient approximation to an identity. The retrieved references are matched to the correct identities using the public keys.

There are also ''tag records'' in Nexus, used for searching for identities using descriptive tags. The design of this could go several ways, but the basic idea is that these records only contain handles.

So, all of the data that is moved and stored on Nexus is relatively small in size. No web pages, no pictures or other media. This is important for speed especially since there is much redundancy.

Please note that I have not actually implemented the layer that manages structured records yet. What is currently implemented can only store (with redundancy) and retrieve unstructured data records using a search key. But the lower-level mechanisms for bootstrapping and maintaining a distributed network with many nodes frequently entering and leaving is now implemented.