From c47376250be51ddab7b323bf632713304f8edb5f Mon Sep 17 00:00:00 2001 From: Tyler Sheaffer Date: Thu, 23 Sep 2021 13:58:27 -1000 Subject: [PATCH 1/3] Fix Extensible and Interoperable typos --- index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.md b/index.md index b6f3f64..8b36635 100644 --- a/index.md +++ b/index.md @@ -535,9 +535,9 @@ Metadata is structured information about a stream or channel separate from the c Metadata is stored in a serialized binary format using [Protocol Buffers](https://developers.google.com/protocol-buffers/). This allows for metadata to be: -- **Extensibile**. Metadata can encompass thousands of fields for dozens of types of content. It must be efficient to both modify the structure and maintain backward compatibility. +- **Extensible**. Metadata can encompass thousands of fields for dozens of types of content. It must be efficient to both modify the structure and maintain backward compatibility. - **Compact**. Blockchain space is expensive. Data must be stored as compactly as possible. -- **Interoperabile**. Metadata will be used by many projects written in different languages. +- **Interoperable**. Metadata will be used by many projects written in different languages. The serialized metadata may be cryptographically signed to indicate membership in a channel. See [Channels](#channels) for more info. -- 2.45.2 From 242485b59e257d5d9f646be60fc593a93115179f Mon Sep 17 00:00:00 2001 From: Tyler Sheaffer Date: Thu, 23 Sep 2021 13:58:46 -1000 Subject: [PATCH 2/3] Remove 4th newlines to increase consistency --- index.md | 7 ------- 1 file changed, 7 deletions(-) diff --git a/index.md b/index.md index 8b36635..d130365 100644 --- a/index.md +++ b/index.md @@ -676,7 +676,6 @@ format | description The blockchain treats metadata as an opaque series of bytes. Clients should not trust the metadata they read from the blockchain. Each client is responsible for correctly encoding and decoding the metadata, and for validating its structure and signatures. This allows evolution of the metadata definition without changes to blockchain consensus rules. - ## Data Files published using LBRY are stored in a distributed fashion by the clients participating in the network. Each file is split into many small pieces. Each piece is encrypted and [announced](#announce) to the network. The pieces may also be uploaded to other hosts on the network that specialize in rehosting content. @@ -750,7 +749,6 @@ The `version` field is always 1. It is intended to signal structure changes in f Every stream must have at least two blobs - the manifest blob and a content blob. Consequently, zero-length streams are not allowed. - #### Stream Encoding A file must be encoded into a stream before it can be published. Encoding involves breaking the file into chunks, encrypting the chunks into content blobs, and creating the manifest blob. Here are the steps: @@ -789,7 +787,6 @@ Decoding a stream is like encoding in reverse, and with the added step of verify 5. Concatenate the decrypted chunks in order. - ### Announce After a stream is encoded, it must be _announced_ to the network. Announcing is the process of letting other nodes on the network know that a client has content available for download. LBRY tracks announced content using a distributed hash table. @@ -849,8 +846,6 @@ Upload sends a blob to the server. If uploading many blobs, the client should us The protocol methods and message types are defined in detail [here](https://github.com/lbryio/lbry.go/blob/master/blobex/blobex.proto). - - ### Reflectors and Data Markets In order for a client to download content, there must be hosts online that have the content the client wants, when the client wants it. To incentivize the continued hosting of data, the blob exchange protocol supports data upload and payment for data. _Reflectors_ are hosts that accept data uploads. They rehost (reflect) the uploaded data and charge for downloads. @@ -925,7 +920,6 @@ URL | Claim ID `lbry://@Arthur*1` | b7bab5 - ### Additional Resources - [lbry.tech](https://lbry.tech) is designed specifically for a technical audience. There you will find detailed explanations and examples, ways to interact with the LBRY community, and guidance for anyone who wants to get more involved. @@ -933,7 +927,6 @@ URL | Claim ID - [lbry.com](https://lbry.com) is an application built on top of LBRY. It's one example of the type of end-to-end experience that is possible to create using this technology. - 
                                                                                            
                                              ++                                            
-- 
2.45.2


From 0239bafaed1e181fe52d68caa97cffd94f3b90d6 Mon Sep 17 00:00:00 2001
From: Tyler Sheaffer 
Date: Thu, 23 Sep 2021 13:58:59 -1000
Subject: [PATCH 3/3] fix small typos on stream decoding steps

---
 index.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/index.md b/index.md
index d130365..032049c 100644
--- a/index.md
+++ b/index.md
@@ -780,8 +780,8 @@ An implementation of this process is available [here](https://github.com/lbryio/
 
 Decoding a stream is like encoding in reverse, and with the added step of verifying that the expected blob hashes match the actual data.
 
-1. Verify that the hash of the manifest blob and matches the stream hash.
-2. Parse the JSON in manifest blob.
+1. Verify that the hash of the manifest blob matches the stream hash.
+2. Parse the JSON in the manifest blob.
 3. Verify the hashes of the content blobs.
 4. Decrypt and remove the padding from each content blob using the stream key and IVs in the manifest.
 5. Concatenate the decrypted chunks in order.
-- 
2.45.2