From c6a684a74115c3a2e3076d6588d5c9a689d2224e Mon Sep 17 00:00:00 2001 From: Matthias Radestock Date: Fri, 16 Jan 2015 17:24:03 +0000 Subject: [PATCH] fix some typos --- site/how-it-works.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/site/how-it-works.md b/site/how-it-works.md index 94387af8..0c119be4 100644 --- a/site/how-it-works.md +++ b/site/how-it-works.md @@ -98,7 +98,7 @@ receiving peers to build up their mappings of which client MAC addresses are local to which peers. The destination peer name enables the receiving peer to identify whether this frame is destined for itself or whether it should be forwarded on to some other peer, -accomodating multi-hop routing. This works even when the receiving +accommodating multi-hop routing. This works even when the receiving intermediate peer has no knowledge of the destination MAC: only the original capturing peer needs to determine the destination peer from the MAC. This way weave peers never need to exchange the MAC addresses @@ -194,7 +194,7 @@ knowledge of that second peer. #### Out-of-date topology The peer-to-peer passing of updates is not instantaneous, so it is -very posisble for a node elsewhere in the network to have an +very possible for a node elsewhere in the network to have an out-of-date view. If the destination peer for a packet is still reachable, then @@ -320,7 +320,7 @@ This is very similar to the [non-crypto encapsulation](#encapsulation). All of the frames are encrypted with the same ephemeral session key and all must be decrypted by the receiving peer. Frames which are to be forwarded on to some further peer will be re-encrypted with the -relevant ephemeral session keys for the onwards connections. Thus all +relevant ephemeral session keys for the onward connections. Thus all traffic is fully decrypted on every peer it passes through. Encryption is again done with the NaCl `secretbox.Seal` function.