View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0003955TalerMerchant frontends (Python3)public2015-09-02 10:142024-01-12 14:08
ReporterMarcello Stanisci Assigned ToMarcello Stanisci  
PriorityhighSeverityblockReproducibilityhave not tried
Status closedResolutionfixed 
Product Version0.0 
Target Version0.0 
Summary0003955: adapt 'create reserve' to real world use cases
Descriptionthe 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.
TagsNo tags attached.

Relationships

parent of 0003959 closedMarcello Stanisci update 'latest_fetch' column each time a reserve is queried 
parent of 0003960 closedMarcello Stanisci inhibit reserve polling on failure 
parent of 0003963 closedMarcello Stanisci reserve's polling starts too early 
parent of 0003923 closedMarcello Stanisci need algorithm to determine which denominations to withdraw 

Activities

Marcello Stanisci

2015-09-02 11:42

reporter   ~0009596

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.

Christian Grothoff

2015-09-03 18:55

manager   ~0009603

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?

Marcello Stanisci

2015-09-04 10:18

reporter   ~0009605

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?

Christian Grothoff

2015-09-04 12:24

manager   ~0009606

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).

Marcello Stanisci

2015-09-04 13:52

reporter   ~0009607

Ok! So let's do as described in message 9603

Marcello Stanisci

2015-10-20 22:25

reporter   ~0009760

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/;
        
        }

Marcello Stanisci

2015-10-20 23:20

reporter   ~0009761

Grey out the 'Wire funds' button when uninstalling the wallet

Marcello Stanisci

2015-10-21 00:02

reporter   ~0009762

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;

        }

Marcello Stanisci

2015-10-21 00:05

reporter   ~0009763

Fixed in:
8e06fbf (wallet repo)
761a763 (mint repo)

Issue History

Date Modified Username Field Change
2015-09-02 10:14 Marcello Stanisci New Issue
2015-09-02 10:14 Marcello Stanisci Status new => assigned
2015-09-02 10:14 Marcello Stanisci Assigned To => Marcello Stanisci
2015-09-02 11:42 Marcello Stanisci Note Added: 0009596
2015-09-03 18:55 Christian Grothoff Note Added: 0009603
2015-09-04 10:18 Marcello Stanisci Note Added: 0009605
2015-09-04 12:24 Christian Grothoff Note Added: 0009606
2015-09-04 13:52 Marcello Stanisci Note Added: 0009607
2015-09-04 17:46 Marcello Stanisci Relationship added parent of 0003959
2015-09-04 17:46 Marcello Stanisci Relationship added parent of 0003960
2015-09-04 18:26 Marcello Stanisci Relationship added parent of 0003963
2015-09-19 20:40 Christian Grothoff Priority normal => high
2015-09-19 20:40 Christian Grothoff Severity minor => block
2015-09-19 20:40 Christian Grothoff Product Version => 0.0
2015-09-19 20:40 Christian Grothoff Target Version => 0.0
2015-09-19 20:40 Christian Grothoff Description Updated
2015-09-30 09:31 Marcello Stanisci Relationship added parent of 0003923
2015-10-20 22:25 Marcello Stanisci Note Added: 0009760
2015-10-20 23:20 Marcello Stanisci Note Added: 0009761
2015-10-21 00:02 Marcello Stanisci Note Added: 0009762
2015-10-21 00:05 Marcello Stanisci Note Added: 0009763
2015-10-21 00:05 Marcello Stanisci Status assigned => resolved
2015-10-21 00:05 Marcello Stanisci Resolution open => fixed
2015-10-21 17:11 Christian Grothoff Status resolved => closed
2015-11-29 13:48 Christian Grothoff Category merchant (demonstrator) => merchant frontend (demonstrator)
2016-02-17 03:24 Florian Dold Category merchant frontend (demonstrator) => merchant frontend (donations)
2024-01-12 14:08 Christian Grothoff Category merchant frontend (donations) => Merchant frontends (Python3)