[taler-docs] branch master updated: fix bad anchor warning

[gnunet]

This is an automated email from the git hooks/post-receive script.

grothoff pushed a commit to branch master
in repository docs.

The following commit(s) were added to refs/heads/master by this push:
     new e39dd668 fix bad anchor warning
e39dd668 is described below

commit e39dd668c013a44854d8b9fd62b486a90f6931b9
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Thu Mar 7 09:52:56 2024 +0100

    fix bad anchor warning
---
 manpages/challenger.conf.5.rst |   2 +-
 taler-developer-manual.rst     | 114 +++++++++++++++++------------------------
 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  [...]
+  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  [...]
 
 
 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
 
 

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.