From 1d5f4fd1e6a55832b2ac59e35b8df3eb36aa1db5 Mon Sep 17 00:00:00 2001
From: umgefahren <55623006+umgefahren@users.noreply.github.com>
Date: Tue, 5 Nov 2024 14:34:25 +0100
Subject: [PATCH] Format the README

---
 README.md | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/README.md b/README.md
index 409e1df..c77cf51 100644
--- a/README.md
+++ b/README.md
@@ -8,15 +8,15 @@ This is an implementation of a (js-)libp2p node running on [Cloudflare Workers](
 
 There are a couple of reasons I wanted to do this:
 
-1. *libp2p in serverless environments*: I wanted to see if you could run libp2p in serverless environments, only starting when a connection is coming in.
-2. *Building a better bootstrap node*: Since this node should be, thanks to Cloudflare, geographically close to users it could decrease access latency when bootstrapping a node. I see the greatest possibilities for improvement here.
-3. *Increasing general KAD performance by encouraging connections to physically close nodes*: Although I don't do this yet I think Kademlias performance could be improved if the routing table would initially be filled with nodes that are geographically close to the bootstrapping node. I see queries that go around the world as a future/current performance bottleneck in DHT performance.
-4. *Test limits and flexibility of js-libp2p*
-5. *Build a comprehensive map of libp2p nodes*: Since Cloudflare provides [IP location information](https://blog.cloudflare.com/location-based-personalization-using-workers/) for every incoming request it would now be possible to map out where nodes are connecting from. This could give insights in possible (future) performance improvements.
+1. _libp2p in serverless environments_: I wanted to see if you could run libp2p in serverless environments, only starting when a connection is coming in.
+2. _Building a better bootstrap node_: Since this node should be, thanks to Cloudflare, geographically close to users it could decrease access latency when bootstrapping a node. I see the greatest possibilities for improvement here.
+3. _Increasing general KAD performance by encouraging connections to physically close nodes_: Although I don't do this yet I think Kademlias performance could be improved if the routing table would initially be filled with nodes that are geographically close to the bootstrapping node. I see queries that go around the world as a future/current performance bottleneck in DHT performance.
+4. _Test limits and flexibility of js-libp2p_
+5. _Build a comprehensive map of libp2p nodes_: Since Cloudflare provides [IP location information](https://blog.cloudflare.com/location-based-personalization-using-workers/) for every incoming request it would now be possible to map out where nodes are connecting from. This could give insights in possible (future) performance improvements.
 
 ## Does it work?
 
-*Yes!*
+_Yes!_
 
 At the time of writing you can access the node at `/dns/libp2p-on-edge.dione.network/tcp/443/wss/p2p/12D3KooWEEh437zVGirT8xqBo7WxBJvXTEucFZRp7hUsK55pp1tt`.