commit 011360c007f5a6d022cca8f6e37350c20d86ca17
parent 46d6789df8e7c7a195f89c0eb09315b80e019b23
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Fri, 19 Sep 2025 15:58:58 +0200
add mailbox and taldir DD, WIP
Diffstat:
2 files changed, 111 insertions(+), 0 deletions(-)
diff --git a/design-documents/070-alias-directory-mailbox.rst b/design-documents/070-alias-directory-mailbox.rst
@@ -0,0 +1,110 @@
+DD 70: Alias Lookup and Mailbox
+###############################
+
+Summary
+=======
+
+GNU Taler is a payment system that makes privacy-friendly online transactions
+fast and easy.
+This project will facilitate the support of peer-to-peer payments (P2P) for the
+GNU Taler payment system between users by implementing a privacy-friendly
+directory service and lightweight inbox service (TALer DIRectory).
+The services will allow users to securely associate their
+online identities (such as email addresses, phone numbers, X/Twitter/Mastodon handles or other suitable verifiable addresses and accounts) with their wallet
+public keys and the URL of an inbox service and use it for P2P payments.
+Storage and retrieval may also be offloaded to distributed directory services
+such as DNS or GNS (RFC 9498) instead of a database
+and web service while maintaining the respective privacy guarantees.
+
+Motivation
+==========
+
+The Digital Euro is current in development and as a part of it the
+so-called "Alias Lookup Service" is being developed for at least
+28 Millon Euros (Tender "PRO-009485").
+
+To enable peer-to-peer payments for the GNU Taler payment system
+between users such a directory service and lightweight inbox service are also required.
+But, this service one the one hand has delicate privacy requirements not found
+in .
+We believe that the estimated development costs from the ECB tender
+are unreasonably and unexplicably high and we can demostrate how an efficient,
+privacy-friendly and lean service that offers this kind of functionality can be
+developed within this proposal at a fraction of the cost of the
+"Alias Lookup Service":
+
+The directory service will allow users to securely associate their
+online identities (such as email addresses, phone numbers, X/Twitter/Mastodon handles or other suitable verifiable addresses and accounts) with their wallet
+public keys and the URL of an inbox service.
+Additionally we found that storage and retrieval may also be offloaded to distributed directory services such as DNS or GNS (RFC 9498) instead of a database
+and web service while maintaining the respective privacy guarantees.
+We have added such a task to the estimate.
+
+In order to facilitate fund transfers in the P2P context, we
+will extend the Taler wallet (in particular, the browser-based
+WebExtension) to allow users to associate the wallet with one or more
+(waller) addresses, to query the directory to send money or invoices, to
+encrypt the payment messages to the public key obtained from the
+directory, to transmit the message via the lightweight inbox service,
+and to poll the inbox service for incoming requests and show them to
+the user.
+Both the key directory service and the inbox service may provide their
+services for a fee to compensate the operator for operational costs
+including the validation of addresses.
+
+Requirements
+============
+
+The implementation must take great care to ensure the privacy and
+integrity of the mappings from the identity to the wallet keys.
+For this, plain text identity information such as email addresses should
+only be processed as part of the validation and registration processes.
+The actual mappings will be indexed using salted hashes.
+
+Queries for wallet keys also should require the caller to provide the
+already hashed identity to minimize data leakage from requests.
+
+This minimizes the handling of personally identifyable information (PII)
+at the service and limits exposure in case of data leaks at the operator.
+
+The service must be suitable to be operated at very high availability constraints.
+As such, the service must be scalable and ideally have a small footprint and
+computing base.
+
+Proposed Solution
+=================
+
+The directory and mailbox services will be implemented as two distinct services.
+Both with have an open REST API which will be specified as part of the protocol.
+
+Directory
+---------
+
+The directory will support an extensible interface for alias *validators*.
+Validators will ensure that users that want to register mailbox URIs under an alias
+are actually the owner/in control over the particular alias.
+For example, in order to use an email address as the alias a verification link will be
+sent to that address and the user needs to confirm registration.
+
+In addition to the REST API, the directory will support an extensible interface for
+alias *disseminators*.
+Disseminators will publish the alias-mailbox mapping.
+For example, DNS or GNS validators will publish the mappings under zones of the operator.
+
+Definition of Done
+==================
+
+(Only applicable to design documents that describe a new feature. While the
+DoD is not satisfied yet, a user-facing feature **must** be behind a feature
+flag or dev-mode flag.)
+
+Alternatives
+============
+
+Drawbacks
+=========
+
+Discussion / Q&A
+================
+
+(This should be filled in with results from discussions on mailing lists / personal communication.)
diff --git a/design-documents/index.rst b/design-documents/index.rst
@@ -81,4 +81,5 @@ Design documents that start with "XX" are considered deprecated.
067-merchant-self-provisioning
068-tokens-roadmap
069-exchange-base-url-completion
+ 070-alias-directory-mailbox
999-template
