docs: update main README

Author: daviddias

README.md

@@ -47,115 +47,84 @@ The lab's genesis comes from a need present in the IPFS and libp2p projects to a
     <th><b>Research Area</b></th>
     <th><b>Open Problem(s)</b></th>
     <th><b>Short Description</b></th>
-    <th><b>RFPs</b></th>
   </tr>
 
   <tr>
     <th><b>Networks Observability</b></th>
     <th>NEEDs OPEN PROBLEM</th>
     <th></th>
-    <th></th>
   </tr>   
 
   <tr>
     <th><b>Resilliency in Adversarial Networks</b></th>
     <th>NEEDs OPEN PROBLEM</th>
     <th></th>
-    <th></th>
   </tr>   
 
   <tr>
     <th><b>Heterogeneous Runtimes</b></th>
     <th>NEEDs OPEN PROBLEM</th>
     <th>(e.g. Browsers, IoT, Low Powered and/or Battery powered devices)</th>
-    <th></th>
   </tr>   
 
   <tr>
     <th><b>Content Addressing</b></th>
     <td><b><a href="https://github.com/protocol/ResNetLab/blob/master/OPEN_PROBLEMS/ROUTING_AT_SCALE.md">Routing at Scale (1M, 10M, 100M, 1B.. nodes)</a></b></td>
     <td>Content-addressable networks face the challenge of routing scalability, as the amount of addressable elements in the network rises by several orders of magnitude compared to the host-addressable Internet of today.</td>
-    <td>
-      <ul>
-        <li><a href="https://github.com/protocol/research-RFPs/blob/master/RFPs/rfp-7-MLDHT.md">RFP-7: Multi-Level DHT Design and Evaluation</a></li>
-      </ul>
-    </td>
   </tr>  
 
   <tr>
     <th></th>
     <td><b><a href="https://github.com/protocol/ResNetLab/blob/master/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md">Preseve full users' privacy when providing and fetching Content</a></b></td>
     <td>How to ensure that the user's of the IPFS network can collect and provide information while mainting their full anonymity.</td>
-    <td>
-      <ul>
-        <li></li>
-      </ul>
-    </td>
   </tr>
 
   <tr>
     <th><b>Mutability</b></th>
     <td><b><a href="https://github.com/protocol/ResNetLab/blob/master/OPEN_PROBLEMS/MUTABLE_DATA.md">Mutable Data (Naming, Real-Time, Guarantees)</a></b></td>
     <td>Enabling a multitude of different patterns of interactions between users, machines and both. In other words, what are the essential primitives that must be provided for dynamic applications to exist, what are the guarantees they require (consistency, availability, persistancy, authenticity, etc) from the underlying layer in order create powerful and complete applications in the Distributed Web.</td>
-    <td>
-      <ul>
-        <li></li>
-      </ul>
-    </td>
   </tr>  
 
   <tr>
     <th></th>
     <td><b><a href="https://github.com/protocol/ResNetLab/blob/master/OPEN_PROBLEMS/HUMAN_READABLE_NAMING.md">Human Readable Naming</a></b></td>
     <td>You can only have two of three properties for a name: Human-meaningful, Secure and/or Decentralized. This is Zooko's Trilemma. Can we have all 3, or even more? Can context related to some data help solve this problem?</td>
-    <td>
-      <ul>
-        <li></li>
-      </ul>
-    </td>
   </tr>    
 
   <tr>
     <th></th>
     <td><b><a href="https://github.com/protocol/ResNetLab/blob/master/OPEN_PROBLEMS/PUBSUB_AT_SCALE.md">PubSub at Scale (1M, 10M, 100M, 1B.. nodes)</a></b></td>
     <td>As the IPFS system is evolving and growing, communicating new entries to the IPNS is becoming an issue due to the increased network and node load requirements. The expected growth of the system to multiple millions of nodes is going to create significant performance issues, which might render the system unusable. Despite the significant amount of related literature on the topic of pub/sub, very few systems have been tested to that level of scalability, while those that have been are mostly cloud-based, managed and structured infrastructures.</td>
-    <td>
-      <ul>
-        <li><a href="https://github.com/protocol/research-RFPs/blob/master/RFPs/rfp-8-pubsub.md">RFP-8: Scalability Bounds of P2P Pub/Sub (libp2p floodsub, gossipsub and episub)</a></li>
-      </ul>
-    </td>
   </tr>  
 
   <tr>
     <th><b>Data Exchange</b></th>
     <td><b><a href="https://github.com/protocol/ResNetLab/blob/master/OPEN_PROBLEMS/ENHANCED_BITSWAP_GRAPHSYNC.md">Enhanced Bitswap/GraphSync with more Network Smarts </a></b></td>
     <td>Bitswap is a simple protocol and it generally works. However, we feel that its performance can be substantially improved. One of the main factors that hold performance back is the fact that a node cannot request a subgraph of the DAG and results in many round-trips in order to “walk down” the DAG. The current operation of bitswap is also very often linked to duplicate transmission and receipt of content which overloads both the end nodes and the network.</td>
-    <td>
-      <ul>
-        <li></li>
-      </ul>
-    </td>
   </tr>   
 
   <tr>
     <th><b>Distributed Type Systems</b></th>  
     <td><b><a href="https://github.com/ipfs/notes/pull/394">Improved layouts to represent data in hash-linked graphs (using IPLD) </a></b></td>
     <td>Future™ ⚙️</td>
-    <td>
-      <ul>
-        <li></li>
-      </ul>
-    </td>
   </tr>     
 </table>
 
 ### Projects
 
-- P2P Observatory
-- Beyond Bitswap
-- drand
 - Hydra Booster
 - Gossipsub v1.1 
+- drand
+- [Beyond Bitswap](BEYOND_BITSWAP)
+- P2P Observatory
+
+### RFPs
+
+- ACTIVE
+  - n/a
+- PAST
+  - <a href="https://github.com/protocol/research-RFPs/blob/master/RFPs/rfp-7-MLDHT.md">RFP-7: Multi-Level DHT Design and Evaluation</a>
+  - <a href="https://github.com/protocol/research-RFPs/blob/master/RFPs/rfp-8-pubsub.md">RFP-8: Scalability Bounds of P2P Pub/Sub (libp2p floodsub, gossipsub and episub)</a>
 
 ### Collaborations
 
@@ -181,4 +150,4 @@ The lab's genesis comes from a need present in the IPFS and libp2p projects to a
 
 ### Contact
 
-You can reach out to us anytime with your question and interest in these projects by emailing [resnetlab@protocol.ai](mailto:resnetlab@protocol.ai)
+You can reach out to us anytime with your question and interest in these projects by emailing [resnetlab@protocol.ai](mailto:resnetlab@protocol.ai)