-
Notifications
You must be signed in to change notification settings - Fork 119
added a proxy server for create-unsigned-tx to delegate the taker side for easy wallet integration #380
base: develop
Are you sure you want to change the base?
Conversation
I suggest using SimpleHTTPServer from the python standard lib. We wont want to include the flask web framework as a dependency for JM. We use SimpleHTTPServer as such here https://github.com/JoinMarket-Org/joinmarket/blob/develop/ob-watcher.py . Should be easy to switch over. edit: ghtdak's new version of ob-watcher uses twisted. here https://github.com/ghtdak/joinmarket/blob/txjoinmarket/joinmarket/ob_watcher.py and his txjoinmarket branch is what we are suppose to be moving to soon. |
As discussed on IRC (I understood that @ghtdak changed ob_watcher to twisted, which would get merged anyway) SimpleHTTPServer is almost obsolete, while develop is in feature freeze, making a merge not an option until after develop got merged to master?
Ok, my code seams to be actually very very bad, as it would only serve to one taker at a time but this blog post for example suggests using twisted with flask. |
That Joinmarket needs an html front end is clear. That we need something even as relatively lightweight as Flask built into the infrastructure is somewhat less clear. I've been looking at Cyclone (a Twisted integration with Tornado) which includes bottle but I don't have strong opinions on html template type things. Twisted also has a tiny template language which they make a point of not pushing. Really, any or multiple template mechanisms will work. Cyclone supports websockets which seems like a nice way to support dynamic pages when we get to that point but this is also completely independent of templating. (Cyclone has some good / simple examples) At this stage, we're talking about a couple of resource paths for a web front end and to support wallet integration. A minimal HTTP front end which is async (Cyclone or straight Twisted) seems more than enough. If a more full blown front end is necessary, we can revisit. All this being said, if someone has strong opinions, that's cool as long as it supports async. Most lightweight frameworks integrate with twisted. I recommend strongly against threading unless there is a demonstrated need, something I think is very unlikely. |
@ghtdak sorry I had posted my last comment too quickly and updated it several times. I'm currently digging into twisted.web and stuff that's making ob_watcher work with twisted. So far I'm confused where there is an entry point at all. Will report back or push my results. Thank you. |
twisted.web now and cyclone.web later? Anyway, I tried to turn it into twisted and that worked so far (many code paths would still crash, due to flask.abort and stuff) and it returns an unsigned tx with the help of some makers but it's still blocking and I haven't figured out yet, how to best solve that. Maybe with callInThread? But so far I failed to not finish the reply. |
No, I'd probably start with Cyclone though I doubt you need even that
Edit 1: As is often the case, I missed the context switch. I'll take a look and see if I can't hack something together given what you want on txJoinmarket even though you're asking about how to do Flask on the No. First, you can't really pull another entire framework onto Twisted (if that is indeed what you were trying). Frameworks involve event loops so unless the framework is integrated with Twisted, it ain't gonna work. And, there's virtually zero chance that you would want to for something as simple as this. I tried looking through your code but there's too much Flask specific stuff to wade through easily. And, I definitely would avoid all the auth / security stuff at first. TLS and other security stuff can be added after you've got the application specific XML / Json / whatever generated. Just start simple. Fork Another approach might be to hack something from the Cyclone demo directories with a fake application object just to get the interaction going. Once you've got communication between your Later today I'll put something in experimental (a directory in my tree) to see if I can't point you in a better direction. |
97d2603
to
47479d5
Compare
To use joinmarket in all wallets, it has to be as easy as possible for the user and the developers to integrate, while providing the maximum security assuming bad/malicious code in the projects that are considered to be integrated (JM in this case).
As most wallets are not python based, an integration via the network was chosen. This allows integration with any wallet, having the JM part run either on an external server or on the device that also runs the wallet, maybe in a sandboxed environment.
The provided changes are
The test script run looks something like this: