Currently our approach to multi-federation LN gateways is to run multiple gateway clients (called actors in the current gateway architecture) in the same gatewayd process, all using the same LN node. Unfortunately this doesn't work well if the federations we want to connect to use different API versions...

Core issue doesn't seem unique to the gateway. Any multi-federation app like the gateway, would need runtime upgrades of individual federation clients, and mixed client versions.

Could we solve for this, before preferring app design that limits to a single client version?

cACK on the alternative gateway design proposal

I don't think it's feasible for the Fedimint project to maintain a general-purpose, multi-version client.

The GW is special because we can extract a very simple interface for which we can the guarantee stability. It also has much bigger bang for the buck because every federation upgrade will move all the funds over the GW one way or another.

I don't think it's feasible for the Fedimint project to maintain a general-purpose, multi-version client.

Fully agreed on this.

Regarding @okjodom's "gateway swaps between federations", I still see value in being able to do that (short-circuits the need to use lightning), but the design as it is today essentially requires each federation that the gateway supports to have the same version.

@elsirion if we were to implement this inter-gateway protocol described above, do you think that eliminates the use case for swapping between federations? They seem to achieve similar goals, with @okjodom's approach having more code complexity vs the operational complexity of running multiple instances/versions of gatewayd

I don't think it's feasible for the Fedimint project to maintain a general-purpose, multi-version client.

Fully agreed on this.
Regarding @okjodom's "gateway swaps between federations", I still see value in being able to do that (short-circuits the need to use lightning)

1

but the design as it is today essentially requires each federation that the gateway supports to have the same version.

Here is where we need to improve, but without complete app architecture change. How do we make our current design be able to download and run multiple federation client versions. Perhaps gatewayd should be able to download FM client configs within some compatible client version range?.

The GW is special because we can extract a very simple interface for which we can the guarantee stability. It also has much bigger bang for the buck because every federation upgrade will move all the funds over the GW one way or another.

I'm wondering if we can do this but without restricting gatewayd to a single client

I expect / suspect (cc @justinmoon) other multi-federation apps like https://fedi.xyz have the same app architecture challenge to work through, so instead of limiting gatewayd to a single client, we need some general app pattern for loading client versions that are within a compatible version range.

RE: Each gatewayd instance connects exactly one federation

Is this the equivalent of asking a fedimint mobile wallet dev to limit their app to one FM client and release an app version for every FM release?

RE: operational complexity of running multiple instances/versions of gatewayd (which has a single federation client)

Is this the equivalent of asking such fm mobile wallet user to download a new app/version for every federation they want to join, assuming each of these federations have incompatible versions?

The problem of multiple client versions becomes much more tractable with a smaller, more purpose-built API.

E.g. Fedi doesn't have a general solution but just implements the APIs the frontend uses using multiple client library versions. If e.g. a new client library version exposes more information the API consumed by the frontend can be extended and default values be filled in for old client library versions that don't support it, but these defaults are highly context dpendent.

The problem of multiple client versions becomes much more tractable with a smaller, more purpose-built API.

E.g. Fedi doesn't have a general solution but just implements the APIs the frontend uses using multiple client library versions. If e.g. a new client library version exposes more information the API consumed by the frontend can be extended and default values be filled in for old client library versions that don't support it, but these defaults are highly context dpendent.

Makes sense. I think gatewayd and any other multi-federation app that comes along should try to formalize such a pattern so it reasons over clients with different versions.

RE: We want to migrate users from an old to a new federation, as described in #2689

If gatewayd version X adapts client library versions 1, 2, 3, 4, then it can perform swaps and thus support upgrades/downgrades across all four versions

Dev call:

• Continue with current multi-federation architecture, with support for swap between federations, feat: gateway swap between federations #3297
• Define an inter gatewayd protocol that might be applicable in scenarios like client migration across incompatible versions

With stabilization of FM this doesn't seem like worth the effort anymore.