> For the complete documentation index, see [llms.txt](https://decentrl.gitbook.io/decentrl/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://decentrl.gitbook.io/decentrl/mediator/registration.md).

# Registration

In order for identity to be able to register on a mediator, the mediator DID Document needs to have **DecentrlMediatorRegister** service available. This service looks something like this

```json
{
  "id": "did:web:mediator.decentrl.network#mediator",
  "type": "DecentrlMediatorRegister",
  "serviceEndpoint": {
    "uri": "https://mediator.decentrl.network/register",
    "routingKeys": ["did:web:mediator.decentrl.network#key-ECDH-1"]
  }
}
```

* **serviceEndpoint** should be a URL linking to the POST route for registration.
* **routingKeys** should be an array of references to the public encryption keys used by the mediator to enable E2EE communication. Minimum of one routing keys is required in order to establish secure communication with the mediator.

### Registration

When registering on a mediator, an encrypted payload containing a list of mediator features you wish to enable for your identity has to be sent. 

{% hint style="info" %}
Choosing which features identities wish to have enabled on the mediators increases the privacy of the identities. Take Elon Musk for an example, let's say Elon wishes to have a DID from which he can post status updates to his followers, something like Twitter. In this case, he might want only one-way public communication channels enabled on his mediators to prevent random people from messaging and spamming him.

He could however have a different DID setup for encrypted communication with his friends. This did would have a two-way private feature enabled on the mediator. Because DIDs are private and cannot just be guessed, only people who know the id of Elons private communication DID will be able to contact him.
{% endhint %}

{% hint style="info" %}
It is suggested to use different DIDs for different services as it increases the security of your identity.
{% endhint %}

*Unencrypted payload should look something like this*

```json
{
  "features": ["TWO_WAY_PRIVATE", "ONE_WAY_PUBLIC"],
}
```

Once you have your payload prepared, you can encrypt it using **ECDH-ES A256GCM** JWE encryption using your private **EC P-256** key and one of the public routing keys specified in the mediator's service endpoint. When setting protected JWE headers, set `kid` property to the id of the public key related to the private key that was used for encryption. That way it's easier for mediator to verify the identity of the sender.

The encrypted payload can now be posted to the registration endpoint. It should be included in the body in the following format

```typescript
interface {
  encryptedPayload: string;
}
```

Once the mediator receives and decrypts payload, it will know which features to register for the current identity and it will also have a verificaiton of the identity due to the nature of eliptic curve encryption (authcrypt)

{% hint style="info" %}
Mediators can be **public**, meaning that anyone can register and they can also be **private** allowing registration of only selected identities.. (might require payment to use, etc..)
{% endhint %}