Issues

There are currently a few issues that we need to solve.

Key resolver

• Be more consistent in naming.

  Is it a key resolver, address resolver? Both? Use a more consistent name.

• Create a decentralized system

  The current system is a centralized system meaning the owner of that system (we) are in control. This pretty much defeats the purpose of the system in general, as we don't want anyone to be able to control the system. So instead, we need to come up with a decentralized system.

  • https://github.com/zerotier/lf

Organizations

Organizations are special in the sense that they can control their underlying addresses. For instance, an address john@acme-inc! should not be able to register without the approval of the acme-inc! organization. One way to achieve this is to restrict the creation of the address in the resolver so only verified accounts can be added. Somehow, the resolver needs to know to which organization a hash belongs to, and ask for details.

The issue with this is that we do not know if an address-hash is an organization hash or not since all are hashed through SHA256, and non-organizational account do not need any checks.

We could fix this by double hashing:

john@acme-inc! = SHA256( SHA256(john) + SHA256(acme-inc))

When sending information to the resolver, we could do the following:

• use hash(john@acme-inc!) as the main address

• send in data:

    account: sha256(john)
    org: sha(acme-inc)
    pub-key: <....>
    pow: <....>
  

Can we "spoof" accounts this way? If I want to use foo@facebook!, I can add the account hash, but since we know the organization, it will contact the organization prior to adding the key (which will probably fail). If we don't add the organization data, the url we post to (hash(foo@facebook!)) will not match the constructed hash given from the data (sha256(sha256(foo)+sha256(Facebook)).

When no organization is present, we can skip the organization part and we can simply construct sha256(sha256(john)+sha256(""))