summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorChristian Grothoff <christian@grothoff.org>2024-03-07 09:52:56 +0100
committerChristian Grothoff <christian@grothoff.org>2024-03-07 09:52:56 +0100
commite39dd668c013a44854d8b9fd62b486a90f6931b9 (patch)
tree4a23f9fba7740acff3d1e4f5f0da1e93ab77b697
parent70d848507ba233fa9e530481cd7816c399db6d19 (diff)
downloaddocs-e39dd668c013a44854d8b9fd62b486a90f6931b9.tar.gz
docs-e39dd668c013a44854d8b9fd62b486a90f6931b9.tar.bz2
docs-e39dd668c013a44854d8b9fd62b486a90f6931b9.zip
fix bad anchor warning
-rw-r--r--manpages/challenger.conf.5.rst2
-rw-r--r--taler-developer-manual.rst114
2 files changed, 49 insertions, 67 deletions
diff --git a/manpages/challenger.conf.5.rst b/manpages/challenger.conf.5.rst
index 66c46e80..626d11f7 100644
--- a/manpages/challenger.conf.5.rst
+++ b/manpages/challenger.conf.5.rst
@@ -72,7 +72,7 @@ ADDRESS_TYPE
Type of the address that is being collected, returned as part of the ``address_type`` in the ``/info`` endpoint. Examples include ``email`` or ``phone``.
ADDRESS_RESTRICTIONS
- JSON object with a map of keys (names of the fields of the address to be entered by the user) to objects with a "regex" (string) containing an extended Posix regular expression for allowed address field values, and a "hint"/"hint_i18n" giving a human-readable explanation to display if the value entered by the user does not match the regex. Keys that are not mapped to such an object have no restriction on the value provided by the user. Examples would be '{"email":{"hint":"valid e-mail address required","regex":"^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+$"}' or '{"zip":{"hint":"numeric zip code required","regex":"^[0-9]+$"}'.
+ JSON object with a map of keys (names of the fields of the address to be entered by the user) to objects with a "regex" (string) containing an extended Posix regular expression for allowed address field values, and a "hint"/"hint_i18n" giving a human-readable explanation to display if the value entered by the user does not match the regex. Keys that are not mapped to such an object have no restriction on the value provided by the user. Examples would be '{"email":{"hint":"valid e-mail address required","regex":"^[a-zA-Z0-9\_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+$"}' or '{"zip":{"hint":"numeric zip code required","regex":"^[0-9]+$"}'.
SEE ALSO
diff --git a/taler-developer-manual.rst b/taler-developer-manual.rst
index 1aa5cc8d..3035e55d 100644
--- a/taler-developer-manual.rst
+++ b/taler-developer-manual.rst
@@ -1524,18 +1524,16 @@ use when talking to end users or even system administrators.
trusted third party that verifies that the :term:`exchange` is operating correctly
bank
- traditional financial service provider who offers wire :term:`transfers <transfer>` between accounts
+ traditional financial service provider who offers
+ :term:`wire transfers <wire transfer>` between accounts
buyer
individual in control of a Taler :term:`wallet`, usually using it to
- :term:`spend` the :term:`coins` on :term:`contracts` (see also :term:`customer`).
+ :term:`spend` the :term:`coins <coin>` on :term:`contracts <contract>` (see also :term:`customer`).
close
- closes
- closed
- closing
operation an :term:`exchange` performs on a :term:`reserve` that has not been
- :term:`drained` by :term:`withdraw` operations. When closing a reserve, the
+ :term:`emptied <empty>` by :term:`withdraw` operations. When closing a reserve, the
exchange wires the remaining funds back to the customer, minus a :term:`fee`
for closing
@@ -1543,10 +1541,8 @@ 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
coins are individual token representing a certain amount of value, also known as the :term:`denomination` of the coin
- commitment
refresh commitment
data that the wallet commits to during the :term:`melt` stage of the
:term:`refresh` protocol where it
@@ -1555,9 +1551,8 @@ use when talking to end users or even system administrators.
probabilistically (see: :term:`kappa`) during the :term:`reveal` stage.
contract
- contracts
formal agreement between :term:`merchant` and :term:`customer` specifying the
- :term:`contract terms` and signed by the merchant and the :term:`coins` of the
+ :term:`contract terms` and signed by the merchant and the :term:`coins <coin>` of the
customer
contract terms
@@ -1573,32 +1568,32 @@ use when talking to end users or even system administrators.
particular :term:`denomination`
deposit
- deposits
- depositing
operation by which a merchant passes coins to an exchange, expecting the
exchange to credit his bank account in the future using an
:term:`aggregate` :term:`wire transfer`
drain
- drained
- a :term:`reserve` is being drained when a :term:`wallet` is using the
- reserve's private key to :term:`withdraw` coins from it. This reduces
- the balance of the reserve. Once the balance reaches zero, we say that
- the reserve has been (fully) drained. Reserves that are not drained
- (which is the normal process) are :term:`closed` by the exchange.
+ process by which an exchange operator takes the profits
+ (from :term:`fees <fee>`) out of the escrow account and moves them into
+ their regular business account
dirty
- dirty coin
- a coin is dirty if its public key may be known to an entity other than
+ a :term:`coin` is dirty if its public key may be known to an entity other than
the customer, thereby creating the danger of some entity being able to
link multiple transactions of coin's owner if the coin is not refreshed
+ empty
+ a :term:`reserve` is being emptied when a :term:`wallet` is using the
+ reserve's private key to :term:`withdraw` coins from it. This reduces
+ the balance of the reserve. Once the balance reaches zero, we say that
+ the reserve has been (fully) emptied. Reserves that are not emptied
+ (which is the normal process) are :term:`closed <close>` by the exchange.
+
exchange
Taler's payment service operator. Issues electronic coins during
withdrawal and redeems them when they are deposited by merchants
expired
- expiration
Various operations come with time limits. In particular, denomination keys
come with strict time limits for the various operations involving the
coin issued under the denomination. The most important limit is the
@@ -1620,18 +1615,17 @@ use when talking to end users or even system administrators.
fee
an :term:`exchange` charges various fees for its service. The different
fees are specified in the protocol. There are fees per coin for
- :term:`withdrawing`, :term:`depositing`, :term:`melting`, and
- :term:`refunding`. Furthermore, there are fees per wire transfer
- for :term:`closing` a :term:`reserve`: and for
- :term:`aggregate` :term:`wire transfers` to the :term:`merchant`.
+ :term:`withdrawing <withdraw>`, :term:`depositing <deposit>`, :term:`melting <melt>`, and
+ :term:`refunding <refund>`. Furthermore, there are fees per wire transfer
+ when a :term:`reserve` is :term:`closed <close>`
+ and for :term:`aggregate` :term:`wire transfers <wire transfer>`
+ to the :term:`merchant`.
fresh
- fresh coin
- a coin is fresh if its public key is only known to the customer
+ a :term:`coin` is fresh if its public key is only known to the customer
- json
JSON
- JavaScript Object Notation
+ JavaScript Object Notation (JSON) is a
serialization format derived from the JavaScript language which is
commonly used in the Taler protocol as the payload of HTTP requests
and responses.
@@ -1641,11 +1635,11 @@ use when talking to end users or even system administrators.
The probability of successfully evading the income transparency with the
refresh protocol is 1:kappa.
- LibEuFin
- FIXME: explain
+ libeufin
+ Kotlin component that implements a regional currency bank and an
+ adapter to communicate via EBICS with European core banking systems.
link
- linking
specific step in the :term:`refresh` protocol that an exchange must offer
to prevent abuse of the :term:`refresh` mechanism. The link step is
not needed in normal operation, it just must be offered.
@@ -1655,9 +1649,7 @@ use when talking to end users or even system administrators.
message signing keys
melt
- melted
- melting
- step of the :term:`refresh` protocol where a :term:`dirty coin`
+ step of the :term:`refresh` protocol where a :term:`dirty` :term:`coin`
is invalidated to be reborn :term:`fresh` in a subsequent
:term:`reveal` step.
@@ -1683,19 +1675,19 @@ use when talking to end users or even system administrators.
recoup
Operation by which an exchange returns the value of coins affected
- by a :term:`revocation` to their :term:`owner`, either by allowing the owner to
+ by a :term:`revocation <revoke>` to their :term:`owner`, either by allowing the owner to
withdraw new coins or wiring funds back to the bank account of the :term:`owner`.
planchet
precursor data for a :term:`coin`. A planchet includes the coin's internal
secrets (coin private key, blinding factor), but lacks the RSA signature
- of the :term:`exchange`. When :term:`withdrawing`, a :term:`wallet`
+ of the :term:`exchange`. When :term:`withdrawing <withdraw>`, a :term:`wallet`
creates and persists a planchet before asking the exchange to sign it to
get the coin.
purchase
Refers to the overall process of negotiating a :term:`contract` and then
- making a payment with :term:`coins` to a :term:`merchant`.
+ making a payment with :term:`coins <coin>` to a :term:`merchant`.
privacy policy
Statement of an operator how they will protect the privacy of users.
@@ -1708,13 +1700,11 @@ use when talking to end users or even system administrators.
merchant backend.
refresh
- refreshing
- operation by which a :term:`dirty coin` is converted into one or more
- :term:`fresh` coins. Involves :term:`melting` the :term:`dirty coin` and
- then :term:`revealing` so-called :term:`transfer keys`.
+ operation by which a :term:`dirty` :term:`coin` is converted into one or more
+ :term:`fresh` coins. Involves :term:`melting <melt>` the :term:`dirty` coins and
+ then :term:`revealing <reveal>` so-called :term:`transfer keys <transfer key>`.
refund
- refunding
operation by which a merchant steps back from the right to funds that he
obtained from a :term:`deposit` operation, giving the right to the funds back
to the customer
@@ -1726,25 +1716,23 @@ use when talking to end users or even system administrators.
reserve
accounting mechanism used by the exchange to track customer funds
- from incoming :term:`wire transfers`. A reserve is created whenever
+ from incoming :term:`wire transfers <wire transfer>`. A reserve is created whenever
a customer wires money to the exchange using a well-formed public key
in the subject. The exchange then allows the customer's :term:`wallet`
to :term:`withdraw` up to the amount received in :term:`fresh`
- :term:`coins` from the reserve, thereby draining the reserve. If a
- reserve is not drained, the exchange eventually :term:`closes` it.
+ :term:`coins <coin>` from the reserve, thereby emptying the reserve. If a
+ reserve is not emptied, the exchange will eventually :term:`close` it.
Other definition: Funds set aside for future use; either the balance of a customer at the
exchange ready for withdrawal, or the funds kept in the exchange;s bank
account to cover obligations from coins in circulation.
reveal
- revealing
step in the :term:`refresh` protocol where some of the transfer private
keys are revealed to prove honest behavior on the part of the wallet.
In the reveal step, the exchange returns the signed :term:`fresh` coins.
revoke
- revocation
exceptional operation by which an exchange withdraws a denomination from
circulation, either because the signing key was compromised or because
the exchange is going out of operation; unspent coins of a revoked
@@ -1756,22 +1744,14 @@ use when talking to end users or even system administrators.
time.
spend
- spending
operation by which a customer gives a merchant the right to deposit
coins in return for merchandise
- transfer
- transfers
- wire transfer
- wire transfers
- method of sending funds between :term:`bank` accounts
-
transfer key
- transfer keys
special cryptographic key used in the :term:`refresh` protocol, some of which
are revealed during the :term:`reveal` step. Note that transfer keys have,
- despite the name, no relationship to :term:`wire transfers`. They merely
- help to transfer the value from a :term:`dirty coin` to a :term:`fresh coin`
+ despite the name, no relationship to :term:`wire transfers <wire transfer>`. They merely
+ help to transfer the value from a :term:`dirty` coin to a :term:`fresh` coin
terms
the general terms of service of an operator, possibly including
@@ -1804,25 +1784,27 @@ use when talking to end users or even system administrators.
Cross-browser API used to implement the GNU Taler wallet browser extension.
wire gateway
- FIXME: explain
+ API used by the exchange to talk with some real-time gross settlement system
+ (core banking system, blockchain) to notice inbound credits wire transfers
+ (during withdraw) and to trigger outbound debit wire transfers (primarily
+ for deposits).
+
+ wire transfer
+ a wire transfer is a method of sending funds between :term:`bank` accounts
wire transfer identifier
- wtid
Subject of a wire transfer from the exchange to a merchant;
set by the aggregator to a random nonce which uniquely
identifies the transfer.
withdraw
- withdrawing
- withdrawal
operation by which a :term:`wallet` can convert funds from a :term:`reserve` to
fresh coins
zombie
- zombie coin
- coin where the respective :term:`denomination key` is past its
- :term:`deposit` :term:`expiration` time, but which is still (again) valid
- for an operation because it was :term:`melted` while it was still
+ :term:`coin` where the respective :term:`denomination key` is past its
+ :term:`deposit` :term:`expiration <expired>` time, but which is still (again) valid
+ for an operation because it was :term:`melted <melt>` while it was still
valid, and then later again credited during a :term:`recoup` process