fix: add capabilities message and outline how to upgrade a standard m…

…essage

ping-payload-extensions/extensions.md

@@ -6,6 +6,7 @@ This is a list and short description of all the extensions
 
 | Type number  |  Name | Supported sub-networks  | Short Description  | Is this call Required to Implement  |
 |---|---|---|---|---|
+| [0](extensions/type-0.md)  |  Capabilities | All  | Provides a list of enabled types  |  Yes  |
 | [1](extensions/type-1.md)  |  Basic Radius Payload | State, Beacon, Canonical Transaction Index, Transaction Gossip  | Provides the nodes Radius  |  Yes  |
 | [2](extensions/type-2.md)  | History Radius Payload  |  History | Provides the nodes radius and ephemeral header count  |  Yes  |
 | [3](extensions/type-3.md)  |  Client Info | All  | It will return you something like `trin/0.1.1-2b00d730/linux-x86_64/rustc1.81.0`  |  Yes  |

ping-payload-extensions/extensions/type-0.md

@@ -0,0 +1,19 @@
+# Capabilities Payload
+
+Any network can only have Portal client can only every have 500 extensions enabled per Portal sub-networks.
+
+This payload provides a list of u16's each u16 provide in the list corresponds to an an enabled extension type.
+
+Ping and Pong Payload
+```python
+
+MAX_CAPABILITIES_LENGTH = 500
+
+capabilities = SSZ.serialize(List[u16, MAX_CAPABILITIES_LENGTH])
+
+BasicRadiusPayload = Container(
+  type: 0,
+  payload: capabilities
+)
+```
+

ping-payload-extensions/ping-custom-payload-extensions.md

@@ -73,4 +73,36 @@ This error code is for if an extension is asking for something and it doesn't ex
 Wasn't able to decode the payload
 
 #### 3: System error
-A critical error happened and the ping can't be processed
+A critical error happened and the ping can't be processed
+
+## Standard extensions
+
+Every Portal Network Client is required to support 3 extensions
+- [Type 0: Capabilities Payload](extensions/type-0.md): useful for finding what ping extensions a client supports
+- Sub-network standard extension. For history this is currently [Type 2: History Radius Payload](extensions/type-2.md). For State and Beacon the base extension is [Type 1: Basic Radius Payload](extensions/type-1.md). These are extensions what are crucial. This standard extensions are specified the respective sub-networks specification  
+- Type 3: [Get Client info Payload](extensions/type-3.md)
+
+
+## What is the [Type 0: Capabilities Payload](extensions/type-0.md) for
+It is for Portal implementations which want to see what extensions a peer supports. Not all extensions need to be implemented by all parties. So in order for a peer to find if an extension is implemented a [Type 0: Capabilities Payload](extensions/type-0.md) should be exchanged.
+
+Non-required extension offer a way for Portal implementations to offer extended functionality to its users without requiring every implementing party to agree. This allows for a diverse set of use cases to be fulfilled without requiring every implementer implement every extension, or requiring the need to bloat the minimal [Portal-Wire-Protocol](../portal-wire-protocol.md) with new `Message Types`.
+
+## How do sub-network standard extension's work
+sub-network standard extension's are fundamental extensions that are required for a Portal sub-network to function. They must be supported by the sub-networks implementations.
+
+### What is the process for changing a sub-network standard extension
+
+The process of changing a Portal sub-networks standard extension is through a hard fork set by a timestamp. When the timestamp is reached the old standard extension is replaced by the new standard extension. Details on what standard extensions for what networks are being replace are specified in the fork's document.
+
+### Can a node use the next standard extension for a network before the hardfork
+Yes there is no limitation for a Portal Client implementation using the next standard extension or a 3rd party extension before the hard fork has taken place. A requirement of this flexibility is that the new extension being used in-place of the standard extension must still fulfill the duties of the current standard extension. One downside of using new Standard Extension's before the fork is you won't know if a peer supported it yet unless you did either a
+- trial and error to see if the peer supports the call
+- Sent a [Type 0: Capabilities Payload](extensions/type-0.md)
+
+This can be useful for 
+- accessing functionality before the hard fork has taken place in a none breaking way
+- Extending the protocol with implementation specific heuristics.
+
+It is only recommended to do this for peers in an implementations routing table as most connections are too short lived to make the addition call worth it.
+