Merge pull request #29 from tsheaff/typos-2021-09-23
This commit is contained in:
Alex Grin
GitHub
commit
54f1477e6f
1 changed files with 4 additions and 11 deletions
15
index.md
15
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.
|
||||
|
||||
|
|
@ -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:
|
||||
|
|
@ -782,14 +780,13 @@ 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.
|
||||
|
||||
|
||||
|
||||
### 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.
|
||||
|
||||
|
||||
|
||||
<pre class="pdf-hide" style="font: 10px/5px monospace;overflow:hidden;text-align: center;margin: 10rem 0">
|
||||
|
||||
++
|
||||
|
|
|
|||
Loading…
Reference in a new issue