Fergal

**From today's call:** discussed how we could completely migrate to just having ESSR payloads in the body (with the unencrypted ESSR payload in the headers for load balancers). KERIA and...

@kentbull I think this PR can be closed given it's inactivity - it should be handled at a DB level rather than in memory in keripy, and the keripy comments...

We should think about publishing dev tags more frequently too. So far I've just been building from githash via npm

The only thing to consider with every merge (since every PR is against `main`) is it could bring a lot of noise with tags and npm artifacts. I'd be OK...

Yeah, websockets are an option. Message brokers can use things like AMPQ and MQTT but perhaps to not complicate architecture there could be a built-in websocket endpoint which serves signed...

One concern that @lenkan is horizontally scaling KERIA and websockets straight out of KERIA making that more complex, and I tend to agree. Most likely, I might do a stop...

By internal broker, I didn't mean internal to KERIA - I just meant internal to my infrastructure and without proper authentication as a stop gap solution. So not necessarily websockets...

Thanks @SmithSamuelM this is helpful. Though here I'm solely referring to the Signify client being notified of long running operations completing from its agent - these long running operations only...

Expanding the API for refreshing sounds like a good idea @SmithSamuelM - and agreed it should be idempotent. Overall sounds like it'd be a lot more reliable. Regarding the Signify...

OK great, thanks! Two other things that come to mind are: 1. If the Signify client is completely offline - we'd have to buffer those event updates if we want...