Automatically merged updates to draft EIP(s) 2848 (#2855)

Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing

EIPS/eip-2848.md

@@ -13,7 +13,7 @@ created: 2020-08-02
 
 ## Simple Summary
 <!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.-->
-My Own Messages (MOM) is a standard to notarize and share messages using Ethereum, so that contents are verificable and decentralized.
+My Own Messages (MOM) is a standard to notarize and share messages using Ethereum, so that contents are verifiable and decentralized.
 
 ## Abstract
 <!--A short (~200 word) description of the technical issue being addressed.-->
@@ -51,12 +51,12 @@ Clients **SHOULD** allow users to choose and set the source to download content
 
 As the default setting, clients **MUST** consider `text/markdown` ([RFC 7763](https://www.ietf.org/rfc/rfc7763.txt)) as the media type of the content represented by a multihash, and in particular [Markdown](https://en.wikipedia.org/wiki/Markdown) text in [UTF-8](https://en.wikipedia.org/wiki/UTF-8) without [BOM](https://en.wikipedia.org/wiki/Byte_order_mark).
 
-Clients **MAY** let users choose to parse messages considering other content types. In this case they **SHOULD** cast a warning to users stating that a content type other then `text/markdown` is used while processing messages.
+Clients **MAY** let users choose to parse messages considering other content types. In this case they **SHOULD** cast a warning to users stating that a content type other than `text/markdown` is used while processing messages.
 
 It's **RECOMMENDED** that clients inform users about the actual setting of the default content type.
 
 ### MOM transactions
-Clients **MUST** assume that **invalid MOM transacions don't exist**. If a transaction does not strictly follow the MOM standard, clients **MUST** ignore it and they **MUST NOT** consider it a MOM transaction at all.
+Clients **MUST** assume that **invalid MOM transactions don't exist**. If a transaction does not strictly follow the MOM standard, clients **MUST** ignore it and they **MUST NOT** consider it a MOM transaction at all.
 
 Because there can be security implications parsing data sent by users, clients **SHOULD NOT** try to keep track or interpret transactions as _invalid_ MOM transactions.
 
@@ -108,7 +108,7 @@ MOM wants to be useful, easy to implement and read, error proof, fast and cheap,
 - using a smart contract for messages can leads more easily to errors and misunderstandings:
     - address of the contract can be wrong
     - smart contract must be deployed on that specific network to send messages
-- executing a smart contract costs much more then sending transactions
+- executing a smart contract costs much more than sending transactions
 - executing a smart contract just to store static data is the best example of an anti-pattern (expensive and almost useless)
 
 Without a specific smart contract to rely on, the MOM standard can be implemented and used right now in any existing networks, and even in future ones.
@@ -121,7 +121,7 @@ There's no benefit to store _static_ messages on-chain, if they are not related
 ### Why not storing op codes inside the message?
 While cost effectiveness is a very important feature in a blockchain related standard, there's also a compromise to reach with usability and usefulness.
 
-Storing commands inside the messages forces the client to actually download messages to understand what to do with them. This is very unefficent, bandwidth and time consuming.
+Storing commands inside the messages forces the client to actually download messages to understand what to do with them. This is very inefficient, bandwidth and time consuming.
 
 Being able to see the commands before downloading the content, it allows the client to recreate the history of all messages and then, at the end, download only updated messages.
 
@@ -148,12 +148,12 @@ Or, for a more classical client-server approach, you can use the latest version
 
 ## Implementation
 <!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->
-You can use an already working MOM javascript package on [GitHub Packages](https://github.com/InternetOfPeers/mom-js/packages/323930) or [npmjs](https://www.npmjs.com/package/@internetofpeers/mom-js). The package is already used by the MOM client above, and you can use it in your ÐApps too with:
+You can use an already working MOM JavaScript package on [GitHub Packages](https://github.com/InternetOfPeers/mom-js/packages/323930) or [npmjs](https://www.npmjs.com/package/@internetofpeers/mom-js). The package is already used by the MOM client above, and you can use it in your ÐApps too with:
 ```
 npm install @internetofpeers/mom-js
 ```
 
-Transaction [`0x8e49485c56897757a6f2707b92cd5dad06126afed92261b9fe1a19b110bc34e6`](https://etherscan.io/tx/0x8e49485c56897757a6f2707b92cd5dad06126afed92261b9fe1a19b110bc34e6) is an example of a valid MOM transaction already mined on the Mainnet; it's an `ADD` message.
+Transaction [`0x8e49485c56897757a6f2707b92cd5dad06126afed92261b9fe1a19b110bc34e6`](https://etherscan.io/tx/0x8e49485c56897757a6f2707b92cd5dad06126afed92261b9fe1a19b110bc34e6) is an example of a valid MOM transaction already mined on the Main net; it's an `ADD` message.
 
 ## Security Considerations
 <!--All EIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. EIP submissions missing the "Security Considerations" section will be rejected. An EIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.-->
@@ -169,7 +169,7 @@ MOM standard involves parsing payloads generated by potentially malicious client
 - Ignore malformed transactions (transactions that don't strictly follow the rules)
 
 ### Messages
-Default content-type of a message following the MOM standard is Markdown text in UTF8 without BOM. It is highly raccomended to disallow the reading of any not-text content-type, unless expressly acknowledged by the user.
+Default content-type of a message following the MOM standard is Markdown text in UTF8 without BOM. It is highly recommended to disallow the reading of any not-text content-type, unless expressly acknowledged by the user.
 
 Because content multihash is always stored into the chain, clients can download that content from Content Addressable Network (like IPFS or Swarm) or from central servers. In the latter case, a client should always check the integrity of the received messages, or it must warn the user if it cannot do that (feature not implemented or in error).