Correcting a few typos and updating blockchain addresses

README.md

@@ -33,7 +33,7 @@ It includes information describing how to build and access AI services that are
 
 SingularityNET is an open and decentralized network of AI services made accessible through 
 the blockchain. AI developers publish their services onto the SingularityNET network where they can be used by anyone with 
-an internet connection. AI deveopers are able to charge for the use of their services using the 
+an internet connection. AI developers are able to charge for the use of their services using the 
 native AGI token -- an ERC20 token hosted on Ethereum.
 
 AI services span the entire gamut of offerings in artificial intelligence and machine learning.
@@ -55,11 +55,11 @@ which can be called using the AGI token.
 
 * **SNET Daemon:** An AI service developer exposes their service to the network by running
 the SNET Daemon alongside their service. The SNET Daemon interacts with the blockchain to 
-facilitate authorization and payment for services and acts as a passthrough for making API
+facilitate authorization and payment for services and acts as a pass-through for making API
 calls to the service.
 
 * **SNET DApp:** The SingularityNET DApp is a front-end for exploring available AI services 
-and inetracting with them through a web-UI. 
+and interacting with them through a web-UI. 
 
 ### Current state of development
 

doc/Naming-Standards.md

@@ -20,7 +20,7 @@ Here `snet` is the organization, `faces` is a prefix for grouping related servic
 Service authors *should* use lowercase alphanumerics, for each of these components. Multiple word components should
 be [slugified with dashes](https://docs.djangoproject.com/en/2.1/ref/utils/#django.utils.text.slugify) ([wikipedia definition of "slug"](https://en.wikipedia.org/wiki/Clean_URL#Slug)) (i.e. dashes should separate the words).
 
-This is analogous to a URL on the web. A domain name is case insensitive, and while a URL path can use captialisation, many web applications
+This is analogous to a URL on the web. A domain name is case insensitive, and while a URL path can use capitalisation, many web applications
 will treat these paths as case insensitive.
 
 ### Internationalisation and UTF-8

doc/Resources.md

@@ -12,8 +12,8 @@
 ## SNET Alpha Network ##
 
 * DApp: http://alpha.singularitynet.io
-* Kovan Registry Address: [0x440cf8424fcd7fc2d2ff3a5668c919e93a3d2aab](https://kovan.etherscan.io/address/0x440cf8424fcd7fc2d2ff3a5668c919e93a3d2aab)
-* Kovan Agent Factory Address: [0x1faa8ec70afe4f5ce904da935a6ddf5f3482eedb](https://kovan.etherscan.io/address/0x1faa8ec70afe4f5ce904da935a6ddf5f3482eedb)
+* Kovan Registry Address: [0x2e4b2f2b72402b9b2d6a7851e37c856c329afe38](https://kovan.etherscan.io/address/0x2e4b2f2b72402b9b2d6a7851e37c856c329afe38)
+* Kovan MultiPartyEscrow Address: [0xdd4292864063d0da1f294ac65d74d55a44f4766c](https://kovan.etherscan.io/address/0xdd4292864063d0da1f294ac65d74d55a44f4766c)
 
 ## Community
 

guidelines/CONTRIBUTING.md

@@ -86,7 +86,7 @@ Sometimes your PR will have merge conflicts with the original repository's maste
     git fetch original_repository_git_url
     ```
 
--   Merge tour chagnes with the lastest changes from the original repository.
+-   Merge your changes with the latest changes on the original repository.
 
     ```bash
     git merge FETCH_HEAD

multiPartyEscrowContract/MPEServiceMetadata.md

@@ -1,6 +1,6 @@
 # Overview
 
-Service metadata is the off-chain descrition of SingularityNET service.
+Service metadata is the off-chain description of SingularityNET service.
 In order to use a SingularityNet service client need to know.
 
 * Address of MultiPartyEscrow contract
@@ -18,9 +18,9 @@ There are three ways of providing this metadata to the clients and the daemons.
 ### Security notes
 
 There are two important security notes.
-* The client shoudn't use mpe_address from metadata as a solely source of MultiPartyEscrow contract address. 
+* The client shouldn't use mpe_address from metadata as a solely source of MultiPartyEscrow contract address. 
   But he should check that its mpe_address corresponds to the mpe_address in metadata (cross validation of MultiPartyEscrow contract address)
-* The client should check that hash of metadata correspond to IPFS hash, overwise the client can be attacked if ipfs client is compromised.
+* The client should check that hash of metadata correspond to IPFS hash, otherwise the client can be attacked if ipfs client is compromised.
 
 ### Format of metadata
 
@@ -50,7 +50,7 @@ There are two important security notes.
 #                   for example service provider can use region name as group name
 #      group_name - unique name of the group (human readable)
 #      group_id   - unique id of the group (random 32 byte string in base64 encoding)
-#      payment_address - Ethereum address to recieve payments
+#      payment_address - Ethereum address to receive payments
 #
 #endpoints[] - address in the off-chain network to provide a service
 #      group_name 

multiPartyEscrowContract/MultiPartyEscrow.md

@@ -71,9 +71,9 @@ mapping (uint256 => PaymentChannel) public channels;
 
 ```
 
-Comments are selfexplanatory, but few clarifications migth be useful. 
+Comments are self-explanatory, but few clarifications might be useful. 
 
-* The full ID of "atomic" payment channel is "[MPEContractAddress, channelId, nonce]". The MPEContractAdress is the address of MPE contract,
+* The full ID of "atomic" payment channel is "[MPEContractAddress, channelId, nonce]". The MPEContractAddress is the address of MPE contract,
    which is needed to prevent the multi contracts attacks. channelId is a index in the channels mapping. nonce is a part of close/reopen logic.
 * by changing the nonce we effectively close the old channel [MPEContractAddress, channelId, oldNonce]
   and open the new one [MPEContractAddress, channelId, newNonce]. More explanations will be given later.
@@ -99,14 +99,14 @@ function channelClaim(uint256 channelId, uint256 amount, uint8 v, bytes32 r, byt
 ```
 
 It should be noted that v,r,s are parts of the signature.
-The recipent should present the signature for the following message [MPEContractAdress, channelId, nonce, amount].
-It should be noted that [MPEContractAdress, channel_id, nonce] is the full ID of "atomic" channel. 
+The recipient should present the signature for the following message [MPEContractAddress, channelId, nonce, amount].
+It should be noted that [MPEContractAddress, channel_id, nonce] is the full ID of "atomic" channel. 
 
 The recipient has two possibility:
 * (is_sendback==true)  "close" the channel and send remainder back to the sender.
 * (is_sendback==false) "close/reopen". We transfer the claimed amount to the recipient, but instead of sending remainder back to the sender we
-  simple change the nonce of the channel. By doing this we close the old atomic channel [MPEContractAdress, channel_id, old_nonce] 
-  and open the new one [MPEContractAdress, channel_id, new_nonce]
+  simple change the nonce of the channel. By doing this we close the old atomic channel [MPEContractAddress, channel_id, old_nonce] 
+  and open the new one [MPEContractAddress, channel_id, new_nonce]
 
 
 By the following functions the client can extend expiration time and he can add funds to the channel at any time.
@@ -120,16 +120,16 @@ function channelClaimTimeout(uint256 channel_id);
 ```
 
 
-### Usercases 
+### User cases 
 
-#### Simple usercase 
+#### Simple user case 
 
 Informal description:
 
 * Client deposit tokens to the MPE. We could propose to everybody to use MPE as a wallet for all theirs AGI tokens
 * Client select service provider.
-* Client open with choosen payment group. 
-* It should be noted that the client can send requests to any replica from the selected payment group (replicas in one payment groups should share state of the payment channel amoung them)
+* Client open with chosen payment group. 
+* It should be noted that the client can send requests to any replica from the selected payment group (replicas in one payment groups should share state of the payment channel among them)
 * Client starts to send requests to the replicas. With each call he send the signed authorization for the server to "withdraw" the commutative amount of the tokens which are due.
 * At some point server can decide to close/reopen channel in order to fix the profit. At the next call from the client, the server should inform the client that 
 that "nonce" of the channel has been changed (see [state-less logic](MultiPartyEscrow_stateless_client.md) ). 
@@ -151,17 +151,17 @@ We assume that REPLICA1 is from payment group with groupId=group1
 * CLIENT1 send to SERVER1/REPLICA1 authorization SIGNED_BY_CLIENT1(ContractAdress=MPEAdress, channel_id=0, nonce=0, amount=3)
 * CLIENT1 send to SERVER1/REPLICA1 authorization SIGNED_BY_CLIENT1(ContractAdress=MPEAdress, channel_id=0, nonce=0, amount=4)
 * CLIENT1 send to SERVER1/REPLICA1 authorization SIGNED_BY_CLIENT1(ContractAdress=MPEAdress, channel_id=0, nonce=0, amount=5)
-* Server desides to close/reopen the channel (fix the 5 AGI of the profit)
+* Server decides to close/reopen the channel (fix the 5 AGI of the profit)
 * SERVER1 call: channelClaim(channel_id = 0, amount=5, signature = SIGNED_BY_CLIENT1(ContractAdress=MPEAdress, channel_id=0, nonce=0, amount=5), is_sendback=false)
 * MPE add 5 AGI to the balance of SERVER1
 * MPE change the nonce (nonce +=1) and value (value -= 5) in the PaymentChannel: [channel_id = 0, sender=CLIENT1, recipient=SERVER1, replicaId=REPLICA1, value=5 AGI, nonce=1, expiration=expiration0]  
-* Client recieve information that channel has been reopen, and nonce has been changed (see [state-less logic](MultiPartyEscrow_stateless_client.md) )
+* Client receives information that channel has been reopen, and nonce has been changed (see [state-less logic](MultiPartyEscrow_stateless_client.md) )
 * CLIENT1 send to SERVER1/REPLICA1 authorization SIGNED_BY_CLIENT1(ContractAdress=MPEAdress, channel_id=0, nonce=1, amount=1)
 * CLIENT1 send to SERVER1/REPLICA1 authorization SIGNED_BY_CLIENT1(ContractAdress=MPEAdress, channel_id=0, nonce=1, amount=2)
 * CLIENT1 send to SERVER1/REPLICA1 authorization SIGNED_BY_CLIENT1(ContractAdress=MPEAdress, channel_id=0, nonce=1, amount=3)
 * CLIENT1 send to SERVER1/REPLICA1 authorization SIGNED_BY_CLIENT1(ContractAdress=MPEAdress, channel_id=0, nonce=1, amount=4)
-* Client decides to put more funds in the channel and extend it expiration datas.
-* CLEINT1 calls channelExtendAndAddFunds(channel_id=0, new_expiration = now + 1day, amount=10 AGI)
+* Client decides to put more funds in the channel and extend its expiration date.
+* CLIENT1 calls channelExtendAndAddFunds(channel_id=0, new_expiration = now + 1day, amount=10 AGI)
 * MPE change the value and expiration data in the PaymentChannel: [channel_id = 0, sender=CLIENT1, recipient=SERVER1, groupId=group1, value=15 AGI, nonce=1, expiration=expiration1, signer=CLIENT1]
 * MPE subtract 10 AGI from the balance of the CLIENT1
 * CLIENT1 send to SERVER1/REPLICA1 authorization SIGNED_BY_CLIENT1(ContractAdress=MPEAdress, channel_id=0, nonce=1, amount=5)
@@ -181,7 +181,7 @@ We assume that REPLICA1 is from payment group with groupId=group1
 
 ### Remarks
 
-* Service provider can use the same ethereum address for all payment goups or he can use different address. 
+* Service provider can use the same ethereum address for all payment groups or he can use different address. 
 In any case, the daemons very rarely need to send on-chain transactions. It means, that we actually don't need to provide the demons with direct access to the private key. 
 Instead it could be some centralized server to sign the transactions from the daemons (in some cases it even can be done in semi-manual manner by the service owner). We call such server a treasurer server.
 * In the current implementation the client sign off-chain authorization messages with the "signer" private key. It means that the client don't necessary need to sign transaction with his ethereum identity, instead he can use another key pairs.

multiPartyEscrowContract/MultiPartyEscrow_stateless_client.md

@@ -19,7 +19,7 @@ The client receive the following information from the daemon
 (It should be noted that two last values are not in the current version, and we need them only for calculate unspent_amount in the case then current_nonce != blockchain_nonce)
 
 Here we should consider the difficult case, namely the situation in which the server starts close/reopen procedure for the channel.
-The client doesn't need to wait (or recieve at all) confirmation from the blockchain, because it is not in the interest of the server to lie. But the server also doesn't need to wait the confirmation from the blockchain (if he makes sure that the request is mined before expiration of the channel).
+The client doesn't need to wait (or receive at all) confirmation from the blockchain, because it is not in the interest of the server to lie. But the server also doesn't need to wait the confirmation from the blockchain (if he makes sure that the request is mined before expiration of the channel).
 
 Before considering all possible cases, let's define the following parameters
 * blockchain_nonce - nonce of the channel in the blockchain

multiPartyEscrowContract/front-to-back-examples/example1.md

@@ -18,7 +18,7 @@ from the client side:
 
 ## Preparation
 
-Please follow the tutorial [Build-and-deploy-SingularityNET-locally](Build-and-deploy-SingularityNET-locally.md) in order to deploy SingularitNet localy.
+Please follow the tutorial [Build-and-deploy-SingularityNET-locally](Build-and-deploy-SingularityNET-locally.md) in order to deploy SingularityNET locally.
 
 The following example can be also executed on the kovan test net, but you will need to make sure that your organization name haven't been already taken and you should probably use another account for the collect payment from the client side (see KOVAN warnings bellow) 
 

multiPartyEscrowContract/snap-cli_call_parameters.md

@@ -1,6 +1,6 @@
 # How to pass call parameters in snet-cli and parameters modifer.
 
-Here we describe how to pass parameters to the service in snet-cli, and we demostrate how to pass binary paramaters via comandline interface.
+Here we describe how to pass parameters to the service in snet-cli, and we demonstrate how to pass binary parameters via command line interface.
 
 ## JSON parameters