The UI as it is right know is designed to update a static (in number of lines) view. What I did here is maybe adding an error message. The UI would need to know that a message is going to be there. I'm also not a fan of using stdout / stderr directly, but I do not have a tool for getting around it right know. I could update the UI toolset and maybe add an Optional or Scrolling widget. Do we need that in this PR?

Originally posted by @HenrikThoroe in #14 (comment)

The UI should be able to render not only static content but also integrate dynamic content.
This would allow the usage in scenarios where it is not known which layout the UI will have (like error messages, a stream of messages, ...).

We disabled the EnryptionMiddleware in #14:

Yes I fully support that idea. I disabled it, because it did not work yet out of the box and I'd like to have it easy to go for the user. I think we should add support for encrypted network traffic in a future release when we can add a good UX (Support in config files / CLI for example) to that.

• HenrikThoroe here

We probably want to support SSL out of the box and add an optional config settings for certificate pinning

VHook

Don't get me wrong, it's a good tool. But for now it's lacking a few important functionalities and produces quite a bit overhead.
Would be nice if you could improve on it. If you don't have time I could do it as well.

Below I listed what I currently miss.

Overhead

// Would be nice to combine expect and awaitValue methods
await hook.expect(equals(*), timeout: Duration(years: 42));

// For now we have to use a two-liner for this
await hook.awaitValue(Duration(years: 42));
hook.expect(equals(*));

Functionality

• Have to use bool? if I only want to distinguish between two states.
• No replacement for Completer.completeError
• If my value can be null I cannot await it
• I'd like to await based on the value and not be limited to null checks. For example awaitValue(Duration(years: 42), (value) => condition)

Originally posted by @HenrikThoroe in #9 (comment)

This is an umbrella topic for all parts of the codebase that we could consider pulling into their own respective packages which we might then publish.

Current suggestions:

• YAML writer suggested here
• TUI framework (does not seem ready yet but would also reduce coupling)