# Code structure

Modules should have their own specific API.
When a module currently requires to send messages, the API should reflect semantics instead of providing the module a way to just carry raw messages.
For example, there are currently modules able to send messages (with a very simple `MessageToSend message` API), but instead of dealing with raw messages that need to be built inside the module, the API should be more semantic such as `ChangePassword new-password`.

Once modules will have specific APIs, the entire state of the application could be moved into a single module (or *component*).
Thus, every state modification can be handled in a single place.

Minor modifications:

- explanations and static content in general should be written using some kind of templates, not directly in Halogen

# Features

Delegation:

- new RR record: the "delegation record", effectively removing all other RRs
  => requires 2 nameservers
- also enable to change NS records (but after a accepting the consequences)?

About the admin interface:

- enable administrators to ask for users' info and show zones
- perform a few more administrative operations (*TBD*)

Slightly more complex features to implement:

- zone-wise indications to help people configure their zone for specific uses (web, mail)

# Tests

Check for common errors:

- nodes with both a CNAME and another RR
- verify that SPF mechanisms point to available records

More specialized tests or debug options:

- verify the length of received messages in `App.Message.IPC`
- MAYBE: run `named-checkzone` on the genetared zone and provide the result in case of an error

# Display

- say that there is no IPv6 on the server at the moment, so there is no point doing IPv6 address updates
- admin interface: basically just rewrite the whole thing, it's a mess

Details:

- *maybe* notifications should disappear after a few seconds
- hide logs by default?

# General note

The code should be reviewed and a decent documentation should be provided.

Right now, the code is still in a somewhat early stage and **multiple** refactoring should take place.

Some code should be pushed in the [bulma purescript module][psbulma].

# TODO in authd and dnsmanagerd

- enable users to change their NS
- MIGRATION-related: remove migrated accounts with no connection in over 6 months

[psbulma]: https://github.com/KaneRoot/purescript-bulma