Skip to content
Joshua Thijssen edited this page May 27, 2020 · 13 revisions

Users and Organisations

Like domain-names, it's possible to have organizations to which users belong. This way we can differentiate between John at organization 1 and john at organization 2.

Users and organization names should be [a-z0-9-], case insensitive.

Finding public keys from senders and receivers

When creating an email, it's possible to do this offline. Since these emails cannot be send anyway, they remain in the users' outbox until a connection is available to the sender's account.

At this point, the mail client can ask the mail server for public keys for the receiver(s). These are either cached or found by a DHT system called Kademlia. This is a peer-to-peer system running on mail servers that are connected to each other.

Since we need a bootstrap to get onto Kademlia, a list of peer hubs should be available online. Think of this as the root-servers of DNS.

Users have a minimal length of 3 chars. Organizations have a minimal length of 2 chars. Note that due to the nature of sending emails, it's still possible to generate and publicize accounts of less.

Who can register an account

A mail server can accept the registration of accounts. This can be done for everybody (any handle/organization is welcome), or strict (only certain organizations are welcome) or whitelisted (only certain handle/organizations are welcome)

How to deal with double/fake accounts?

Creating an account requires CPU effort. For every account that is available to the outside world, a proof-of-work should be completed. Mail servers can define how many bits of work are needed before an address is accepted.

Accounts should be signed: we should always know for sure that the sender is actually the sender.

IDs

Instead of email addresses, we should use IDs. This could be something like a handle like jaytaph!organization or something. We should be able to differentiate between users of an organization and an organization itself.

Clone this wiki locally