Definitions

Main.Definitions History

Hide minor edits - Show changes to output

December 15, 2010, at 04:20 PM by Romualdo Grillo -
Added lines 50-51:
The term is introduced and explained in this [[http://screenr.com/c5K|video]] from min.0:18 to min.1:30.
December 14, 2010, at 10:03 AM by Romualdo Grillo - Changed order in the list
Changed lines 3-4 from:
* [[#Ripple_Client|Ripple Client]]
* [[#Ripple_Server|Ripple Server]]
to:
Changed lines 10-25 from:

[[#Ripple_Client]]
!!!Ripple client: Software to manage Ripple credit data.
* Software that manages accounts that involve lines of credit between parties, and uses the Ripple server to route payments.
* Software that authenticates itself to a Ripple server via username/password, digital certificate, SSH public key, or similar.
A bank could "Ripple-enable" its online banking web interface to permit account-holders to send Ripple payments as an alternative payment mechanism, alongside the standard online checking functionality. The bank's software is a Ripple client, and has some means of authenticating itself to its Ripple server(s).
The bank with "Ripple parallel to online checking" scenario described above is only one possibility among many. Online accounting software for direct payments, Inter-LETS payments, online currency conversions, and other scenarios also work.
[[Potential Ripple clients
]].

[[#Ripple_Server]]
!!!Ripple server:
* Software to operate on Ripple credit data.
* Software that transacts Ripple credit data.
* Software that authenticates Ripple clients, allowing them to manage credit data.
The Ripple protocol allows for a number of servers to operate independently of each other, and communicate with each other when clients with different servers need to interact.

to:
* [[#Ripple_Client|Ripple Client]]
* [[#Ripple_Server|Ripple Server]]

Changed lines 64-79 from:
In either case, node-specific exchange rates are used for the above conversion functions. So node B has an exchange rate table stored for routing payments between all of its neighbors.
to:
In either case, node-specific exchange rates are used for the above conversion functions. So node B has an exchange rate table stored for routing payments between all of its neighbors.

[[#Ripple_Client]]
!!!Ripple client: Software to manage Ripple credit data.
* Software that manages accounts that involve lines of credit between parties, and uses the Ripple server to route payments.
* Software that authenticates itself to a Ripple server via username/password, digital certificate, SSH public key, or similar.
A bank could "Ripple-enable" its online banking web interface to permit account-holders to send Ripple payments as an alternative payment mechanism, alongside the standard online checking functionality. The bank's software is a Ripple client, and has some means of authenticating itself to its Ripple server(s).
The bank with "Ripple parallel to online checking" scenario described above is only one possibility among many. Online accounting software for direct payments, Inter-LETS payments, online currency conversions, and other scenarios also work.
[[Potential Ripple clients]].

[[#Ripple_Server]]
!!!Ripple server:
* Software to operate on Ripple credit data.
* Software that transacts Ripple credit data.
* Software that authenticates Ripple clients, allowing them to manage credit data.
The Ripple protocol allows for a number of servers to operate independently of each other, and communicate with each other when clients with different servers need to interact
.
November 18, 2010, at 02:38 PM by Romualdo Grillo -
Changed lines 21-22 from:
!!!Ripple server:Software to operate on Ripple credit data.
to:
!!!Ripple server:
*
Software to operate on Ripple credit data.
Changed lines 28-29 from:
!!!Party:Entity that deals with Ripple credit:
to:
!!!Party:
*
Entity that deals with Ripple credit:
Changed lines 34-35 from:
!!!User:Ripple account-holder:
to:
!!!User:
*
Ripple account-holder:
Changed lines 44-45 from:
!!!Node:Ripple credit transaction point:
to:
!!!Node:
*
Ripple credit transaction point:
Changed lines 52-53 from:
!!![[Credit relationship]]:Agreement between two nodes:
to:
!!![[Credit relationship]]:
*
Agreement between two nodes:
Changed lines 65-66 from:
!!!Credit Network: Also referred to as Trust Network or Ripple Network:
to:
!!!Credit Network:
*
Also referred to as Trust Network or Ripple Network:
Changed lines 71-72 from:
!!![[Credit exchange]]: Transaction between two nodes:
to:
!!![[Credit exchange]]:
*
Transaction between two nodes:
November 18, 2010, at 02:33 PM by Romualdo Grillo -
Changed lines 31-32 from:
!!![[#User]]
:User:Ripple account-holder:
to:
[[#User]]
!!!User:Ripple account-holder:
Changed lines 40-41 from:
!!![[#Node]]
:Node:Ripple credit transaction point:
to:
[[#Node]]
!!!Node:Ripple credit transaction point:
Changed lines 47-48 from:
!!![[#Credit_relationship]]
:[[Credit relationship]]:Agreement between two nodes:
to:
[[#Credit_relationship]]
!!![[Credit relationship]]:Agreement between two nodes:
Changed lines 59-60 from:
!!![[#Credit_Network]]
:Credit Network: Also referred to as Trust Network or Ripple Network:
to:
[[#Credit_Network]]
!!!Credit Network: Also referred to as Trust Network or Ripple Network:
Changed lines 64-65 from:
!!![[#Credit_exchange]]
:[[Credit exchange]]: Transaction between two nodes:
to:
[[#Credit_exchange]]
!!![[Credit exchange]]: Transaction between two nodes:
November 18, 2010, at 02:31 PM by Romualdo Grillo -
Changed lines 26-27 from:
[[#]]
:Party:Entity that deals with Ripple credit:
to:
[[#Party]]
!!!Party:Entity that deals with Ripple credit:
Changed line 31 from:
[[#User]]
to:
!!![[#User]]
Changed line 40 from:
[[#Node]]
to:
!!![[#Node]]
Changed line 47 from:
[[#Credit_relationship]]
to:
!!![[#Credit_relationship]]
Changed line 59 from:
[[#Credit_Network]]
to:
!!![[#Credit_Network]]
Changed line 64 from:
[[#Credit_exchange]]
to:
!!![[#Credit_exchange]]
November 18, 2010, at 02:29 PM by Romualdo Grillo -
Changed line 13 from:
!!!Ripple client:Software to manage Ripple credit data:
to:
!!!Ripple client: Software to manage Ripple credit data.
Changed lines 16-19 from:
* A bank could "Ripple-enable" its online banking web interface to permit account-holders to send Ripple payments as an alternative payment mechanism, alongside the standard online checking functionality. The bank's software is a Ripple client, and has some means of authenticating itself to its Ripple server(s).
* The bank with "Ripple parallel to online checking" scenario described above is only one possibility among many. Online accounting software for direct payments, Inter-LETS payments, online currency conversions, and other scenarios also work.
* [[Potential Ripple clients]].
to:
A bank could "Ripple-enable" its online banking web interface to permit account-holders to send Ripple payments as an alternative payment mechanism, alongside the standard online checking functionality. The bank's software is a Ripple client, and has some means of authenticating itself to its Ripple server(s).
The bank with "Ripple parallel to online checking" scenario described above is only one possibility among many. Online accounting software for direct payments, Inter-LETS payments, online currency conversions, and other scenarios also work.
[[Potential Ripple clients]].
Changed line 21 from:
:Ripple server:Software to operate on Ripple credit data:
to:
!!!Ripple server:Software to operate on Ripple credit data.
Changed lines 24-25 from:
* The Ripple protocol allows for a number of servers to operate independently of each other, and communicate with each other when clients with different servers need to interact.
to:
The Ripple protocol allows for a number of servers to operate independently of each other, and communicate with each other when clients with different servers need to interact.
Changed lines 29-30 from:
* Parties can be individuals, groups of individuals such as a circle of friends, agricultural or other co-ops, businesses, governments, banks, etc.
to:
Parties can be individuals, groups of individuals such as a circle of friends, agricultural or other co-ops, businesses, governments, banks, etc.
Changed lines 34-39 from:
* Users authenticate themselves to a Ripple client via username/password, or some other authentication scheme.
* A user can be a party itself, or a representative of the party, or a software application that can authenticate itself.
* A user engages with a Ripple account directly, while a party engages with Ripple credit.
* A party might have many users, while a user might have many parties.
* The Ripple server doesn't work in terms of users or parties, only nodes.
to:
Users authenticate themselves to a Ripple client via username/password, or some other authentication scheme.
A user can be a party itself, or a representative of the party, or a software application that can authenticate itself.
A user engages with a Ripple account directly, while a party engages with Ripple credit.
A party might have many users, while a user might have many parties.
The Ripple server doesn't work in terms of users or parties, only nodes.
Changed lines 43-46 from:
* A node has credit relationships (lines of credit) with other nodes.
* A node can be a payment endpoint, either a payer or a recipient.
* A node can be a payment intermediary, receiving value from one node and passing it along to another in a [[credit exchange]] as part of a payment chain.
to:
A node has credit relationships (lines of credit) with other nodes.
A node can be a payment endpoint, either a payer or a recipient.
A node can be a payment intermediary, receiving value from one node and passing it along to another in a [[credit exchange]] as part of a payment chain.
Changed lines 49-52 from:
* A credit relationship exists between two nodes, say node A and node B.
* It describes a line of credit that node A has with node B, or the reciprocal line of credit that node B has with node A.
* It has a specific unit of value, such as the US Dollar, Euro, ounce of gold, or gigajoule.
* A credit relationship consists of accounts for both nodes, each containing the following data:
to:
A credit relationship exists between two nodes, say node A and node B.
It describes a line of credit that node A has with node B, or the reciprocal line of credit that node B has with node A.
It has a specific unit of value, such as the US Dollar, Euro, ounce of gold, or gigajoule.
A credit relationship consists of accounts for both nodes, each containing the following data:
Changed lines 56-58 from:
* Two nodes connected by a credit relationship are called ''neighbors''.
* Two nodes may have more than one credit relationship connecting them to each other, for instance to allow for credit relationships in more than one currency.
to:
Two nodes connected by a credit relationship are called ''neighbors''.
Two nodes may have more than one credit relationship connecting them to each other, for instance to allow for credit relationships in more than one currency.
Changed lines 62-63 from:
* A credit network G = (V, E) is a directed graph with n nodes and m edges. Nodes represent entities or agents. Edges represent pairwise credit limits between agents.
to:
A credit network G = (V, E) is a directed graph with n nodes and m edges. Nodes represent entities or agents. Edges represent pairwise credit limits between agents.
Changed lines 67-70 from:
* It can be a link in a longer payment chain. Suppose a payer A wants to pay a recipient E, where the two parties are connected by nodes B, C, and D. Credit exchanges would Ripple through these credit relationships.
* When routing in the same currency, node B can charge a transaction fee, or can be altruistic and choose not to charge a fee.
* When routing between two different currencies, node B can charge an exchange rate between the currencies.
* In either case, node-specific exchange rates are used for the above conversion functions. So node B has an exchange rate table stored for routing payments between all of its neighbors.
to:
It can be a link in a longer payment chain. Suppose a payer A wants to pay a recipient E, where the two parties are connected by nodes B, C, and D. Credit exchanges would Ripple through these credit relationships.
When routing in the same currency, node B can charge a transaction fee, or can be altruistic and choose not to charge a fee.
When routing between two different currencies, node B can charge an exchange rate between the currencies.
In either case, node-specific exchange rates are used for the above conversion functions. So node B has an exchange rate table stored for routing payments between all of its neighbors.
November 18, 2010, at 02:24 PM by Romualdo Grillo - Added "Credit Network" and formatted
Changed lines 3-13 from:
:Ripple client:Software to manage Ripple credit data:
to:
* [[#Ripple_Client|Ripple Client]]
* [[#Ripple_Server|Ripple Server]]
* [[#Party|Party]]
* [[#User|User]]
* [[#Node|Node]]
* [[#Credit_relationship|Credit relationship]]
* [[#Credit_Network|Credit Network]]
* [[#Credit_exchange|Credit exchange]]

[[#Ripple_Client]]
!!!
Ripple client:Software to manage Ripple credit data:
Added line 20:
[[#Ripple_Server]]
Added line 26:
[[#]]
Added line 31:
[[#User]]
Added line 40:
[[#Node]]
Added line 47:
[[#Credit_relationship]]
Added lines 59-64:
[[#Credit_Network]]
:Credit Network: Also referred to as Trust Network or Ripple Network:
* [[#Node|Nodes]] and [[#Credit_relationship|Credit relationships]] form a Credit Network. The term Credit Network is not limited to description of Ripple project. An equivalent definition is given in the article "A Little Trust Goes a Long Way" Pranav etc..:
* A credit network G = (V, E) is a directed graph with n nodes and m edges. Nodes represent entities or agents. Edges represent pairwise credit limits between agents.

[[#Credit_exchange]]
October 16, 2010, at 08:42 PM by Ryan - restore, sorry
September 29, 2010, at 04:36 AM by Daniel - clean up
Changed lines 10-11 from:
:Ripple server:Software to store Ripple credit data:
* Software that holds Ripple account data.
to:
:Ripple server:Software to operate on Ripple credit data:
* Software that transacts Ripple credit data.
September 27, 2010, at 12:04 AM by Daniel - clean up
Changed lines 6-9 from:
* Simple example: A bank could "Ripple-enable" its online banking web interface to permit account-holders to send Ripple payments as an alternative payment mechanism, alongside the standard online checking functionality.
** Broadly speaking, the bank is a Ripple client, and has some means of authenticating itself to its Ripple server(s).
** In a more precise technical sense, when a bank customer logs into an online banking service and initiates a Ripple payment, and the online banking software interacts with the Ripple server, the bank software is acting as a Ripple client.
* Note: the
bank with "Ripple parallel to online checking" scenario described above is only one possibility among many. Online accounting software for direct payments, Inter-LETS payments, online currency conversions, and other scenarios also work.
to:
* A bank could "Ripple-enable" its online banking web interface to permit account-holders to send Ripple payments as an alternative payment mechanism, alongside the standard online checking functionality. The bank's software is a Ripple client, and has some means of authenticating itself to its Ripple server(s).
* The bank with "Ripple parallel to online checking" scenario described above is only one possibility among many. Online accounting software for direct payments, Inter-LETS payments, online currency conversions, and other scenarios also work.
September 26, 2010, at 08:58 PM by Daniel - formatting
Changed line 35 from:
:Credit relationship:Agreement between two nodes:
to:
:[[Credit relationship]]:Agreement between two nodes:
Changed lines 45-46 from:
* [[Credit relationship]].
to:
Changed lines 1-52 from:
(:redirect Credit Exchange:)
to:
The definitions on this page explain the main terminology used in describing Ripple.

:Ripple client:Software to manage Ripple credit data:
* Software that manages accounts that involve lines of credit between parties, and uses the Ripple server to route payments.
* Software that authenticates itself to a Ripple server via username/password, digital certificate, SSH public key, or similar.
* Simple example: A bank could "Ripple-enable" its online banking web interface to permit account-holders to send Ripple payments as an alternative payment mechanism, alongside the standard online checking functionality.
** Broadly speaking, the bank is a Ripple client, and has some means of authenticating itself to its Ripple server(s).
** In a more precise technical sense, when a bank customer logs into an online banking service and initiates a Ripple payment, and the online banking software interacts with the Ripple server, the bank software is acting as a Ripple client.
* Note: the bank with "Ripple parallel to online checking" scenario described above is only one possibility among many. Online accounting software for direct payments, Inter-LETS payments, online currency conversions, and other scenarios also work.
* [[Potential Ripple clients]].

:Ripple server:Software to store Ripple credit data:
* Software that holds Ripple account data.
* Software that authenticates Ripple clients, allowing them to manage credit data.
* The Ripple protocol allows for a number of servers to operate independently of each other, and communicate with each other when clients with different servers need to interact.

:Party:Entity that deals with Ripple credit:
* Something or someone using Ripple to send, receive, and route payments.
* Parties can be individuals, groups of individuals such as a circle of friends, agricultural or other co-ops, businesses, governments, banks, etc.

:User:Ripple account-holder:
* The direct owner of a Ripple account.
* Users authenticate themselves to a Ripple client via username/password, or some other authentication scheme.
* A user can be a party itself, or a representative of the party, or a software application that can authenticate itself.
* A user engages with a Ripple account directly, while a party engages with Ripple credit.
* A party might have many users, while a user might have many parties.
* The Ripple server doesn't work in terms of users or parties, only nodes.

:Node:Ripple credit transaction point:
* A node is Ripple's internal representation of a user's account.
* A node has credit relationships (lines of credit) with other nodes.
* A node can be a payment endpoint, either a payer or a recipient.
* A node can be a payment intermediary, receiving value from one node and passing it along to another in a [[credit exchange]] as part of a payment chain.

:Credit relationship:Agreement between two nodes:
* A credit relationship exists between two nodes, say node A and node B.
* It describes a line of credit that node A has with node B, or the reciprocal line of credit that node B has with node A.
* It has a specific unit of value, such as the US Dollar, Euro, ounce of gold, or gigajoule.
* A credit relationship consists of accounts for both nodes, each containing the following data:
** Balance: the amount of debt owed by one node to the other.
** Maximum balance: a limit on debt that can be owed by the other node.
** Minimum balance: a limit on debt that can be owed to the other node.
* Two nodes connected by a credit relationship are called ''neighbors''.
* Two nodes may have more than one credit relationship connecting them to each other, for instance to allow for credit relationships in more than one currency.
* [[Credit relationship]].

:[[Credit exchange]]: Transaction between two nodes:
* A credit exchange is a payment flow through credit relationships.
* It can be a link in a longer payment chain. Suppose a payer A wants to pay a recipient E, where the two parties are connected by nodes B, C, and D. Credit exchanges would Ripple through these credit relationships.
* When routing in the same currency, node B can charge a transaction fee, or can be altruistic and choose not to charge a fee.
* When routing between two different currencies, node B can charge an exchange rate between the currencies.
* In either case, node-specific exchange rates are used for the above conversion functions. So node B has an exchange rate table stored for routing payments between all of its neighbors.
September 26, 2010, at 08:00 PM by Daniel - redirect
Changed lines 1-52 from:
The definitions on this page explain the main terminology used in describing Ripple.

:Ripple client:Software to manage Ripple credit data:
* Software that manages accounts that involve lines of credit between parties, and uses the Ripple server to route payments.
* Software that authenticates itself to a Ripple server via username/password, digital certificate, SSH public key, or similar.
* Simple example: A bank could "Ripple-enable" its online banking web interface to permit account-holders to send Ripple payments as an alternative payment mechanism, alongside the standard online checking functionality.
** Broadly speaking, the bank is a Ripple client, and has some means of authenticating itself to its Ripple server(s).
** In a more precise technical sense, when a bank customer logs into an online banking service and initiates a Ripple payment, and the online banking software interacts with the Ripple server, the bank software is acting as a Ripple client.
* Note: the bank with "Ripple parallel to online checking" scenario described above is only one possibility among many. Online accounting software for direct payments, Inter-LETS payments, online currency conversions, and other scenarios also work.
* [[Potential Ripple clients]].

:Ripple server:Software to store Ripple credit data:
* Software that holds Ripple account data.
* Software that authenticates Ripple clients, allowing them to manage credit data.
* The Ripple protocol allows for a number of servers to operate independently of each other, and communicate with each other when clients with different servers need to interact.

:Party:Entity that deals with Ripple credit:
* Something or someone using Ripple to send, receive, and route payments.
* Parties can be individuals, groups of individuals such as a circle of friends, agricultural or other co-ops, businesses, governments, banks, etc.

:User:Ripple account-holder:
* The direct owner of a Ripple account.
* Users authenticate themselves to a Ripple client via username/password, or some other authentication scheme.
* A user can be a party itself, or a representative of the party, or a software application that can authenticate itself.
* A user engages with a Ripple account directly, while a party engages with Ripple credit.
* A party might have many users, while a user might have many parties.
* The Ripple server doesn't work in terms of users or parties, only nodes.

:Node:Ripple credit transaction point:
* A node is Ripple's internal representation of a user's account.
* A node has credit relationships (lines of credit) with other nodes.
* A node can be a payment endpoint, either a payer or a recipient.
* A node can be a payment intermediary, receiving value from one node and passing it along to another in a [[credit exchange]] as part of a payment chain.

:Credit relationship:Agreement between two nodes:
* A credit relationship exists between two nodes, say node A and node B.
* It describes a line of credit that node A has with node B, or the reciprocal line of credit that node B has with node A.
* It has a specific unit of value, such as the US Dollar, Euro, ounce of gold, or gigajoule.
* A credit relationship consists of accounts for both nodes, each containing the following data:
** Balance: the amount of debt owed by one node to the other.
** Maximum balance: a limit on debt that can be owed by the other node.
** Minimum balance: a limit on debt that can be owed to the other node.
* Two nodes connected by a credit relationship are called ''neighbors''.
* Two nodes may have more than one credit relationship connecting them to each other, for instance to allow for credit relationships in more than one currency.
* [[Credit relationship]].

:[[Credit exchange]]: Transaction between two nodes:
* A credit exchange is a payment flow through credit relationships.
* It can be a link in a longer payment chain. Suppose a payer A wants to pay a recipient E, where the two parties are connected by nodes B, C, and D. Credit exchanges would Ripple through these credit relationships.
* When routing in the same currency, node B can charge a transaction fee, or can be altruistic and choose not to charge a fee.
* When routing between two different currencies, node B can charge an exchange rate between the currencies.
* In either case, node-specific exchange rates are used for the above conversion functions. So node B has an exchange rate table stored for routing payments between all of its neighbors.
to:
(:redirect Credit Exchange:)
September 26, 2010, at 07:57 PM by Daniel - update link
Changed lines 45-46 from:
* [[Credit relationship example]].
to:
* [[Credit relationship]].
September 26, 2010, at 07:54 PM by Daniel - formatting
Changed lines 10-11 from:
* [[Potential Ripple Clients]]
to:
* [[Potential Ripple clients]].
Changed lines 45-46 from:
* [[Credit Relationship Example]]
to:
* [[Credit relationship example]].
September 26, 2010, at 07:54 PM by Daniel - clean up
Changed line 9 from:
* Note: the bank with "Ripple parallel to online checking" scenario described above is only one possibility among many. Online accounting software direct payments, Inter-LETS payments, online currency conversions, and other scenarios also work.
to:
* Note: the bank with "Ripple parallel to online checking" scenario described above is only one possibility among many. Online accounting software for direct payments, Inter-LETS payments, online currency conversions, and other scenarios also work.
September 26, 2010, at 03:53 AM by Daniel - clean up
Changed lines 36-37 from:
* A credit relationship exists between two nodes, say node A and node B
* It describes a line of credit that node A has with node B, or the reciprocal line of credit node B has with node A
to:
* A credit relationship exists between two nodes, say node A and node B.
* It describes a line of credit that node A has with node B, or the reciprocal line of credit that node B has with node A.
Changed lines 43-44 from:
* Two nodes connected by a credit relationship are called ''neighbours''.
* Two nodes may have more than one credit relationships connecting them, for instance to allow for credit relationships in more than one currency.
to:
* Two nodes connected by a credit relationship are called ''neighbors''.
* Two nodes may have more than one credit relationship connecting them to each other, for instance to allow for credit relationships in more than one currency.
September 26, 2010, at 03:52 AM by Daniel - clean up
Changed lines 18-20 from:
* Something or someone that uses Ripple to send, receive, and route payments.
* Parties can be individuals, or groups of individuals such as a circle of friends, agricultural or other co-ops, businesses, governments, banks, software applications, etc.
to:
* Something or someone using Ripple to send, receive, and route payments.
* Parties can be individuals, groups of individuals such as a circle of friends, agricultural or other co-ops, businesses, governments, banks, etc.
Added line 22:
* The direct owner of a Ripple account.
Changed line 24 from:
* An obvious example is a person, but a user could also be a bot or some automated process that knows how to authenticate itself.
to:
* A user can be a party itself, or a representative of the party, or a software application that can authenticate itself.
Changed lines 27-28 from:
* The Ripple server doesn't know anything about users or parties, only nodes.
to:
* The Ripple server doesn't work in terms of users or parties, only nodes.
Added line 30:
* A node is Ripple's internal representation of a user's account.
Changed lines 32-34 from:
* It can be a payment endpoint, either a payer or a recipient.
* It can be a payment intermediary, receiving value from one node and passing it along to another in a [[credit exchange]] as part of a payment chain.
to:
* A node can be a payment endpoint, either a payer or a recipient.
* A node can be a payment intermediary, receiving value from one node and passing it along to another in a [[credit exchange]] as part of a payment chain.
September 26, 2010, at 03:46 AM by Daniel - clean up
Changed lines 44-45 from:
* [[Credit Relationship Example With Disputed Balance]]
to:
September 26, 2010, at 03:45 AM by Daniel - clean up
Changed lines 48-51 from:
* It can be a link in a longer payment chain. Suppose a payer A wants to pay a recipient E, where the two parties are connected by Nodes B, C, and D. Credit exchanges would Ripple through these credit relationships.
* When routing in the same currency, Node B can charge a transaction fee, or can be altruistic and choose not to charge a fee.
* When routing between two different currencies, Node B can charge an exchange rate between the currencies.
* In either case, node-specific exchange rates are used for the above conversion functions. So Node B has an exchange rate table stored for routing payments between all of its neighbors.
to:
* It can be a link in a longer payment chain. Suppose a payer A wants to pay a recipient E, where the two parties are connected by nodes B, C, and D. Credit exchanges would Ripple through these credit relationships.
* When routing in the same currency, node B can charge a transaction fee, or can be altruistic and choose not to charge a fee.
* When routing between two different currencies, node B can charge an exchange rate between the currencies.
* In either case, node-specific exchange rates are used for the above conversion functions. So node B has an exchange rate table stored for routing payments between all of its neighbors.
September 26, 2010, at 03:44 AM by Daniel - clean up
Changed lines 47-51 from:
* is a payment flow from one credit relationship to another, that passes through a node
* is
a link in a payment chain, say Node A -> Node B -> Node C, where B and C are the previous and successor nodes, and the ultimate payer / payment recipient are at the start and end of the chain: Payer -> ..... -> A -> B -> C -> ..... Recipient
* when routing in the same currency, Node B can charge a transaction fee
, or can be friendly and choose not charge a fee
* when routing between two different currencies, Node B has some
conversion rate between the currencies
* In either case, node-specific exchange rates are used for the above conversion functions. So Node B has an exchange rate table stored for routing payments between all of its neighbors
to:
* A credit exchange is a payment flow through credit relationships.
* It can be
a link in a longer payment chain. Suppose a payer A wants to pay a recipient E, where the two parties are connected by Nodes B, C, and D. Credit exchanges would Ripple through these credit relationships.
* When routing in
the same currency, Node B can charge a transaction fee, or can be altruistic and choose not to charge a fee.
* When routing between two different currencies
, Node B can charge an exchange rate between the currencies.
* In either case, node-specific exchange rates are used for the above
conversion functions. So Node B has an exchange rate table stored for routing payments between all of its neighbors.
September 26, 2010, at 03:38 AM by Daniel - clean up
Changed line 6 from:
* Simple example: A bank could "Ripple-enable" its online banking web interface to permit account holders to send Ripple payments as an alternative payment mechanism, alongside the standard online checking functionality.
to:
* Simple example: A bank could "Ripple-enable" its online banking web interface to permit account-holders to send Ripple payments as an alternative payment mechanism, alongside the standard online checking functionality.
Changed lines 22-27 from:
* Users authenticate themselves to a ripple client via username/password, or some other authentication scheme
* Obvious example is people, but could also be a bot or some automated process that knows how to authenticate itself.
* A party might have many users, or a user might have many parties.
* The ripple server doesn't know anything about users or parties, only nodes.
* A user may interact with the ripple system via a single registered node
, or may choose to register multiple nodes, just as an email user might choose to have more than one email address
to:
* Users authenticate themselves to a Ripple client via username/password, or some other authentication scheme.
* An obvious example is a person, but a user could also be a bot or some automated process that knows how to authenticate itself.
* A user engages with a Ripple account directly, while a party engages with Ripple credit.
* A party might have many users, while a user might have many parties.
* The Ripple server doesn't know anything about users or parties
, only nodes.
Changed lines 29-33 from:
* has credit relationships (lines of credit) with other nodes
* can be a payment endpoint, either payer or recipient
* can be a payment intermediary, receiving value from one node and passing it along to another in a [[Credit Exchange]] as part of a payment chain
* A ripple party might well send and receive all ripple payments via a single node, but a party might also have reasons to register multiple nodes
to:
* A node has credit relationships (lines of credit) with other nodes.
* It can be a payment endpoint, either a payer or a recipient.
* It can be a payment intermediary, receiving value from one node and passing it along to another in a [[credit exchange]] as part of a payment chain.
Changed lines 34-44 from:
* exists between two nodes, say node A and node B
* describes a line of credit that node A has with
node B, and the reciprocal line of credit node B has with node A
*
has a specific unit of value, such as USD, Euro, or oz. of gold
* has an account for each node
, each containing the following data:
** balance, the amount of debt owed by
the other node
** max balance, a limit on debt that can be owed by the other node
** min
balance, a limit on debt that can be owed to the other node
*** Consider the balance for Node A, for a credit relationship connecting A<->B. Assuming the debt balance starts at 0$, an upper limit of $50 and a lower limit of (-$25) means that Node B has a credit limit of $50 with Node A, while Node A's self-imposed issuance limit is $25. (Node A doesn't want to allow itself to go deeper into debt than $25 with Node B.)
*** Balances can start at any number, they need not start at 0.
*** All three quantities can be reset arbitrarily by either node, for its side of the accounting
*** It doesn't matter if two nodes at opposite ends of a credit relationship disagree about the exact amount of debt they've recorded is owed by the other. In fact, Node A could have recorded that Node B owes it money in its account, while Node B has recorded that Node A owes it money on its own account. As long as A's credit limit exceeds the amount of money it believes B owes, and B's credit limit exceeds the amount of money it believes A owes, the ripple server can use this credit relationship in a payment exchange for payment routing in either direction. Ripple does payment routing, not account reconciliation
.
to:
* A credit relationship exists between two nodes, say node A and node B
* It describes a line of credit that
node A has with node B, or the reciprocal line of credit node B has with node A
* It has a specific unit of value, such as the US Dollar, Euro, ounce of gold
, or gigajoule.
* A credit relationship consists of accounts for both nodes, each containing
the following data:
** Balance: the amount of debt owed by one node to the other.
** Maximum
balance: a limit on debt that can be owed by the other node.
** Minimum balance: a limit on debt that can be owed to the other node.
Changed line 42 from:
* Two nodes may have more than one credit relationships connecting them, for instance to allow for credit relationships in more than one currency
to:
* Two nodes may have more than one credit relationships connecting them, for instance to allow for credit relationships in more than one currency.
Changed lines 44-45 from:
* To do: [[Credit Relationship Example With Disputed Balance]]
to:
* [[Credit Relationship Example With Disputed Balance]]
September 26, 2010, at 03:26 AM by Daniel - clean up
Changed lines 18-20 from:
* Something or someone that uses ripple to send, receive, and route payments
* Parties can be individuals, or collectives such as a group of friends, an agricultural coop, businesses, governments, banks, etc.
to:
* Something or someone that uses Ripple to send, receive, and route payments.
* Parties can be individuals, or groups of individuals such as a circle of friends, agricultural or other co-ops, businesses, governments, banks, software applications, etc.
September 26, 2010, at 03:25 AM by Daniel - clean up
Added lines 1-2:
The definitions on this page explain the main terminology used in describing Ripple.
Changed lines 4-10 from:
* Software that manages accounts that involve lines of credit between parties, and uses the ripple server to route payments
* Software that authenticates itself to a ripple server via username/password, digital certificate, ssh public key, or similar
* Simple example: A bank could "ripple enable" its online banking web interface to permit accountholders to send ripple payments as an alternative payment mechanism, alongside the standard online checking functionality.
** Broadly speaking, the bank is a ripple client, and has some means of authenticating itself to its ripple server(s).
** In a more precise technical sense, when a bank customer logged into online banking initiates a ripple payment, and the online banking software interacts with the ripple server, this is bank software acting as a ripple client.
** The web browser bank customers use to access their online checking, and through this make ripple payments, is *not* a ripple client -- it is a client of the bank's web server software. Bank customers don't have a user/password to authenticate themselves to the ripple server; the bank does. The password that bank customers do have, which allows them to access their online banking, is a different password from the one the bank uses to interact with its ripple server.
* Note: the bank with "ripple parallel to online checking"  scenario described above is not very likely to arise anytime soon, though it could conceivably happen if ripple becomes very popular. Inter-LETS payments, online accounting software direct payments, online currency conversions, and other scenarios are more plausible. The bank example was used only because this is a scenario we think the greatest number of people are familiar with, whereas not that many people know what a LETS system is
.
to:
* Software that manages accounts that involve lines of credit between parties, and uses the Ripple server to route payments.
* Software that authenticates itself to a Ripple server via username/password, digital certificate, SSH public key, or similar.
* Simple example: A bank could "Ripple-enable" its online banking web interface to permit account holders to send Ripple payments as an alternative payment mechanism, alongside the standard online checking functionality.
** Broadly speaking, the bank is a Ripple client, and has some means of authenticating itself to its Ripple server(s).
** In a more precise technical sense, when a bank customer logs into an online banking service and initiates a Ripple payment, and the online banking software interacts with the Ripple server, the bank software is acting as a Ripple client.
* Note: the bank with "Ripple parallel to online checking" scenario described above is only one possibility among many. Online accounting software direct payments, Inter-LETS payments, online currency conversions, and other scenarios also work.
Added lines 12-16:
:Ripple server:Software to store Ripple credit data:
* Software that holds Ripple account data.
* Software that authenticates Ripple clients, allowing them to manage credit data.
* The Ripple protocol allows for a number of servers to operate independently of each other, and communicate with each other when clients with different servers need to interact.

September 26, 2010, at 12:49 AM by Daniel - clean up
Changed line 1 from:
:Ripple Client:Software to manage Ripple credit data:
to:
:Ripple client:Software to manage Ripple credit data:
Changed lines 17-23 from:
* Obvious example is people, but could also be a bot or some automated process that knows how to authenticate itself.  

A
party might have many users, or a user might have many parties.
The ripple server doesn't know anything about users or parties, only nodes.

* a user may interact with the ripple system via a single registered node, or may choose to register multiple nodes, just as an email user might choose to have more than one email address
to:
* Obvious example is people, but could also be a bot or some automated process that knows how to authenticate itself.
* A party might have many users, or a user might have many parties.
* The ripple server doesn't know anything about users or parties, only nodes.
* A user may interact with the ripple system via a single registered node, or may choose to register multiple nodes, just as an email user might choose to have more than one email address
September 26, 2010, at 12:43 AM by Daniel - clean up
September 26, 2010, at 12:43 AM by Daniel - clean up
Changed lines 29-30 from:
* [[Main/Users, Parties, and Nodes]])
to:
Changed line 47 from:
:Credit exchange: Transaction between two nodes:
to:
:[[Credit exchange]]: Transaction between two nodes:
Changed lines 52-53 from:
* In either case, node-specific exchange rates are used for the above conversion functions. So Node B has an exchange rate table stored for routing payments between all of its neighbors
* [[Credit Exchange|Credit Exchange Example]]
to:
* In either case, node-specific exchange rates are used for the above conversion functions. So Node B has an exchange rate table stored for routing payments between all of its neighbors
September 26, 2010, at 12:38 AM by Daniel - clean up
Changed lines 1-3 from:
!!!! Definitions

'''Ripple
Client'''
to:
:Ripple Client:Software to manage Ripple credit data:
Changed lines 10-12 from:
----

'''
Party'''
to:

:Party:Entity that deals with Ripple credit:
Changed line 15 from:
'''User'''
to:
:User:Ripple account-holder:
Changed lines 22-26 from:
[[Users,Parties, and Nodes]]

----

'''A
Node'''
to:
* a user may interact with the ripple system via a single registered node, or may choose to register multiple nodes, just as an email user might choose to have more than one email address

:
Node:Ripple credit transaction point:
Changed line 31 from:
'''A Credit Relationship'''
to:
:Credit relationship:Agreement between two nodes:
Changed line 48 from:
'''A Credit Exchange'''
to:
:Credit exchange: Transaction between two nodes:
Changed lines 54-55 from:
* [[Credit Exchange|Credit Exchange Example]]
to:
* [[Credit Exchange|Credit Exchange Example]]
September 17, 2010, at 12:48 AM by Daniel - Remove link to non-existent Ripple Usage Examples
Changed line 10 from:
* Note: the bank with "ripple parallel to online checking"  scenario described above is not very likely to arise anytime soon, though it could conceivably happen if ripple becomes very popular. Inter-LETS payments, online accounting software direct payments, online currency conversions, and other scenarios are more plausible -- see [[Ripple Usage Examples]]. The bank example was used only because this is a scenario we think the greatest number of people are familiar with, whereas not that many people know what a LETS system is.
to:
* Note: the bank with "ripple parallel to online checking"  scenario described above is not very likely to arise anytime soon, though it could conceivably happen if ripple becomes very popular. Inter-LETS payments, online accounting software direct payments, online currency conversions, and other scenarios are more plausible. The bank example was used only because this is a scenario we think the greatest number of people are familiar with, whereas not that many people know what a LETS system is.
Changed line 11 from:
* Potential Ripple Clients
to:
* [[Potential Ripple Clients]]
Changed line 9 from:
** The web browser bank customers use to access their online checking, and through this make ripple payments, is *not* a ripple client -- it is a client of the bank's web server software. (There might be a scenario where a user surfing the web would authenticate themselves directly to a ripple server, but we consider this a far less common scenario than the bank type scenario described above.)
to:
** The web browser bank customers use to access their online checking, and through this make ripple payments, is *not* a ripple client -- it is a client of the bank's web server software. Bank customers don't have a user/password to authenticate themselves to the ripple server; the bank does. The password that bank customers do have, which allows them to access their online banking, is a different password from the one the bank uses to interact with its ripple server.
Added line 11:
* Potential Ripple Clients
March 13, 2008, at 04:33 PM by thomas - explanation of why bank chosen as motivating example, though LETS is more probable to arise
Changed lines 6-10 from:
* Basic examples: A [[http://en.wikipedia.org/wiki/Local_Exchange_Trading_Systems|LETS]] system could ripple-enable its [[http://project.cyclos.org/site.php|web interface]] to permit members to send and route ripple payments. A traditional bank could ripple enable its online banking web interface to permit account-holders to send ripple payments as an alternative payment mechanism, alongside the standard online checking functionality. Now LETS members can pay their cable bills with income they have earned in community currency, even though the cable company accepts only traditional checks in national currency -- because the ripple server finds a payment path and does the conversion from community currency to standard US dollars. [[Paying the Cable Bill With Ripple]] (to do.)
** Broadly speaking, in the above scenario the LETS system and the bank are a ripple clients, which have some means of authenticating themselves to their ripple server(s).
** In a more precise technical sense
, when a bank customer (or LETS custemer) logs in to the web site and initiates a ripple payment, this is the bank (or LETS) software acting as a ripple client.
** The web browser thank bank customers users use to do banking online is *not* a ripple client
-- it is a client of the bank's web server software. (There might be a scenario where a user surfing the web would authenticate themselves directly to a ripple server, but we consider this a far less common scenario than the bank type scenario described above.)
to:
* Simple example: A bank could "ripple enable" its online banking web interface to permit accountholders to send ripple payments as an alternative payment mechanism, alongside the standard online checking functionality.
** Broadly speaking, the bank is a
ripple client, and has some means of authenticating itself to its ripple server(s).
** In a more precise technical sense, when a bank customer logged into online banking initiates a ripple payment, and the online banking software interacts with the ripple server, this is bank software acting as a ripple client.
** The web browser bank customers use
to access their online checking, and through this make ripple payments, is *not* a ripple client -- it is a client of the bank's web server software. (There might be a scenario where a user surfing the web would authenticate themselves directly to a ripple server, but we consider this a far less common scenario than the bank type scenario described above.)
* Note: the bank with "ripple parallel to online checking"  scenario described above is not very likely to arise anytime soon, though it could conceivably happen if ripple becomes very popular. Inter
-LETS payments, online accounting software direct payments, online currency conversions, and other scenarios are more plausible -- see [[Ripple Usage Examples]]. The bank example was used only because this is a scenario we think the greatest number of people are familiar with, whereas not that many people know what a LETS system is.
March 12, 2008, at 11:39 PM by 190.33.59.5 - ripple client definition
Changed line 3 from:
'''Client'''
to:
'''Ripple Client'''
Changed lines 5-11 from:
* Client sooftware that authenticates itself to the ripple server via username/password, digital certificate, ssh public key, or some related authentication scheme
*
[[Main/RippleClientExamples|ripple client examples]]
* Simple example: A bank could "ripple enable" its online banking web interface to permit accountholders to send ripple payments as an alternative payment mechanism, alongside the standard online checking functionality.
** Broadly speaking, the bank is a ripple client
, and has some means of authenticating itself to its ripple server(s).
** In a more precise technical sense, when a bank customer logged into online banking initiates a ripple payment, and the online banking software interacts with
the ripple server, this is bank software acting as a ripple client.
** The web browser bank customers use to access their online checking, and through this make ripple payments,
is *not* a ripple client -- it is a client of the bank's web server software. (There might be a scenario where a user surfing the web would authenticate themselves directly to a ripple server, but we consider this a far less common scenario than the bank type scenario described above.)
to:
* Software that authenticates itself to a ripple server via username/password, digital certificate, ssh public key, or similar
* Basic examples: A
[[http://en.wikipedia.org/wiki/Local_Exchange_Trading_Systems|LETS]] system could ripple-enable its [[http://project.cyclos.org/site.php|web interface]] to permit members to send and route ripple payments. A traditional bank could ripple enable its online banking web interface to permit account-holders to send ripple payments as an alternative payment mechanism, alongside the standard online checking functionality. Now LETS members can pay their cable bills with income they have earned in community currency, even though the cable company accepts only traditional checks in national currency -- because the ripple server finds a payment path and does the conversion from community currency to standard US dollars. [[Paying the Cable Bill With Ripple]] (to do.)
** Broadly speaking, in the above scenario the LETS system and the bank are a ripple clients, which have some means of authenticating themselves to their ripple server(s).
** In a more precise technical sense, when a bank customer (or LETS custemer) logs in to the web site and initiates a ripple payment, this is the bank (or LETS) software acting as a ripple client.
** The web browser thank bank customers users use to do banking online
is *not* a ripple client -- it is a client of the bank's web server software. (There might be a scenario where a user surfing the web would authenticate themselves directly to a ripple server, but we consider this a far less common scenario than the bank type scenario described above.)
March 12, 2008, at 05:12 PM by 190.33.59.5 -
Changed lines 7-8 from:
* Simple example: A bank could "ripple enable" its online banking web interface to permit accountholders to send ripple payments as an alternative payment mechanism, alongside the now ubiquitous online checking functionality. Broadly speaking, the bank is a ripple client, and has some means of authenticating itself to its ripple server(s). The web browser bank customers use to access their online checking, and through this make ripple payments, is *not* a ripple client -- it is a client of the bank's web server software. The apache web server the bank is using to serve up web pages is also not the ripple client. When a bank customer logged into online banking initiates a ripple payment, and the online banking software interfaces with the ripple server (probably via HTTP or XMPP), this *is* the bank software acting as a ripple client.
to:
* Simple example: A bank could "ripple enable" its online banking web interface to permit accountholders to send ripple payments as an alternative payment mechanism, alongside the standard online checking functionality.
**
Broadly speaking, the bank is a ripple client, and has some means of authenticating itself to its ripple server(s).
** In a more precise technical sense, when a bank customer logged into online banking initiates a ripple payment, and the online banking software interacts with the ripple server, this is
bank software acting as a ripple client.
** The web browser bank customers use to access their online checking, and through this make ripple payments, is *not* a ripple client -- it is
a client of the bank's web server software. (There might be a scenario where a user surfing the web would authenticate themselves directly to a ripple server, but we consider this a far less common scenario than the bank type scenario described above.)
March 12, 2008, at 05:02 PM by 190.33.59.5 -
Changed lines 4-5 from:
* Software that manages accounts that involve lines of credit between parties.
to:
* Software that manages accounts that involve lines of credit between parties, and uses the ripple server to route payments
* Client sooftware that authenticates itself to the ripple server via username/password, digital certificate, ssh public key, or some related authentication scheme
Changed lines 7-8 from:
to:
* Simple example: A bank could "ripple enable" its online banking web interface to permit accountholders to send ripple payments as an alternative payment mechanism, alongside the now ubiquitous online checking functionality. Broadly speaking, the bank is a ripple client, and has some means of authenticating itself to its ripple server(s). The web browser bank customers use to access their online checking, and through this make ripple payments, is *not* a ripple client -- it is a client of the bank's web server software. The apache web server the bank is using to serve up web pages is also not the ripple client. When a bank customer logged into online banking initiates a ripple payment, and the online banking software interfaces with the ripple server (probably via HTTP or XMPP), this *is* the bank software acting as a ripple client.
March 12, 2008, at 05:11 AM by 190.33.59.5 -
Changed lines 36-42 from:
** current balance: the amount of debt currently owed by the other node
** an upper limit on debt that can be owed by the other node (frequently a positive number, can be understood as a credit limit)
** a lower limit on debt that can be owed by the other node (frequently
a negative number, can be understood as an issuance limit)
** Consider the balance for Node A, for
a credit relationship connecting A<->B. Assuming the debt balance starts at 0$, an upper limit of $50 and a lower limit of (-$25) means that Node B has a credit limit of $50 with Node A, while Node A's self-imposed issuance limit is $25. (Node A doesn't want to allow itself to go deeper into debt than $25 with Node B.)
** However, debt balances can start at any number, they need not start at 0.
** all three quantities can be reset arbitrarily by either node, for its side of the accounting
** It doesn't matter if two nodes at opposite ends of a credit relationship disagree about the exact amount of debt they've recorded is owed by the other. In fact, Node A could have recorded that Node B owes it money in its account, while Node B has recorded that Node A owes it money on its own account. As long as A's credit limit exceeds the amount of money it believes B owes, and B's credit limit exceeds the amount of money it believes A owes, the ripple server can use this credit relationship in a payment exchange for payment routing in either direction. Ripple does payment routing, not account reconciliation.
to:
** balance, the amount of debt owed by the other node
** max balance, a limit on debt that can be owed by the other node
** min balance, a limit on debt that can be owed to the other node
*** Consider the balance for Node A, for
a credit relationship connecting A<->B. Assuming the debt balance starts at 0$, an upper limit of $50 and a lower limit of (-$25) means that Node B has a credit limit of $50 with Node A, while Node A's self-imposed issuance limit is $25. (Node A doesn't want to allow itself to go deeper into debt than $25 with Node B.)
*** Balances can start at any number, they need not start at 0.
*** All three quantities can be reset arbitrarily by either node, for its side of the accounting
*** It doesn't matter if two nodes at opposite ends of a credit relationship disagree about the exact amount of debt they've recorded is owed by the other. In fact, Node A could have recorded that Node B owes it money in its account, while Node B has recorded that Node A owes it money on its own account. As long as A's credit limit exceeds the amount of money it believes B owes, and B's credit limit exceeds the amount of money it believes A owes, the ripple server can use this credit relationship in a payment exchange for payment routing in either direction. Ripple does payment routing, not account reconciliation.
March 12, 2008, at 04:58 AM by 190.33.59.5 -
Changed lines 36-39 from:
** the amount of debt owed by the other node
** an upper limit, which is the maximum balance on this account
** a lower limit, which is the minimum balance on this account
** all three quantities can be reset arbitrarily by either node, for its side of the accounting
to:
** current balance: the amount of debt currently owed by the other node
** an upper limit on debt that can be owed by the other node (frequently a positive number, can be understood as a credit limit)
** a lower limit on debt that can be owed by the other node (frequently a negative number, can be understood as an issuance limit)
Added line 41:
** all three quantities can be reset arbitrarily by either node, for its side of the accounting
March 12, 2008, at 04:49 AM by 190.33.59.5 -
Changed line 36 from:
** the balance of payments between the two nodes (kept as two balances in case there is disagreement between the nodes)
to:
** the amount of debt owed by the other node
Added lines 39-42:
** all three quantities can be reset arbitrarily by either node, for its side of the accounting
** Consider the balance for Node A, for a credit relationship connecting A<->B. Assuming the debt balance starts at 0$, an upper limit of $50 and a lower limit of (-$25) means that Node B has a credit limit of $50 with Node A, while Node A's self-imposed issuance limit is $25. (Node A doesn't want to allow itself to go deeper into debt than $25 with Node B.)
** However, debt balances can start at any number, they need not start at 0.
** It doesn't matter if two nodes at opposite ends of a credit relationship disagree about the exact amount of debt they've recorded is owed by the other. In fact, Node A could have recorded that Node B owes it money in its account, while Node B has recorded that Node A owes it money on its own account. As long as A's credit limit exceeds the amount of money it believes B owes, and B's credit limit exceeds the amount of money it believes A owes, the ripple server can use this credit relationship in a payment exchange for payment routing in either direction. Ripple does payment routing, not account reconciliation.
Changed lines 46-47 from:
* To do: [[Credit Relationship Example With Disputed Balance]] -- perhaps also explain how disagreement is resolved?
to:
* To do: [[Credit Relationship Example With Disputed Balance]]
March 12, 2008, at 03:22 AM by 190.33.59.5 -
Changed line 36 from:
** the balance of payments between the two nodes (kept as two balances in case there is disagreement between the nodes)
to:
** the balance of payments between the two nodes (kept as two balances in case there is disagreement between the nodes) 
Changed lines 42-43 from:

to:
* To do: [[Credit Relationship Example With Disputed Balance]] -- perhaps also explain how disagreement is resolved?
March 08, 2008, at 05:40 PM by 190.33.59.5 -
Deleted line 39:
*  [[CreditRelationshipBalanceExample | Example of account balance and limits in action.]]
Changed lines 41-43 from:
to:
* [[Credit Relationship Example]]

March 08, 2008, at 05:12 PM by 190.33.59.5 -
Changed line 40 from:
*  [[Implementation/CreditRelationshipBalanceExample | Example of account balance and limits in action.]]
to:
*  [[CreditRelationshipBalanceExample | Example of account balance and limits in action.]]
March 08, 2008, at 04:53 PM by 190.33.59.5 -
Added line 44:
* is a payment flow from one credit relationship to another, that passes through a node
Changed lines 48-50 from:
* In either case, node-specific [[Exchange Rates]] are used for the above conversion functions. Here, Node B has an exchange rate table stored for routing payments between all of its neighbors

to:
* In either case, node-specific exchange rates are used for the above conversion functions. So Node B has an exchange rate table stored for routing payments between all of its neighbors
* [[Credit Exchange|Credit Exchange Example]]
March 08, 2008, at 04:42 PM by 190.33.59.5 -
Deleted line 16:
Changed lines 27-30 from:
* can be a payment intermediary, receiving value from one node and passing it along to another as part of a payment chain
** when routing in the same currency, can charge a transaction fee, or can be friendly, and not charge a fee
** when routing between two different currencies, has some conversion rate between the currencies
**  node-specific [[Exchange Rates]] are used for the above conversion functions
to:
* can be a payment intermediary, receiving value from one node and passing it along to another in a [[Credit Exchange]] as part of a payment chain
Added lines 42-49:

'''A Credit Exchange'''
* is a link in a payment chain, say Node A -> Node B -> Node C, where B and C are the previous and successor nodes, and the ultimate payer / payment recipient are at the start and end of the chain: Payer -> ..... -> A -> B -> C -> ..... Recipient
* when routing in the same currency, Node B can charge a transaction fee, or can be friendly and choose not charge a fee
* when routing between two different currencies, Node B has some conversion rate between the currencies
* In either case, node-specific [[Exchange Rates]] are used for the above conversion functions. Here, Node B has an exchange rate table stored for routing payments between all of its neighbors

March 08, 2008, at 04:22 PM by 190.33.59.5 -
Added lines 7-8:
----
Changed lines 16-18 from:
* A party might have many users, or a user might have many parties.
* The ripple server doesn't know anything about users or parties, only nodes.
to:


A party might have many users, or a user might have many parties.
The ripple server doesn't know anything about users or parties, only nodes.

[[Users,Parties, and Nodes]]

----

Changed line 31 from:
**  node-specific [[Credit Relationship Exchange Rates]] are used for the above conversion functions
to:
**  node-specific [[Exchange Rates]] are used for the above conversion functions
Changed line 35 from:
'''A credit relationship'''
to:
'''A Credit Relationship'''
Deleted lines 45-48:

'''A User'''
* a user may interact with the ripple system via a single registered node, or may choose to register multiple nodes, just as an email user might choose to have more than one email address
**
March 08, 2008, at 03:59 PM by 190.33.59.5 -
Changed lines 25-26 from:
* [[Main/UsersPartiesAndNodes|Users, Parties, and Nodes]])
to:
* [[Main/Users, Parties, and Nodes]])
March 08, 2008, at 03:58 PM by 190.33.59.5 -
Changed lines 25-26 from:
* [[Main/UsersPartiesAndNodes|reasons to register multiple Nodes]])
to:
* [[Main/UsersPartiesAndNodes|Users, Parties, and Nodes]])
March 08, 2008, at 03:57 PM by 190.33.59.5 -
Changed lines 24-25 from:
* A ripple party might well send and receive all ripple payments via a single node, but a party might also have [[UsersAndNodes|reasons to register multiple nodes]] (Change link to [[Main/UsersPartiesAndNodes|reasons to register multiple Nodes]])
to:
* A ripple party might well send and receive all ripple payments via a single node, but a party might also have reasons to register multiple nodes
* [[Main/UsersPartiesAndNodes|reasons to register multiple Nodes]])
March 08, 2008, at 03:43 PM by 190.33.59.5 -
Changed lines 24-25 from:
* A ripple party might well send and receive all ripple payments via a single node, but a party might also have [[UsersAndNodes|reasons to register multiple nodes]] (Change link to [[PartiesAndNodes]])
to:
* A ripple party might well send and receive all ripple payments via a single node, but a party might also have [[UsersAndNodes|reasons to register multiple nodes]] (Change link to [[Main/UsersPartiesAndNodes|reasons to register multiple Nodes]])
March 08, 2008, at 03:37 PM by 190.33.59.5 -
Changed line 3 from:
'''A Client'''
to:
'''Client'''
Changed lines 5-6 from:
** See [[Main/RippleClientExamples]]
to:
* [[Main/RippleClientExamples|ripple client examples]]

'''Party'''
* Something or someone that uses ripple to send, receive, and route payments
* Parties can be individuals, or collectives such as a group of friends, an agricultural coop, businesses, governments, banks, etc.

'''User'''
* Users authenticate themselves to a ripple client via username/password, or some other authentication scheme
* Obvious example is people, but could also be a bot or some automated process that knows how to authenticate itself. 
* A party might have many users, or a user might have many parties.
* The ripple server doesn't know anything about users or parties, only nodes.

Changed lines 21-25 from:
** when routing, can charge a transaction fee
**
can be friendly, and not charge a fee
* nodes store [[Credit Relationship Exchange Rates]]. These rates determine transaction fees, if any
, when acting as a payment intermediary
* a ripple user might well register only a single node, but a user might also have [[UsersAndNodes|reasons to register multiple
nodes]]
to:
** when routing in the same currency, can charge a transaction fee, or can be friendly, and not charge a fee
** when routing between two different currencies
, has some conversion rate between the currencies
**  node-specific [[Credit Relationship Exchange Rates]] are used for the above conversion functions
* A ripple party might well send and receive all ripple payments via a single node, but a party might also have [[UsersAndNodes|reasons to register multiple
nodes]] (Change link to [[PartiesAndNodes]])
March 08, 2008, at 03:10 PM by 190.33.59.5 -
Added lines 1-30:
!!!! Definitions

'''A Client'''
* Software that manages accounts that involve lines of credit between parties.
** See [[Main/RippleClientExamples]]

'''A Node'''
* has credit relationships (lines of credit) with other nodes
* can be a payment endpoint, either payer or recipient
* can be a payment intermediary, receiving value from one node and passing it along to another as part of a payment chain
** when routing, can charge a transaction fee
** can be friendly, and not charge a fee
* nodes store [[Credit Relationship Exchange Rates]]. These rates determine transaction fees, if any, when acting as a payment intermediary
* a ripple user might well register only a single node, but a user might also have [[UsersAndNodes|reasons to register multiple nodes]]

'''A credit relationship'''
* exists between two nodes, say node A and node B
* describes a line of credit that node A has with node B, and the reciprocal line of credit node B has with node A
* has a specific unit of value, such as USD, Euro, or oz. of gold
* has an account for each node, each containing the following data:
** the balance of payments between the two nodes (kept as two balances in case there is disagreement between the nodes)
** an upper limit, which is the maximum balance on this account
** a lower limit, which is the minimum balance on this account
* Two nodes connected by a credit relationship are called ''neighbours''.
*  [[Implementation/CreditRelationshipBalanceExample | Example of account balance and limits in action.]]
* Two nodes may have more than one credit relationships connecting them, for instance to allow for credit relationships in more than one currency

'''A User'''
* a user may interact with the ripple system via a single registered node, or may choose to register multiple nodes, just as an email user might choose to have more than one email address
**