You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For now this repo is being deliberately done in the simplest way I can imagine, with an HTTP JSON-RPC interface.
There is nothing difficult about having the counterparties interact over the existing message channel code in jmclient, except for the fact that it needs running the underlying jmdaemon code either in-process or separately.
On that topic, IRC is not a particularly bad messaging interface for this, and we already have very well tested/functioning code including Tor/SOCKS. One change that may well be needed in-line with other discussions is, create the possibility to persist nicks(IDs) on the message channel; this has been considered undesirable for JM but may make sense here (it's easy to do).
The fact that the code currently uses joinmarket's wallet code (and is therefore compatible with it) is relevant; one point that's simple is: JM may make one sensible source for server utxos. See #11
At the more application level, the question of whether a market based fees and offer/fill approach makes sense/interacts with other issues mentioned here, like #8 and the whole discussion of persistent ID, client-server and DOS mentioned here and there.
The text was updated successfully, but these errors were encountered:
See JoinMarket-Org/joinmarket#335 for ideas about CoinSwap on Joinmarket.
For now this repo is being deliberately done in the simplest way I can imagine, with an HTTP JSON-RPC interface.
There is nothing difficult about having the counterparties interact over the existing message channel code in
jmclient
, except for the fact that it needs running the underlyingjmdaemon
code either in-process or separately.On that topic, IRC is not a particularly bad messaging interface for this, and we already have very well tested/functioning code including Tor/SOCKS. One change that may well be needed in-line with other discussions is, create the possibility to persist nicks(IDs) on the message channel; this has been considered undesirable for JM but may make sense here (it's easy to do).
The fact that the code currently uses joinmarket's wallet code (and is therefore compatible with it) is relevant; one point that's simple is: JM may make one sensible source for server utxos. See #11
At the more application level, the question of whether a market based fees and offer/fill approach makes sense/interacts with other issues mentioned here, like #8 and the whole discussion of persistent ID, client-server and DOS mentioned here and there.
The text was updated successfully, but these errors were encountered: