Pages

https://ripple.com/build/historical-database-api-tool/#get-account-transaction-history
https://ripple.com/build/historical-database-api-tool/#get-transaction-by-account-and-sequence
https://ripple.com/build/historical-database-api-tool/#get-transaction
https://ripple.com/build/historical-database-api-tool/#get-ledger

contain text: "https://api.ripple.com" instead of "https://history.ripple.com".

HTTP GET requests like:

https://api.ripple.com/v1/ledgers/3170DA37CE2B7F045F889594CBC323D88686D2E90E8FFD2BBCD9BAD12E416DB5?transactions=true&binary=false&expand=true

don't work.

The xrp-ledger.toml checker can do domain verification for an account if you give it a URL, but (as Markus T. mentioned) it would be really cool to do lookups the other way—enter an XRP Ledger address, look up the Domain associated with that address (in the mainnet or test net) and then check the xrp-ledger.toml file associated with it.

Pages like

https://ripple.com/build/websocket-tool/#server_state

show the option "server_info" on the left side.

But this option (link) is not clickable. Cursor doesn't change when I hover over it.

I can click on the right part of letter "o" (last character of text "server_info").

Browsers: Chrome 41.0.2272.101 m and Firefox 36.0.1.

XRP as a name is often used, but on https://developers.ripple.com/xrp.html the explanation what XRP actually stands for (an ISO 4217 compatible code for "Ripple credits/ripples", "1 XRP is one ripple") as well as the inventor of the "drop" name (ThePiachu in https://forum.ripple.com/viewtopic.php?f=1&t=40&p=228 - they might have even been called "Jeds" otherwise) is missing.

Currently there's some info about currency formatting in two different places. This info should be merged into one location/section. Current locations:

• Basic Data Types#Currencies
• Currency Formats

1. Move details about how to specify currencies to the same location.
   • Make sure all the links (including the common link defs are adjusted to match the new location
2. Move details on the serialization format (including diagrams) to the serialization page.
3. Make the serialization diagrams formatted consistently with the other diagrams — for example, using a plain box to outline the object with text floating above it, rather than using the "package" block type with the name in the little folder-tab-thingie

According to

https://wiki.ripple.com/Ripple.txt

there should be a ripple.txt validator at

https://ripple.com/tools/txt/

But instead of a validator I get a nice picture of JoelKatz and 404.

We should update the templates for doc pages to provide metadata for apps such as Facebook, Slack, Twitter, and others to present when they "unfurl" a link.

The Slack Developer Blog post on unfurling contains a bunch of the relevant technical info on the kinds of properties you can provide to improve link unfurling.

We don't want to do a separate oEmbed server, but there's a lot of room to provide more info via <meta> tags in the HTML, following the Facebook OpenGraph, Twitter cards, etc. standards.

We have a great existing guide on how to assign a regular key pair but we don't have a tutorial for disabling the master key pair.

Disabling the master key is an important part of key rotation if you suspect your master keys are compromised, such as in case of a hack / network intrusion or due to something like the attack described in the "Biased Nonce Sense" paper. It's also necessary to disable your master key if you want to make an account multisign-only.

This article should:

• Describe the prerequisites for disabling the master key pair, such as setting up a regular key and/or a signerlist. (Those tutorials already exist, so this article can link them.)
• Include step-by-step instructions for disabling a master key pair.
• Include sufficient warnings about the risks of disabling the master key pair.
  • Possibly describe how to "blackhole" an account, either intentionally or accidentally.
• Link back to the Cryptographic Keys article for notes on why you might do this or how to understand the context around the tutorial.
• Update other articles to link to it appropriately. For example:
  • The "disable it" link in the warning here can change to go to the new tutorial
  • The tutorial should be added to the "Explore next steps" tutorials for Assign a Regular Key Pair and Set Up Multi-Signing. (Feel free to tweak those two tutorials to be styled a little more consistently, too, if you have time to spend on it.)

Bonus points: Make it an interactive tutorial with working examples that actually do these things with a Test Net account

As pointed out in XRPLF/rippled#2856, we should improve the get_counts documentation (see https://developers.ripple.com/get_counts.html) to explain what these fields mean and how a server operator can interpret them.

I don't think they are quite right, or I'm not interpreting them quite right. Please see: XRPLF/xrpl.js#431 (comment)

See tx C26C0FD55DC0EAED8EF1193C5BED8B83D603D71C804B2999E18A3CED9F91E91D for example.

On this page:
https://developers.ripple.com/build-run-rippled-macos.html

You have this written for step 6:

6. Install Boost 1.67.0. rippled 1.2.0 is compatible with Boost 1.67.
    1. Download Boost 1.67.0 .
    2. Extract it to a folder. Be sure to note the location.
    3. In a terminal, run:
        ./bootstrap.sh
        ./b2 cxxflags="-std=c++14"

Step 3 won't work unless you are inside of your boost directory. I propose changing step 3 to something like this:

    3. In a terminal, run:
        $ cd location/of/your/boost/directory
        ./bootstrap.sh
        ./b2 cxxflags="-std=c++14"
        

This would require a change to line 34 in this file:

ripple-dev-portal/content/tutorials/manage-the-rippled-server-installation/build-run-rippled-macos.md

Description of QualityIn and QualityOut fields is very short and vague ("Value(?) incoming balances"):

https://developers.ripple.com/trustset.html

This page

https://web.archive.org/web/20150422102043/https://wiki.ripple.com/Trust_line_quality

contains an explanation but it is deprecated.

(I edited the Trust Line Quality link to use the wayback machine instead of the broken wiki. --@mDuo13)

(I edited the TrustSet link to point directly to the doc page on developers.ripple.com. The old ripple.com/build link redirected to the Transaction Formats hub page. -- @jhaaaa)

I have followed the instructions, when I run dactyl_build I get an error stack and all are Python files, nothing from my current build, the error ends with the following, which I know is related to character map, but not sure how to solve it:

...
appdata\local\programs\python\python36\lib\encodings\cp1252.py", line 23, in decode
return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 7051: character maps to

Introduced in XRPLF/rippled#835

For example, on

https://ripple.com/build/rest-tool/#sign-transaction

it should be possible to change the server address (to testnet server, for example).

See https://github.com/ripple/rippled/blob/112a863e7346793234c973e97818ced4c6e36867/src/ripple/app/tx/impl/PayChan.cpp#L235-L236

See https://github.com/ripple/rippled/blob/35fa20a110e3d43ffc1e9e664fc9017b6f2747ae/src/ripple/app/tx/impl/Change.cpp#L106-L203

https://data.ripple.com/v2/exchange_rates/XRP/USD+rMwjYedjc7qqtKYVLiAccJSmCwih4LnE2q

https://data.ripple.com/v2/normalize?amount=2000&currency=XRP&exchange_currency=USD&exchange_issuer=rMwjYedjc7qqtKYVLiAccJSmCwih4LnE2q

Why are these endpoints not documented? Are you planning to remove them?

See screenshot of

https://ripple.com/build/rest-tool/#sign-transaction

Sometimes it opens when I click several times on it.

Thank you very much!

API command ripple_path_find (and probably other commands) returns paths that contain fields "type" and "type_hex". But the values of these two fields are not documented.

For example:

"paths_computed": [
          [
            {
              "account": "rBycsjqxD8RVZP5zrrndiVtJwht7Z457A8",
              "type": 1,
              "type_hex": "0000000000000001"
            },
            {
              "currency": "XRP",
              "type": 16,
              "type_hex": "0000000000000010"
            },
            {
              "currency": "BTC",
              "issuer": "rMwjYedjc7qqtKYVLiAccJSmCwih4LnE2q",
              "type": 48,
              "type_hex": "0000000000000030"
            }
          ],

Hi Team,

I hope, You are doing Great.I have generated XRP address using to ripple-lib lib. (address, secret, public key, private key).I am not able to transfer coin. I am getting error which says that it needs destination tab I need to help.
--------------------------error---------------------------
1D1C42DEF57B6EF068C53BA75D8906E69DA03CFABB2E437C7589040FF4D0C17A
{
"resultCode": "tecNO_DST_INSUF_XRP",
"resultMessage": "Destination does not exist. Too little XRP sent to create it."
}

Steps:

1. Open Microsoft Edge and go to https://www.websocket.org/echo.html
2. Enter: wss://s.altnet.rippletest.net:51233
3. press Connect
4. JavaScript console logs the following error: WebSocket Error: Incorrect HTTP response. Status code 403, Forbidden

This works in Chrome. This also works if I use wss://s1.ripple.com:51233/

Translation Plans

We would like to translate the XRP Ledger Dev Portal to several languages, starting with Japanese. In each case, we will add translated pages piecemeal as they become available.

This page describes how we would organize and present the translated content.

User Experience

Users browsing the dev portal receive the English language version by default. When a page is available in other languages, a section in the right sidebar (next to the "In this Page" listing) indicates which languages it is available in. Each language name is presented in its native language. For example, the sidebar would list "Español", not "Spanish".

When a user clicks a language in the sidebar, it takes them to an alternate-language version of the same page in the same site. The URL of the language pages changes to include a language code per IETF BCP47. For example, "en" for English, "es" for Spanish, "ja" for Japanese, "zh-CN" for Simplified Chinese, "zh-TW" for Traditional Chinese (as used in Taiwan), and so on.

Pages in the alternate-language version of a site retain their (english, ASCII) HTML filenames. For example:

English: https://developers.ripple.com/xrp-ledger-overview.html
Japanese: https://developers.ripple.com/ja/xrp-ledger-overview.html

English is the default because we are creating most if not all documents in English originally. Optionally we can set up a redirect on the web server to go from /en/* to /*.

While a user is viewing an alternate-language version of a site, all links to other documents go to the same-language versions if available. If those versions are not available, it falls back to an English-language version of the page with the foreign-language prefix. This allows a path from two translated pages to pass through an untranslated page. For example:

"Introduction" (ja version) → "Transaction Censorship Detection" (not translated; falls back to English) → "rippled Server Modes" (ja version)

Future feature: When a user is viewing an untranslated (that is, English-language) page from a non-English language view, the sidebar has a "Translate this page" link. This link leads to a GitHub editor where the user can create a translation of the page, using the English language source Markdown as a starting point. Or, if that's too difficult, the link goes to a set of instructions for how to contribute a translation.

Source Files

I propose a convention of keeping translated Markdown source files in the same folder as their untranslated counterparts, using the same file name except that the file extension is .{lang}.md instead of just .md, where {lang} is the langauge code. For example, xrp-ledger-overview.ja.md for Japanese and xrp-ledger-overview.zh-CN.md for Simplified Chinese.

Future feature: A "translation freshness checker" script could list all translated files that have been modified less recently than their English-language counterparts. (This doesn't necessarily mean those files are out of date, as the fixes may be English-specific, but it provides a starting point for finding translations that need to be refreshed.)

dactyl-config.yml Changes

The "local" target will be renamed "en".

The first time a translation in a new language is made available, we create a new target whose short name is the language code for that language. The display name for the target is "XRP Ledger Dev Portal" followed by the display name of the language in parentheses. For example, for Japanese, the target's short name would be "ja" and the display name would be "XRP Ledger Dev Portal (日本語)". Each target will also have a lang property with the short name of the language.

When we create a new target, we add all untranslated pages from the "en" target to the new target. For translated pages, we add separate entries to the pages array that are used only by their language target.

Example:

    # English-language version of a translated page
    -   md: concepts/introduction/xrp-ledger-overview.md
        html: xrp-ledger-overview.html
        funnel: Docs
        doc_type: Concepts
        category: Introduction
        blurb: Get a quick and concise introduction to key features of the XRP Ledger.
        targets:
            - en

    # Japanese-language version of a translated page
    -   md: concepts/introduction/xrp-ledger-overview.ja.md
        html: xrp-ledger-overview.html
        funnel: Docs
        doc_type: Concepts
        category: Introduction
        blurb: TODO: Japanese blurb
        targets:
            - ja

    # English version of an untranslated page
    -   md: concepts/introduction/intro-to-consensus.md
        html: intro-to-consensus.html
        funnel: Docs
        doc_type: Concepts
        category: Introduction
        blurb: Develop a basic understanding of the XRP Ledger's consensus mechanism.
        targets:
            - en
            - ja # Use the English version until it's translated.

Build System Changes

Each supported language is built as a separate target. Therefore, the deploy process must build each of them. After building English, the build/deploy system builds each other language to a subfolder of the target output folder, rather than building them to the target output folder directly.

Non-English targets use the same static content as the English-language version of the site. (They may reference differently-named image files, but those image files are stored in a single img/ folder that is shared across all translations.) Therefore, when building non-English targets, the build system uses the --no_static or -S flag of dactyl_build to skip copying the static content additional times.

The "all target link checker" script will need to be updated to build all language targets, then run the link checker once on the compiled output.

Template Changes

The templates will need several modifications to support various languages.

The base template will add appropriate meta tags and attributes to mark the language of the page.

When building any non-English tag, the path to the static assets must change to be based on the parent (English) directory rather than the current directory.

The document templates will need to be modified to display alternate translations of the page, probably in the right sidebar next to the "In this Page" content.

Graphics in Translations

Translated graphics can use the same file extension convention as Markdown source files. For example, a PNG file translated to Spanish would use the file extension .es.png, and would be stored alongside the English-language version in the img/ folder.

Because the translated pages are served from subdirectories, any references in their content Markdown to diagrams must use the parent (English) directory as a base for their paths.

The target definition for non-English languages can use a new custom Dactyl filter to automatically adjust source files so that diagrams can be linked similarly regardless of language. This way, the path to un-translated graphics is consistent across languages.

For example:

English: img/anatomy-of-a-ledger-complete.png
Japanese: img/anatomy-of-a-ledger-complete.ja.png → ../img/anatomy-of-a-ledger-complete.ja.png

(The → indicates the transformation that would be handled automatically by the filter.)

Hi Team,
I hope you are doing well. I have to generate an XRP address. I have Save XRP address and public key, private key save but secret loss so how can I get the secret key by using public key and private key. I need to help.

Here: https://ripple.com/build/transactions/

Especially it should be clear that value, currency and issuer in Amount object need to be in lower case.

https://ripple.com/blog/implementing-the-interledger-protocol/

At the bottom of the page is a link to the https://interledger.org/ , but this link doesn't work.

It is not clear how node_size is supposed to influence the amount of memory consumed by rippled.

Existing documentation looks outdated.

Since the most prevalent cloud server now is Debian/Ubuntu (see links below), and the latest packages appear on Debian/Ubuntu (which developers need) could you please provide a native Debian installation under apt-get?

Note: I tried to install the yum-utils for the Debian version but yum-utils does not exist on the apt-get repository. I tried also downloading the yum-utils.deb package directly, but it does not have any ./config or installation instructions.

W3TECHS - https://w3techs.com/technologies/details/os-linux/all/all
Ubuntu - 34.1%
Debian - 31.4%
CentOS - 20.6%
Red Hat - 3.7%
Gentoo - 2.7%

W3COOK - http://www.w3cook.com/os/ubuntu
Ubuntu - 29.9%
CentOS - 24.57%
Debian - 11.31%
Fedora - 0.68%
Red Hat - 0.01%

THE CLOUD MARKET - http://thecloudmarket.com/stats
Ubuntu - 57.5%
Windows - 7.8%
Red Hat - 4.8%
CentOS - 3.7%
Fedora 1.4%

OPENSTACK - http://www.openstack.org/assets/survey/April-2016-User-Survey-Report.pdf (Page 47)
Ubuntu - 55% (With an potential growth of up to 19%)
CentOS - 20% (With an potential growth of up to 7%)
Red Hat - 16% (With an potential growth of up to 4%)
SUSE - 2% (With an potential growth of up to 1%)
Debian - 3% (With an potential growth of up to 0%)

The instructions in this document (https://developers.ripple.com/run-rippled-as-a-validator.html#connect-using-public-hubs) can leave a validator without connectivity. The public hubs are meant for bootstrapping, and not for [ips_fixed] in conjuction with [peer_private] as 1.

If, for any reason, the hubs are unable to provide a slot to the validator and these are the only two entries in [ips_fixed], the validator will be left with no connectivity. This is because [peer_private] will enforce connections being made to only the entries in [ips_fixed].

I think both these sections can be commented out, and should only be used if the validator has their own proxy(s) in front.

The payment transaction type documented here appears to include a duplicate:

destination. address | address | The address to receive at.
destination. address | address | The address to send to.

Default example at:

https://ripple.com/build/rest-tool/#sign-transaction

returns "400 Bad Request":

{
  "success": false,
  "error_type": "invalid_request",
  "message": "Invalid secret",
  "error": "restINVALID_PARAMETER"
}

HI,

Im creating a test account using test faucet.

curl -s -X POST https://faucet.altnet.rippletest.net/accounts

{"account":{"secret":"shgwzzmyf5QHhTnrnFNK62YfPapkx","address":"rhHjQnUsKDHxi5M15a56gryus7YYJUqn1p"},"balance":10000}

but when Im trying to get the account information using the test network (https://s.altnet.rippletest.net:51234) Im getting "account not found error"

It is now https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg, not https://github.com/ripple/rippled/blob/master/doc/rippled-example.cfg any more.

Hi Team,
I hope, You are All doing Great. The resolution that you gave is working. But only the problem is for sending 20 XRP one should have atleast 20 XRP in reserve in the wallet. please tell me how to send my whole XRP balance in another wallet.

Value of parameter limit seems to be clamped, but this is not documented.

For example,

https://data.ripple.com/v2/exchanges/XRP/USD+rMwjYedjc7qqtKYVLiAccJSmCwih4LnE2q?interval=1hour&format=csv&limit=100000

returns only 1000 results and you cannot get more results because in this case API doesn't return 'marker'.

https://ripple.com/build/rippled-apis/#ledger, see the cpp code for how it works.

Nothing critical here, but in case it has been missed... I am seeing pages which show request formats for JSON-RPC and Commandline, but are missing output formats.

Without running them, it's unclear whether there is anything different about running these and the websocket implementation, or if the docs are simply incomplete. (Of course I can run them, but just communicating the first impression of someone consuming the docs)

I went through the first 3 sections. These all have Websocket outputs defined, but are missing either JSON-RPC, Commandline, or both for output formats.

Account

• https://developers.ripple.com/account_info.html
• https://developers.ripple.com/account_objects.html
• https://developers.ripple.com/account_offers.html
• https://developers.ripple.com/account_tx.html

Ledger

• https://developers.ripple.com/ledger.html
• https://developers.ripple.com/ledger_closed.html
• https://developers.ripple.com/ledger_current.html
• https://developers.ripple.com/tx.html
• https://developers.ripple.com/ledger_entry.html

Transactions

• https://developers.ripple.com/submit_multisigned.html
• https://developers.ripple.com/transaction_entry.html
• https://developers.ripple.com/tx.html
• https://developers.ripple.com/tx_history.html

In case anyone is interested for a simple example in Go

https://developers.ripple.com/monitor-incoming-payments-with-websocket.html

package main

// Connect to the XRPL Ledger using websocket and subscribe to an account
// translation from the JavaScript example to Go
// https://developers.ripple.com/monitor-incoming-payments-with-websocket.html
// This example uses the Gorilla websocket library to create a websocket client
// install: go get github.com/gorilla/websocket

import (
	"encoding/json"
	"flag"
	"log"
	"net/url"
	"os"
	"os/signal"
	"time"

	"github.com/gorilla/websocket"
)

// websocket address
var addr = flag.String("addr", "s.altnet.rippletest.net:51233", "http service address")

// Payload object
type message struct {
	Command  string   `json:"command"`
	Accounts []string `json:"accounts"`
}

func main() {
	flag.Parse()
	log.SetFlags(0)

	var m message

	// check for interrupts and cleanly close the connection
	interrupt := make(chan os.Signal, 1)
	signal.Notify(interrupt, os.Interrupt)

	u := url.URL{Scheme: "ws", Host: *addr, Path: "/"}
	log.Printf("connecting to %s", u.String())

	// make the connection
	c, _, err := websocket.DefaultDialer.Dial(u.String(), nil)
	if err != nil {
		log.Fatal("dial:", err)
	}
	// on exit close
	defer c.Close()

	done := make(chan struct{})

	// send a subscribe command and a target XRPL account
	m.Command = "subscribe"
	m.Accounts = append(m.Accounts, "rUCzEr6jrEyMpjhs4wSdQdz4g8Y382NxfM")

	// struct to JSON marshalling
	msg, _ := json.Marshal(m)
	// write to the websocket
	err = c.WriteMessage(websocket.TextMessage, []byte(string(msg)))
	if err != nil {
		log.Println("write:", err)
		return
	}

	// read from the websocket
	_, message, err := c.ReadMessage()
	if err != nil {
		log.Println("read:", err)
		return
	}
	// print the response from the XRP Ledger
	log.Printf("recv: %s", message)

	// handle interrupt
	for {
		select {
		case <-done:
			return
		case <-interrupt:
			log.Println("interrupt")

			// Cleanly close the connection by sending a close message and then
			// waiting (with timeout) for the server to close the connection.
			err := c.WriteMessage(websocket.CloseMessage, websocket.FormatCloseMessage(websocket.CloseNormalClosure, ""))
			if err != nil {
				log.Println("write close:", err)
				return
			}
			select {
			case <-done:
			case <-time.After(time.Second):
			}
			return
		}
	}
}

The sign method has the following parameter restrictions, however they are not documented in sign_for, which uses the same parameters.

I didn't want to open a PR because I wasn't sure if it was intentional, or missed.

• secret cannot be used with key_type, seed, seed_hex, passphrase
• seed must also have key_type and cannot be used with secret, seed_hex, passphrase
• seed_hex must also have key_type and cannot be used with secret, seed, passphrase
• passphrase must also have key_type and cannot be used with secret, seed, seed_hex
• key_type cannot be used with secret

The existing documentation of source/destination tags is in the gateway guide:

• About Source & Destination Tags
• Generating Source & Destination Tags - which also mentions why you should set the RequireDest flag

We should adapt these contents to be stand-alone articles about destination tags, including info on how they apply to other use cases (like exchanges). The docs should be split up into concept and tutorial articles (similar to how they're broken up now) that link to each other and further relevant articles.

We are making some non-trivial changes to our package repository build and infrastructure for the upcoming 1.3 release, so the docs need to change. I'll try to summarize here, but we'll probably have an ongoing discussion as we try to flesh-out the details.

For both package types, I think we need to advise that users do a manual upgrade from 1.2, which means:

• stop rippled
• Backup DATA AND CONFIG FILES - the location of the config is probably /opt/ripple/etc/rippled.cfg, but might be somewhere else if they moved it. The validators.txt file in the same location should be saved too. The data directory depends on their config/setup. All data directory files should be saved, including the node-db files.
• uninstall the previous package. For rpm packages, this probably involves rpm -e rippled. For things installed via alien on ubuntu, maybe there is an alien uninstall, or just use rpm? (TBD)
• install 1.3 as described below
• restore data and config files to desired location.
• NOTE: If you are just running a stock server with no config tweaks and don't care about the data you had before upgrade, then the data/config backup step is not needed.

These steps are specific to the 1.2-->1.3 upgrade. Future versions past 1.3 should not require these manual backup/restore steps.

rpm installation

The repository and instructions for using it have changed. The steps are now something like:

<with sudo:>
yum -y update
yum -y install yum-utils
cat << REPOFILE > /etc/yum.repos.d/ripple.repo
[ripple-stable]
name=XRP Ledger Packages
baseurl=https://repos.ripple.com/repos/rippled-rpm/stable/
enabled=1
gpgcheck=0
gpgkey=https://repos.ripple.com/repos/rippled-rpm/stable/repodata/repomd.xml.key
repo_gpgcheck=1
REPOFILE
yum -y update
yum -y install rippled

(important note: the name used above [ripple-stable] is important in order for the update script we provide to work properly - it relies on this naming scheme specifically)

The system enable/start steps in the existing instructions can remain.

deb package installation

We now have a native debian package - no more alien involved. The steps are:

<with sudo:>
apt -y update
apt -y install apt-transport-https ca-certificates wget gnupg
wget -q -O - "https://repos.ripple.com/repos/api/gpg/key/public" | apt-key add -
# Fingerprint: C001 0EC2 05B3 5A33 10DC 90DE 395F 97FF CCAF D9A2
echo "deb https://repos.ripple.com/repos/rippled-deb <DISTRO> stable" > /etc/apt/sources.list.d/ripple.list
apt -y update
apt-get -y install rippled

Note: <DISTRO> above is one of:

• xenial (for ub 16.04)
• bionic (for ub 18.04)
• stretch (for debian stable/9)

These are currently the only distros we support, but that list will change in the future as we choose to add more debian distros.

I believe the daemon will start automatically after installation with deb - but this needs to be confirmed. If it does not, then we can duplicate the systemctl steps from the rpm instructions.

automatic or manual updates

An update script is installed at /opt/ripple/bin/update-rippled.sh. This script can be invoked manually, or via cron. We provide a crontab file in /opt/ripple/etc/update-rippled-cron which can be enabled by creating a symlink to this file in /etc/cron.d

For manual updates on both distros, I think we can just recommend that users run the update script manually, as needed.

This is one of the most clearly-explained documentation centres I've ever seen. But it's also visually "utilitarian" to the point it actually becomes difficult to read and navigate. The previous developer centre ("build") was better in this regard.

For the benefit of coders who may need to switch regularly between the ripple dev portal, Sublime Text, other IDE's and Shell Terminals, could design work also incorporate an (optional) Dark Theme?

Polls I found on the subject showed a consistent preference for Darkness.

Rippled now requires Boost 1.67 or later due to Beast getting into that release. We should update the docs here and also audit other tutorials so that they reference the right minimum Boost version.

Please add specs at least for transactions.

The example for getTransactions returns an error:
[MissingLedgerHistoryError(Server is missing ledger history in the specified range)]

However, all fields in options are marked as Optional. Which of the fields are required?

Is there any way to learn when the API changes? i.e. when methods are added/deprecated, or parameters are changed.

As I go through the API documentation and find a mix of deprecated arguments, methods, or badges indicating the version a particular method became available, I am seeing the need for an organization relying on the API directly, or a developer maintaining wrapper libraries, to know when changes are made.

If there's something in place, I'd recommend adding documentation about it, perhaps in the API Conventions doc.

An email list where devs can be notified when changes occur would be extremely helpful as well. I think it's especially important to address due to the nature of the API in that it manages both value and trust.

https://xrpl.org/peer-protocol.html#configuring-a-private-server is the start of a tutorial for how to configure your server as a private peer. However, it could really stand to be improved.

The existing docs for configuring a validator to Connect to the network with proxies is almost exactly what this guide should describe. In fact, it might be best to use that as a starting point, then replace that with a link to the resulting doc.

The doc should include:

• Step by step information (prerequisites, what file to edit, when to restart the server, etc.)
• Describe the recommended (and other possible) network infrastructure, with diagrams and text.

Hello. I have question.
How do I create a i18n document?
Have a nice day~