A standardized p2p layer would definitely be useful, but as for the specific use cases above, doesn’t the Gas Stations Network (EIP-1613 / GSN repo) solve them without requiring a p2p layer?

Mixers - The mixer implements the RelayRecipient interface and compensates relayers using the mixed deposits. The client (an ETH-less address) randomly selects a relayer from the RelayHub contract and sends the transaction. The relayer calls the mixer’s accept_relay_call() which verifies the ring signatures / ZKPs and confirms relay fee paid by the mixer. Then, the relayer delivers the transaction and the client gets the ETH.

Multisig wallets - the multisig wallet implements RelayRecipient, with an accept_relay_call() that returns true only for the multisig participants, and compensates the relayer for their transactions. ETH-less signer selects a relayer from RelayHub, sends the transaction, the relayer checks accept_relay_call(), delivers the transaction, and gets compensated.

Transactions sending to ZK Rollup networks - requires GSN relayers to implement packaging into rollup transactions, but otherwise doesn’t change the model. Why do you consider registering IP addresses (or rather, URLs) on a contract a bad thing? Ethereum already has this infrastructure (GSN has active relayers and is going on mainnet very soon), and will already have incentivized relayers registered in the RelayHub contract, so we might as well reuse them for ZK rollup.

I’m not saying we don’t need a standard p2p layer, but for many use cases there may be a simpler solution that reuses existing infrastructure and can work in a standard browser without having to deal with the connectivity nightmare of maintaining p2p connections across firewalls and NAT gateways. This is especially true for the Multisig wallets use case which is often used in enterprise networks, where p2p protocols are likely to be blocked but web is permitted.