Some package we use, depends on opentelemetry.. this sounds scary (even though harmless, as we don't do any telemetry whatsoever).

Just to make sure we don't get strange discussions, see if we can remove it somehow..

Describe the bug While trying to create a new vault on a specified file the parameters will induce to an error

To Reproduce

$ ./bm-client --vault test.vault vault init

Vault already exists. Use --path to create a new vault on a specific path.

$ ./bm-client --vault test.vault vault init --path .

Please enter your new vault password:
Please retype your new vault password:
error: cannot create vault:  rename . ..backup: device or resource busy

However this works

$ ./bm-client  vault init --path test.vault

Please enter your new vault password:
Please retype your new vault password:
successfully created a new vault at  test.vault

Expected behavior Either --path or --vault should be used as parameter but not both

Fixes #200

• Changed the configuration into a more robust resolver configuration system
• allows to configure the resolvers
• setting a default_resolver that always works (or gives an error during startup)
• chaining is only done when asked, and will error when no entries are configured on the chain

Updated changelog to describe the latest changes

- Service support: Now you can install both bm-bridge and bm-server as system services using bm-config
- bm-bridge: It now uses a config file instead of parameters
- bm-bridge: Support for mail relay (aka gateway mode) for organizations, this way an organization can "host" using the BitMaelum protocol.

This will allow to install a service to run bm-server or bm-bridge automatically.

It will also use now a config file for bm-bridge and add support to run bm-bridge in your own organization, this way you can host your own mailgateway! account to translate BitMaelum messages to email addresses on your own organization.

Check if we can have a gateway to regular email so we can use regular email clients.

use [email protected] for john! and john#[email protected] as addresses

Even though we do have a lot of documentation, this project is fairly complex with all the moving parts around.

Let's try and see if we can make an on-boarding process that allows us to easily start with bitmaelum (i think we already have a pretty ok tutorial, but let's double check)

Having a separate header.json, catalog.json and 0 or more blocks might not be the best way to manage messages. Instead, having a single file with the message would be "better".

In that case, we could have a packed-message format. Maybe we shouldn't bother too much with inventing something new, and just use plain tar for this.

During transmission, we still use all the parts separately, but once stored on a server, we could pack it.

We have to figure out if this actually would work with things like scanning files etc

Implement the multi-recipient setup (see wiki https://github.com/bitmaelum/bitmaelum-suite/wiki/Multiple-recipients-(CC-and-BCC) and https://github.com/bitmaelum/bitmaelum-suite/wiki/Proposal-multi-recipients).

• [ ] delivery pool configurable pool of workers that will deliver a block either remotely or locally.
• [ ] proof-of-work pool this pool will either create a proof-of-work ticket, or returns quickly with a "in-progress" status. it should cache tickets so we can later fetch the ticket for uploading other blocks as well.
• [ ] setup receiving side that will push blocks to the queue
• [ ] update ticket system on client and server side to add extra info (header, blocks etc)

func createPool() {
  for i:=0; i!=25; i++ {
    go poolWorker()
  }
}
func poolWorker() {
  for {
    data <- queueChannel
    ticket := ticketPool.getTicket(data.Header)
    if ticket == nil {
        // requeue data for later when the ticket is finished
        queueChannel <- data
        continue
    }
    deliver(data.Header, data.Block) // or catalog, or attachment)
}

We should not discard errors with _, but handle them accordingly.

All code should handle errors. If there is a solid reason not to do this then document on the line why this is not checked. Test code is allowed to disregard errors.

Proposal: we do a soft-delete (deleted_at column to the db). Later we can see if we want to hard-delete old records (say > 6months)

We also need some kind of tool: bm-client account revoke or something?