diff --git a/content/data_v2.md b/content/data_v2.md index 659ed27525..3221370bde 100644 --- a/content/data_v2.md +++ b/content/data_v2.md @@ -752,7 +752,7 @@ Response: ## Get Account ## -[[Source]
](https://github.com/ripple/rippled-historical-database/blob/develop/api/routesV2/getaccount.js "Source") +[[Source]
](https://github.com/ripple/rippled-historical-database/blob/develop/api/routesV2/getAccount.js "Source") Get creation info for a specific ripple account @@ -1869,7 +1869,7 @@ The `rippled` Historical Database consists of several processes that can be run Command: `node import/live` * [Backfiller](#backfiller) - Populates the database with older ledgers from a `rippled` instance. Command: `node import/postgres/backfill` -* API Server - Provides [REST API access](#usage) to the data. +* API Server - Provides [REST API access](#api-method-reference) to the data. Command: `npm start` (restarts the server automatically when source files change), or `node api/server.js` (simple start) diff --git a/content/gateway_guide.md b/content/gateway_guide.md index 910ca2bc02..2ff4e6631a 100644 --- a/content/gateway_guide.md +++ b/content/gateway_guide.md @@ -178,12 +178,12 @@ Payments going from Ripple to a gateway can be single-currency or cross-currency ### Requirements for Receiving from Ripple ### -In addition to the [requirements for making deposits possible](#deposit-requirements), there are several prerequisites that ACME must meet in order to process payments coming from Ripple: +In addition to the [requirements for sending into Ripple](#requirements-for-sending-to-ripple), there are several prerequisites that ACME must meet in order to process payments coming from Ripple: - ACME must monitor its cold and hot wallet Ripple accounts for incoming payments. - ACME must know which user to credit internally for the incoming payments. - We recommend that ACME should [bounce any unrecognized incoming payments](#bouncing-payments) back to their sender. - - Typically, the preferred method of recognizing incoming payments is through [destination tags](#destination-tags). + - Typically, the preferred method of recognizing incoming payments is through [destination tags](#source-and-destination-tags). ## Precautions ## diff --git a/content/rippled-setup.md b/content/rippled-setup.md index 26ed00845d..9047a804a4 100644 --- a/content/rippled-setup.md +++ b/content/rippled-setup.md @@ -263,9 +263,10 @@ Becoming a validator that participates in the network involves several steps. In ## Domain Verification ## -Network participants are unlikely to trust validators without knowing who is operating them. To address this concern, validator operators can associate their validator with a web domain that they operate. [Publishing a ripple.txt](#ripple.txt) and [setting the validator's account domain](#account-domain) allows services like [validators.ripple.com](https://validators.ripple.com) to detect the domain associated with the validator. +Network participants are unlikely to trust validators without knowing who is operating them. To address this concern, validator operators can associate their validator with a web domain that they operate. [Publishing a ripple.txt](#ripple-txt) and [setting the validator's account domain](#account-domain) allows services like [validators.ripple.com](https://validators.ripple.com) to detect the domain associated with the validator. + +### ripple.txt ### -### ripple.txt ### Publish a [ripple.txt](https://wiki.ripple.com/Ripple.txt) page at your domain with a signed SSL certificate. diff --git a/content/rippled.md b/content/rippled.md index 6861f3edae..eca3509226 100644 --- a/content/rippled.md +++ b/content/rippled.md @@ -26,7 +26,7 @@ https://groups.google.com/forum/#!forum/ripple-server Before you can run any commands against a `rippled` server, you must know which server you are connecting to. Most servers are configured not to accept requests directly from the outside network. -Alternatively, you can [run your own local copy of `rippled`](rippled-setup.html). This is required if you want to access any of the [Admin Commands](#List-of-Admin-Commands). In this case, you should use whatever IP and port you configured the server to bind. (For example, `127.0.0.1:54321`) Additionally, in order to access admin functionality, you must connect from a port/IP address marked as admin in the config file. +Alternatively, you can [run your own local copy of `rippled`](rippled-setup.html). This is required if you want to access any of the [Admin Commands](#list-of-admin-commands). In this case, you should use whatever IP and port you configured the server to bind. (For example, `127.0.0.1:54321`) Additionally, in order to access admin functionality, you must connect from a port/IP address marked as admin in the config file. The [example config file](https://github.com/ripple/rippled/blob/d7def5509d8338b1e46c0adf309b5912e5168af0/doc/rippled-example.cfg#L831-L854) listens for connections on the local loopback network (127.0.0.1), with JSON-RPC (HTTP) on port 5005 and WebSocket (WS) on port 6006, and treats all connected clients as admin. @@ -201,6 +201,7 @@ The response format for commandline methods is identical to JSON-RPC responses, It is impossible to enumerate all the possible ways an error can occur. Some may occur in the transport layer (for example, loss of network connectivity), in which case the results will vary depending on what client and transport you are using. However, if the `rippled` server successfully receives your request, it will try to respond in a standardized error format. Some example errors: +
*WebSocket* @@ -2976,7 +2977,7 @@ The key generated by this method can also be used as a regular key for an accoun The globally-shared ledger is the core of the Ripple Network. Each `rippled` server keeps a current version of the ledger, which contains all the accounts, transactions, offers, and other data in the network in an optimized tree format. As transactions and offers are proposed, each server incorporates them into its current copy of the ledger, closes it periodically, and (if configured) participates in the process of advancing the globally-validated version. After concensus is reached in the network, that ledger version is validated and becomes permanently immutable. Any transactions that were not included in one ledger become candidates to be included in the next validated version. ## ledger ## -[[Source]
](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/Ledger.cpp "Source") +[[Source]
](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/LedgerHandler.cpp "Source") Retrieve information about the public ledger. @@ -5692,7 +5693,7 @@ The request includes the following parameters: #### Response Format #### -If a pathfinding request was successfully closed, the response follows the same format as the initial response to [`path_find create`](#path_find-create). If there was no outstanding pathfinding request, an error is returned instead. +If a pathfinding request was successfully closed, the response follows the same format as the initial response to [`path_find create`](#path-find-create). If there was no outstanding pathfinding request, an error is returned instead. #### Possible Errors #### @@ -5730,7 +5731,7 @@ The request includes the following parameters: #### Response Format #### -If a pathfinding request is open, the response follows the same format as the initial response to [`path_find create`](#path_find-create). If there was no outstanding pathfinding request, an error is returned instead. (Prior to version 0.26, the server erroneously reports success. See [RIPD-293](https://ripplelabs.atlassian.net/browse/RIPD-293) for more information.) +If a pathfinding request is open, the response follows the same format as the initial response to [`path_find create`](#path-find-create). If there was no outstanding pathfinding request, an error is returned instead. (Prior to version 0.26, the server erroneously reports success. See [RIPD-293](https://ripplelabs.atlassian.net/browse/RIPD-293) for more information.) #### Possible Errors #### @@ -6083,11 +6084,11 @@ The following fields are deprecated, and may be omitted: `paths_canonical`, and ## sign ## -[[Source]
](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/Sign.cpp "Source") +[[Source]
](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/SignHandler.cpp "Source") The `sign` method takes a transaction, specified as JSON, and a secret key, and returns a signed binary representation of the transaction that can be submitted. The result is always different, even when you provide the same transaction JSON and secret key. -__*Note:*__ It is possible and preferable to sign a transaction without connecting to a server instead of using this command. For example, [ripple-lib's rsign.js](https://github.com/ripple/ripple-lib/blob/develop/bin/rsign.js) demonstrates offline signing of a transaction. You should prefer to do offline signing of a transaction, especially when you do not control the server you are sending a transaction to. An untrustworthy server can abuse its position to change the transaction before signing it, or worse, use your secret to sign additional arbitrary transactions as if they came from you. +__*Note:*__ It is possible and preferable to sign a transaction without connecting to a server instead of using this command, by using [ripple-lib](https://github.com/ripple/ripple-lib). You should prefer to do offline signing of a transaction, especially when you do not control the server you are sending a transaction to. An untrustworthy server can abuse its position to change the transaction before signing it, or worse, use your secret to sign additional arbitrary transactions as if they came from you. #### Request Format #### An example of the request format: @@ -8347,7 +8348,8 @@ An example of the request format: *Commandline* -```#Syntax: validation_seed [secret] +``` +#Syntax: validation_seed [secret] rippled validation_seed 'BAWL MAN JADE MOON DOVE GEM SON NOW HAD ADEN GLOW TIRE' ``` diff --git a/content/ripplerest_api.md b/content/ripplerest_api.md index 9e31945c6b..7ca9d0aa2d 100644 --- a/content/ripplerest_api.md +++ b/content/ripplerest_api.md @@ -190,7 +190,7 @@ Following that, use these instructions to get Ripple-REST installed and running: `cp config-example.json config.json` 5. Start the server: `npm start` -6. Visit [http://localhost:5990](http://localhost:5990) in a browser to view available endpoints and get started +6. Visit `http://localhost:5990` in a browser to view available endpoints and get started ## Configuring `ripple-rest` ## @@ -990,7 +990,7 @@ The JSON body of the request includes the following parameters: | Field | Type | Description | |-------|------|-------------| | payment | [Payment object](#payment_object) | The payment to send. You can generate a payment object using the [Prepare Payment](#prepare-payment) method. | -| client\_resource\_id | String | A unique identifier for this payment. You can generate one using the [`GET /v1/uuid`](#calculating_a_uuid) method. | +| client\_resource\_id | String | A unique identifier for this payment. You can generate one using the [`GET /v1/uuid`](#create-client-resource-id) method. | | secret | String | A secret key for your Ripple account. This is either the master secret, or a regular secret, if your account has one configured. | | last\_ledger\_sequence | String | (Optional) A string representation of a ledger sequence number. If this parameter is not set, it defaults to the current ledger sequence plus an appropriate buffer. | | max\_fee | String | (Optional) The maximum transaction fee to allow, as a decimal amount of XRP. | @@ -1741,7 +1741,7 @@ The response includes the original [`order`](#order-objects), if the `action` is For transactions that cancel orders, the `order` object describes the transaction that canceled the original order. -The response also includes `balance_changes` and [`order changes`](order-change-objects) +The response also includes `balance_changes` and [`order changes`](#order-change-objects) for the perspective account (e.g., the Ripple account address used in the URI). The `direction` of the transaction is either `incoming`, `outgoing` or `unaffected`. Outgoing transactions are made by the perspective account. Incoming transactions affect the perspective account. @@ -2232,7 +2232,7 @@ The `rippled_server_status` object may have any of the following fields: | load\_factor | Number | The load factor the server is currently enforcing, as a multiplier for the base transaction fee. The load factor is determined by the highest of the individual server’s load factor, cluster’s load factor, and the overall network’s load factor. | | peers | Number | How many other `rippled` servers this server is connected to | | pubkey_node | String | Public key used to verify this node for internal communications; this key is automatically generated by the server the first time it starts up. (If deleted, the node can just create a new pair of keys.) | -| server_state | String | A string indicating to what extent the server is participating in the network. See [Possible Server States in the rippled documentation](rippled-apis#possible-server-states) for more details. | +| server_state | String | A string indicating to what extent the server is participating in the network. See [Possible Server States in the rippled documentation](rippled-apis.html#possible-server-states) for more details. | | validated_ledger | Object | Information about the fully-validated ledger with the highest sequence number (the most recent) | | validated_ledger.age | Unsigned Integer | The time since the ledger was closed, in seconds | | validated_ledger.base_fee_xrp | Number | Base fee, in XRP. This may be represented in scientific notation such as 1e-05 for 0.00005 | diff --git a/content/tx-cost.md b/content/tx-cost.md index 1ec8f85586..94ab634bcc 100644 --- a/content/tx-cost.md +++ b/content/tx-cost.md @@ -17,7 +17,7 @@ The transaction cost is only debited from the sender's XRP balance when the tran When you sign a transaction online, you can omit the `Fee` field. In this case, `rippled` or ripple-lib looks up an appropriate value based on the state of the peer-to-peer network, and includes it before signing the transaction. There are several drawbacks and limitations to this system, however: * If the network's transaction fee goes up between signing and distributing the transaction, the transaction may not be confirmed. - * In the worst case, the transaction may be stuck in a state of being neither definitively confirmed or rejected, unless it included a `LastLedgerSequence` parameter or until you cancel it with a new transaction that uses the same `Sequence` number. See [reliable transaction submission](reliable-tx.html) for best practices. + * In the worst case, the transaction may be stuck in a state of being neither definitively confirmed or rejected, unless it included a `LastLedgerSequence` parameter or until you cancel it with a new transaction that uses the same `Sequence` number. See [reliable transaction submission](reliable_tx.html) for best practices. * If the network's transaction fee is abnormally high, you may end up destroying more of your XRP than expected. You can avoid this by double-checking the details of the signed transaction before submitting it. * If you are using `rippled`, you can also use the `fee_mult_max` parameter of the [`sign` command](rippled-apis.html#sign) to set a limit to the load scaling you will allow. * You cannot look up the fee if you are offline. diff --git a/content/tx_format.md b/content/tx_format.md index e85766f7f6..d2ef06cbfc 100644 --- a/content/tx_format.md +++ b/content/tx_format.md @@ -53,7 +53,7 @@ Typically, you create a transaction in JSON format first. Here is an example of After doing that, you generate the signed binary format for the transaction. There are two ways to do this: 1. Convert it to a binary blob and sign it offline. This is preferable, since it means that the account secret used for signing the transaction is never transmitted over any network connection. - * [rsign.js](https://github.com/ripple/ripple-lib/blob/develop/bin/rsign.js) is a JavaScript implementation of offline signing. + * [ripple-lib](https://github.com/ripple/ripple-lib) has an implementation of offline signing. 2. Have a `rippled` server sign the transaction for you. The [sign command](rippled-apis.html#sign) takes a JSON-format transaction and secret and returns the signed binary transaction format ready for submission. (Transmitting your account secret is dangerous, so you should only do this from within a trusted and encrypted sub-net, to a server you control.) * As a shortcut, you can use the [submit command](rippled-apis.html#submit) with a `tx_json` object to sign and submit a transaction all at once. This is only recommended for testing and development purposes. @@ -176,7 +176,7 @@ Main article: [Reliable Transaction Submission](reliable_tx.html) ### Identifying Transactions ### -The `"hash"` is the unique value that identifies a particular transaction. The server provides the hash in the response when you submit the transaction; you can also look up a transaction in an account's transaction history with the [account_tx command](rippled-apis.html#account_tx). +The `"hash"` is the unique value that identifies a particular transaction. The server provides the hash in the response when you submit the transaction; you can also look up a transaction in an account's transaction history with the [account_tx command](rippled-apis.html#account-tx). The transaction hash can be used as a "proof of payment" since anyone can [look up the transaction by its hash](#looking-up-transaction-results) in order to verify its final status. @@ -334,7 +334,7 @@ Example payment: ### Special issuer Values for SendMax and Amount ### -Most of the time, the `issuer` field of a non-XRP [currency amount](rippled-apis.html#currency-amounts) indicates the account of the gateway that issues that currency. However, when describing payments, there are special rules for the `issuer` field in the `Amount` and `SendMax` fields of a payment. +Most of the time, the `issuer` field of a non-XRP [currency amount](rippled-apis.html#specifying-currency-amounts) indicates the account of the gateway that issues that currency. However, when describing payments, there are special rules for the `issuer` field in the `Amount` and `SendMax` fields of a payment. * There is only ever one balance for the same currency between two accounts. This means that, sometimes, the `issuer` field of an amount actually refers to a counterparty that is redeeming issuances, instead of the account that created the issuances. * When the `issuer` field of the destination `Amount` field matches the `Destination` account address, it is treated as a special case meaning "any issuer that the destination accepts." This includes all accounts to which the destination has extended trust lines, as well as issuances created by the destination which may be held on other trust lines. @@ -529,13 +529,13 @@ Instead of using an account's master key to sign transactions, you can set an al A Regular Key pair is generated in the same way as any other Ripple keys (for example, with [wallet_propose](rippled-apis.html#wallet-propose)), but it can be changed. A Master Key pair is an intrinsic part of the account's identity (the address is derived from the master public key) so the Master Key cannot be changed. Therefore, using a Regular Key to sign transactions instead of the master key whenever possible is beneficial to security. -If your regular key is compromised, but the master key is not, you can use this method to regain control of your account. As a special feature, each account is allowed to perform SetRegularKey transaction *without* a transaction fee as long as the [*lsfPasswordSpent* flag](ripple-ledger.html#accountroot) for the account is not set. To use this feature, submit a SetRegularKey transaction with a `Fee` value of 0, signed by the account's *master key*. (This way, you don't have to worry about whether the attacker has used up all the account's spare XRP.) The [*lsfPasswordSpent* flag]() is automatically cleared if your account receives a payment of XRP. +If your regular key is compromised, but the master key is not, you can use this method to regain control of your account. As a special feature, each account is allowed to perform SetRegularKey transaction *without* a transaction fee as long as the [*lsfPasswordSpent* flag](ripple-ledger.html#accountroot) for the account is not set. To use this feature, submit a SetRegularKey transaction with a `Fee` value of 0, signed by the account's *master key*. (This way, you don't have to worry about whether the attacker has used up all the account's spare XRP.) The [*lsfPasswordSpent* flag](ripple-ledger.html#accountroot) is automatically cleared if your account receives a payment of XRP. ## OfferCreate ## -[[Source]
](https://github.com/ripple/rippled/blob/master/src/ripple/module/app/transactors/CreateOffer.cpp "Source") +[[Source]
](https://github.com/ripple/rippled/blob/master/src/ripple/app/tx/impl/CreateOffer.cpp "Source") An OfferCreate transaction is effectively a [limit order](http://en.wikipedia.org/wiki/limit_order). It defines an intent to exchange currencies, and creates an Offer node in the Ripple Consensus Ledger if not completely fulfilled when placed. Offers can be partially fulfilled. @@ -648,7 +648,7 @@ The following invalid flag combination prompts a temINVALID_FLAG error: ## OfferCancel ## -[[Source]
](https://github.com/ripple/rippled/blob/master/src/ripple/module/app/transactors/CancelOffer.cpp "Source") +[[Source]
](https://github.com/ripple/rippled/blob/master/src/ripple/app/tx/impl/CancelOffer.cpp "Source") An OfferCancel transaction removes an Offer node from the Ripple Consensus Ledger. @@ -675,7 +675,7 @@ The OfferCancel method returns [tesSUCCESS](https://ripple.com/wiki/Transaction_ ## TrustSet ## -[[Source]
](https://github.com/ripple/rippled/blob/master/src/ripple/module/app/transactors/SetTrust.cpp "Source") +[[Source]
](https://github.com/ripple/rippled/blob/master/src/ripple/app/tx/impl/SetTrust.cpp "Source") Create or modify a trust line linking two accounts. diff --git a/index.html b/index.html index 0f07bda49a..f1a1ade2c5 100644 --- a/index.html +++ b/index.html @@ -178,17 +178,6 @@
Middleware
-
-

Gatewayd

-

Framework software for building a gateway—just add the connections to your payment system.

- -
-

Ripple REST

Easily connect with a rippled server using REST: check balances, set trust lines, and more.

diff --git a/tool/check_links.py b/tool/check_links.py index 6b7e9327f1..1947dfc161 100755 --- a/tool/check_links.py +++ b/tool/check_links.py @@ -6,6 +6,18 @@ import os externalCache = [] atRoot = True +broken_links = [] + +soupsCache = {} +def getSoup(fullPath): + if fullPath in soupsCache.keys(): + soup = soupsCache[fullPath] + else: + with open(fullPath, 'r') as f: + soup = BeautifulSoup(f.read(), "html.parser") + soupsCache[fullPath] = soup + return soup + for dirpath, dirnames, filenames in os.walk("../"): if atRoot: dirnames.remove('tool') @@ -13,23 +25,96 @@ for dirpath, dirnames, filenames in os.walk("../"): for fname in filenames: fullPath = os.path.join(dirpath, fname); if fullPath.endswith(".html"): - f = open(fullPath, 'r') - soup = BeautifulSoup(f.read()) + soup = getSoup(fullPath) links = soup.find_all('a') for link in links: + if "href" not in link.attrs: + #probably an type anchor, skip + continue + endpoint = link['href'] - if "://" in endpoint: + if not endpoint.strip(): + print("Empty link in",fullPath) + broken_links.append( (fullPath, endpoint) ) + + elif endpoint == "#": + continue + + elif "mailto:" in endpoint: + print("Skipping email link in %s to %s"%(fullPath, endpoint)) + continue + + elif "://" in endpoint: if endpoint not in externalCache: print("Testing remote URL %s"%(endpoint)) - code = requests.head(endpoint).status_code + try: + code = requests.head(endpoint).status_code + except Exception as e: + print("Error occurred:",e) + code = 500 + if code == 405: + #HEAD not allowed -- does GET work? + try: + code = requests.get(endpoint).status_code + except Exception as e: + print("Error occurred:",e) + code = 500 + if code < 200 or code >= 400: print("Broken remote link in %s to %s"%(fullPath, endpoint)) + broken_links.append( (fullPath, endpoint) ) else: + print("...success.") externalCache.append(endpoint) - elif endpoint[0] == '#': - continue + + + + elif '#' in endpoint: + print("Testing local link %s from %s"%(endpoint, fullPath)) + filename,anchor = endpoint.split("#",1) + if filename == "": + fullTargetPath = fullPath + else: + fullTargetPath = os.path.join(dirpath, filename) + if not os.path.exists(fullTargetPath): + print("Broken local link in %s to %s"%(fullPath, endpoint)) + broken_links.append( (fullPath, endpoint) ) + + elif "-api-tool.html" in fullTargetPath: + #These pages are populated dynamically, so BeatifulSoup wouldn't + # be able to find anchors in them anyway + print("Skipping anchor link in %s to API tool %s" % + (fullPath, endpoint)) + continue + + elif fullTargetPath != "../": + targetSoup = getSoup(fullTargetPath) + if not targetSoup.find(id=anchor) and not targetSoup.find( + "a",attrs={"name":anchor}): + print("Broken anchor link in %s to %s"%(fullPath, endpoint)) + broken_links.append( (fullPath, endpoint) ) + else: + print("...anchor found.") + continue + elif endpoint[0] == '/': + #can't really test links out of the local field + print("Skipping absolute link in %s to %s"%(fullPath, endpoint)) continue + else: if not os.path.exists(os.path.join(dirpath, endpoint)): print("Broken local link in %s to %s"%(fullPath, endpoint)) + broken_links.append( (fullPath, endpoint) ) + +if not broken_links: + print("Success! No broken links found.") +else: + print("%d broken links found:"%(len(broken_links))) + [print("File:",fname,"Link:",link) for fname,link in broken_links] + + #Tempfix: don't consider a failure if the only broken link is + # the SSL validation failure on validators.ripple.com... + if broken_links == [("../rippled-setup.html","https://validators.ripple.com")]: + exit(0) + exit(1) diff --git a/tool/parse_pages.py b/tool/parse_pages.py index ff47675067..aa5c5339a3 100755 --- a/tool/parse_pages.py +++ b/tool/parse_pages.py @@ -17,6 +17,7 @@ import subprocess #Python markdown works instead of pandoc from markdown import markdown +from bs4 import BeautifulSoup #Watchdog stuff import time#, logging @@ -46,7 +47,17 @@ def parse_markdown(md): md = re.sub("(]*)>", add_markdown_class, md) #the actual markdown parsing is the easy part - return markdown(md, extensions=["markdown.extensions.extra", "markdown.extensions.toc"]) + html = markdown(md, extensions=["markdown.extensions.extra", "markdown.extensions.toc"]) + + #replace underscores with dashes in h1,h2,etc. for Flatdoc compatibility + soup = BeautifulSoup(html, "html.parser") + headers = soup.find_all(name=re.compile("h[0-9]"), id=True) + for h in headers: + if "_" in h["id"]: + h["id"] = h["id"].replace("_","-") + + html2 = soup.prettify() + return html2 def get_pages(): print("reading page manifest...") @@ -143,6 +154,8 @@ def watch(pre_parse, pdf): class UpdaterHandler(PatternMatchingEventHandler): def on_any_event(self, event): print("got event!") + if pdf: + make_pdf(pdf) render_pages(pre_parse, pdf) patterns = ["*tool/pages.json","*tool/template-*.html"] @@ -188,7 +201,7 @@ if __name__ == "__main__": #Not an accident that we go on to re-gen files in non-PDF format if args.watch: - watch(args.pre_parse) + watch(args.pre_parse, args.pdf) else: render_pages(args.pre_parse) diff --git a/tool/template-index.html b/tool/template-index.html index 00f965b167..4fdc892186 100644 --- a/tool/template-index.html +++ b/tool/template-index.html @@ -84,17 +84,6 @@
Middleware
-
-

Ripple REST

Easily connect with a rippled server using REST: check balances, set trust lines, and more.