View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006652 | Taler | wallet-core | public | 2020-11-26 16:07 | 2022-11-04 19:52 |
| Reporter | Florian Dold | Assigned To | Florian Dold | 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 | feature | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 0.9 | Fixed in Version | 0.9 | ||
| Summary | 0006652: support peer-to-peer payments | ||||
| Description | Right now we have a strict separation between merchants and customers. Eventually we might also want to support direct payments between customers via their Taler wallet. The main challenge for this is KYC. We could implement special KYCed reserves for this that are then used as the wire info for a payment (payto://taler-kyc-reserve/) from customer to customer. The KYC would allow transaction limits to be placed on receiving money as a customer. A prerequisite for these P2P payments would be that the receiving party has a KYC registered reserve/account with an exchange. | ||||
| Tags | No tags attached. | ||||
| It's still totally unclear is how the signaling between the sender and receiver of the P2P payment will work. Unlike when a merchant is involved, the two parties can't directly communicate with each other. Of course the exchange might be able to help here, at least as long as it's not expensive for the exchange. So what's the desired user experience here? Does the receiver of the money initiate? If so, does the receiver simply give some generic address, or do they create some kind of "P2P contract terms"? How does the receiver learn whether/when they received a payment? Does the sender of the money initiate? If so, how does the sender know when/how to sign deposit permissions? Or do we have some special "wildcard deposit permission" where the P2P receiver can substitute their own wire transfer information? | |
| Pro/con of sender-initiated payments: * can be used to simply attach money to some message * doesn't give the sender any guarantees what will happen with their money * requires additional "wildcard deposit permission" support from the exchange (the receiver of the message does a /deposit, but can give arbitrary wire data) * the contract terms will be chosen by the receiver, and will be completely under their control * the size of the payment message is proportional to the number of coins involved Pro/con of receiver-initiated payments: * lots of overlap with payments based on a merchant backend * unclear how the communication will happen between the two parties I think the sender-initiated payments are simpler and cover more use cases that are not already covered by payments where a merchant backend is involved. | |
| Spec seems done, moving towards implementation category. | |
| Exchange implementation is basically done, next are wallet and auditor! | |
| What's left here is basically a "v2" of the wallet-core API based on input of the UI developers. | |
| Do you already have such input? Should this then not be separate bugs for each of the requested tweaks? | |
| Yes, but the general sentiment was that we should not break the API before we release 0.9. So maybe we can put this down for 0.9.{1,2}? | |
| Sure, but moreover, I'm suggesting that you track those desired change requests in new bug report(s). | |
| MVP in the wallet works, and we've opened other bugs for missing parts and polishing. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-11-26 16:07 | Florian Dold | New Issue | |
| 2021-01-17 19:53 | Florian Dold | Note Added: 0017366 | |
| 2021-01-17 20:17 | Florian Dold | Note Added: 0017367 | |
| 2021-04-18 00:29 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2021-04-18 00:29 | Christian Grothoff | Status | new => assigned |
| 2021-04-18 00:34 | Christian Grothoff | Priority | low => normal |
| 2021-04-18 00:34 | Christian Grothoff | Category | other => exchange API (HTTP specification) |
| 2021-04-18 00:34 | Christian Grothoff | Product Version | => git (master) |
| 2021-04-18 00:34 | Christian Grothoff | Target Version | => 0.9 |
| 2021-08-01 10:04 | Christian Grothoff | Priority | normal => low |
| 2021-08-01 10:04 | Christian Grothoff | Target Version | 0.9 => 0.9.1 |
| 2021-08-01 10:04 | Christian Grothoff | Target Version | 0.9.1 => |
| 2021-08-01 13:04 | Christian Grothoff | Category | exchange API (HTTP specification) => exchange |
| 2021-08-01 13:04 | Christian Grothoff | Note Added: 0018046 | |
| 2021-12-26 12:11 | Christian Grothoff | Target Version | => 0.9.1 |
| 2022-06-05 12:30 | Christian Grothoff | Note Added: 0018917 | |
| 2022-07-03 12:00 | Christian Grothoff | Assigned To | Christian Grothoff => Florian Dold |
| 2022-07-03 12:00 | Christian Grothoff | Priority | low => high |
| 2022-08-25 19:07 | Christian Grothoff | Category | exchange => wallet (TS core) |
| 2022-10-20 09:44 | Christian Grothoff | Target Version | 0.9.1 => 0.9 |
| 2022-11-01 13:33 | Florian Dold | Note Added: 0019327 | |
| 2022-11-01 13:49 | Christian Grothoff | Note Added: 0019328 | |
| 2022-11-01 14:24 | Florian Dold | Note Added: 0019329 | |
| 2022-11-01 14:41 | Christian Grothoff | Note Added: 0019331 | |
| 2022-11-04 19:15 | Florian Dold | Status | assigned => informing |
| 2022-11-04 19:15 | Florian Dold | Resolution | open => fixed |
| 2022-11-04 19:15 | Florian Dold | Note Added: 0019358 | |
| 2022-11-04 19:16 | Florian Dold | Fixed in Version | => 0.9 |
| 2022-11-04 19:52 | Christian Grothoff | Status | informing => closed |
| 2023-04-13 18:36 | Florian Dold | Category | wallet (TS core) => wallet-core |