plan

       -----------------------------         [ Permission Request ]
scan -> [in_q]  rfid reader  [out_q] >---- /run/queeriouslabs/auth.sock
       -----------------------------

                                     --------------------------------
                                 --> [in_q]  authenticator  [out_q] >-----+
                                /    --------------------------------     |         [ Authenticated request ]
/run/queeriouslabs/auth.sock --<                                          +------/run/queeriouslabs/latch.sock
                                \                                         | 
                                 <----------------------------------------+


in_q  :  one
out_q :  many


Authenticator is the only real server, others are clients
Actions can only be performed by the authenticator

transport layers:
    - devices (e.g. event system, uarts, i2c WHATEVER)
    - unix domain sockets
    - networking (zeromq)

rfid_reader is implicitly requesting the /latch/open action
    - a successful scan generates the request
    - unsuccessful scan doesn't do anything

autheticator decides if that's allowed
    - yes: forwards request to /latch/open
    - no: rejection


task/server to read input -->  place into in_q
task to read in_q         -->  triggers device.input(msg)
device puts in out_q      -->  task to send


if server:
    - put client into a dict w/ label
    - grab client from dict w/ label to send

out_q should be (client, msg) pair -> clients[<client_id>] = client
in_q should be (client, msg) pair  -> client = clients[<client_id>]


input task:
    - opens listening connections
    - Manages input transport, connections, etc and puts messages into in_q
    - Adds clients to client dict

output task:
    - removes (client, msg) pairs from out_q and sends via clienet's transport
    - closes connections
    - removes clients from client dict


input:
    - binding address
    - client callback

connection types:
- unix sockets (server, client)
- tcp socekts (server, client)
- event system (reader, writer)


# Notes
# Specs for a device
- unix sockets for IPC
- zeromq for inter-device communication
- processes over asyncio / threads
- asyncio over threads
- always starts at least one process/task/tread
- encrypted inter-device commuinication
- encrypted disks - but how to boot?  maybe not.

# ACL
- nice file format for mapping identifier to bounded permissions
    - encrypt on-disk, push to somewhere else
- hash identifier to use with hooks
- cache in memory
- updater which updates restarts services when updated
    - stores on disk / sync disk and cache
- logging

- Response from ACL
    {
        [
            perm: "/path/to/device/component/[crud]",
            grant: True/False,
            context: {'k':'v',}
        ]
    }
    - notify other devices (e.g. WWE entrances)?

- Request to ACL:
    ID, permission request(s), 
- json request format
    {
        tgt_dev_id: target device
        src_dev_id: device uuid making request
        requestor_id: permission requested for this id
        permissions: {} dict of permissions requested
    }

- permission spec
    {
        perm: "/path/to/device/component/[c|r|u|d]",
        context: 
            {
                "key": "value", # any extra information required to compute constraints
            }
    }


# Testing

## Research
https://promity.com/2020/06/03/testing-asynchronous-code-in-python/
https://asynctest.readthedocs.io/en/latest/tutorial.test_cases.html
https://tonybaloney.github.io/posts/async-test-patterns-for-pytest-and-unittest.html