Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversion from Musicoin to MUS #5

Open
bengyles opened this issue Aug 21, 2020 · 6 comments
Open

Conversion from Musicoin to MUS #5

bengyles opened this issue Aug 21, 2020 · 6 comments
Labels
enhancement New feature or request

Comments

@bengyles
Copy link
Collaborator

For the conversion itself we have created a webpage that connects to metamask and allows the user to send musicoin to a specific address so we can then send the right ratio of the tokens back to that same address in metamask.

Because of double spending we have to make sure we can verify the transaction is confirmed on the blockchain so we can then make sure it is done only once in case someone tries to do it multiple times.

I still think the best way to do it is to save the transaction to the db and make some kind of queue where we can then poll every x amount of time to see if the transaction has been confirmed by the blockchain (since it could take a few days even with the old chain) and when it is confirmed we can send the tokens from the backend, this could also double as a log in case there are some issues so I wouldn't delete the records but just put their status as "migrated" or something.

the only piece of the puzzle I need to know is how we can check the queue every hour or a few times a day or something
so I think it's best I just keep the musicoin transaction in hurricane and put all the rest in our existing backend, or we could do it with a separate app and db too but then we would have to set that up ofcourse.

First I was thinking of creating a node app to just subscribe to blockchain events, for example listen to transactions sent to a specific address. But if the app is down for some reason some events may be missed so that's why I think it's better to use the db approach here.

what do you think @immartian ?

@immartian
Copy link
Contributor

Thanks, @bengyles,

I still think the best way to do it is to save the transaction to the db and make some kind of queue where we can then poll every x amount of time to see if the transaction has been confirmed by the blockchain (since it could take a few days even with the old chain) and when it is confirmed we can send the tokens from the backend, this could also double as a log in case there are some issues so I wouldn't delete the records but just put their status as "migrated" or something.

Agreed, we should save a Tx to db and show it's status from UI. If a Tx eventually got executed, we can get the receipt and confirm the record being fulfilled. We can create another node app to do the queue checking every 5 minutes.

@immartian immartian added the enhancement New feature or request label Aug 21, 2020
@bengyles
Copy link
Collaborator Author

interesting... so perhaps after the transaction is saved to the db we can take the user to a page where he can monitor it and recommend they bookmark it to check later... can you help us figure out the UX for this @gibranseptya?

@gibranseptya
Copy link
Collaborator

Yeah sure, It'd be helpful if you could help me with a sketch or simple flow of how the process would be based on the idea you have above? just to get the idea of the overall flow I will design

@bengyles
Copy link
Collaborator Author

@gibranseptya it's basically what we have already, but when the transaction is done (through metamask) the user gets redirected to the page where he can see the status of the swap

@gibranseptya
Copy link
Collaborator

I see, we basically need one more page to show the status? what kind of data do we need to show on that page? and where is it from?

@bengyles
Copy link
Collaborator Author

I would suggest a page migration/{ID} where we can see the tx hash, sender, amount, status pending/completed and maybe some additional info we can add but I think this should be enough, what do you think @immartian ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants