okjodom

> The GW needs to maintain separate e-cash wallets per federation Supported by #714 , by fact of the each registered federation getting a dedicated **GatewayActor**

> "Internal routing" can now happen between federations and becomes more complex Semantics: We probably should distinguish between payments/routing by giving definitions for "internal payments", "external payments" and "self payments"....

> > Add a hop to the route hint so that the route becomes [gateway, federation, user] where the user key is randomly generated by the user and the federation...

> I don't really see the code do anything with the id? Could that be added in the same PR? As it is it seems to add a bunch of...

> Sounds good, do you know if the [current CI failure](https://github.com/fedimint/fedimint/actions/runs/3305068342/attempts/1) is related to the PR or just general flakyness? A job rerun might help me confirm. The latency test...

At present, we have the following integration tests 1. `lightning_gateway_pays_internal_invoice` - category: *gateway behavioural* - validates implementation of internal payment within the gateway - internal payments should be shifted to...

force pushed to retrigger codecov rerun ?!

In leading this discussion, I propose a new gateway component architecture with details below: 

## LnGateway As the main gateway structure, it comprises of the following components - **LnRpc** lightning rpc - agnostic of implementation - **webserver** - A webserver with REST api to...

## Gateway Actor This is the execution unit containing all gateway business logic. Specs: - Each actor has a 1:1 mapping with a federation that the gateway serves - Groups...