Change Details

**Userland view** ``` $ notifications [00:04] <tasacora> Something happened. https://app.domain.tld/somewhere. [00:05] <lorem> Something happened. https://app.domain.tld/somewhereaboutlorem. [00:07] <tasacora> Something else happened. https://app.domain.tld/somewhereelse. ``` As we use a AMQP exchange, I'm going a flag to offer to filter by routing key: ``` $ notifications --routing-key "nasqueron.tasacora.#" [00:04] <tasacora> Something happened. https://app.domain.tld/somewhere. [00:07] <tasacora> Something else happened. https://app.domain.tld/somewhereelse. ``` **Application lifecycle** At startup, the client connects to the broker, creates a temporary queue bound to the ''notifications'' exchange and dedicated for the client, to get messages. When the broker sends a message to the client, we parse JSON and print it. The broker will take care to delete the temporary queue. **Plans about security** The application will connect directly to the RabbitMQ server. We'll store credentials by machine in `/usr/local/etc/notifications.conf` or `/etc/notifications.conf`, with read-only access to public dev data on the broker. To enhance security, the command could be run on a remote system through SSH (the DevCentral container already offers a way to answer commands for any connection through a public key set in preferences there). There is currently no plan to implement ACL for notifications, as notifications are public events you can get on our IRC channels or directly at the source.

**Userland view** ``` $ notifications [00:04] <tasacora> Something happened. https://app.domain.tld/somewhere. [00:05] <lorem> Something happened. https://app.domain.tld/somewhereaboutlorem. [00:07] <tasacora> Something else happened. https://app.domain.tld/somewhereelse. ``` As we use a AMQP exchange, I'm going a flag to offer to filter by routing key: ``` $ notifications --routing-key "nasqueron.tasacora.#" [00:04] <tasacora> Something happened. https://app.domain.tld/somewhere. [00:07] <tasacora> Something else happened. https://app.domain.tld/somewhereelse. ``` **Application lifecycle** At startup, the client connects to the broker, creates a temporary queue bound to the ''notifications'' exchange and dedicated for the client, to get messages. When the broker sends a message to the client, we parse JSON and print it. The broker will take care to delete the temporary queue. **Plans about security** The application will connect directly to the RabbitMQ server. We'll store credentials by machine in `/usr/local/etc/notifications.conf` or `/etc/notifications.conf`, with read-only access to public dev data on the broker. To enhance security, the command could be run on a remote system through SSH (the DevCentral container already offers a way to answer commands for any connection through a public key set in preferences there) or connect through HTTP to an AQMP → HTTP API we would add to the notifications center. There is currently no plan to implement ACL for notifications, as notifications are public events you can get on our IRC channels or directly at the source.

**Userland view** ``` $ notifications [00:04] <tasacora> Something happened. https://app.domain.tld/somewhere. [00:05] <lorem> Something happened. https://app.domain.tld/somewhereaboutlorem. [00:07] <tasacora> Something else happened. https://app.domain.tld/somewhereelse. ``` As we use a AMQP exchange, I'm going a flag to offer to filter by routing key: ``` $ notifications --routing-key "nasqueron.tasacora.#" [00:04] <tasacora> Something happened. https://app.domain.tld/somewhere. [00:07] <tasacora> Something else happened. https://app.domain.tld/somewhereelse. ``` **Application lifecycle** At startup, the client connects to the broker, creates a temporary queue bound to the ''notifications'' exchange and dedicated for the client, to get messages. When the broker sends a message to the client, we parse JSON and print it. The broker will take care to delete the temporary queue. **Plans about security** The application will connect directly to the RabbitMQ server. We'll store credentials by machine in `/usr/local/etc/notifications.conf` or `/etc/notifications.conf`, with read-only access to public dev data on the broker. To enhance security, the command could be run on a remote system through SSH (the DevCentral container already offers a way to answer commands for any connection through a public key set in preferences there) or connect through HTTP to an AQMP → HTTP API we would add to the notifications center. There is currently no plan to implement ACL for notifications, as notifications are public events you can get on our IRC channels or directly at the source.