Moneropedia: create Message entry and fill-in I2NP

Also, update:

- Tunnel
- Encryption
- Destination

Referencing:
 - monero-project/kovri#256
 - monero-project/monero-site#155

knowledge-base/moneropedia/destination.md

@@ -3,12 +3,12 @@ layout: moneropedia
 entry: "Destination"
 tags: ["kovri"]
 terms: ["Destination", "Destinations"]
-summary: "A in-net address that serves as a final endpoint"
+summary: "A in-net address that serves as a final endpoint (either local or remote)"
 ---
 
 ### The Basics
 
-A @destination is the @I2P @in-net address of the final endpoint you are trying to connect to (example: an @I2P website, service, or Monero node).
+A @destination is the @I2P @in-net address of the final endpoint you are trying to connect to (example: an @I2P website, service, or Monero node). This can also include a *local destination* of which *other* peers need to connect to in order to make contact and communication (similar to how, in @clearnet, your IP address is given to a website when you connect so it knows *where* to send the information back to).
 
 ### In-depth Information
 

knowledge-base/moneropedia/encryption.md

@@ -2,7 +2,7 @@
 layout: moneropedia
 entry: "Encryption"
 tags: ["kovri"]
-terms: ["encryption", "encrypted"]
+terms: ["encryption", "encrypted", "encrypting"]
 summary: "The process of encoding messages or information in a way that only authorized parties can decode and read"
 ---
 

knowledge-base/moneropedia/i2np.md

@@ -2,14 +2,27 @@
 layout: moneropedia
 entry: "I2NP"
 tags: ["kovri"]
-terms: ["I2NP", "Message", "Messages"]
-summary: "TODO(anonimal): finish"
+terms: ["I2NP"]
+summary: "The I2P Network Protocol: the mechanism in which I2NP messages are sent over the I2P network"
 ---
 
 ### The Basics
 
-TODO(anonimal): finish
+From @Java-I2P:
+
+>
+@I2NP manages the routing and mixing of messages between routers, as well as the selection of what transports to use when communicating with a peer for which there are multiple common transports supported
 
 ### In-depth information
 
-TODO(anonimal): finish
+From @Java-I2P:
+
+>
+@I2NP (@I2P Network Protocol) @messages can be used for one-hop, router-to-router, point-to-point @messages. By @encrypting and wrapping @messages in other @messages, they can be sent in a secure way through multiple hops to the ultimate @destination. @I2NP does not specify nor require any particular @transport layer but does require at least one @transport in use.
+
+>
+Whenever a @destination wants to send a message to to another @destination, it provides its local router with both the @destination structure and the raw bytes of the message to be sent. The router then determines where to send it, delivers it through outbound @tunnels, instructing the end point to pass it along to the appropriate inbound @tunnel, where it is passed along again to that @tunnel's end point and made available to the target for reception.
+
+### Notes
+
+Read more about the @I2NP [protocol](https://geti2p.net/en/docs/protocol/i2np) and [specification](https://geti2p.net/spec/i2np).

knowledge-base/moneropedia/message.md

+---
+layout: moneropedia
+entry: "Message"
+tags: ["kovri"]
+terms: ["Message", "Messages"]
+summary: "The mechanisms in which information travels within I2P"
+---
+
+### The Basics
+
+*Messages* (which exist on top of the @transports layer), contain varying types of information that are needed for the network but, most importantly, everything you see, do, send, or receive, will come and go in the form of *messages*.
+
+There are 2 essential types of *messages* in @I2P:
+
+- @Tunnel messages
+- @I2NP messages
+
+Essentially: *@tunnel messages* **contain** @I2NP **message fragments** which are then [reassembled](https://geti2p.net/en/docs/tunnels/implementation) at certain points within a @tunnel's path.
+
+### In-depth information
+
+@I2NP messages have a close relationship with @tunnel @messages so it is easy to get the term *messages* confused when reading @Java-I2P specifications:
+
+>
+1. First, the tunnel gateway accumulates a number of I2NP messages and preprocesses them into tunnel messages for delivery.
+2. Next, that gateway encrypts that preprocessed data, then forwards it to the first hop.
+3. That peer, and subsequent tunnel participants, unwrap a layer of the encryption, verifying that it isn't a duplicate, then forward it on to the next peer.
+4. Eventually, the tunnel messages arrive at the endpoint where the I2NP messages originally bundled by the gateway are reassembled and forwarded on as requested.
+
+### Notes
+
+- @I2NP @messages need to be fragmented because they are variable in size (from 0 to almost 64 KB) and @tunnel @messages are fixed-size (approximately 1 KB).
+- For details and specifications, visit the [I2NP spec](https://geti2p.net/spec/i2np) and [Tunnel Message spec](https://geti2p.net/spec/tunnel-message)

knowledge-base/moneropedia/tunnel.md

@@ -8,7 +8,7 @@ summary: "Uni-directional virtual paths that pass messages through a defined seq
 
 ### The Basics
 
-When you communicate over @I2P (visit an @eepsite / use a @garlic-service), you'll first need to connect to a peer by using @transports and then build virtual *tunnels*. These virtual tunnels are temporary, uni-directional paths that pass information through a defined sequence of @I2P routers to your @destination. Tunnels are built, and then used, with layered @garlic-encryption and are a general-purpose mechanism to transport all @I2NP messages.
+When you communicate over @I2P (visit an @eepsite / use a @garlic-service), you'll first need to connect to a peer by using @transports and then build virtual *tunnels*. These virtual tunnels are temporary, uni-directional paths that pass information through a defined sequence of @I2P routers to your @destination. Tunnels are built, and then used, with layered @garlic-encryption and are a general-purpose mechanism to transport all @I2NP @messages.
 
 Each peer builds, at a minimum, *two* uni-directional tunnels: one for **outbound traffic**, and one for **inbound traffic**. These tunnels are classified as either **inbound tunnels** (where @messages come toward the creator of the tunnel) or **outbound tunnels** (where the tunnel creator sends @messages away from the creator of the tunnel). Thus, *four* tunnels are required for a single round-trip @message and reply to your @destination (two for your, two for your destination).