-
Notifications
You must be signed in to change notification settings - Fork 119
New message channel implementations #650
Comments
So if we used a p2p network we might have the issue that makers will be the only long-running peers and they have a strong incentive not to relay other maker's offers. It's worth checking how bitsquare does things, since you'd think they have a similar issue that the only long running peers are liquidity-providers and they won't want to relay competing offers. There might be some clever idea involving hashing things as commitments so makers can't leave out offers without the taker knowing. |
A few random comments:
Might not be needed for JM to know anything about Tor. But if it does: |
IRC obviously has its pluses and minuses, but I'm mainly writing this to advertise the fact that it should be very easy to write new MessageChannel implementations. See here.
By subclassing
MessageChannel
and implementing those functions, you can run Joinmarket via something else: any server that can handle routing of messages between clients. I did a very primitive version over websockets, just to test it, seemed OK. I also tried matrix (see matrix.org) but found it hard to get it to work with a reasonable level of speed.The most useful feature such a new implementation could have, it seems to me, is good scalability: the ability to handle hundreds of clients at once, that, while their bandwidth requirement over time is small, require fast bursts of several kB for a few seconds occasionally. Thanks for any help on this.
The text was updated successfully, but these errors were encountered: