Improved markdown formatting of understanding reticulum manual chapter

docs/markdown/networks.md

@@ -46,11 +46,11 @@ with Reticulum:
 >   (called *destinations* in Reticulum terminology) as it needs, which become
 >   globally reachable to the rest of the network. There is no central point of
 >   control over the address space.
->   <br/>
+>   
 > * Reticulum was designed to handle both very small, and very large networks.
 >   While the address space can support billions of endpoints, Reticulum is
 >   also very useful when just a few devices needs to communicate.
->   <br/>
+>   
 > * Low-bandwidth networks, like LoRa and packet radio, can interoperate and
 >   interconnect with much larger and higher bandwidth networks without issue.
 >   Reticulum automatically manages the flow of information to and from various
@@ -60,27 +60,27 @@ with Reticulum:
 >   it will try as best as possible to comply with this, while still respecting
 >   bandwidth limits, but you *will* waste a lot of precious bandwidth and airtime,
 >   and your LoRa network will not work very well.
->   <br/>
+>   
 > * Reticulum provides sender/initiator anonymity by default. There is no way
 >   to filter traffic or discriminate it based on the source of the traffic.
->   <br/>
+>   
 > * All traffic is encrypted using ephemeral keys generated by an Elliptic Curve
 >   Diffie-Hellman key exchange on Curve25519. There is no way to inspect traffic
 >   contents, and no way to prioritise or throttle certain kinds of traffic.
 >   All transport and routing layers are thus completely agnostic to traffic type,
 >   and will pass all traffic equally.
->   <br/>
+>   
 > * Reticulum can function both with and without infrastructure. When *transport
 >   nodes* are available, they can route traffic over multiple hops for other
 >   nodes, and will function as a distributed cryptographic keystore. When there
 >   is no transport nodes available, all nodes that are within communication range
 >   can still communicate.
->   <br/>
+>   
 > * Every node can become a transport node, simply by enabling it in it’s
 >   configuration, but there is no need for every node on the network to be a
 >   transport node. Letting every node be a transport node will in most cases
 >   degrade the performance and reliability of the network.
->   <br/>
+>   
 >   > *In general terms, if a node is stationary, well-connected and kept running
 >   > most of the time, it is a good candidate to be a transport node. For optimal
 >   > performance, a network should contain the amount of transport nodes that
@@ -92,14 +92,14 @@ with Reticulum:
 >   entirely new, and so far, mostly unexplored class of networked applications,
 >   where networks, and the information flow within them can form and dissolve
 >   organically.
->   <br/>
+>   
 > * You can just as easily create closed networks, since Reticulum allows you to
 >   add authentication to any interface. This means you can restrict access on
 >   any interface type, even when using legacy devices, such as modems. You can
 >   also mix authenticated and open interfaces on the same system. See the
 >   [Common Interface Options](interfaces.md#interfaces-options) section of the [Interfaces](interfaces.md#interfaces-main)
 >   chapter of this manual for information on how to set up interface authentication.
->   <br/>
+>   
 
 Reticulum allows you to mix very different kinds of networking mediums into a
 unified mesh, or to keep everything within one medium. You could build a “virtual