ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-20 19:55:54 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix straggling Ripple rebranding issues (DOC-353)

Browse Source
This commit is contained in:
mDuo13
2016-04-27 17:30:02 -07:00
parent 6cc20f251f
commit dd41593346
6 changed files with 10 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
content/concept-paths.md
View File

@@ -53,7 +53,7 @@ The default path could be any of the following:
* If the transaction is uses only one currency (regardless of issuer), then the default path assumes the payment will ripple through the accounts involved. This path will only work if there are trust lines connecting those accounts.
* If `SendMax` is omitted, or the `issuer` of the `SendMax` is the sender, the default path needs a trust line from the sending `Account` to the `issuer` of the destination `Amount` in order to work.
* If the `SendMax` and `Amount` have different `issuer` values, and neither are the sender or receiver, the default path is probably not useful because it would need to ripple across a trust line between the two issuers. Ripple, Inc. typically discourages issuers from trusting one another directly.
* If the `SendMax` and `Amount` have different `issuer` values, and neither are the sender or receiver, the default path is probably not useful because it would need to ripple across a trust line between the two issuers. Ripple (the company) typically discourages issuers from trusting one another directly.
* For cross-currency transactions, the default path uses the order book between the source currency (as specified in the `SendMax` field) and the destination currency (as specified in the `Amount` field).
The following diagram enumerates all possible default paths:

6
content/reference-rippled.md
View File

@@ -48,7 +48,7 @@ The response comes as a JSON object.
#### Public Servers ####
Currently Ripple Labs maintains a set of public WebSocket servers at:
Currently Ripple (the company) maintains a set of public WebSocket servers at:
| Domain | Port | Notes |
| ------------- | ---- | ----- |
@@ -79,7 +79,7 @@ The response is also a JSON object.
#### Public Servers ####
Currently, Ripple Labs maintains a set of public JSON-RPC servers at:
Currently, Ripple (the company) maintains a set of public JSON-RPC servers at:
| Domain | Port | Notes |
| ------------- | ----- |---|
@@ -3696,7 +3696,7 @@ You must provide either `ledger_index` or `ledger_hash` but not both.
The response follows the [standard format](#response-formatting). However, the request returns a failure response if it does not have the specified ledger _even if it successfully instructed the `rippled` server to start retrieving the ledger_.
**Note:** In order to retrieve a ledger, the rippled server must have a direct peer with that ledger in its history. If none of the peers have the requested ledger, you can use the [`connect` command](#connect) or the `fixed_ips` section of the config file to add Ripple Labs' full-history server at `s2.ripple.com` and then make the `ledger_request` request again.
**Note:** In order to retrieve a ledger, the rippled server must have a direct peer with that ledger in its history. If none of the peers have the requested ledger, you can use the [`connect` command](#connect) or the `fixed_ips` section of the config file to add Ripple's full-history server at `s2.ripple.com` and then make the `ledger_request` request again.
A failure response indicates the status of fetching the ledger. A successful response contains the information for the ledger in a similar format to the [`ledger` command](#ledger).

4
content/tutorial-rippled-setup.md
View File

@@ -55,7 +55,7 @@ There are several properties that define a good validator. The more of these pro
* **Identified**. It should be clear who runs the validator. Ideally, a list of trusted validators should include validators operated by different owners in multiple legal jurisdictions and geographic areas, to reduce the chance that any localized events could interfere with the validator's impartial operation.
* Setting up [Domain Verification](#domain-verification) is a good start.
At present, Ripple, Inc. cannot recommend any validators aside from the 5 core validators run by Ripple, Inc.: these validators are included in the default `rippled` configuration. However, we are collecting data on other validators and building tools to report on their performance. For metrics on the validators currently operating, see [validators.ripple.com](https://validators.ripple.com).
At present, Ripple (the company) cannot recommend any validators aside from the 5 core validators run by Ripple (the company): these validators are included in the default `rippled` configuration. However, we are collecting data on other validators and building tools to report on their performance. For metrics on the validators currently operating, see [validators.ripple.com](https://validators.ripple.com).
# Installing rippled #
@@ -268,5 +268,3 @@ To enable clustering, modify the following sections of your [config file](https:
* Generate a unique seed (using the [`validation_create` command](reference-rippled.html#validation-seed)) for each of your servers, and configure it under the `[node_seed]` section. The `rippled` server uses this key to sign its messages to other servers in the peer-to-peer network. **Note:** This is a different key than the one `rippled` uses to sign ledger proposals for consensus, but it is in the same format.
* Add the public keys (for peer communication) of each of your other servers under the `[cluster_nodes]` section.