Here is a list of things that we could use some help with: * The core polyproto HTTP API routes need to be streamlined - as in, trying to achieve a similar thing on two different routes should be done in a similar way (https://docs.polyphony.chat/APIs/core/). No code experience needed, just some knowledge on HTTP REST API best practices, if possible. * There are some unfinished polyproto HTTP API routes, which need to be designed snd documented (https://docs.polyphony.chat/APIs/core/). * No code experience needed, just some knowledge on HTTP REST API best practices, if possible. * The entirety of the polyproto HTTP API documentation should be translated into TypeSpec definitions (https://typespec.io). TypeSpec is a modern way to describe APIs, and TypeSpec definitions compile down to OpenAPI 3.0 for easy codegen in all sorts of different programming languages. No prior experience with TypeSpec is required - I am also currently in the process of learning it, and it seems to be quite simple and mostly ergonomic.

* The polyproto Rust crate (https://github.com/polyphony-chat/polyproto-rs) could use general optimizations and most importantly internal refactors to allow for wasm-bindgen to create a JavaScript/TypeScript library directly from our Rust code via an FFI, as the Rust codebase should ideally act as a single source of truth to keep implementations in different languages from exerting different behaviors. This would ideally require knowledge of FFIs/ABIs or an interest in learning about these topics. * In addition to the previous point, C-Bindings from the Rust library would also be extremely useful to easily make polyproto available in other programming languages via the C-ABI and FFIs.

Find us at https://github.com/polyphony-chat and/or join our development Discord at https://discord.gg/4DPuQStJ4s. Yes, we are aware of the irony :)