QUIC plugin system

[comblock]

QUIC plugin system

Description

We could implement a plugin system that uses QUIC. This would allow for insane flexibility, for example, a single plugin connecting to multiple feather instances (this would be especially useful for network wide systems like messaging). A system like this also allows the user to decide which language they want to write plugins in (they will need to implement the protocol themselves if they chose a language other than rust however). Additionally, a QUIC plugin would also allow for hot loading plugins which is really useful for development.

Alternatives

Dynamic linking - Rust doesn't provide a stable ABI so this is basically impossible
Static linking - This is possible but developer unfriendly and people can't chose their own language
wasm - Supporting languages other than rust with wasm will be a mess and wasm also comes at a performance cost
gRPC - While gRPC is great in theory, only the client (plugins) can send requests to the server so the server can't send data when an event is triggered, etc. You could work around this by having both a gRPC client and server for the plugins and feather itself, but that would be too messy.

Additional Information

I think we should design the protocol around spending as least time as possible for encoding and decoding. I still think encryption and compression should be options, but should only be activated if the client (plugin) explicitly requests it (this might be useful for certain use cases, for example if the plugin is hosted somewhere else).

This plugin system would make it really easy for companies to integrate feather into their tech stack or design a tech stack around feather.

https://github.com/cloudflare/quiche and https://github.com/quinn-rs/quinn seem to be the most popular QUIC implementations in rust

[comblock]

I think we're sticking with wasm for now, though we can add quic support later as a sort of bridge between the wasm system and the quic system.