draft encryption support for hookshot

[HarHarLinks]

per the comment in main.yml, this requires some experimental synapse features to also be enabled, which the role does not do yet at the time of writing (94abf2d).
i manage that by setting (iirc) in my host vars:

matrix_synapse_configuration_extension_yaml: |
  experimental_features:
    msc2409_to_device_messages_enabled: true
    msc3202_device_masquerading: true
    msc3202_transaction_extensions: true

other than that, i tried this out at some point which worked for a while but eventually broke in a way that hookshot's messages were not decryptable anymore. i couldn't figure out what broke it and had no time to try it again, so i never contributed this patch. i think the feature is not quite stable yet, unless i made a mistake somewhere, which is for you to review. i am sharing it now out of interest from members in the hookshot room.

this PR is a draft for the above 2 reasons. feel free to take it as the base for something production ready.

[spantaleev]

It's quite unfortunate that the container-name (and what we call _ident in our roles) is called matrix_hookshot_container_url here, making you think it's http://something-something -- a value unsuitable for a container name.

In actuality, matrix_hookshot_container_url is just matrix-hookshot - a container name / identifier.

[spantaleev]

These assumptions should not be hardcoded and should use variables (matrix_hookshot_queue_host and matrix_hookshot_queue_port).

The port could default to 6379, since that's quite standard for Redis.

The host should default to empty. Perhaps you can only enable the queue (if statement) if the host is non-empty. Example: {% if matrix_hookshot_queue_host %}

The matrix_hookshot_queue_host and matrix_hookshot_queue_port variables can be set to the correct values (matrix-redis, ..) via group_vars/matrix_servers - the file we use for wiring the different roles together. It's better to explicitly wire things via this central file, instead of having roles randomly assume things about other roles or each into each other's variables.

matrix_hookshot_queue_host would be defined as such in group_vars/matrix_servers:

matrix_hookshot_queue_host: "{{ redis_identifier if matrix_hookshot_experimental_encryption_enabled and redis_enabled else '' }}"

This: provides sane defaults for these variables, potentially overrides them via the group vars file.. and still allows people to use external Redis instances, if they want to.

[spantaleev]

This should be out of the if that deals with the queue stuff, since one may wish to enable the queue without enabling experimental encryption.

Experimental encryption does probably require the queue configuration, but I suppose Hookshot checks for this by itself. You may add a check in validate_config.yml if you're feeling like it though.

experimentalEncryption settings should be dependant on {% if matrix_hookshot_experimental_encryption_enabled %}.

[spantaleev]

As discussed before, it's not great for roles to make assumptions about other roles.

The assumption that this role makes there is that when encryption is enabled, Redis will also be enabled via nothing else but matrix-redis.

---

It's better to redo this by:

• adding a new matrix_hookshot_container_additional_networks variable, which can connect the Hookshot container to any arbitrary additional network. In some roles, we even split this into multiple lists of networks (multiple variables) in defaults/main.yml:
  • matrix_hookshot_container_additional_networks: "{{ matrix_hookshot_container_additional_networks_auto + matrix_hookshot_container_additional_networks_custom }}"
  • matrix_hookshot_container_additional_networks_auto: []
  • matrix_hookshot_container_additional_networks_custom: []
  • With the above, matrix_hookshot_container_additional_networks_auto is supposed to be managed by the playbook, while matrix_hookshot_container_additional_networks_custom is supposed to be managed by the user
• matrix_hookshot_container_additional_networks_auto may be redefined in group_vars/matrix_servers to inject redis_container_network (equal to matrix-redis) into the list of networks under certain conditions (if matrix_hookshot_queue_host == redis_identifier and redis_enabled). You can find various examples of _additional_networks redefinitions in group_vars/matrix_servers
• redoing this systemd .service file, so that it loops over the list of networks (matrix_hookshot_container_additional_networks) and connects to them all

With this, the role is configurable and does not hardcode anything about matrix-redis. All wiring happens in group_vars/matrix_servers and people can do their own network wiring or use external Redis if they need to.

[roland-5]

Typo: endcryption -> encryption