GITBOOK-237: change request with no subject merged in GitBook

Author: Mayank Pandey

Diff for: SUMMARY.md

@@ -19,18 +19,18 @@
   * [UI Settings](configuration/ui-settings.md)
   * [HTTP Transfer limit](configuration/http-transfer-limit.md)
   * [Deal Filters](configuration/deal-filters.md)
+  * [Remote CommP](configuration/remote-commp.md)
 * [Backup and Restore](backup-and-restore.md)
 * [Tutorials](tutorials/README.md)
   * [How to store files with Boost on Filecoin](tutorials/how-to-store-files-with-boost-on-filecoin.md)
   * [Using filters for storage and retrieval deals](tutorials/using-filters-for-storage-and-retrieval-deals.md)
   * [Setting up a monitoring stack for Boost](tutorials/setting-up-a-monitoring-stack-for-boost.md)
 * [Bitswap Retrieval](bitswap-retrieval.md)
 * [HTTP Retrieval](http-retrieval.md)
-* [GraphQL API](graphql-api.md)
-* [Remote CommP](remote-commp.md)
 * [Troubleshooting](troubleshooting.md)
 * [Experimental Features](experimental-features/README.md)
   * [FVM Contract Deals](experimental-features/fvm-contract-deals.md)
+* [GraphQL API](graphql-api.md)
 * [JSON-RPC API](json-rpc-api.md)
 * [FAQ](faq.md)
 * [Need help?](need-help.md)

Diff for: boost-architecture/libp2p-protocols.md

@@ -4,7 +4,7 @@ Boost supports the same libp2p protocols as legacy markets, and adds new version
 
 ## Propose Storage Deal Protocol
 
-The client makes a deal proposal over `v1.2.0` of the Propose Storage Deal Protocol: `/fil/storage/mk/1.2.0`
+The client makes a deal proposal over `v1.2.0` or `v1.2.1` of the Propose Storage Deal Protocol: `/fil/storage/mk/1.2.0` or `/fil/storage/mk/1.2.1`
 
 It is a request / response protocol, where the request and response are CBOR-marshalled.
 
@@ -13,7 +13,7 @@ There are two new fields in the Request of `v1.2.1` of the protocol, described i
 ### Request
 
 | Field                       | Type               | Description                                                                                        |
-|-----------------------------|--------------------|----------------------------------------------------------------------------------------------------|
+| --------------------------- | ------------------ | -------------------------------------------------------------------------------------------------- |
 | DealUUID                    | uuid               | A uuid for the deal specified by the client                                                        |
 | IsOffline                   | boolean            | Indicates whether the deal is online or offline                                                    |
 | ClientDealProposal          | ClientDealProposal | Same as `<v1 proposal>.DealProposal`                                                               |
@@ -22,8 +22,8 @@ There are two new fields in the Request of `v1.2.1` of the protocol, described i
 | Transfer.ClientID           | string             | Any id the client wants (useful for matching logs between client and server)                       |
 | Transfer.Params             | byte array         | Interpreted according to `Type`. eg for "http" `Transfer.Params` contains the http headers as JSON |
 | Transfer.Size               | integer            | The size of the data that is sent across the network                                               |
-| SkipIPNIAnnounce (v1.2.1)   | boolean            | Whether the provider should announce the deal to IPNI or not  (default: false)                     |
-| RemoveUnsealedCopy (v1.2.1) | boolean            | Whether the provider should keep an unsealed copy of the deal  (default: false)                    |
+| SkipIPNIAnnounce (v1.2.1)   | boolean            | Whether the provider should announce the deal to IPNI or not (default: false)                      |
+| RemoveUnsealedCopy (v1.2.1) | boolean            | Whether the provider should keep an unsealed copy of the deal (default: false)                     |
 
 ### Response
 
@@ -60,4 +60,3 @@ It is a request / response protocol, where the request and response are CBOR-mar
 | SignedProposalCid   | cid          | cid of the client deal proposal + signature                                                                                                                                                   |
 | PublishCid          | cid          | The cid of the publish message, if the deal has been published                                                                                                                                |
 | ChainDealID         | integer      | The ID of the deal on chain, if it's been published                                                                                                                                           |
-

Diff for: remote-commp.md renamed to configuration/remote-commp.md

@@ -10,8 +10,11 @@ You can use the regular Unix OS signals
 **Is Boost compatible with the Lotus client? Can a client use `lotus client deal` to send a deal to Boost storage providers or do they have to use the boost client?**\
 Yes, boost should work with any client given it supports the storage market protocol / default standard of Filecoin network today.
 
-**Does Boost provide retrieval functionality or a client still need to use the Lotus client for retrievals?**\
-Boost doesn't change anything about retrieval so far. We are working on new retrieval options.
+**Does Boost provide retrieval functionality?**\
+Yes, Boost provides 3 protocols for retrievals as of now. By default, Boost has Graphsync retrieval enabled. SPs can run Bitswap and HTTP retrievals by running [`booster-bitswap`](bitswap-retrieval.md) and [`booster-http`](http-retrieval.md) respectively.
+
+**Does Boost client have retreival functionality?**\
+Yes, Boost client supports retrieval over graphsync protocol. But we highly recommend, using [`Lassie`](https://docs.filecoin.io/basics/how-retrieval-works/basic-retrieval/#lassie) client for Filecoin/IPFS retrievals.
 
 **Can Boost make verified deals?**\
 Yes, payments for deals can be made either from a regular wallet, or from DataCap. Deals that are paid for with DataCap are called `verified` deals.