I think the idea is that we figure out which flows work in what ways and then decide on what we believe is the best integration. This step is (imo) needed because I honestly think we don’t have a clear idea of how these things should be done. This is partly because the “figuring out” of interactive exchange integration was put on the exchanges themselves (which had a hard time prior to slatepacks probably), so this exchange is a research project so that we learn of the possible integration issues that may be there and decide on how to best solve them.
Here’s what I think might be possible steps:
Experiement with flows
Decide on which one is the preferred one (we want unified experience through exchanges)
Have a simple (insecure!) example
Try to make it as secure as we can for both the exchange and the user
Stress testing to find more practical issues
In the future when we really know things and know what is secure and what is not, possibly write helper libraries for exchange Grin integration (though I suspect this won’t happen any time soon)
When we get to step 4., we should have something that could be a reference implementation, but we first need to finish the previous steps in my opinion. Yes, this means that having SRS flow would be best also for deposits. I actually wonder if we should have 2 separate exchanges to avoid making a code mess e.g. exchange1.learngrin.com and exchange2.learngrin.com or something. But I can’t tell whether that’s a good idea or not.
I also believe that in order to really compare the options fairly, the wallets should have a support for both, otherwise the users make the only choice they have which is the “only implemented flow”.
The code is in Python, I think this is a good opportunity for people to get involved and learn more about Grin. What do you think about instead of adding support for both within the same source code, maybe just clone it and run it in different subdomains as @oryhp expressed?
I think if you over complicate the code it would be hard to follow, but also I think that by separating the code anyone could go and help you (potentially). Both flows are different, so the challenges too, but having both implementations will definitely help us educating users, and also we will have a better picture of what is simpler. I understand that current implemented flow (RSR) seems to be better from the exchange perspective, but without having payment proofs for invoices, it feels incomplete. I’m happy to see Grin++ users playing with this testnet exchanges, and, again, this can be used to educate.
I honestly feel lost using the CLI after using Grin++
took down the testnet exchange. I’m not too familiar with deployment so I’ll need to figure out some things before i put it back on (not sure when i’ll have the time to learn them)
very cool, i setup a vagrant testnet machine and played around with this, great work so far. I can help with figuring out deployment details if needed let me know.
If they’re related to the testnet exchange implementation then please post them here or if you’re on keybase you can ask there (on general channel or message me directly if that’s what you prefer). But as it was pointed out in this topic this version of exchange is not suitable for real usage, so if you want to implement something similar then you will have to do it in a different way
I have to build a site with the function of deposit and withdrawal (Mainnet)
Can I build a site running on Mainnet by just giving some modifications to your project?
No, you shouldn’t do that because the code of my testnet exchange was never checked by anyone and it was written for testing the flow, not to be used in production (it also contains some wallet changes which are not in production and i have no clue whether they’re even viable, i only made them to make it work for my case). The design i chose has some problematic downsides so i wouldn’t suggest using it in its current form for anything on the mainnet. I don’t use skype or telegram, only grin’s keybase - link
