View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003955 | Taler | taler-merchant-demos | public | 2015-09-02 08:14 | 2024-01-12 13:08 |
| Reporter | Marcello Stanisci | Assigned To | Marcello Stanisci | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | high | Severity | block | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | 0.0 | ||||
| Target Version | 0.0 | ||||
| Summary | 0003955: adapt 'create reserve' to real world use cases | ||||
| Description | the demonstrator should reproduce a system for doing wire transfers (aimed to create reserves on some mint) which does not rely on the wallet, just as normal bannks do. Furthermore, the wallet should provide a mean to check the amount of money on the created reserve. | ||||
| Tags | No tags attached. | ||||
| ID | Summary | Status | Assigned To | Estimated effort (hours) |
|---|---|---|---|---|
| 0003923 | need algorithm to determine which denominations to withdraw | closed | Marcello Stanisci | |
| 0003959 | update 'latest_fetch' column each time a reserve is queried | closed | Marcello Stanisci | |
| 0003960 | inhibit reserve polling on failure | closed | Marcello Stanisci | |
| 0003963 | reserve's polling starts too early | closed | Marcello Stanisci | |
| This issue (hours) | ||||
| Its children (hours) | 0 | |||
| Together (hours) | 0 | |||
Nothing is missing: the plan can be finished.
| parent of | 0003959 | closed | Marcello Stanisci | update 'latest_fetch' column each time a reserve is queried |
| parent of | 0003960 | closed | Marcello Stanisci | inhibit reserve polling on failure |
| parent of | 0003963 | closed | Marcello Stanisci | reserve's polling starts too early |
| parent of | 0003923 | closed | Marcello Stanisci | need algorithm to determine which denominations to withdraw |
| In particular, since the wallet is totally unaware of the mint's URL (and it needs this information for both checking the present amount on some reserve and for storing DB records like "mint_url, reserve_key"), it is needed a way of letting it know that. Choice 1: ask the user to insert that into 'create reserve' dialog when he specifies also the desired amount. | |
| Ok, here is my 'preferred' interaction right now: 1) We get rid of the 'create reserve' entry in the menu entirely; instead, we begin the interaction by having the user visit the WEBSITE of the mint. (the menu entry could be replaced by one where we jump to a default page where we offer a list of mints for various currencies so the user knows where to start) 2) The mint website has a button 'wire funds to reserve' or something like that. That button (active if extension present) triggers the extension and passes the mint's base URL to it; that way, the extension can learn where to /withdraw/sign from later. The extension then shows the dialog with the reserve public key and the /wire information (like /wire/sepa details from the mint) and allows the user to enter an amount. 3) The user is then supposed to enter the same information from that dialog into his banking application. 4) The wallet starts to periodically check in the background if the amount has arrived, and if so, withdraws the coins. Does this make sense? | |
| 1) Yes, that way the user may feel less "lost": the mint has a *homepage* now. 2) This is the part where the user may feel a bit annoyed, by having to enter two times the same information: the amount. As for the 'wire funds to reserve', that is handy and intuitive as well. Here the protocol with which the banks transfer their funds may save the user from stating two times the amount, but a slight modification in the interaction between the agents is needed. Let consider the new scenario: When the wallet wants to create a new reserve, it generates its public key for *both* the bank and the mint. Then it uses this key in the wire transfer subject (as we already do), and it sends it to the mint as well, so the mint know that a new reserve should be created. At this point the mint can mark this reserve as "incomplete". Hopefully, if the protocol between the banks let the mint know how much money it has to receive, the mint can mark the reserve as "complete" as soon as it gets all the expected money. Of course, when a reserve associated with some public key turns to be "complete", that means that the desired amount has been transferred (and the coins can be withdrawn). That may help since the user enters the amount just once during the interaction with his bank system and the wallet can soon start polling the mint about this new reserve. 4) The situation now is that the user click on a 'withdraw' menu and chooses how much to withdraw. Do you suggest to change this behaviour and withdraw all the coins automatically as soon as the reserve is created? | |
| Oh, I'm aware about the ugliness of (2), but ultimately we want to partner with banks and get rid of (2) entirely anyway (not exactly the way you describe, but that doesn't matter). The point is, until we have either more tight integration with a bank and unless we have the wallet speak the bank's protocol (which it won't for a while, if ever), I see no alternative. (4) yes, I think we should always 'empty' the reserve(s). | |
| Ok! So let's do as described in message 9603 | |
| Adding a subdirectory 'website/' to the mint's tree. Add the following directive to nginx's mint virtual server: # the URI where the user will see the options to wire funds to the mint. location /transfer { index index.html; alias /home/m/prog/Taler/mint/website/; } | |
| Grey out the 'Wire funds' button when uninstalling the wallet | |
| Add also the following to the mint's virtual server conf location ~ \.php$ { root /home/m/prog/Taler/mint/website/; fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } | |
| Fixed in: 8e06fbf (wallet repo) 761a763 (mint repo) | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-09-02 08:14 | Marcello Stanisci | New Issue | |
| 2015-09-02 08:14 | Marcello Stanisci | Status | new => assigned |
| 2015-09-02 08:14 | Marcello Stanisci | Assigned To | => Marcello Stanisci |
| 2015-09-02 09:42 | Marcello Stanisci | Note Added: 0009596 | |
| 2015-09-03 16:55 | Christian Grothoff | Note Added: 0009603 | |
| 2015-09-04 08:18 | Marcello Stanisci | Note Added: 0009605 | |
| 2015-09-04 10:24 | Christian Grothoff | Note Added: 0009606 | |
| 2015-09-04 11:52 | Marcello Stanisci | Note Added: 0009607 | |
| 2015-09-04 15:46 | Marcello Stanisci | Relationship added | parent of 0003959 |
| 2015-09-04 15:46 | Marcello Stanisci | Relationship added | parent of 0003960 |
| 2015-09-04 16:26 | Marcello Stanisci | Relationship added | parent of 0003963 |
| 2015-09-19 18:40 | Christian Grothoff | Priority | normal => high |
| 2015-09-19 18:40 | Christian Grothoff | Severity | minor => block |
| 2015-09-19 18:40 | Christian Grothoff | Product Version | => 0.0 |
| 2015-09-19 18:40 | Christian Grothoff | Target Version | => 0.0 |
| 2015-09-19 18:40 | Christian Grothoff | Description Updated | |
| 2015-09-30 07:31 | Marcello Stanisci | Relationship added | parent of 0003923 |
| 2015-10-20 20:25 | Marcello Stanisci | Note Added: 0009760 | |
| 2015-10-20 21:20 | Marcello Stanisci | Note Added: 0009761 | |
| 2015-10-20 22:02 | Marcello Stanisci | Note Added: 0009762 | |
| 2015-10-20 22:05 | Marcello Stanisci | Note Added: 0009763 | |
| 2015-10-20 22:05 | Marcello Stanisci | Status | assigned => informing |
| 2015-10-20 22:05 | Marcello Stanisci | Resolution | open => fixed |
| 2015-10-21 15:11 | Christian Grothoff | Status | informing => closed |
| 2015-11-29 12:48 | Christian Grothoff | Category | merchant (demonstrator) => merchant frontend (demonstrator) |
| 2016-02-17 02:24 | Florian Dold | Category | merchant frontend (demonstrator) => merchant frontend (donations) |
| 2024-01-12 13:08 | Christian Grothoff | Category | merchant frontend (donations) => Merchant frontends (Python3) |
| 2026-08-23 14:16 | Florian Dold | Category | Merchant frontends (Python3) => taler-merchant-demos |