f Remove paragraph, exemplary, etc.

Author: tnull

lightning-rapid-gossip-sync/src/lib.rs

@@ -17,33 +17,29 @@
 //! data. The gossip data is formatted compactly, omitting signatures and opportunistically
 //! incremental where previous channel updates are known. This mechanism is enabled when the
 //! timestamp of the last known channel update is communicated. A reference server implementation
-//! can be found [here](https://github.com/lightningdevkit/rapid-gossip-sync-server).
+//! can be found [on Github](https://github.com/lightningdevkit/rapid-gossip-sync-server).
 //!
 //! The primary benefit of this syncing mechanism is that it allows a low-powered client to offload
 //! the validation of gossip signatures to a trusted server. This enables the client to privately
 //! calculate routes for payments, and to do so much faster than requiring a full peer-to-peer
 //! gossip sync to complete.
 //!
-//! The reason the rapid sync server requires trust is that it could provide bogus data, though, at
-//! worst, all that would result in is a fake network topology, which wouldn't enable the server to
-//! steal or siphon off funds. It could, however, reduce the client's privacy by forcing all
-//! payments to be routed via channels the server controls.
-//!
 //! The server calculates its repsonse on the basis of a client-provided `latest_seen` timestamp,
 //! i.e., it will return all rapid gossip sync data it has seen after the given timestamp.
 //!
 //! # Getting Started
-//! Firstly, the data needs to be retrieved from the server. An examplary server request could look
-//! as simple as the following. Note that the first ever rapid sync should use `0` for
-//! `last_sync_timestamp`:
+//! Firstly, the data needs to be retrieved from the server. For example, you could use the server
+//! at <https://rapidsync.lightningdevkit.org> with the following request format:
 //!
 //! ```shell
 //! curl -o rapid_sync.lngossip https://rapidsync.lightningdevkit.org/snapshot/<last_sync_timestamp>
 //! ```
+//! Note that the
+//! first ever rapid sync should use `0` for `last_sync_timestamp`.
 //!
-//! Then, one of the client's graph processing functions need to be called. In this example, we
-//! process the update by reading its contents from disk, which we do by calling the
-//! `sync_network_graph_with_file_path` method:
+//! After the gossip data snapshot has been downloaded, one of the client's graph processing
+//! functions needs to be called. In this example, we process the update by reading its contents
+//! from disk, which we do by calling [sync_network_graph_with_file_path]:
 //!
 //! ```
 //! use bitcoin::blockdata::constants::genesis_block;
@@ -63,6 +59,7 @@
 //! let rapid_sync = RapidGossipSync::new(&network_graph);
 //! let new_last_sync_timestamp_result = rapid_sync.sync_network_graph_with_file_path("./rapid_sync.lngossip");
 //! ```
+//! [sync_network_graph_with_file_path]: RapidGossipSync::sync_network_graph_with_file_path
 
 // Allow and import test features for benching
 #![cfg_attr(all(test, feature = "_bench_unstable"), feature(test))]
@@ -84,9 +81,7 @@ mod error;
 /// Core functionality of this crate
 mod processing;
 
-/// The main Rapid Gossip Sync object. See the [crate-level documentation] for a usage example.
-///
-/// [crate-level documentation]: crate
+/// The main Rapid Gossip Sync object.
 pub struct RapidGossipSync<NG: Deref<Target=NetworkGraph<L>>, L: Deref>
 where L::Target: Logger {
 	network_graph: NG,