Kord-Extensions/kord-extensions

Support ProxyFox API

Oliver-makes-code opened this issue · 5 comments

Summary

We're getting closer to the release of ProxyFox's API,
and I'd like for things to have support for it.
I'm creating this as a tracking issue for support for it.
For privacy reasons, we have elected to make only the /messages endpoint not require a token.
The model for a message (currently at least) is almost the same as PK's model,
with the exceptions of id being renamed to proxied,
and the system and member fields being IDs rather than full objects.
Link to source file for message model

Preferred Behaviour

Similar API to the PluralKit extension,
maybe split common code so ProxiedMessage*Event and UnProxiedMessage*Event work for both PK and PF

Extra

API endpoints and models aren't yet finalized.
If you have any suggestions for any changes we should make,
feel free to mention them here.

CC: @Ampflower, @TibiNonEst, as they work on ProxyFox

Hello, and thanks for opening an issue! As this is the first time you've created an issue on this repository, we'd just like to offer you a warm welcome to the project, and the following pointers:

  • Most importantly, all issues must adhere to our Code of Conduct. Please give it a quick read if you haven't already.

  • While our team is passionate about the projects we've created here, we're all volunteers. Please don't be offended if it takes time for us to get to your issue - we'll be here as soonas we can be!

  • Please provide as much information as possible when asking a question, reporting a problem, or submitting a feature request. This will help us to address your issue quickly and efficiently. If you forgot to add some information, no worries - feel free to edit the issue and add anything you missed!

    Thanks for contacting us! If you have any further questions, please feel free to join us on Discord in the #dev-kotdis channel (or #kordex-discussion for Kord Extensions projects), or to contact a staff member directly.

Interesting - I have nothing against proper support for other plural-proxying solutions. However, I need to point out that the model you linked to is close to useless because you manually serialize everything to a string - the point of kotlinx.serialization is that you can use rich, self-documenting types, so without proper tying or documentation, this isn't going to be enough information to figure things out.

Oh, I didn't notice that, I think it was done this way because we were still in the middle of migrating to kx.ser from gson.
I'll look into fixing it

Has there been any movement on the development of this API?

If so, have you made sure it'll scale properly under load? Make sure you stress test before any work is done here.