search

xmtp / xmtp-node-go

Software for the nodes that currently form the XMTP network
MIT License
10 stars 3 forks source link

Reject old SDK versions at API #405

Open nplasterer opened 1 month ago

nplasterer commented 1 month ago

libxmtp version in the header of requests. Force requests to be on a good version and reject all requests that aren't on that version.

nplasterer commented 1 month ago

Client work knowing what version and storing it as a header API work to take in those headers and reject the requests.

insipx commented 1 month ago

The easiest way to accomplish this is to start properly versioning xmtp_mls, and then use the CARGO_VERSION environment variable: https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-crates.

This needs to be inserted into headers for requests in xmtp_api_grpc, (doc] and xmtp_api_http (doc)

We might want to pair that with a more official release process for libxmtp, probably a lightweight one for now while there is still lots of churn.

Should also consider whether we version our crates as one workspace, or version them separately by-crate. Probably, a workspace-wide version would work well -- this would ensure xmtp_mls, xmtp_api_grpc, and xmtp_api_http all have the same version. otherwise we could run into issues where we accidentally update the version in one place but not in another.

the sqlite-wasm backend could be versioned separately

insipx commented 1 month ago

~done in xmtp/libxmtp#1011~ Api part client part is finished

nplasterer commented 1 month ago

What exactly needs to be done from the sdk side?

insipx commented 4 weeks ago

I don't think anything has to change for the SDKs, this should only be for libxmtp. I re-opened because I think this issue is also for changes to the go backend