taler-docs

Documentation for GNU Taler components, APIs and protocols
Log | Files | Refs | README | LICENSE

commit 342da9662f90b01e8e5935b7a6945d15c8df7792
parent 828fa7ba4544c9a9ca112a7d7478ef892ae7fd19
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date:   Tue,  7 Oct 2025 15:13:16 +0200

more notes, ref DD13

Diffstat:
Mdesign-documents/013-peer-to-peer-payments.rst | 2++
Mdesign-documents/070-alias-directory-mailbox.rst | 26+++++++++++++++-----------
2 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/design-documents/013-peer-to-peer-payments.rst b/design-documents/013-peer-to-peer-payments.rst @@ -1,3 +1,5 @@ +.. _dd-13: + DD 13: Wallet-to-Wallet Payments ################################ diff --git a/design-documents/070-alias-directory-mailbox.rst b/design-documents/070-alias-directory-mailbox.rst @@ -101,17 +101,19 @@ US-2: Send Payment Request Prerequisites: Bob has installed Taler Wallet Bob wants to request money from Alice. -He opens his Taler wallet and opens the *Request from Friend* screen from the menu. -The screen consists of a search input and an Alias type selector. +He opens his Taler wallet and opens ``Taler Button->Send`` screen from the menu. +There, *Send to Alias* can be selected. +The *Send to Alias* screen consists of a search input and an Alias type selector. Bob selects the Alias type (e.g. GitHub or Email) and inputs Alice's Alias. This will initiate a lookup request to the :ref:`Taldir API <api-taldir>`. If no results were found, Bob cannot use this feature. If found, Bob will be able to proceed to create a payment request. A screen that allows to create a payment request is shown to Bob. -Once Bob has entered all necessary details, the payment request is sent to -Alice's Mailbox URI through the :ref:`Mailbox API <api-mailbox>`. +Once Bob has entered all necessary details, a payment request (:ref:`DD 13 <dd-13>`) is sent to Alice's Mailbox URI through the :ref:`Mailbox API <api-mailbox>`. This request may fail, for example if Alice's Mailbox is full. + **Note**: Sending messages via Mailbox API may incur fees. + **Note**: It makes sense to use something like HPKE to encrypt the payment request to Alice's Wallet Public Key. In general, the Payment Request payload is undefined. We require (probably) a unique request ID in order to properly handle resending payment requests in UC-4. @@ -140,6 +142,8 @@ She may also decline to pay. US-4: Resend Payment Request ---------------------------- + **Note**: This US is possibly invalid / not required. + Prerequisites: Bob has sent a Payment Request to Alice Bob opens the screen in the Wallet that displays sent payment requests. @@ -151,17 +155,18 @@ US-5: Send Money Prerequisites: Alice has installed Taler Wallet, Alice has registered an Alias. - **Note**: It is unclear if this is valid user story. - Bob wants to directly send money to Alice (e.g. PayPal style). -He opens his Taler wallet and opens the *Send to Friend* screen from the menu. -The screen consists of a search input and an Alias type selector. +He opens his Taler wallet and opens ``Taler Button->Receive``. +There he selects the *Receive from Alias*. +The *Receive from Alias* screen consists of a search input and an Alias type selector. Bob selects the Alias type (e.g. GitHub or Email) and inputs Alice's Alias. This will initiate a lookup request to the :ref:`Taldir API <api-taldir>`. If no results were found, Bob cannot use this feature. If found, Bob will be able to proceed to create a payment. A screen that allows to create a payment is shown to Bob. -Once Bob has entered all necessary details, the payment is made. +Once Bob has entered all necessary details, the payment is made according to :ref:`DD 13 <dd-13>`. + + **Note**: Sending messages via Mailbox API may incur fees. So does creating a purse in the offer. This should probably be done in a single user action. **Note**: Should mailbox be used to notify Alice of payment? @@ -170,8 +175,7 @@ Open Questions ============== -- Payment Request Message unspecified. - - Requests should probably have an ID, maybe we can simply use the hash of the message. + - Payment Request Message unspecified. We should probabl use :ref:`DD 13 <dd-13>` but it seems outdated? Whatever is used for NFC/QR could be used in a message. - Requests should probably be encrypted (HPKE?) Proposed Solution