Ideas for Decentralizing the Bridge Server


#1

This is something to be looked at as a solution for more decentralized approach to the WalletConnect standard. Allowing sessions to not be vulnerable to one bridge server to break the connection.

My first idea to tackle this was to use a similar approach to Riot Chat which uses the Matrix protocol to distribute chat channels.

Alternatively suggested by Jarrad was to use Whisper protocol that enables you to use topics as sessions that could be used to relay the messages

There is also other ideas that included libp2p and WebRTC to make the connections between the client and the wallet more direct without requiring the Bridge server to sustain the connection

Looking forward for more input in these ideas


#2

I wonder if a collaboration with Status would help move this faster.


#3

Absolutely, I have talked to Jarrad and also talked to Peter Czaban from Web3 Foundation, they are working and funding libp2p and whisper protocol development


#4

Yea - whisper or PSS would be perfect for this use case - but as Perfect is the enemy of good: I really like the current solution as a bridge technology (pun intended).
That said: there should be upgrade paths and clear separation of protocol and transport layer. So that the current transport layer (bridge + push server) can be easily swapped for e.g. whisper or PSS (IMHO PSS might even be a nicer fit as we IMHO mostly don’t really need the darkness of whisper for a use-case where the results end up on chain anyway)
A little bit of upgrade-ability is already introduced with the version in the upcoming walletconnect URL EIP: https://ethereum-magicians.org/t/wallet-connect-eip/850/2 - but I think we should think about this even more. As far as I see with whisper or PSS we would not even need the encryption key as these protocols are already caring for the encryption.


#5

Following up the discussions from Telegram on making WalletConnect bridges more decentralized, @Ricburton suggested taking a look at Origin Protocol approach to messaging.
After inspecting their origin-bridge repository, we can see that their implementation really differs from our simple and centralized RedisDB by using a peer-to-peer database network called OrbitDB that uses IPFS Pubsub to automatically sync databases with peers.

OrbitDB Repository

This would make for a far more reasonable approach that could be implemented sooner, perhaps even with the upcoming v1.0 release candidate. Although both IPFS Pubsub and OrbitDB are both experimental right now, this approach seems to fair much better than Whisper in terms of decentralization and performance.

Would love hear more inputs on this?
cc @ligi @localethereumMichael @jin @jdkanani @subtly @herrmit @yarrumretep @alexander.mangel @artyom @Dobrokhvalov @spence


#6

@pedrouid Long term, I believe the solution is a protocol that’s going to look a lot like email across a p2p network. Short term it needs funding and man hours (or I do, anyway).

I wouldn’t recommend moving away from redis or whisper until the underlying protocol is worked out and audited. The protocol should be transport agnostic. That said, I do think there’s a lot for the project still to sort out. Would recommend looking at how Parity and each of the hardware wallets work (even though some bits are still missing).


#7

First of all: I like every movement to more decentralized solutions.

That said we can already try out things (especially UX patterns) and bridge the gap with some centralized workarounds. It is just important that they do not stick (workarounds tend to stick - especially if the effort to migrate from them is high). So I think it is important we abstract the transport layer away so we can easily change from bridge-server+FCM to orbit to whisper or PSS and to whatever comes up in the process. I have an idea how to do this that I would like to bounce to you anyway @pedrouid when you are in Berlin.


#8

I couldn’t agree with this more.


#9

What are your ideas to make the protocol transport agnostic? I have ideas on how to make the transport plugable - but I do not yet see a way to make it completely transport agnostic. The problem is that we need that the clients need to agree on a transport - otherwise how would they know how to communicate - and that needs to be part of the WalletConnect protocol.
What we could do is to split the initialisation part (needs IMHO unfortunately some transport dependency) and the communication part (there we can be agnostic). That is basically part of the idea I wanted to bounce with @pedrouid when he is here. For the communication I think we can just speak a (subset) of JSON-RPC (why reinvent the wheel).


#10

This is excellent feedback @subtly @localethereumMichael @ligi. Thanks a lot for your input!! :raised_hands:

I completely agree with everyone, I’m definitely excited about integrating OrbitDB but let’s first prioritize making the bridge spec to be transport-agnostic. Like @ligi said, let’s not reinvent the wheel and use a subset of JSON-RPC to do this.

There is definitely a need for more information be shared before completing the handshake, indicating some bridge parameters like version, transport protocol, etc and also include fallback protocols

After doing this, I’m thinking of adding some flags for the current py-walletconnect-bridge implementation for RedisDB and OrbitDB


#11

For the transport protocol, it is relatively safe to use TLS 1.3 with forward secrecy (and no SNI). There is also the signal protocol, devp2p and libp2p. In any case, what you want is forward secrecy or better. But, funny enough, the wireline transport isn’t as important. If the inner-protocol is secure, it can run over anything (including, cringe web-sockets or web-rtc; please don’t require either of these!).

  • wire transport (TLS, signal, devp2p, libp2p; anything with forward secrecy)
  • messaging encryption
  • walletconnect protocol between devices

You could run whisper over signal via redis-pubsub or orbitdb. If libp2p doesn’t support signal protocol, I’d ask. There’s no reason it shouldn’t unless there’s some kind of patent or IP issue blocking it. We’ve got this stuff in our queue for our dapp, but each of these have 6-12 month timeline, so just chatting here in the mean time :slight_smile:


#12

Following up this discussion on the meetup in Berlin, the proposal is to separate the transport from walletconnect-core library and use JSON-RPC methods to interact.
This way a Dapp will be able to choose any transport to be used instead of relying on the bridge implementation that’s built-in into the correct spec;

const bridgeTransport = new WalletConnectTransport({
      bridgeUrl: "https://bridge.walletconnect.org"
});

const webConnector = new WalletConnect({
     transport: bridgeTransport,
     dappName: "DappExample"
});

Another concern raised was that this would require an abstraction of sessions for unifying the API between all transports. One solution proposed was to substitute the sessionID with a conjunction of adresses that would form the session ID.

{
    sessionId: "0x24e1c52091fa01add2f7a3ea6da63a24fb4c176e:0xac5e7d50288ffc77e6326f4304cfc12785acea47"
}

This would allow to mark topics for Whisper messages or identifying sessions on the Bridge without conflicting between different transports. In addition, this would make push notifications easier and more private. Allowing transport protocols to not require to have access to an FCM token to trigger a push notification and also allowing Push servers to listen to topics from Whisper messages to know what devices to notify the signing requests.