RPC Hooks

[dgduncan]

This is a placeholder ticket for future discussion about RPC based hooks. This comes from a discussion started here https://github.com/orgs/mochi-mqtt/discussions/281 where the desire to have the capability of utilizing the hosted Docker image and custom hooks outside of the standard ones that come included. This is explicitly for the usecase where the image is not wished to be built from source and instead the hosted image is used and configured with a file. Normally this functionality would be written and included essentially inside whatever hosts the mqtt.Server, but it currently seems that there is a desire to run Mochi as it comes.

To do a bit of ideation, the first thing that comes to mind is that a user could have a separate container, server, or whatever where these hooks are hosted. A contract would be defined such that certain endpoints would be exposed which would provide the given functionality. Included in this contract would be things such max response time, payloads, etc. A "capabilities" endpoint would be exposed where the service provides how many unique modules there are, which hooks each use, and the routes to each.

[SimonMacIntyre]

As an example from my use case, we want to basically drop a custom hook onto the server that leverages the OnConnectAuthenticate, so we can control the auth. The idea is that from for example a backend developer's perspective, we configure the broker with mostly just opening the right ports for the protocols we want enabled, hosting it on the network beside a backend or auth or database service, and our custom hook authenticates the user. The only change we need to make to the 'server' is essentially to add these hooks where we'd inject little bits of business logic like this.

Does that make sense? Happy to hear if I am trying to do things in a strange way if there is a cleaner alternative to this kind of pattern.

[mochi-co]

This is an interesting idea. In essence, we need to implement the ability to configure and run hooks which aren't in the original source compilation. In theory this is the problem that https://pkg.go.dev/plugin was supposed to solve, but I think we can all agree that's not the correct solution.

As I see it, we need two implement two new features:

1. Hooks need to be configurable using a global config array/using a file config. Currently auth.Hook and debug.Hook utilise a configuration parameter, and this could be a good starting point for implementing a yaml config (we may need to implement user-set ids for hooks):

hooks:
- auth:
    id: existing-auth
    auth:
    - username: peach
      password: password1
      allow: true
    - username: melon
      password: password2
      allow: true
    acl:
    - remote: 127.0.0.1:*
    - username: melon
      filters:
        melon/#: 3
        updates/#: 2
    - filters:
        '#': 1
        updates/#: 0
- debug:
    id: debug-hook-id
    showPacketData: true
- rpc:
    id: rpc-hook-1
    OnConnect: rpc-endpoint
    OnConnectAuthenticate: rpc-endpoint
    OnPublish: rpc-endpoint

2. We could then implement a configurable RPC hook could work as above. The next step would be determining how we could receive incoming requests. A listener could be used for this, and configured in a similar way.