diff --git a/reports/archive/3.md b/reports/archive/3.md index 55c12af6c8..83dcf68710 100644 --- a/reports/archive/3.md +++ b/reports/archive/3.md @@ -77,7 +77,7 @@ This has a number of limitations: **B)** the quota system, for example on uploads, becomes blind to functional roles of objects, and can only operate on raw size and similar metrics, which may not be as flexible as one wants. For example, perhaps you want to make sure that no one store more than one channel cover photo explicitly. -As is, if new members are given a 1GB upload quota for example (which is quite low), they may chose to use that by uploading 1 milllion 1Kb images for example, which is both abusive and makes no sense. +As is, if new members are given a 1GB upload quota for example (which is quite low), they may chose to use that by uploading 1 million 1Kb images for example, which is both abusive and makes no sense. **C)** the distribution system will be very sensitive to the role of a data object, as this is major determinant for future bandwidth requirement profile, hence having this explicitly represented will be very useful. <== speculative point, as we have not thought much about distribution. diff --git a/testnets/acropolis/specification/README.md b/testnets/acropolis/specification/README.md index 2306b445db..c3d04c87da 100644 --- a/testnets/acropolis/specification/README.md +++ b/testnets/acropolis/specification/README.md @@ -262,7 +262,7 @@ The runtime implements the following set of APIs. #### [AuraApi](https://crates.parity.io/substrate_consensus_aura/trait.AuraApi.html) -- **slot_duration**: Auro module `slot_duration` routine. +- **slot_duration**: Aura module `slot_duration` routine. #### [AuthoritiesApi](#) diff --git a/testnets/acropolis/specification/runtime/actors-module.md b/testnets/acropolis/specification/runtime/actors-module.md index 8aaf7f2c59..3fbc441882 100644 --- a/testnets/acropolis/specification/runtime/actors-module.md +++ b/testnets/acropolis/specification/runtime/actors-module.md @@ -35,7 +35,7 @@ Entry is achieved through staking funds. Storage providers are rewarded periodic ### Tranches The module is used to configure the storage tranches available in the storage system, and for updating operational parameters associated with each tranche, such as minimum stake and storage capacity. Tranches must always aim to maintain a minimum number of providers `MinSlots`. -The module will prevent un-stakig when it would result in `MinSlots` no longer being filled. Once tranches are created they cannot be destroyed, however their operational parameters can be adjusted. If at anytime the maximum number of slots `MaxSlots` for a tranche is update to be less than the number of active providers `N` in the tranche, no new providers can be allowed to join until the number drops below `MaxSlots` again. +The module will prevent un-staking when it would result in `MinSlots` no longer being filled. Once tranches are created they cannot be destroyed, however their operational parameters can be adjusted. If at anytime the maximum number of slots `MaxSlots` for a tranche is update to be less than the number of active providers `N` in the tranche, no new providers can be allowed to join until the number drops below `MaxSlots` again. ### Role Account Members will utilize a separate account, referred to as the role account, which will be associated with their membership, to hold the staked funds. This corresponding key, is referred to as the role key. diff --git a/testnets/acropolis/specification/runtime/content-directory.md b/testnets/acropolis/specification/runtime/content-directory.md index b43eb3f99a..41d57f32e4 100644 --- a/testnets/acropolis/specification/runtime/content-directory.md +++ b/testnets/acropolis/specification/runtime/content-directory.md @@ -63,7 +63,7 @@ The purpose of creating such a hierarchy depends on the `SchemaId` used in the root entry. Possible uses are: * For structuring podcast/video episodes in a series. -* For providing multiple languate tracks, subtitle tracks, commentary, +* For providing multiple language tracks, subtitle tracks, commentary, etc. for video content. * etc. @@ -117,10 +117,10 @@ The content creation protocol is as follows: ## Events - `MetadataAdded`: `ContentMetadata` has been added to `MetadataByContentId`. The - event payload is the `ContentId` of the matching metdata. + event payload is the `ContentId` of the matching metadata. - `MetadataUpdated`: `ContentMetadata` has been updated. The - event payload is the `ContentId` of the matching metdata. + event payload is the `ContentId` of the matching metadata. - `RootContentUpdated`: a `ContentMetadata` that represents root content in a metadata hierarchy has been updated. The payload is the `ContentId`, and a diff --git a/testnets/acropolis/specification/runtime/data-object-storage-registry-module.md b/testnets/acropolis/specification/runtime/data-object-storage-registry-module.md index 9dae69d115..0d51714a31 100644 --- a/testnets/acropolis/specification/runtime/data-object-storage-registry-module.md +++ b/testnets/acropolis/specification/runtime/data-object-storage-registry-module.md @@ -40,7 +40,7 @@ For an *available* `DataObject`, there is thus at least one, possibly many `StorageRelationship` contains an `available` flag, which shows whether the relationship is currently fulfillable by the storage provider. -This permits indiciating an intent to fulfil on the runtime by providing +This permits indicating an intent to fulfil on the runtime by providing an inactive relationship, then synchronizing content, and finally updating the relationship when content can be served. diff --git a/testnets/acropolis/specification/runtime/data-object-type-registry-module.md b/testnets/acropolis/specification/runtime/data-object-type-registry-module.md index 90afd64208..7fe6b0b234 100644 --- a/testnets/acropolis/specification/runtime/data-object-type-registry-module.md +++ b/testnets/acropolis/specification/runtime/data-object-type-registry-module.md @@ -28,14 +28,14 @@ None. All stored `DataObjects` are associated with a type. This type does not describe a file or media type, but rather how `DataObjects` of this type are to be -handled by the storage network. This information is encapsualted in the +handled by the storage network. This information is encapsulated in the `DataObjectType` structure, identified by a `DataObjectTypeId`. Of course, storage nodes should still impose some constraints on how what uploads to accept. These constraints are described by the `constraints` field of the `DataObjectType`. There is a corresponding `constraints_version` field, which indicates the version of the constraints specification, i.e. how to -inteprer the `constraints` field. +interpreter the `constraints` field. ## Concepts @@ -58,7 +58,7 @@ field is expected to be valid JSON with the following structure: ### Content Creation For apps attempting to upload data, the choice of `DataObjectType` is a -harcoded property. `DataObjectType` represents a *purpose*, i.e. a media cover +hardcoded property. `DataObjectType` represents a *purpose*, i.e. a media cover image or some such. The uploading app knows exactly the purpose of each file to upload, and chooses the appropriate `DataObjectType` accordingly. @@ -73,7 +73,7 @@ to upload, and chooses the appropriate `DataObjectType` accordingly. commence. Applying constraints means verifying that the file to be uploaded passes the -constraints - if it would not pass, the content is rejected immediatly, and none +constraints - if it would not pass, the content is rejected immediately, and none of the following steps are executed. This effectively implements OR-chaining of conditions from most specific to least specific matches. diff --git a/testnets/acropolis/specification/runtime/discovery-module.md b/testnets/acropolis/specification/runtime/discovery-module.md index 35749075ea..994b28f9ba 100644 --- a/testnets/acropolis/specification/runtime/discovery-module.md +++ b/testnets/acropolis/specification/runtime/discovery-module.md @@ -36,10 +36,10 @@ with the help of a cryptographic signature. As such, the *discovery workflow* is and should be largely independent on how discovery is performed. The *discovery workflow* is almost entirely off-chain, -but boostraps from on-chain information. +but bootstraps from on-chain information. The *publishing workflow* does require actors to understand how discovery is -peformed. This current version uses [IPNS](https://docs.ipfs.io/guides/concepts/ipns/) +performed. This current version uses [IPNS](https://docs.ipfs.io/guides/concepts/ipns/) as a building block for discovery. The *publishing workflow* includes modifying on-chain data, albeit relatively rarely. @@ -116,7 +116,7 @@ None. Allow root to set the current bootstrap endpoints. Note that the number of endpoints is never expected to grow large, as new nodes are discovered from this set of -boostrap endpoints - therefore always setting the entire vector is sufficient. +bootstrap endpoints - therefore always setting the entire vector is sufficient. #### Errors diff --git a/testnets/acropolis/specification/runtime/members-module.md b/testnets/acropolis/specification/runtime/members-module.md index 08549d216f..cac098d5a9 100644 --- a/testnets/acropolis/specification/runtime/members-module.md +++ b/testnets/acropolis/specification/runtime/members-module.md @@ -71,7 +71,7 @@ The second is for a screening authority, which is a designated account, to simpl - `MemberProfile`: Maps member id to `Profile` of member. -- `Handles`: Maps handle to corresponding memberid. +- `Handles`: Maps handle to corresponding member id. - `NextPaidMembershipTermsId`: Next paid membership terms id. @@ -153,7 +153,7 @@ Change about text on membership. #### Errors - Bad signature. -- No member id found for accountid. +- No member id found for account id. - Not primary account. - Member profile not found. diff --git a/testnets/acropolis/specification/runtime/migration-module.md b/testnets/acropolis/specification/runtime/migration-module.md index f19aeac68d..6758826feb 100644 --- a/testnets/acropolis/specification/runtime/migration-module.md +++ b/testnets/acropolis/specification/runtime/migration-module.md @@ -50,7 +50,7 @@ Standard. ### Description -Pre block execution code which actually performs migration and initilization under suitable conditions, namely +Pre-block execution code which actually performs migration and initialization under suitable conditions, namely - `SpecVersion` is not set, which would possibly be the case from genesis - `SpecVersion` is less than the runtime [spec version](../README.md#runtime-version) diff --git a/testnets/athens/README.md b/testnets/athens/README.md index f563fe0869..0197ce07ae 100644 --- a/testnets/athens/README.md +++ b/testnets/athens/README.md @@ -515,11 +515,11 @@ new roles - **Martin** - **Schedule:** - Storage and Validator get payouts mondays at ~1100GMT - - Counil gets payouts ~10:00GMT day after election and, if applicable, vote. + - Council gets payouts ~10:00GMT day after election and, if applicable, vote. ### Support -- **Description:** Provide support to users enaging with testnet functionality and campaigns +- **Description:** Provide support to users engaging with testnet functionality and campaigns - **Manager:** **Jaydip** - **Team:** - **Jaydip**