Updated The macro skeptics guide to the p2pProtocol macro (markdown)

The-macro-skeptics-guide-to-the-p2pProtocol-macro.md

@@ -100,6 +100,6 @@ The rest is simple helpers for APIs such as `peer.state(BeaconSync)`, `eth2Node.
 
 ### Closing words on intentional programming and regularity
 
-When you design an API, you should always strive to capture the intent of the programmer as precisely as possible. When yuo do that, it becomes much easier to add features such as "Implement this protocol in a mock peer that will reply with pre-recoreded messages", "Dump the JSON contents of all network messages", "Create a visualization tool of the network traffic". All of these [cross-cutting concerns](https://en.wikipedia.org/wiki/Cross-cutting_concern) become a matter of enhancing the protocol processing layer with new capabilities.
+When you design an API, you should always strive to capture the intent of the programmer as precisely as possible. When you do that, it becomes much easier to add features such as "Implement this protocol in a mock peer that will reply with pre-recoreded messages", "Dump the JSON contents of all network messages", "Create a visualization tool of the network traffic". All of these [cross-cutting concerns](https://en.wikipedia.org/wiki/Cross-cutting_concern) become a matter of enhancing the protocol processing layer with new capabilities.
 
 When the programmers are responsible for getting the low-level details right, some irregularity will innevitably sneak in. The Waku protocol for example had a number of such irregularities that Kim was able to point out to the design team only because they were difficult to express within the constraints of the p2pProtocol macro.