Best way to serialize "connect info"?

[justinmoon]

Currently we use the following JSON encoding to allow clients to "join a federation":

{"members":[[0,"wss://fm-signet.sirion.io:443"]],"max_evil":0}

This basically just JSON-encodes the parameters to WsFederationApi::new(). Once a client has a WsFederationApi, it can download configs from all federation servers?

What is the optimal way to encode this information?

• max_evil can be derived from the peer count via hbbft::util::max_faulty(), so that really doesn't need to be included. (could be removed from WsFederationApi::new() as well ...
• The 0 in [0,"wss://fm-signet.sirion.io:443"] is just a "peer id" which can also be implied by order of the array.
• So really all we need is the websocket URLs ...

Might be easier to copy/paste if we bech32m-encoded it? Maybe the error-correcting would help, too? But then it's harder to inspect it visually...

[elsirion]

bech32 encoding would make the QR bigger. An interesting option would be a custom encoding that compatible with alphanumeric QR encoding that only needs ~5.5bit/char. e.g.

WSS://FM-SIGNET.SIRION.IO:443+WSS://FOO.BAR:443+WSS://TESTMINT.XYZ:443+WSS://TESTMINT.COM:443

vs. ["wss://fm-signet.sirion.io:443","wss://foo.bar:443","wss://testmint.xyz:443","wss://testmint.com:443"]

[yojoe]

Ideally, joining a federation should be as simple as scanning and trusting a cryptographic peer id (hash/multihash of a public key) via an out-of-bounds mechanism from a guardian you trust. So the QR code would just need to be the size of the hash function used. Any other configuration data (even connection endpoints) could be fetched (and verified) using the peer id. For example directly from the guardian node (after connection endpoint lookup via a DHT). See my thoughts in #744.

[yojoe]

I also wonder if the real world use of Fedimint would require that at least one guardian approves/peers a member using their "member peer id" as well? I'm not sure many guardians would want the federation they are responsible for to be joinable by anyone who has the "Federation Code" (think of DoS, Sybil attacks, privacy leaks, ...). So eventually the onboarding/peering process needs to be an interactive protocol...

[elsirion]

I'm not sure many guardians would want the federation they are responsible for to be joinable by anyone who has the "Federation Code" (think of DoS, Sybil attacks, privacy leaks, ...).

Just in case there is some confusion, Fedimint isn't a p2p protocol, there are two classes of participants:

• Guardians: also called federation members in some older documents or peers in the server code. They control the multisig wallet and issue e-cash.
• Users: they just deposit BTC and transact in e-cash tokens, but don't run the federation.

Guardians can not join at will. Currently they are a fixed set defined at setup. Eventually there could be a dynamic join mechanism where guardians can add/remove others through a vote.

Users on the other hand can join at will but don't have any responsibilities, so it's not too bad if anyone can join. The privacy properties of the federation also make it impossible to enforce any access restrictions. The best we can do is hiding the connect QR code in apps if the federation is closed and only let guardians share the join QR code.

[yojoe]

Sure. But I was wondering if a fedimint federation could inherit some of the robustness properties of a p2p application so that a minority subset of guardians could temporarily leave (unavailable, disconnected) while the remaining guardians can still drive forward consensus due to threshold signatures. And if you employ an authenticated pubsub (Publish/Subscribe) protocol for guardian message exchange, not all guardians need to maintain a stable connection to all other guardians.

[elsirion]

I was wondering if a fedimint federation could inherit some of the robustness properties of a p2p application so that a minority subset of guardians could temporarily leave (unavailable, disconnected) while the remaining guardians can still drive forward consensus due to threshold signatures

That's exactly the goal 😃 I think we achieve it as long as everyone has a public IP with the current network stack. libp2p is certainly interesting to achieve resilience under less ideal network conditions.

I just wanted to make sure we are on the same page since "Sybil attacks, privacy leaks" read like you could mean guardians joining at will.

[yojoe]

I just wanted to make sure we are on the same page since "Sybil attacks, privacy leaks" read like you could mean guardians joining at will.

No, more like random users could cause (high) costs for the federation guardians? Like a lot of unnecessary e-cash transactions to try a denial-of-service against the federation. Or easily figure out which lightning gateways are used by the federation (peg-in and pay ln-invoice). A lot of this stuff can be mitigated if only authenticated users can join.

[elsirion]

Yeah, unfortunately naive implementations of authentication would break privacy. We'd need a scheme that authenticates each request but doesn't allow correlation of different requests of the same user but still allows detecting DoS. That sounds like a really fancy cryptographic scheme if it can exist at all under acceptable trust assumptions (it would certainly weaken privacy which is currently information theoretical, not even an attacker with infinite compute and access to all guardians can break it).

[yojoe]

but doesn't allow correlation of different requests of the same user

But this means fedimint would have a hard requirement on Tor or I2P, else that correlation can always be done via IP address of the request.

[elsirion]

But this means fedimint would have a hard requirement on Tor or I2P, else that correlation can always be done via IP address of the request.

Yes, that's tracked in issue #391.