commit aacdab8f051ebcb9204307bd33ed2639094e7b47 parent 9c4af5d567298b58f659e32b3c31c6a71ef15d19 Author: Christian Grothoff <christian@grothoff.org> Date: Wed, 1 Jul 2026 00:41:09 +0200 fix English Diffstat:
53 files changed, 213 insertions(+), 213 deletions(-)
diff --git a/core/api-auditor.rst b/core/api-auditor.rst @@ -31,7 +31,7 @@ Version History The current protocol version is **v2**. -* The auditor SPA currently targeting protocol version **v1**. +* The auditor SPA is currently targeting protocol version **v1**. **Version history:** @@ -153,7 +153,7 @@ of compromise. The difference between emergencies and emergencies by count is how the auditor detected the problem: by comparing amounts, or by counting coins. -Theroretically, counting coins should always detect an issue first, but given +Theoretically, counting coins should always detect an issue first, but given the importance of emergencies, the auditor checks both total amounts and total numbers of coins (they may differ as coins may be partially deposited). @@ -217,8 +217,8 @@ This section lists cases where the exchange's and auditor's expectation of amounts transferred into a reserve differs. Basically, the exchange database states that a certain reserve was credited for a certain amount via a wire transfer, but the auditor disagrees about this basic fact. This may result in -either a customer loosing funds (by being issued less digital cash than they -should be) or the exchange loosing funds (by issuing a customer more digital +either a customer losing funds (by being issued less digital cash than they +should be) or the exchange losing funds (by issuing a customer more digital cash than they should be). .. include:: auditor/get-monitoring-reserve-in-inconsistency.rst @@ -440,7 +440,7 @@ amounts disagrees with the arithmetic of the auditor. Disagreements imply that either the exchange made a loss (sending out too much money), or screwed a customer (and thus at least needs to fix the financial damage done to the customer). The profitable column is set to true if the arithmetic problem was -be determined to be profitable for the exchange, false if the problem resulted +determined to be profitable for the exchange, false if the problem resulted in a net loss for the exchange. @@ -501,7 +501,7 @@ Wire Out Inconsistencies ------------------------ This section highlights cases where the exchange wired a different amount to a -destimation account than the auditor expected. +destination account than the auditor expected. .. include:: auditor/get-monitoring-wire-out-inconsistency.rst @@ -531,7 +531,7 @@ Row Minor Inconsistencies ------------------------- The section highlights inconsistencies where a row in an exchange table has a -value that is does not satisfy expectations (such as a malformed +value that does not satisfy expectations (such as a malformed signature). These are cause for concern, but not necessarily point to a monetary loss (yet). diff --git a/core/api-bank-integration.rst b/core/api-bank-integration.rst @@ -21,7 +21,7 @@ Taler Bank Integration API ========================== -This chapter describe the APIs that banks need to offer towards Taler wallets +This chapter describes the APIs that banks need to offer towards Taler wallets to tightly integrate with GNU Taler. @@ -57,7 +57,7 @@ Withdrawing ----------- Withdrawals with a Taler-integrated bank are based on withdrawal operations. -Some user interaction (on the bank's websitei) creates a +Some user interaction (on the bank's website) creates a withdrawal operation record in the bank's database. The wallet can use a unique identifier for the withdrawal operation (the ``WITHDRAWAL_ID``) to interact with the withdrawal operation. diff --git a/core/api-common.rst b/core/api-common.rst @@ -75,7 +75,7 @@ handle the error as if an internal error (500) had been returned. This always indicates some serious internal operational error of the exchange, such as a program bug, database problems, etc., and must not be used for client-side problems. When facing an internal server error, clients should - retry their request after some delay. We recommended initially trying after + retry their request after some delay. We recommend initially trying after 1s, twice more at randomized times within 1 minute, then the user should be informed and another three retries should be scheduled within the next 24h. If the error persists, a report should ultimately be made to the auditor, @@ -213,7 +213,7 @@ confused with HTTP status codes. A value of 0 is reserved for "no error" or In C, the respective enumeration is the ``enum TALER_ErrorCode``. Developers may have to re-run ``bootstrap`` and/or update their Git -submodules to ensure that they have the lastest GANA registry. +submodules to ensure that they have the latest GANA registry. --------------------- Common query patterns @@ -300,7 +300,7 @@ payto://-URIs: other (in RFC 8905 optional) arguments to identify the recipient, as those may be needed to do a wire transfer. -* On occation, we also use full payto://-URIs that additionally specify the +* On occasion, we also use full payto://-URIs that additionally specify the *amount* and wire transfer *subject* and are actually intended to trigger a wire transfer. @@ -543,7 +543,7 @@ Phone numbers should start with the ``+`` symbol and the country code. Permissions ^^^^^^^^^^^ -This type epresses which permissions for a subject +This type expresses which permissions for a subject apply on a resource. .. ts:def:: LibeufinPermission @@ -837,7 +837,7 @@ Amounts of currency are serialized as a string of the format fixed-precision numbers, with 8 decimal places. Unlike floating point numbers, this allows accurate representation of monetary amounts. -The following constrains apply for a valid amount: +The following constraints apply for a valid amount: 1. The ``<Currency>`` part must be at most 11 characters long and may only consist of ASCII letters (``a-zA-Z``). @@ -988,7 +988,7 @@ body. // Hash of the payto:// account URI for which KYC // is required. - // The account holder can uses the ``/kyc-check/$H_PAYTO`` + // The account holder can use the ``/kyc-check/$H_PAYTO`` // endpoint to check the KYC status or initiate the KYC process. h_payto: NormalizedPaytoHash; @@ -1272,7 +1272,7 @@ uses 512-bit hash codes (64 bytes). Signatures ^^^^^^^^^^ -Any piece of signed data, complies to the abstract data structure given below. +Any piece of signed data complies with the abstract data structure given below. .. sourcecode:: c diff --git a/core/api-corebank.rst b/core/api-corebank.rst @@ -62,8 +62,8 @@ Config Authentication -------------- -Some endpoints requires the client to authenticate using a bearer token. Tokens can be obtained or refreshed using the :http:post:`/accounts/$USERNAME/token </accounts/$USERNAME/token>` endpoint. -This endpoint support authentication via HTTP Basic auth (RFC 7617). When using Basic authentication, the user-id must be the bank's username, and the password the password of the corresponding user. +Some endpoints require the client to authenticate using a bearer token. Tokens can be obtained or refreshed using the :http:post:`/accounts/$USERNAME/token </accounts/$USERNAME/token>` endpoint. +This endpoint supports authentication via HTTP Basic auth (RFC 7617). When using Basic authentication, the user-id must be the bank's username, and the password the password of the corresponding user. The user ``admin`` is a special, hard-coded username. Some requests require the client to authenticate as administrator. @@ -178,7 +178,7 @@ authentication (MFA) is required. In this case, the response will be a `ChallengeResponse`. In these cases, the client must first request and solve one or more challenges before repeating the request. When repeating the request, they must include a list of comma-separated challenge IDs of the -solved challenges in an ``Taler-Challenge-Ids`` HTTP header. The body must +solved challenges in a ``Taler-Challenge-Ids`` HTTP header. The body must remain absolutely unchanged. .. note:: diff --git a/core/api-donau.rst b/core/api-donau.rst @@ -116,12 +116,12 @@ CSR Issue Batch Issue ~~~~~~~~~~~ -This is the effectiv issue receipts request. Depending on the amount of the donation a +This is the effective issue receipts request. Depending on the amount of the donation a certain amount of blinded unique donation identifiers, or for short BUDIs, are required. Every BUDI will be signed by the corresponding requested donation unit, which is associated with a value. This API is used by the charity but the array of `BlindedDonationReceiptKeyPair` are coming from the donor. -To make the request idempotent, the hash of the hole request is recorded under the +To make the request idempotent, the hash of the whole request is recorded under the corresponding charity_id by the Donau. .. include:: donau/post-batch-issue-CHARITY_ID.rst diff --git a/core/api-exchange.rst b/core/api-exchange.rst @@ -331,7 +331,7 @@ Refreshing exchanges one old coin against ``n`` new coins, where the sum of denominations of the new coins must be smaller than the old coin's denomination plus melting (refresh) and withdrawal fees charged by the exchange. The refreshing API can be used by wallets to melt partially spent coins, making -transactions with the freshly exchangeed coins unlinkabe to previous transactions +transactions with the freshly exchanged coins unlinkable to previous transactions by anyone except the wallet itself. Refreshing is a two-step process, consisting of @@ -378,7 +378,7 @@ depositing a coin, the merchant is credited an amount specified in the deposit permission, possibly a fraction of the total coin's value, minus the deposit fee as specified by the coin's denomination. -For auctions, a bidder performs an deposit operation and provides all relevant +For auctions, a bidder performs a deposit operation and provides all relevant information for the auction policy (such as timeout and public key as bidder) and can use the ``exchange_sig`` field from the `DepositSuccessResponse` message as a proof to the seller for the escrow of sufficient fund. @@ -407,7 +407,7 @@ in using this API. For a recoup, a coin has to provide the necessary information to identify the original transaction (either a withdraw or a refresh) it -became minted, and proof ownership of the coin itself. +became minted, and prove ownership of the coin itself. .. include:: exchange/post-recoup-withdraw.rst diff --git a/core/api-merchant.rst b/core/api-merchant.rst @@ -79,11 +79,11 @@ infrastructure. Merchant backends have one special ``admin`` instance. This ``admin`` instance is used when no explicit instance is specified. Note that using ``/instances/admin/$ANYTHING`` is deprecated and will result in a permanent -redirect (HTTP status 308) to ``$ANYTHING``. a Despite its name, this instance +redirect (HTTP status 308) to ``$ANYTHING``. Despite its name, this instance must be created after the installation. Each instance (admin and others) has a base URL. The resources under -this base URL are divided into to categories: +this base URL are divided into the following categories: * Public endpoints that are exposed to the Internet * Private endpoints (under ``/private/*``) that are only supposed to be exposed @@ -224,7 +224,7 @@ authentication (MFA) is required. In this case, the response will be a `ChallengeResponse`. In these cases, the client must first request and solve one or more challenges before repeating the request. When repeating the request, they must include a list of comma-separated challenge IDs of the -solved challenges in an ``Taler-Challenge-Ids`` HTTP header. The body must +solved challenges in a ``Taler-Challenge-Ids`` HTTP header. The body must remain absolutely unchanged. .. note:: @@ -675,13 +675,13 @@ cart where the wallet picks products and quantities (``inventory-cart``), or a session-based template (``paivana``). The template type controls which fields appear in the contract and which inputs are required during instantiation. -The template itself primarily provides order details that cannot be be changed +The template itself primarily provides order details that cannot be changed by the customer when the wallet creates the order. The idea is that the user *may* be prompted to enter certain information, such as the amount to be paid, or the order summary (as a reminder to themselves or a message to the store), while the template provides all of the other contract details. -The typical user-experience with templatates is that the user first scans a QR +The typical user-experience with templates is that the user first scans a QR code or clicks on a taler://-URI which contains a ``pay-template`` (see `LSD 0006 <https://lsd.gnunet.org/lsd0006/>`__). The URI specifies which values the user should supply, currently either nothing, the amount, the order summary or @@ -690,7 +690,7 @@ values. After the user has supplied those values, the wallet will use the public template API to create the order, then fetch the order details, and proceed as if it had been given the respective ``pay`` URI in the first place: show the full contract details and allow the user to make a payment. If the -user chooses to aborts the payment, the wallet should give the user the +user chooses to abort the payment, the wallet should give the user the opportunity to edit the values and create another order with different values. If the template does not include any values that the user is allowed to edit (so it is basically a fixed contract), the wallet should directly create the @@ -1343,7 +1343,7 @@ Orders ^^^^^^ The `Order` object represents the starting point for new `ContractTerms`. - After validating and sanatizing all inputs, the merchant backend will add + After validating and sanitizing all inputs, the merchant backend will add additional information to the order and create a new `ContractTerms` object that will be stored in the database. @@ -1429,7 +1429,7 @@ order are inventory-based, that is if the `PostOrderRequest` uses inventory, the backend can automatically fill in the amount and other details about the product that are known to it from its ``products`` table. Note that the ``inventory_products`` will be appended to the list of ``products`` that -the frontend already put into the ``order``. So if the frontend can sell +the frontend already put into the ``order``. So the frontend can sell additional non-inventory products together with ``inventory_products``. Note that the backend will NOT update the ``amount`` of the ``order``, so the frontend must already have calculated the total price --- including the @@ -1924,7 +1924,7 @@ It has the following structure: Exchanges ^^^^^^^^^ -The wallet must select an exchange that either the merchant accepts by +The wallet must select an exchange that the merchant accepts by listing it in the exchanges array. .. ts:def:: Exchange diff --git a/core/api-overview.rst b/core/api-overview.rst @@ -86,7 +86,7 @@ Overview .. rubric:: Taler Prepared Transfer API -* **Summary**: Allows Taler clients to prepared wire transfers, enabling recurring wire transfers and optimized transfer flow. +* **Summary**: Allows Taler clients to prepare wire transfers, enabling recurring wire transfers and optimized transfer flow. * **Providers**: LibEuFin Nexus, Cyclos adapter, Depolymerization adapters. @@ -128,7 +128,7 @@ Overview .. rubric:: Taler Mailbox API -* **Summary**: Tansmission of encrypted payment messages between Taler wallets. +* **Summary**: Transmission of encrypted payment messages between Taler wallets. * **Providers**: GNU Taler Mailbox service * **Consumers**: GNU Taler Wallet * :doc:`Docs <api-mailbox>` diff --git a/core/api-sync.rst b/core/api-sync.rst @@ -39,7 +39,7 @@ a padded and encrypted version of the data. However, there are a few general rules that will apply to any version of the backup. Still, except for the 32-byte minimum upload size, the synchronization service -itself cannot not enforce these rules. +itself cannot enforce these rules. * First, the database should be compressed (i.e. gzip), then padded to a power of 2 in kilobytes or a multiple of @@ -54,7 +54,7 @@ itself cannot not enforce these rules. time. HKDFs are used to derive symmetric key material for authenticated encryption (encrypt-then-mac or a modern AEAD-cipher like Keccak). Given that AES is more - easily available and will likey increase the code of + easily available and will likely increase the code of the wallet less, AES plus a SHA-512 HMAC should suffice for now. * The client must enable merging databases in a way that is @@ -74,7 +74,7 @@ itself cannot not enforce these rules. expiration of the longest lasting record that they explicitly deleted. Purchases do not have an expiration time, thus they create - a challenge if an indivdiual purchase is deleted. Thus, when + a challenge if an individual purchase is deleted. Thus, when an individual purchase is deleted, the client is to keep track of the deletion with a deletion record. The deletion record still includes the purchase amount and purchase date. Thus, @@ -432,7 +432,7 @@ The menu should include three entries for synchronization: provider is available, and * "import backup configuration" to: - * import another devices' synchronization options + * import another device's synchronization options (by specifying URL and private key, or possibly scanning a QR code), or * select a synchronization provider from the list, diff --git a/core/api-terminal.rst b/core/api-terminal.rst @@ -260,10 +260,10 @@ Config Endpoint for providers to notify the terminal backend about a payment having happened. This will cause the bank to validate the transaction and allow the withdrawal to proceed. The API is idempotent, meaning sending a payment - notification for the same ``WITHDRAWAL_ID`` return successfuly but not + notification for the same ``WITHDRAWAL_ID`` returns successfully but does not change anything. This endpoint is always *optional*: the bank, exchange and wallet should all eventually notice the wire transfer with or without this - endpoint being called. However, by calling this endpoint checks that might + endpoint being called. However, by calling this endpoint, checks that might otherwise only happen periodically can be triggered immediately. The endpoint may also be used to associate a user ID at a very late stage @@ -329,7 +329,7 @@ Config :query long_poll_ms: *Optional.* If specified, the bank will wait up to ``long_poll_ms`` - milliseconds for operationt state to be different from ``old_state`` before sending the HTTP + milliseconds for operation state to be different from ``old_state`` before sending the HTTP response. A client must never rely on this behavior, as the bank may return a response immediately. :query old_state: @@ -370,7 +370,7 @@ Endpoints for Integrated Sub-APIs .. http:any:: /taler-integration/* - All endpoints under this prefix are specified by the. + All endpoints under this prefix are specified by the :doc:`GNU Taler bank integration API </core/api-bank-integration>`. This API handles the communication with Taler wallets. diff --git a/core/intro-bank-apis.rst b/core/intro-bank-apis.rst @@ -35,7 +35,7 @@ In principle, any typical account-based (core-)banking system can be used as the underlying account-based financial layer for GNU Taler. However, without extra support from the bank, withdrawals can be difficult for -unexperienced users. Thus to make sure that a Taler deployment can achieve +inexperienced users. Thus to make sure that a Taler deployment can achieve mass adoption from non-technical users, extra integration by the bank / core banking system should be provided. @@ -100,7 +100,7 @@ Banking apps may provide integration here simply by handling payto:// URIs. Integration based on payto:// URIs prevents mistakes in typing the cryptographic identifier and bank account number during withdrawals. However, -it still does not allow the wallet do accurately show the status of a +it still does not allow the wallet to accurately show the status of a withdrawal to the user. @@ -125,7 +125,7 @@ The Taler merchant backend has the option to connect to what we call the :doc:`Bank Revenue API <api-bank-revenue>`. A core banking system may provide this API to merchants that have a business -account at the that bank. The API provides read-only access to incoming +account at that bank. The API provides read-only access to incoming transactions on the merchant bank account. It allows merchants to easily and automatically reconcile incoming bank diff --git a/core/tos.rst b/core/tos.rst @@ -42,7 +42,7 @@ and the privacy policy of a service. When returning a full response (not a "304 Not Modified"), the server should also include a "Avail-Languages" header which includes a comma-separated list of the languages in which the terms of service - are available in (see `availability hints specification + are available (see `availability hints specification <https://datatracker.ietf.org/doc/draft-nottingham-http-availability-hints/>`_). Clients can use this to generate a language switcher for users that may not have expressed a proper language preference. @@ -62,7 +62,7 @@ and the privacy policy of a service. .. http:get:: /privacy Get the privacy policy of the service. Behaves the same way as - The "/terms" endpoint, except that it returns the privacy policy + the "/terms" endpoint, except that it returns the privacy policy instead of the terms of service. **Response:** diff --git a/deployments/tops.rst b/deployments/tops.rst @@ -587,7 +587,7 @@ AML/KYC Forms The following subsections define the contents of the forms. The corresponding field names are registered via `GANA <https://git.taler.net/gana.git/tree/gnu-taler-form-attributes>`_. -The the UI for the forms is defined in `taler-typescript-core <https://git.taler.net/taler-typescript-core.git/tree/packages/web-util/src/forms/gana>`_ +The UI for the forms is defined in `taler-typescript-core <https://git.taler.net/taler-typescript-core.git/tree/packages/web-util/src/forms/gana>`_ When the customer or officer submit the information throught the client software it must include the fields FORM_ID and FORM_VERSION attributed as defined in GANA. diff --git a/depolymerization/bitcoin-manual.rst b/depolymerization/bitcoin-manual.rst @@ -19,10 +19,10 @@ Bitcoin Depolymerizer Setup Manual ################################## -depolymerizer-bitcoin is a bitcoin blockhain Taler adapter. +depolymerizer-bitcoin is a bitcoin blockchain Taler adapter. This manual targets system administrators who want to install and -operate a Bictoin GNU Taler Depolymerizer +operate a Bitcoin GNU Taler Depolymerizer In this manual, we explain how to setup a depolymerizer. @@ -90,7 +90,7 @@ If the previous steps succeeded, the ``depolymerizer-bitcoin`` command should be Install binaries ~~~~~~~~~~~~~~~~ -To install the depolymerizer binaries and default configuration localy run: +To install the depolymerizer binaries and default configuration locally run: .. code-block:: console @@ -259,7 +259,7 @@ Or use an existing one: $ sudo -u depolymerizer-bitcoin-node bitcoin-cli -conf=/etc/bitcoind/bitcoin.conf loadwallet $WALLET -You also need to choose an address from you wallet to use as it's unique Taler identifier. You can generate a new address using: +You also need to choose an address from your wallet to use as its unique Taler identifier. You can generate a new address using: .. code-block:: console @@ -287,7 +287,7 @@ Update the configuration files: [depolymerizer-bitcoin-worker] PASSWORD = $PASSWORD -And finaly run the setup process: +And finally run the setup process: .. code-block:: console @@ -354,7 +354,7 @@ Or use an existing one: $ bitcoin-cli loadwallet $WALLET -You also need to choose an address from you wallet to use as it's unique Taler identifier. You can generate a new address using: +You also need to choose an address from your wallet to use as its unique Taler identifier. You can generate a new address using: .. code-block:: console @@ -374,7 +374,7 @@ Update the configuration files: WALLET_NAME = $WALLET PASSWORD = $PASSWORD -And finaly run the setup process: +And finally run the setup process: .. code-block:: console diff --git a/design-documents/001-new-browser-integration.rst b/design-documents/001-new-browser-integration.rst @@ -67,7 +67,7 @@ Requirements In particular, the wallet may not require "broad host" permissions. * Fingerprinting via this API should be minimized. * It must be possible for Websites to interact with the wallet without using JavaScript. -* Single Page Apps (using JavaScript) should be able to interact the wallet without +* Single Page Apps (using JavaScript) should be able to interact with the wallet without requiring a browser navigation. @@ -85,10 +85,10 @@ page that includes the same ``taler://`` URI. Manual Triggering ----------------- -Using the only the ``activeTab`` permission, we can access a page's content +Using only the ``activeTab`` permission, we can access a page's content *while and only while* the user is opening the popup (or a page action). The extension should look at the DOM and search for ``taler://`` links. -If such a link as been found, the popup should display an appropriate +If such a link has been found, the popup should display an appropriate dialog to the user (e.g. "Pay with GNU Taler on the current page."). Using manual triggering is not the best user experience, but works on every Website @@ -123,7 +123,7 @@ which can contain a ``taler://`` URI, such as: https://shop.taler.net/checkout#taler://pay/backend.shop.taler.net/-/-/2020.099-03C5F644XCNMR The fragment is processed the same way a "Taler: " header is processed. -For examle, a ``taler://pay/...`` fragment navigates to an in-wallet page +For example, a ``taler://pay/...`` fragment navigates to an in-wallet page and shows a payment request to the user. diff --git a/design-documents/005-wallet-backup-sync.rst b/design-documents/005-wallet-backup-sync.rst @@ -32,8 +32,8 @@ Proposed Solution The blob stored on the backup/sync server is a compressed and encrypted JSON file. -The various entity types managed by the wallet are modeled LWW-Sets (Last Write -Wins Set CRDT). Timestamps for inserts/deletes are are Lamport timestamps. Concurrent, conflicting insert/delete +The various entity types managed by the wallet are modeled as LWW-Sets (Last Write +Wins Set CRDT). Timestamps for inserts/deletes are Lamport timestamps. Concurrent, conflicting insert/delete operations are resolved in favor of "delete". The managed entities are: @@ -119,7 +119,7 @@ changes made by the wallet are propagated to all sync servers. The goal of this is to make the state of the sync servers converge. The different sync servers one wallet is enrolled with do not necessarily -have the same set of other wallet enrolled. Each sync server has a separate Lamport clock +have the same set of other wallets enrolled. Each sync server has a separate Lamport clock and contains a separate CRDT. Backup user flow @@ -259,7 +259,7 @@ Backup Onboarding If no backup service was selected when the user makes the first withdrawal, an onboarding screen will be shown that takes the user to the backup configuration screen. - Don't loose your money, use a backup service! + Don't lose your money, use a backup service! Your wallet comes with a list of backup services that can store an encrypted copy of your wallet. @@ -321,7 +321,7 @@ Discussion / Q&A * UUID / EdDSA pub and nick name? When nickname clashes, some number is added based on lexical sort of the random id ("phone#1", "phone#2"). -* How do we explain users that it can take days for wallet state to synchronize to all devices? +* How do we explain to users that it can take days for wallet state to synchronize to all devices? * How are people supposed to securely store their backup account key(s)? diff --git a/design-documents/007-payment.rst b/design-documents/007-payment.rst @@ -150,7 +150,7 @@ The merchant backend runs the following steps to generate the HTML page for 4. If *order-ID* identifies an *claimed* and *unpaid* order, run these steps: - 1. If the *claim-token* request parameter is given and the *contract-hash* requesst parameter is + 1. If the *claim-token* request parameter is given and the *contract-hash* request parameter is not given, redirect to the fulfillment URL of the order. (**Note**: We do not check the claim token, as the merchant might have already deleted it when the order is paid, and the fulfillment URL is not considered to be secret/private.) @@ -241,7 +241,7 @@ Covered Scenarios * **Re-purchase detection**. Let's say a detached wallet has already successfully paid for a resource URL. A browser navigates to the resource URL. The storefront will generate a new order and assign a session ID. - Upon scanning the QR code, the wallet will detect that it already has puchased the resource (checked via the fulfillment URL). + Upon scanning the QR code, the wallet will detect that it already has purchased the resource (checked via the fulfillment URL). It will then prove the payment of the **old** order ID under the **new** session ID. diff --git a/design-documents/008-fees.rst b/design-documents/008-fees.rst @@ -44,11 +44,11 @@ The metrics for the exchange should be advisory, i.e. an informed user should be able to accept the withdrawal anyway. The exchange's business interests may be in conflict with (1) a transparency of -cost for the user and and (2) restrictions on denomination/fee structures. +cost for the user and (2) restrictions on denomination/fee structures. Thus the metrics should still allow some degree of variability between exchanges. -We make the assumption that wallet always prefer operations with better +We make the assumption that wallets always prefer operations with better privacy. For example, a single coin should only be used for at most one spend operation and at most one refresh operation. @@ -65,7 +65,7 @@ is *reasonable*: Is there a relationship between the smallest denomination and the size of fees? -Idea: When when only doing spends on a coin that are a multiple of the smallest spending amount, +Idea: When only doing spends on a coin that are a multiple of the smallest spending amount, we constrain the number of coins that are refreshed into. When evaluating the e2e cost of a denomination, look at: diff --git a/design-documents/011-auditor-db-sync.rst b/design-documents/011-auditor-db-sync.rst @@ -19,7 +19,7 @@ the scope of this document. For database access, the auditor should not trust the exchange. In particular, the auditor must assume that the exchange may violate basic database constraints (like foreign keys) or delete/alter records maliciously. However, we also do not want to complicate the auditor logic to -cope with with violations of well-formedness constraints (like foreign keys or +cope with violations of well-formedness constraints (like foreign keys or non-NULL values or size constraints on fields). Finally, the mechanism by which the auditor obtains the database must provide a reasonably current database and the process must perform reasonably well. diff --git a/design-documents/013-peer-to-peer-payments.rst b/design-documents/013-peer-to-peer-payments.rst @@ -155,7 +155,7 @@ Requirements provable for the payer that these funds were not income but merely an aborted transaction. Furthermore, in this case, no KYC should be required from the payer. -* If a payment would partially succeed, i.e. because the payer inadvertedly +* If a payment would partially succeed, i.e. because the payer inadvertently used some double-spent coins and some valid coins, this must fail before the uni-directional communication and be correctable payer-side. In other words, the actual payment must be atomic. @@ -306,7 +306,7 @@ reserve is extended to the KYC deadline. gateway API is extended with a flag that informs the exchange that the incoming wire transfer implies a free KYC check. 5. If the account owner fails to perform the KYC check, all funds - in an reserve remain inaccessible. After a configurable duration, + in a reserve remain inaccessible. After a configurable duration, the funds may be considered forfeit and become the property of the exchange where the reserve is located. 6. The exchange may charge an annual **account fee**, and can @@ -404,7 +404,7 @@ In this protocol variant, the payer is initiating the process. the exchange processes the **merge** request akin to the logic for payments into known accounts, as detailed above. b. If the ``$EXCHANGE_BASE_URL`` does not match the local exchange, - a **wad fee** is charged, and the remaining amount are placed into a **wad** + a **wad fee** is charged, and the remaining amount is placed into a **wad** to inform the target exchange, as detailed below. Wad fees may be covered by the merchant, just like deposit fees, depending on the contract. 8. The exchange confirms the merge (per response to the **merge** request). @@ -550,7 +550,7 @@ Cross-exchange W2W payment offer: Dave is using Taler, but she does not know which exchange he is using. She opens her Taler wallet and initiates a P2P payment. She sends the resulting ``taler://purse/{EXCHANGE_URL}/{PURSE_PRIV}`` in an e-mail to Dave. - Dave opens they link in the e-mail with his Taler wallet. + Dave opens the link in the e-mail with his Taler wallet. Since Dave is using a different exchange than Carol, Dave's wallet issues a **merge** request to Carol's exchange pointing Carol's exchange to Dave's account at his exchange. Shortly after, @@ -613,7 +613,7 @@ Additional considerations a modified refresh protocol could ensure that whoever has knowledge of the account private key can also learn the private keys of coins withdrawn from that account, thereby removing - Taler's "one-hop withdrawal loohole". + Taler's "one-hop withdrawal loophole". Exchange database schema changes @@ -1078,7 +1078,7 @@ key to the payee, so that the payee can sign the merge request with it. This creates a security issue, as theoretically the payee could sign a different contract with the purse private key, and conspire with the exchange to replace the original contract. In this case, the payer would be making a payment to -the "wrong" contract, and have no proof of the exchange an payee conspiring +the "wrong" contract, and have no proof of the exchange and payee conspiring against it. A simple fix seems possible: instead of having simply one public-private key @@ -1109,7 +1109,7 @@ Q / A the sender of the payment cannot be sure that the account of the sender is still valid. -* Q: Who "owns" a purse? The payer of payee? +* Q: Who "owns" a purse? The payer or payee? * Both. Ownership is shared. Either the payer issues a refund on the purse, or the payee claims it by merging diff --git a/design-documents/023-taler-kyc.rst b/design-documents/023-taler-kyc.rst @@ -100,7 +100,7 @@ The outcome of a *check* can set new rules or trigger another *measure* (the latter is conditional on reaching the expiration time of the outcome). As a result, we largely end up in a large state machine where the AML staff has -serious flexibiltiy while the user needs guidance as to the possible next moves +serious flexibility while the user needs guidance as to the possible next moves and/or to the current state of their account (where some information must not be disclosed). @@ -440,7 +440,7 @@ New endpoints have been told that a transaction is not happening because it triggered some KYC/AML measure and now want to check how the KYC/AML requirement could be fulfilled (or whether it already has been - statisfied and the operation can now proceed). Long-polling may be used + satisfied and the operation can now proceed). Long-polling may be used to instantly observe a change in the KYC requirement status. The payto hash of the ``/kyc-check/`` endpoint encodes the @@ -711,7 +711,7 @@ New endpoints the threshold (from the ``wallet_balance_limit_without_kyc`` array) that the wallet would cross, and *not* the *exact* balance of the wallet. The exchange will respond with a wire target UUID. The wallet can then use this UUID to - being the KYC process at ``/kyc-check/``. The wallet must only proceed to + begin the KYC process at ``/kyc-check/``. The wallet must only proceed to obtain funds exceeding the threshold after the KYC process has concluded. While wallets could be "hacked" to bypass this measure (we cannot cryptographically enforce this), such modifications are a terms of service @@ -813,7 +813,7 @@ New endpoints filter is absent, otherwise only decisions for this account. :query active: *Optional*. If set to yes, only return active decisions, if no only - decisions that have been superceeded. Do not give (or use "all") to + decisions that have been superseded. Do not give (or use "all") to see all decisions regardless of activity status. :query investigation: *Optional*. If set to yes, only return accounts that are under @@ -896,7 +896,7 @@ Modifications to existing endpoints When withdrawing, the exchange checks if the KYC status is acceptable. If no KYC was done and if either the amount withdrawn over a particular timeframe -exceeds the threshold or the reserve received received a P2P transfer, then a +exceeds the threshold or the reserve received a P2P transfer, then a ``451 Unavailable for Legal Reasons`` is returned which redirects the consumer to the new ``/kyc-check/`` handler. diff --git a/design-documents/024-age-restriction.rst b/design-documents/024-age-restriction.rst @@ -46,7 +46,7 @@ The minors/wards receive those coins and can now **attest** a required minimum age (provided that age is less or equal to the committed age of the coins) to merchants, who can **verify** the minimum age. -For the rest values (change) after an transaction, the minor/ward can +For the rest values (change) after a transaction, the minor/ward can **derive** new age-restricted coins. The exchange can **compare** the equality of the age-restriction of the old coin with the new coin (in a zero-knowledge protocol, that gives the minor/ward a 1/κ chance to raise the minimum age for @@ -310,7 +310,7 @@ The withdraw protocol is affected in the following situations: specific age group. In these cases, the wallet will have to perform a zero-knowledge protocol with -exchange as part of the the withdraw protocol, which we sketch here. Let +exchange as part of the withdraw protocol, which we sketch here. Let - :math:`\kappa` be the same cut-and-choose parameter for the refresh-protocol. - :math:`\Omega \in E` be a published, nothing-up-my-sleeve, constant @@ -372,7 +372,7 @@ for the withdrawal of one coin: Note that the batch version of withdraw allows the withdrawal of *multiple* coins at once. For that scenario the protocol sketched above is adapted to -accomodate for handling multiple coins at once -- thus multiplying the amount +accommodate handling multiple coins at once -- thus multiplying the amount of data by the amount of coins in question--, but all with the same value of :math:`\gamma`. @@ -504,7 +504,7 @@ Refresh - reveal phase During the reveal phase -- that is upon POST to ``/refreshes/$RCH/reveal`` -- the client has to provide the original age commitment of the old coin (i.e. the vector of public keys), iff the corresponding denomination had support for age -restriction. The size of the vector is defined by the Exchange implicetly as +restriction. The size of the vector is defined by the Exchange implicitly as the amount of age groups defined in the field ``.age_groups`` of the ``ExtensionAgeRestriction``. @@ -516,7 +516,7 @@ the amount of age groups defined in the field ``.age_groups`` of the // Iff the corresponding denomination has support for age restriction, // the client MUST provide the original age commitment, i.e. the vector // of public keys. - // The size of the vector is defined by the Exchange implicetly as the + // The size of the vector is defined by the Exchange implicitly as the // amount of age groups defined in the field ``.age_groups`` of the // ``ExtensionAgeRestriction``. old_age_commitment?: Edx25519PublicKey[]; @@ -614,7 +614,7 @@ this value will not be smaller than, say, 8, and not larger than, say, 21. } By sending the contract term with the field ``minimum_age`` set to an -non-zero integer value, the merchant implicetly signals that it understands the +a non-zero integer value, the merchant implicitly signals that it understands the extension ``age_restriction`` for age restriction from the exchange. diff --git a/design-documents/030-offline-payments.rst b/design-documents/030-offline-payments.rst @@ -14,7 +14,7 @@ Taler is explicitly meant to be an online payment system. However, since there recently seems to be an increased interest in offline CBDC solutions, we have decided to still explore how Taler could support offline payments in the future. -While we still recommend online-only payments, this work operates under the the +While we still recommend online-only payments, this work operates under the following theme: "If Taler can support offline payments that are no worse than those of competing systems (that often offer less freedom and privacy to users), why should we claim we can't support them and fare worse in comparisons"? diff --git a/design-documents/048-wallet-exchange-lifecycle.rst b/design-documents/048-wallet-exchange-lifecycle.rst @@ -17,7 +17,7 @@ distinguish between used and preset/added exchanges. Requirements ============ -The following properties of of exchanges managed by the wallet +The following properties of exchanges managed by the wallet are important: * is the exchange used for something (coins, (account-)reserves, purses, ...) diff --git a/design-documents/049-auth.rst b/design-documents/049-auth.rst @@ -101,7 +101,7 @@ the token endpoint. Token Information ----------------- -List existing token informations. +List existing token information. .. http:get:: /${RESOURCE...}/tokens diff --git a/design-documents/053-wallet-ui.rst b/design-documents/053-wallet-ui.rst @@ -23,7 +23,7 @@ Requirements Every screen MUST be defined in a document with the following information: -* **Identifiable UI screens**: every UI should have an unique identifier that will +* **Identifiable UI screens**: every UI should have a unique identifier that will be use for development discussion and bug reports. There should be an option in the application to enable an active rendering of the id. @@ -521,7 +521,7 @@ Screenshots +-----------+----------------------------------------------------------------+ -This screen is used to ask the the user to confirm the withdrawal operation, +This screen is used to ask the user to confirm the withdrawal operation, now that all data has been provided. diff --git a/design-documents/054-dynamic-form.rst b/design-documents/054-dynamic-form.rst @@ -53,7 +53,7 @@ Fields requirements Metadata requirements --------------------- -* **identification**: the form configuration instance should have an unique +* **identification**: the form configuration instance should have a unique non reusable id. * **label**: the form should have a name recognizable for the user @@ -385,7 +385,7 @@ Money input. List input `````````` -This input allows to enter more than element in the same field, and the +This input allows entering more than one element in the same field, and the resulting JSON will have a json list. The UI should show the elements already present in the list, and for that it will use ``labelFieldId``. diff --git a/design-documents/055-wallet-problem-report.rst b/design-documents/055-wallet-problem-report.rst @@ -96,7 +96,7 @@ Alternatives ============ * Report problems with an API specific to each resource (exchange entry, transaction, ...) -* Have an *alerts* API that returns alerts to the client that the client can show to to the user, +* Have an *alerts* API that returns alerts to the client that the client can show to the user, but that a user can't interact with. Drawbacks diff --git a/design-documents/056-weblate-integration.rst b/design-documents/056-weblate-integration.rst @@ -79,7 +79,7 @@ Requirements 1. We should integrate weblate and iOS development 2. Translator should not translate 2 strings twice: if we can, we should reuse strings between apps -3. It should be clear wether we need to define a new string or add more context to the current strings +3. It should be clear whether we need to define a new string or add more context to the current strings 4. Stick to the `supported formats <https://docs.weblate.org/en/latest/formats.html>`__ Proposed Solution diff --git a/design-documents/057-libeufin-bank-account-lockout.rst b/design-documents/057-libeufin-bank-account-lockout.rst @@ -49,7 +49,7 @@ We can make them unauthenticated only for token creation challenges only: For ``POST /accounts/$USERNAME/challenge/$CHALLENGE_ID/confirm`` this is not a problem, as it requires knowledge of the username, the random challenge ID and the TAN code sent. This endpoint is also throttled, to many attemps invalidate the challenge. -For ``POST /accounts/$USERNAME/challenge/$CHALLENGE_ID``, it requires knowledge of the username and the random challenge ID, but those informations are acessible to an attacker knowing the user password that create a token creation challenge. This endpoint can disclose the tan channel and information (phone number or email address) to the attacker, enabling him to know how to attack the second authenticated factor. We can solve this by hiding or obfuscating the tan information for token creation challenges. +For ``POST /accounts/$USERNAME/challenge/$CHALLENGE_ID``, it requires knowledge of the username and the random challenge ID, but that information is accessible to an attacker knowing the user password that create a token creation challenge. This endpoint can disclose the tan channel and information (phone number or email address) to the attacker, enabling him to know how to attack the second authenticated factor. We can solve this by hiding or obfuscating the tan information for token creation challenges. TAN submission throttling ------------------------- diff --git a/design-documents/058-ebics-tx-unique-id.rst b/design-documents/058-ebics-tx-unique-id.rst @@ -4,17 +4,17 @@ DD 58: EBICS Transaction Unique ID Summary ======= -LibEufin Nexus need to have a single unique ID for each registered incoming transaction. For outgoing transaction we generate a unique ID ourselves but for incoming transaction we are dependent of whatever the bank provide. EBICS and ISO20022 do not provide a perfect transaction identifier and we need to have an ID that is compatible with different ISO20022 dialects and will be compatible with future specification changes. +LibEufin Nexus needs to have a single unique ID for each registered incoming transaction. For outgoing transaction we generate a unique ID ourselves but for incoming transaction we are dependent on whatever the bank provides. EBICS and ISO20022 do not provide a perfect transaction identifier and we need to have an ID that is compatible with different ISO20022 dialects and will be compatible with future specification changes. Problem ======= ISO20022 provides many transaction identifier: -* *AcctSvcrRef (AccountServicerReference)*: unique reference, as assigned by the account servicing institution, to unambiguously identify the instruction. The format is ambiguous, and it is only unique within the account servicing institution. This identifier can be present a the entry level and/or at the transaction level (a single entry can be a batch of transaction), this make this identifier sometimes a bit ambiguous. +* *AcctSvcrRef (AccountServicerReference)*: unique reference, as assigned by the account servicing institution, to unambiguously identify the instruction. The format is ambiguous, and it is only unique within the account servicing institution. This identifier can be present a the entry level and/or at the transaction level (a single entry can be a batch of transaction), this makes this identifier sometimes a bit ambiguous. * *UETR (unique end-to-end transaction reference)*: universally unique identifier to provide an end-to-end reference of a payment transaction. This is the perfect unique ID, it's a UUID v4 that is shared with all participant of the transfer. * *TxId (TransactionIdentification)*: unique identification, as assigned by the first instructing agent, to unambiguously identify the transaction that is passed on, unchanged, throughout the entire interbank chain. The format is ambiguous and only unique for a “pre-agreed period”, whatever that means, but it is shared all participant of the transfer. -* *EndToEndId (EndToEndIdentification)*: unique identification, as assigned by the initiating party, to unambiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-to-end chain. The format is unspecified and nothing guaranteed it will actually be unique as institution are not expected to enforce uniqueness, it is also often NOTPROVIDED. +* *EndToEndId (EndToEndIdentification)*: unique identification, as assigned by the initiating party, to unambiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-to-end chain. The format is unspecified and nothing guarantees it will actually be unique, as institutions are not expected to enforce uniqueness, it is also often NOTPROVIDED. All those identifiers are optional and of course not a single one of them is consistently present in all dialects and all files. diff --git a/design-documents/064-kyc-operation-algo.rst b/design-documents/064-kyc-operation-algo.rst @@ -17,9 +17,9 @@ hidden from the client for regulatory purposes. Requirements ============ -* Minimize the time time the user has to wait (=> long-poll efficiently) +* Minimize the time the user has to wait (=> long-poll efficiently) * Minimize the number of requests that the exchange has do process (=> do not quickly - retry when it's clear the the request is unlikely to succeed now) + retry when it's clear that the request is unlikely to succeed now) Proposed Solution ================= diff --git a/design-documents/067-merchant-self-provisioning.rst b/design-documents/067-merchant-self-provisioning.rst @@ -19,7 +19,7 @@ Requirements ============ * The self-provisioning should be completely automatic, - manual actions of the the service provider must be kept at a minimum. + manual actions of the service provider must be kept at a minimum. Timeline ======== diff --git a/design-documents/080-short-wire-subject.rst b/design-documents/080-short-wire-subject.rst @@ -142,7 +142,7 @@ configurable **hold delay** or such a registration is received. Subject derivation ------------------ -The subject derivation must be deterministic and and use the entire coding space. +The subject derivation must be deterministic and use the entire coding space. We will continue to support the current encoding for simple cases. diff --git a/developer/taler-developer-manual.rst b/developer/taler-developer-manual.rst @@ -42,7 +42,7 @@ overview: European banks. * taler-magnet-bank: implementation of the "bank" API using the Magnet Bank - API.Allows an exchange to interact with Magnet Bank. + API. Allows an exchange to interact with Magnet Bank. * taler-cyclos: implementation of the "bank" API using the Cyclos API. Allows an exchange to interact with a Cyclos network. @@ -385,7 +385,7 @@ Code generator usage policy We do neither encourage nor discourage the use of tools for code generation. It is up to the individual developer to decide if a tool is acceptable for a particular task. But of course, we do encourage you to use FLOSS tools -and we MUST NOT become dependend on non-free software! That said, if you +and we MUST NOT become dependent on non-free software! That said, if you use tools, you must document their use and in particular satisfy the `NLnet policy on the use of "AI" <https://nlnet.nl/news/2025/20250829-policy-on-use-of-AI.html>`__. @@ -405,7 +405,7 @@ For public discussions we use the taler@gnu.org mailinglist. All developers should subscribe to the low-volume Taler mailinglist. There are separate low-volume mailinglists for gnunet-developers (@gnu.org) and for libmicrohttpd (@gnu.org). For internal discussions we use https://mattermost.taler.net/ -(invitation only, but also achieved). +(invitation only, but also archived). What to put in bootstrap @@ -892,7 +892,7 @@ only reserved to "admin" users. Internationalisation ==================== -Internationalisation (a.k.a "translation") is handled with using text-based +Internationalisation (a.k.a "translation") is handled using text-based localization files named PO (Portable Object) holding pairs of original and translated strings. @@ -1269,7 +1269,7 @@ Python Supported Python Versions ^^^^^^^^^^^^^^^^^^^^^^^^^ -Python code should be written and build against version 3.7 of Python. +Python code should be written and built against version 3.7 of Python. Style ^^^^^ @@ -1315,12 +1315,12 @@ informally referred to as ``CMD``, that is iteratively executed by the testing interpreter. This latter is transparently initiated by the testing library. -However, the developer does not have to defined CMDs manually, but +However, the developer does not have to define CMDs manually, but rather call the proper constructor provided by the library. For example, if a CMD is supposed to test feature ``x``, then the library would provide the ``TALER_TESTING_cmd_x ()`` constructor for it. Obviously, each constructor has its own particular arguments that make sense to -test ``x``, and all constructor are thoroughly commented within the +test ``x``, and all constructors are thoroughly commented within the source code. Internally, each CMD has two methods: ``run ()`` and ``cleanup ()``. The @@ -1413,7 +1413,7 @@ Proposal **Avoid**. Generally events that relate to proposal downloads should not be shown to normal users, only developers. Instead, use - "communication with mechant failed" if a proposed order can't be downloaded. + "communication with merchant failed" if a proposed order can't be downloaded. Anonymous E-Cash Should be generally avoided, since Taler is only anonymous for @@ -1438,7 +1438,7 @@ Order **Use instead**: Purchase Fulfillment URL - URL that the serves the digital content that the user purchased + URL that serves the digital content that the user purchased with their payment. Can also be something like a donation receipt. Donau @@ -1471,7 +1471,7 @@ Payment Purchase Used to refer to the "result" of a payment, as in "view purchase". - Use sparsingly, as the word doesn't fit for all payments, such as donations. + Use sparingly, as the word doesn't fit for all payments, such as donations. Contract Terms Partially machine-readable representation of the merchant's obligation after the @@ -1525,7 +1525,7 @@ use when talking to end users or even system administrators. individual that directs the buyer (perhaps the same individual) to make a purchase coin - coins are individual token representing a certain amount of value, also known as the :term:`denomination` of the coin + coins are individual tokens representing a certain amount of value, also known as the :term:`denomination` of the coin refresh commitment data that the wallet commits to during the :term:`melt` stage of the diff --git a/developer/taler-wallet-developer.rst b/developer/taler-wallet-developer.rst @@ -61,7 +61,7 @@ Command-line Wallet This section describes how to use the GNU Taler wallet command line interface (CLI). -The the wallet CLI is targeted at developers and operators, but not meant to be +The wallet CLI is targeted at developers and operators, but not meant to be used by customers. It exposes all functionality that the more user-friendly interfaces (Android app, browser extension) offer. However, it provides more diagnostics and advanced features as well. diff --git a/libeufin/bank-manual.rst b/libeufin/bank-manual.rst @@ -163,7 +163,7 @@ If you received an email containing "Test 1234" you can enable this channel in t Custom TAN channel scripts ++++++++++++++++++++++++++ -It is possible to replace these scripts with use custom scripts to send +It is possible to replace these scripts with custom scripts to send the e-mail or SMS TAN. Such alternative scripts must accept the phone number / e-mail address as the ``$1`` parameter and the message content to be transmitted in their standard input. They should return 0 to indicate successful transmission of the challenge and non-zero on failure. To change the scripts used for multi-factor authentication, change the following @@ -237,7 +237,7 @@ Is this a Taler Exchange? Should be disabled except if you are setting up an account for a GNU Taler exchange. If enabled, transactions that are not compatible with a GNU Taler exchange will be automatically refused by the bank. XXX Cashout channel - Used in a regional currency setup to specify the external account number of a bank account in fiat currency that belongs the merchant. Allows the merchant to exchange its regional currency money for wire transfers in fiat currency into this account. Optional. Not available unless the bank is configured for regional currencies. + Used in a regional currency setup to specify the external account number of a bank account in fiat currency that belongs to the merchant. Allows the merchant to exchange its regional currency money for wire transfers in fiat currency into this account. Optional. Not available unless the bank is configured for regional currencies. Is this account public? Public accounts can be viewed without access control, their balance and transaction history becomes public. @@ -319,4 +319,4 @@ to make the change effective. .. note:: - The user may change the default exchange from within the wallet, assuming they know of an alternative exchanges for the currency. + The user may change the default exchange from within the wallet, assuming they know of an alternative exchange for the currency. diff --git a/libeufin/ebisync-manual.rst b/libeufin/ebisync-manual.rst @@ -30,7 +30,7 @@ implementing a complex cryptographic handshake to download transaction data With LibEuFin EbiSync, existing systems can use LibEuFin to talk with core banking systems over EBICS without having to implement EBICS or the :ref:`Taler Wire Gateway API <taler-wire-gateway-http-api>` themselves. -Instead, existing systems can simply use a HTTP POST request to submit +Instead, existing systems can simply use an HTTP POST request to submit PAIN files. Incoming CAMT files can be automatically placed into Cloud BLOB storage and processed from there. @@ -117,7 +117,7 @@ The package will deploy systemd service files in ``/usr/lib/systemd/system/`` for the various components: * ``libeufin-ebisync-httpd.service``: http server for the Sync API. -* ``libeufin-ebisync-fetch.service``: worker daemon that retrieves files via EBICS and upload them to a destination. +* ``libeufin-ebisync-fetch.service``: worker daemon that retrieves files via EBICS and uploads them to a destination. * ``libeufin-ebisync.target``: main target for EbiSync to be operational. The deployment creates the following key locations in the system: @@ -330,11 +330,11 @@ The ``fetch`` subcommand will always cause libeufin-ebisync to download EBICS fi The ``--transient`` flag makes the command sync only once and return immediately afterwards. Without the flag, EbiSync -will download at the frequency specified in the configuration or when it receive real time notifications. +will download at the frequency specified in the configuration or when it receives real-time notifications. The ``--debug-ebics $SAVEDIR`` flag will cause EBICS transactions steps and payloads to be stored in ``$SAVEDIR/$YYYY-MM-DD`` where ``$YYYY-MM-DD`` represents the date when the download took place. This is mostly useful for debugging. -Submittings files +Submitting files ================= If the ``ebisync-api`` source is configured, submission is triggered by using the API. diff --git a/libeufin/nexus-manual.rst b/libeufin/nexus-manual.rst @@ -264,14 +264,14 @@ database. The ``--transient`` flag makes the command download and import EBICS files only once and return immediately afterwards. Without the flag, Nexus -will download at the frequency specified in the configuration or when it receive real time notifications. +will download at the frequency specified in the configuration or when it receives real-time notifications. The ``--debug-ebics $SAVEDIR`` flag will cause EBICS transactions steps and payloads to be stored in ``$SAVEDIR/$YYYY-MM-DD`` where ``$YYYY-MM-DD`` represents the date when the download took place. This is mostly useful for debugging. Bounce fee ---------- -When a transaction is malformed, she is bounced back, the amount received is transferred back to the sender. +When a transaction is malformed, it is bounced back, the amount received is transferred back to the sender. First time users often make mistakes when sending a transaction manually, so you can expect frequent bounces. It's important that this process is user-friendly, which is why bounces are automatic. However, bounces can be costly if your bank charges you transfer fees. Here are a few parameters you can adjust to get around this problem, but bear in mind that it's often better for business to bear this cost: @@ -316,20 +316,20 @@ the present: Use the ``IGNORE_BOUNCES_BEFORE`` configuration to prevent malformed transactions from being bounced a second time when they are registered again. -Manual balance adjustement +Manual balance adjustment ========================== As LibEuFin Nexus is a Taler-specific EBICS client, it ignores non-payment transactions. This means that certain debits from your banks for fees or taxes -can be ignored. This imply that the actual balance of your bank account may deviate from that expected by Taler Exchange, leading to Exchange bankruptcy. +can be ignored. This implies that the actual balance of your bank account may deviate from that expected by Taler Exchange, leading to Exchange bankruptcy. To fix this, you must periodically send administrative balance adjustment -transfers conaining "ADMIN BALANCE ADJUST" in their subject. +transfers containing "ADMIN BALANCE ADJUST" in their subject. Manual submission acknowledgement ================================= -By default LibEuFin Nexus automatically start submitting all initiated payments. You can enforce manual submission acknowledgement by changing your config: +By default LibEuFin Nexus automatically starts submitting all initiated payments. You can enforce manual submission acknowledgement by changing your config: .. code-block:: ini diff --git a/pos-integration.rst b/pos-integration.rst @@ -19,7 +19,7 @@ Taler Point of Sale Integration ############################### -This guide provides an overview of Point of Sale (PoS) terminals can integrate +This guide provides an overview of how Point of Sale (PoS) terminals can integrate with Taler to allow payments with electronic cash from Taler Wallets. @@ -41,7 +41,7 @@ Architecture Overview Merchant API Basics ------------------- -A Taler merchant backend offers a HTTP API. Requests to private endpoints are +A Taler merchant backend offers an HTTP API. Requests to private endpoints are `authenticated <merchant-api-authentication>`_ with a bearer token in the ``Authorization: Bearer $TOKEN`` header. @@ -137,7 +137,7 @@ Refunds Refunds for paid orders can be given via the :http:post:`[/instances/$INSTANCE]/private/orders/$ORDER_ID/refund` endpoint. -Note that refunds do not arrive automically in user's wallet: The user either needs +Note that refunds do not arrive automatically in the user's wallet: The user either needs to scan the refund QR code from the ``taler_refund_uri`` field of the response to accept the refund or manually trigger checking for a refund in their wallet. diff --git a/regional/regional-automated-manual.rst b/regional/regional-automated-manual.rst @@ -42,7 +42,7 @@ these IPs. Preparing the required subdomain names ++++++++++++++++++++++++++++++++++++++ -The GNU Taler program needs to have three subdomains pointing to your server IP address, in order to let NGINX to accommodate each component. +The GNU Taler program needs to have three subdomains pointing to your server IP address, in order to let NGINX accommodate each component. These are "bank", "exchange" and "backend", this said, you need to have a registered top level domain name, where you can create type (A) entries, as subdomains pointing to your own server public IP address. A very good advice when creating these subdomains, and if your domain panel lets you specify the TTL (time to live) figure, is @@ -88,7 +88,7 @@ Navigate into the *regional-currency/* directory and run *main.sh* as **root**: The script will start by installing the required packages and then asking you fundamental questions about the desired setup, in particular: -#. Wether to encrypt, when stored on disk, sensible configurations such as the admin password. +#. Whether to encrypt, when stored on disk, sensitive configurations such as the admin password. #. The name of the regional currency. It must have 3 to 11 letters. #. Whether to setup the regional currency to be backed by a fiat currency. You'll need a bank account at a fiat currency bank offering an online banking protocol supported by LibEuFin Nexus. If you answer ``y``, you will also need to provide the following information: @@ -232,7 +232,7 @@ In our automated setup the second account is automatically set up correctly without fees or special restrictions. However, various additional *restrictions* and *options* could be configured. Details are explained in the :ref:`regional conversion setup <regional-conversion-setup>` section for the -manual setup and in the the manpage of ``taler-exchange-offline``. +manual setup and in the manpage of ``taler-exchange-offline``. .. include:: ../frags/regional-system-on.rst diff --git a/regional/regional-manual-use.rst b/regional/regional-manual-use.rst @@ -32,20 +32,20 @@ Bank backend walkthrough - As stated above, please visit before "https://bank.$DOMAIN_NAME", to make sure it is available. -- Now login with the username "admin" and the password you have choosen during the installation process, or use the one which might +- Now login with the username "admin" and the password you have chosen during the installation process, or use the one which might have been generated automatically (and shown on your terminal screen), during the installation process. Once inside the Bank Administrator area, please create the "very first" customer account. - Transfer some funds from the "admin" bank account to this new customer account. -- Now logout from the "admin" account, and login again using the recently "customer" account you have created, and make sure the funds you have transfered from admin, have arrived correctly. +- Now logout from the "admin" account, and login again using the recently "customer" account you have created, and make sure the funds you have transferred from admin, have arrived correctly. - Now, please choose the option "Send Money to a Taler Wallet", and try to send for example 100 units of your regional currency to the wallet installed on your browser or mobile phone. -- Now try to spend some of these funds from your wallet, and try to buy something somewhere, with the same digital currency you have choosen, during your installation process, let's say Netzbon. +- Now try to spend some of these funds from your wallet, and try to buy something somewhere, with the same digital currency you have chosen, during your installation process, let's say Netzbon. -- Lastly, you can also try to transfer funds to another "bank account",for that you will need to know the recipient's username or the bank account ID. +- Lastly, you can also try to transfer funds to another "bank account", for that you will need to know the recipient's username or the bank account ID. If you have successfully accomplished all the previous steps, for the bank administrator backend and your installed Wallet, you can move now to test other components such diff --git a/taler-apns-relay-manual.rst b/taler-apns-relay-manual.rst @@ -20,8 +20,8 @@ APNs Relay Manual ################# -taler-apns-relay is an Apple Push Notification relay. It send a background -notification to registered devices at a regula interval to wakup an application and enable recurrent background sync. +taler-apns-relay is an Apple Push Notification relay. It sends a background +notification to registered devices at a regular interval to wake up an application and enable recurrent background sync. This manual targets system administrators who want to install and operate an APNs relay. @@ -108,7 +108,7 @@ The package will deploy systemd service files in * ``taler-apns-relay-httpd.service``: registration REST API. * ``taler-apns-relay-httpd.socket``: systemd socket activation for the HTTP daemon. -* ``taler-apns-relay-worker.service``: worker deamon interacting with the APNs API. +* ``taler-apns-relay-worker.service``: worker daemon interacting with the APNs API. * ``taler-apns-relay.target``: main target for the relay to be operational. The deployment creates the following key locations in the system: diff --git a/taler-auditor-manual.rst b/taler-auditor-manual.rst @@ -54,7 +54,7 @@ To perform this duty, you will need at least (read-only) access to the bank transactions of the exchange, as well as a continuously synchronized replica of the exchange's database. The general assumption for running the auditor is that this is done on a separate system controlled by the auditor. After -all, the goal is to detect nerfarious activity of the exchange operator, +all, the goal is to detect nefarious activity of the exchange operator, which cannot be effectively done on a machine controlled by the exchange operator. @@ -828,7 +828,7 @@ several categories of failures of different severity: caused some other party to experience a financial loss (such as not wiring the correct amount to a merchant). -- Configuration issues (such was wire fees unavailable). +- Configuration issues (such as wire fees unavailable). .. _AuditorDatabaseUpgrades: @@ -875,7 +875,7 @@ The auditor database can be reset using: $ taler-auditor-dbinit -R However, running this command will result in all data in the database being -*lost*. Thus, doing so may result in significant commputation (and bandwidth +*lost*. Thus, doing so may result in significant computation (and bandwidth consumption with the bank) when the auditor is next launched, as it will re-download and re-verify all historic transactions. Hence this should not be done in a production system. @@ -926,7 +926,7 @@ calculations with zero instead. After patching the database, the audit can be restarted. A full reset is not required, as the audit transaction is aborted when the auditor exits with code *42*. After restarting, the resulting audit -report is likely to indicates errors relating to the corrupted fields (such as +report is likely to indicate errors relating to the corrupted fields (such as invalid signatures, arithmetic errors by the exchange, etc.), but at least the loss/gain calculations will be meaningful and actually indicative of the scope of the error created by the corrupted data. @@ -1198,7 +1198,7 @@ Testing the auditor The main objective of the auditor is to detect inconsistencies. Thus, the ``test-auditor.sh`` script deliberately introduces various inconsistencies into -a synthetic exchange database. For this, an "normal" exchange database is +a synthetic exchange database. For this, a "normal" exchange database is first generated using the ``taler-wallet-cli``. Then, various fields or rows of that database are manipulated, and the auditor is let loose on the modified database. Afterwards, the test verifies that the JSON contains values diff --git a/taler-challenger-manual.rst b/taler-challenger-manual.rst @@ -176,7 +176,7 @@ to compartmentalize different parts of the system: * ``postgres``: runs the PostgreSQL database (from *postgresql* package). * ``www-data``: runs the frontend HTTPS service with the TLS keys (from *nginx* package). -The package will deploy a systemd service files in +The package will deploy systemd service files in ``/usr/lib/systemd/system/`` for Challenger: * ``challenger-httpd.service``: the Challenger logic with the public REST API. @@ -251,7 +251,7 @@ configuration contains two configuration options. # ... rest of file ... Challenger comes with ``AUTH_COMMAND`` shell scripts for sending e-mail, SMS -and postal mail. Note that for SMS and postal mail the Challenger scripts uses +and postal mail. Note that for SMS and postal mail the Challenger scripts use third party services to actually send the SMS or print and mail the postal mail. These third parties naturally charge money for their services, and thus the Challenger administrator will need to add the respective credentials to diff --git a/taler-cyclos-manual.rst b/taler-cyclos-manual.rst @@ -22,7 +22,7 @@ Cyclos Adapter Setup Manual taler-cyclos is a Cyclos Taler adapter. It allows running a GNU Taler exchange on top of a core banking system provided by Cyclos, which is commonly -used for regional currencies. taler-cylos implements the +used for regional currencies. taler-cyclos implements the taler-wire-gateway API, which is alternatively provided by the :ref:`libeufin-bank <libeufin-bank>` (stand-alone), :ref:`libeufin-nexus <libeufin-nexus>` (EBICS integration) or the @@ -133,7 +133,7 @@ The package will deploy systemd service files in * ``taler-cyclos-httpd.service``: adapter REST API. * ``taler-cyclos-httpd.socket``: systemd socket activation for the HTTP daemon. -* ``taler-cyclos-worker.service``: worker deamon interacting with the Cyclos API. +* ``taler-cyclos-worker.service``: worker daemon interacting with the Cyclos API. * ``taler-cyclos.target``: main target for the adapter to be operational. The deployment creates the following key locations in the system: @@ -224,7 +224,7 @@ And then run the setup process: $ sudo -u taler-cyclos-worker taler-cyclos -c /etc/taler-cyclos/taler-cyclos.conf setup -If the previous command failed with a ``inaccessibleChannel`` you will have to enable the ``Web services`` channel in you account settings. If this channel is disabled, you should contact the network administrators. +If the previous command failed with an ``inaccessibleChannel`` you will have to enable the ``Web services`` channel in your account settings. If this channel is disabled, you should contact the network administrators. The setup process should fail and provide you with the information needed to fill in the required Cyclos IDs: @@ -242,7 +242,7 @@ The setup process should fail and provide you with the information needed to fil ACCOUNT_TYPE_ID = 7762070814178012479 PAYMENT_TYPE_ID = 7762070814178012479 -And finaly run the setup process again: +And finally run the setup process again: .. code-block:: console @@ -277,7 +277,7 @@ Check the server is correctly configured: Configuration ============= -Here are some configuration you might want to change: +Here are some configuration options you might want to change: Worker frequency ---------------- diff --git a/taler-directory-manual.rst b/taler-directory-manual.rst @@ -34,7 +34,7 @@ address in a messaging service. Examples for messaging services include E-mail and SMS. The service in principle allows registration of any valid URI as inbox service. -For Taler, the URI is a link a :ref:`mailbox <api-mailbox>`. +For Taler, the URI is a link to a :ref:`mailbox <api-mailbox>`. About this manual @@ -69,7 +69,7 @@ Installing from source The following instructions will show how to install libgnunetutil and the core GNU Taler libraries from source. -The package sources can be find in our +The package sources can be found in our `download directory <http://ftpmirror.gnu.org/taler/>`__. GNU Taler components version numbers follow the ``MAJOR.MINOR.MICRO`` format. @@ -147,7 +147,7 @@ to compartmentalize different parts of the system: * ``postgres``: runs the PostgreSQL database (from *postgresql* package). * ``www-data``: runs the frontend HTTPS service with the TLS keys (from *nginx* package). -The package will deploy a systemd service files in +The package will deploy systemd service files in ``/usr/lib/systemd/system/`` for taler-directory: * ``taler-directory.service``: the business logic with the public REST API. @@ -214,7 +214,7 @@ configuration contains two configuration options. # ... rest of file ... Challenger comes with ``AUTH_COMMAND`` shell scripts for sending e-mail, SMS -and postal mail. Note that for SMS and postal mail the Challenger scripts uses +and postal mail. Note that for SMS and postal mail the Challenger scripts use third party services to actually send the SMS or print and mail the postal mail. These third parties naturally charge money for their services, and thus the Challenger administrator will need to add the respective credentials to diff --git a/taler-exchange-manual.rst b/taler-exchange-manual.rst @@ -74,7 +74,7 @@ use it to receive funds via Taler. Consequently, a typical Taler exchange must interact with a bank. The bank of the exchange holds funds in an account where the balance is basically equivalent to the value of all coins in circulation. (Small mismatches arise -whenever customers are about to withdraw coins and have already send the funds +whenever customers are about to withdraw coins and have already sent the funds into the bank account, or if merchants just deposited coins and are about to receive wire transfers for deposited coins, or due to fees charged by the exchange and the operator not yet having drained the fees from the account.) @@ -182,11 +182,11 @@ components: The client-side wire adapter API is implemented in **libtalerbank** and is used by ``taler-exchange-transfer`` to execute wire transfers and by - ``taler-exchange-wirewatch`` and the Taler auditor auditor to query bank + ``taler-exchange-wirewatch`` and the Taler auditor to query bank transaction histories. - **DBMS**: - The exchange requires a DBMS to stores the transaction history for + The exchange requires a DBMS to store the transaction history for the Taler exchange and aggregator, and a (typically separate) DBMS for the Taler auditor. For now, the GNU Taler reference implementation only supports PostgreSQL, but the code could be easily extended to @@ -285,7 +285,7 @@ Security goals From a security point of view, the helpers are designed to *only* make it harder for an attacker who took control of the HTTP daemon's account to -extract the private keys, limiting the attackers ability to creating +extract the private keys, limiting the attacker's ability to create signatures to the duration of their control of that account. .. note:: @@ -299,7 +299,7 @@ The helper processes should be run under a user ID that is separate from that of the user running the main ``taler-exchange-httpd`` service. To get any security benefit from this, it is important that helpers run under a different user ID than the main HTTP frontend. In fact, ideally, each helper should run -under its own user ID. The ``taler-exchange-httpd`` service's will securely +under its own user ID. The ``taler-exchange-httpd`` service will securely communicate with the helpers using UNIX domain sockets. Configuration @@ -921,11 +921,11 @@ wire gateways. Typically only one wire gateway is used. To configure a bank account in Taler, we need to furnish two pieces of information: -- The ``payto://`` URI of the bank account, which uniquely idenfies the +- The ``payto://`` URI of the bank account, which uniquely identifies the account. Examples for such URIs include ``payto://iban/CH9300762011623852957`` for a bank account with an IBAN or - ``payto://x-taler-bank/localhost:8080/2`` for the 2nd bank account a + ``payto://x-taler-bank/localhost:8080/2`` for the 2nd bank account at the Taler bank demonstrator running at ``localhost`` on port 8080. The first part of the URI following ``payto://`` (``iban`` or ``x-taler-bank``) is called the wire method. @@ -1244,7 +1244,7 @@ which periodically expire. Account signing --------------- -The ``enable-account`` step is important to must be used to sign the +The ``enable-account`` step is important and must be used to sign the ``payto://`` URI in a way suitable to convince wallets that this is the correct address to wire funds to. Note that for each bank account, additional options **must** be set in the configuration file to tell the exchange how to @@ -1283,7 +1283,7 @@ using the ``taler-exchange-offline`` tool: The above sets the wire fees for wire transfers involving ``iban`` accounts (in Euros) in the year 2040 to 5 cents (wire fee) and 10 cents (closing fee). -The tool only supports setting fees that applies for the entire calendar year. +The tool only supports setting fees that apply for the entire calendar year. We recommend provisioning an exchange with wire fees at least for the next two years. Note that once the fees have been set for a year, they cannot be @@ -1312,7 +1312,7 @@ provision it with auditor signatures. This is also done using the ``taler-exchange-offline`` tool on the offline system. First, the auditor must be configured and provide the exchange operator with its public key (using ``taler-auditor-offline setup``) and the -URL of it's REST API. The exchange operator also needs a human-readable name +URL of its REST API. The exchange operator also needs a human-readable name that may be shown to users to identify the auditor. For more information on how to setup and operate an auditor, see :doc:`manpages/taler-auditor-offline.1` and :doc:`taler-auditor-manual`. @@ -1460,7 +1460,7 @@ transactions list. $ taler-wallet-cli deposit track $DEPOSIT_GROUP_ID You can also check using the exchange-tools whether the exchange sent -the an outgoing transfer: +an outgoing transfer: .. code-block:: shell-session @@ -1508,7 +1508,7 @@ standard database replication techniques. After all, the exchange operator runs this for diagnostics and can generally trust its own database to maintain the database invariants. -Running the auditor against a the original the production database (without +Running the auditor against the original production database (without using ``taler-auditor-sync``) enables the auditing logic to perform a few additional checks that can detect inconsistencies. These checks are enabled by passing the **-i** option to the ``taler-auditor`` command. As always, @@ -1608,7 +1608,7 @@ deployment with a bank, exchange and (optionally) auditor. Real benchmarks that are intended to demonstrate the scalability of GNU Taler should not use the tools presented in this section: they may be suitable for -microbenchmarking and tuning, but the setup is inherently not optimzied for +microbenchmarking and tuning, but the setup is inherently not optimized for performance or realism, both for the load generation and the server side. Thus, we do not recommend using these performance numbers to assess the scalability of GNU Taler. That said, the tools can be useful to help identify @@ -1698,7 +1698,7 @@ Processing is then handled by *parallel* (``-P``) service workers. taler-exchange-benchmark ------------------------ -This is the benchmarking tool simulates a number of clients withdrawing, +This benchmarking tool simulates a number of clients withdrawing, depositing and refreshing coins. Operations that are not covered by the ``taler-exchange-benchmark`` tool today include closing reserves, refunds, recoups and P2P payments. diff --git a/taler-kyc-manual.rst b/taler-kyc-manual.rst @@ -131,7 +131,7 @@ KYC Terminology subject to *expiration*. This can be because *attributes* become outdated or because sanctions have a time limit. The expiration time thus determines when a new *measure* is triggered in the absence of a transaction crossing - thresholds in the current set of *legtimization rules*. + thresholds in the current set of *legitimization rules*. * **Legitimization rules**: The *legitimization rules* determine under which *conditions* which *measures* will be taken. A `LegitimizationRuleSet` @@ -152,7 +152,7 @@ KYC Terminology which determines the *outcome*. We generally distinguish between "original" measures (defined globally in the exchange configuration) and "custom" measures (defined specifically for an account by AML staff). - Additionally, only *origional* measures that have a *check* of type + Additionally, only *original* measures that have a *check* of type "SKIP" and that require no inputs can be used as *FALLBACK* measures. * **Outcome**: An `AmlOutcome` describes the account state that an account @@ -178,7 +178,7 @@ KYC Terminology * **Trigger**: A specific transaction that satisfies a **Condition**. * **Type of operation**: The operation type determines which Taler-specific - operation has triggered the KYC requirement. We support four types of + operation has triggered the KYC requirement. We support five types of operation: withdraw (by customer), deposit (by merchant), aggregate transfer (to merchant), P2P receive (by wallet) and (high) wallet balance. @@ -191,7 +191,7 @@ The KYC configuration determines the *legitimization rules*, and specifies which providers offer which *checks*. The configuration specifies a set of providers, one per configuration -section. The names of the configuration sections must being with +section. The names of the configuration sections must begin with ``kyc-proider-`` followed by an arbitrary ``$PROVIDER_ID``: .. code-block:: ini @@ -387,7 +387,7 @@ Configuration of possible KYC/AML checks The configuration specifies a set of possible KYC checks offered by external providers, one per configuration section. The names of the configuration -sections must being with ``kyc-check-`` followed by an arbitrary +sections must begin with ``kyc-check-`` followed by an arbitrary ``$CHECK_NAME``. .. code-block:: ini @@ -452,7 +452,7 @@ sections must being with ``kyc-check-`` followed by an arbitrary # Usually should point to a measure that requests # AML staff to investigate. The fallback measure # context always includes the reasons for the - # failure. Fallback measures MUST be *origional* + # failure. Fallback measures MUST be *original* # measures and MUST use a check of # type "SKIP" and MUST NOT require any inputs. FALLBACK = MEASURE_NAME @@ -505,12 +505,12 @@ submission from ``attributes``. The LINK Type ^^^^^^^^^^^^^ -When using KYC checks of type "FORM", the KYC-SPA will show a link that allows +When using KYC checks of type "LINK", the KYC-SPA will show a link that allows the user to begin the KYC process at an external provider under the given DESCRIPTION. The external providers are expected to yield KYC attributes in the form of -key-value pairs where the list of key is defined in the GANA +key-value pairs where the list of keys is defined in the GANA ``gnu-taler-kyc-attributes`` registry, which also defines the format of each attribute. External providers may not directly yield attributes using the correct encodings, thus converter helper programs are typically used to convert @@ -571,7 +571,7 @@ condition triggers: The operation types of KYC rules refer to the following scenarios: - * **AGGREGATION**: Triggered when an exchange is about to do an + * **AGGREGATION**: Triggered when an exchange is about to do a wire transfer to a merchant. Such wire transfers typically have aggregated multiple smaller deposits, and thus enforcing KYC rules at aggregation time is more efficient than checking individual @@ -983,26 +983,26 @@ AML Forms --------- AML forms are defined by the :ref:`dynamic forms design document <dd54dynamicforms>`. -The shipped implementation with of the exchange is installed in +The shipped implementation with the exchange is installed in .. code-block:: shell-session ${INSTALL_PREFIX}/share/taler-exchange/spa/forms.js -The variable ``form`` contains the list of all form available. For +The variable ``form`` contains the list of all forms available. For every entry in the list the next properties are expected to be present: ``label``: used in the UI as the name of the form ``id``: identification name, this will be saved in the exchange database along with the values to correctly render the form again. -It should simple, short and without any character outside numbers, +It should be simple, short and without any character outside numbers, letters and underscore. ``version``: when editing a form, instead of just replacing fields it will be better to create a new form with the same id and new version. -That way old forms in the database will used old definition of the form. +That way old forms in the database will use the old definition of the form. It should be a number. ``impl`` : a function that returns the design and behavior of form. @@ -1010,8 +1010,8 @@ See DD 54 dynamic forms. .. attention:: - do not remove a form the list if it has been used. Otherwise you - won't be able to see the information save in the exchange database. + do not remove a form from the list if it has been used. Otherwise you + won't be able to see the information saved in the exchange database. To add a new one you can simply copy and paste one element, and edit it. @@ -1196,7 +1196,7 @@ This template is instantiated using the following information: * debug: boolean; true if we are running in debug mode and are allowed to return HTML with potentially sensitive information - * server_response: Object; could be NULL; this includes the (malformed) OAuth2 server response, it should be shown to the use if "debug" is true + * server_response: Object; could be NULL; this includes the (malformed) OAuth2 server response, it should be shown to the user if "debug" is true oauth2-bad-request @@ -1294,7 +1294,7 @@ This template is instantiated using the following information: persona-exchange-unpaid ----------------------- -The Persona server refused our request (HTTP 402 Payment REquired from Persona, returned as a HTTP 503 Service Unavailable). +The Persona server refused our request (HTTP 402 Payment Required from Persona, returned as a HTTP 503 Service Unavailable). This template is instantiated using the following information: @@ -1344,7 +1344,7 @@ This template is instantiated using the following information: * debug: boolean; true if we are running in debug mode and are allowed to return HTML with potentially sensitive information - * server_response: Object; could be NULL; this includes the (malformed) OAuth2 server response, it should be shown to the use if "debug" is true + * server_response: Object; could be NULL; this includes the (malformed) OAuth2 server response, it should be shown to the user if "debug" is true persona-network-timeout diff --git a/taler-magnet-bank-manual.rst b/taler-magnet-bank-manual.rst @@ -101,7 +101,7 @@ The package will deploy systemd service files in * ``taler-magnet-bank-httpd.service``: adapter REST API. * ``taler-magnet-bank-httpd.socket``: systemd socket activation for the HTTP daemon. -* ``taler-magnet-bank-worker.service``: worker deamon interacting with the Magnet Bank API. +* ``taler-magnet-bank-worker.service``: worker daemon interacting with the Magnet Bank API. * ``taler-magnet-bank.target``: main target for the adapter to be operational. The deployment creates the following key locations in the system: @@ -187,7 +187,7 @@ Update the configuration files: CONSUMER_KEY = $CONSUMER_KEY CONSUMER_SECRET = $CONSUMER_SECRET -And finaly run the setup process: +And finally run the setup process: .. code-block:: console diff --git a/taler-mailbox-manual.rst b/taler-mailbox-manual.rst @@ -60,7 +60,7 @@ Installing from source The following instructions will show how to install libgnunetutil and the core GNU Taler libraries from source. -The package sources can be find in our +The package sources can be found in our `download directory <http://ftpmirror.gnu.org/taler/>`__. GNU Taler components version numbers follow the ``MAJOR.MINOR.MICRO`` format. @@ -124,7 +124,7 @@ to compartmentalize different parts of the system: * ``postgres``: runs the PostgreSQL database (from *postgresql* package). * ``www-data``: runs the frontend HTTPS service with the TLS keys (from *nginx* package). -The package will deploy a systemd service files in +The package will deploy systemd service files in ``/usr/lib/systemd/system/`` for taler-mailbox: * ``taler-mailbox.service``: the business logic with the public REST API. diff --git a/taler-merchant-manual.rst b/taler-merchant-manual.rst @@ -378,7 +378,7 @@ Installing from source The following instructions will show how to install a GNU Taler merchant backend from source. -The package sources can be find in our +The package sources can be found in our `download directory <http://ftpmirror.gnu.org/taler/>`__. .. include:: frags/semver.rst @@ -405,11 +405,11 @@ libraries! .. note:: There is an additional **optional** dependency that you could install to - obtain support for tax-deductable donations. This is only useful for + obtain support for tax-deductible donations. This is only useful for charities and only in countries with tax authorities that operate a Donau to register charities and accept Taler-style digitally signed donation statements. As of right now, we are pretty sure that list is right now - empty. But, if you want to experiment with Taler-style donation statmenets, + empty. But, if you want to experiment with Taler-style donation statements, you need to install Donau after the exchange and before the merchant. .. include:: frags/install-before-check.rst @@ -754,7 +754,7 @@ merchant backend as ``$USER`` using (to provide a trivial example): To ensure these processes run always in the background and also after rebooting, you should use systemd, cron or some other init system of your operating system to launch the process. You should also periodically re-start -these services to prevent them from exhausing the memory utilization of the +these services to prevent them from exhausting the memory utilization of the PostgreSQL database. Consult the documentation of your operating system for how to start and stop daemons. @@ -888,7 +888,7 @@ times, once for each instance. This means unauthorized users can distinguish between the case where the instance does not exist (HTTP 404) and the case where access is denied (HTTP 403). - This is concern can be addressed using a properly configured + This concern can be addressed using a properly configured :ref:`reverse proxy <reverse-proxy-configuration>`. @@ -901,7 +901,7 @@ or no instance must be configured at all yet. To start, point your browser to ``$PROTO://backend.$DOMAIN_NAME/``, replacing "$PROTO" with "https" or (rarely) "http" and "$DOMAIN_NAME" with your -organizations DNS domain or subdomain. +organization's DNS domain or subdomain. .. note:: @@ -941,7 +941,7 @@ fee amount for each order it creates. .. note:: - Details on the acceptable fee calcuation + Details on the acceptable fee calculation are described in the Taler design document 47. Finally, you need to specify several settings relating to default @@ -952,7 +952,7 @@ deadlines. refuse the payment and require the customer to get a new quote. (2) The "Default refund delay" specifies how long the customer may receive - refunds. The refund period is cummulative on top of the "Default payment + refunds. The refund period is cumulative on top of the "Default payment delay". Thus, the refund period ends independently of when the customer actually paid for the order. The exchange will **not** wire the funds to the merchant before the refund deadline lapses, as after the funds have been @@ -960,7 +960,7 @@ deadlines. (3) The "Default wire transfer delay" specifies how soon the exchange **must** wire the funds **after** the refund deadline. The delay is again - cummulative on top of the "Default payment delay" and the "Default refund + cumulative on top of the "Default payment delay" and the "Default refund delay". However, the resulting time is still not the actual wire deadline, as first the "Default wire rounding interval" is also considered. @@ -1073,7 +1073,7 @@ bank account. The following page should appear: .. image:: screenshots/enter_instance_details.png First, you should select the wire method, after which the dialog will show you -additional fields specific to the wire method. For example, if youchoose +additional fields specific to the wire method. For example, if you choose ``iban`` as the account type, the following page should appear: .. image:: screenshots/instance_iban_config.png @@ -1090,7 +1090,7 @@ Detecting Settlement: Manually Adding Transfers ----------------------------------------------- The exchange may aggregate many small amounts into one larger wire transfer. -If you want to safely determine for which orders have been settled (final +If you want to safely determine which orders have been settled (final payment from the exchange has been received), the backend must learn about the wire transfers made into your bank account. Basically, as a secure system, we do not simply trust a claim by the exchange that it would transfer the money, @@ -1239,8 +1239,8 @@ you can specify which URL, which HTTP headers, which HTTP method and what HTTP body to send to the Webhook. Webhooks are automatically retried (with increasing delays) when the target server returns a temporary error. -`Mustach templates <https://mustache.github.io/mustache.5.html>`__ and limited -version of it are used when defining the contents of Webhooks. +`Mustach templates <https://mustache.github.io/mustache.5.html>`__ and a limited +version of it is used when defining the contents of Webhooks. Depending on the triggering event, the templates will be expanded with event-specific data. Limited in this case means that only a specific string is being replaced with the event-specific data, no support for parsing conditions or nested structures @@ -1678,7 +1678,7 @@ This template is instantiated using the following information: * order_summary: String; a text summarizing the order - * contract_terms: Object; the full contract terms (shoud probably + * contract_terms: Object; the full contract terms (should probably not be shown in full!) * refund_amount: Amount; how much did the merchant refund @@ -1842,7 +1842,7 @@ some of them being common to all subcommands: The tool comes with two operation modes: *ordinary*, and *corner*. The first just executes normal payments, meaning that it uses the -``admin`` instance and make sure that all payments get aggregated. The +``admin`` instance and makes sure that all payments get aggregated. The second gives the chance to leave some payments unaggregated, and also to use merchant instances other than ``admin`` (which is, actually, the one used by default by the tool). diff --git a/taler-merchant-pos-terminal.rst b/taler-merchant-pos-terminal.rst @@ -41,7 +41,7 @@ it uses the saved configuration data to fetch the current configuration (defined below) and populates the currency, the products and their categories. -The Tabled UI is separated into three columns: +The tablet UI is separated into three columns: * Right: Product categories that the user can select to show different products. * Middle: Products available in the selected category and their prices. @@ -126,7 +126,7 @@ The elements of the JSON file are defined as follows: // Typically, a product only belongs to one category, but more than one is supported. categories: number[]; - // Where to deliver this product. This may be an URL for online delivery + // Where to deliver this product. This may be a URL for online delivery // (i.e. 'http://example.com/download' or 'mailto:customer@example.com'), // or a location label defined inside the configuration's 'locations'. delivery_location: string;