fix: resolve PR concerns

ping-payload-extensions/extensions.md

@@ -6,7 +6,6 @@ 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 extensions  |  Yes  |
+| [0](extensions/type-0.md)  | Client Info and Capabilities | All  | Returns client info e.x. `trin/0.1.1-2b00d730/linux-x86_64/rustc1.81.0` and a list of enabled extensions  |  Yes  |
 | [1](extensions/type-1.md)  |  Basic Radius Payload | State, Beacon | 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  | Returns client info e.x. `trin/0.1.1-2b00d730/linux-x86_64/rustc1.81.0`  |  Yes  |

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

@@ -1,19 +1,42 @@
-# Capabilities Payload
+# Client Info and Capabilities Payload
 
-Portal clients can only have max 500 extensions enabled per sub-network.
+## Client Info 
+Client info are ASCII hex encoded strings.
+
+Client info strings consist of 4 parts
+- client name (e.x. `trin`,`fluffy`)
+- client version + short commit (e.x. `0.1.1-2b00d730`)
+- operating system + cpu archtecture (e.x. `linux-x86_64`)
+- programming language + language version (e.x. `rustc1.81.0`)
+
+Example 
+- String: `trin/0.1.1-2b00d730/linux-x86_64/rustc1.81.0`
+- Hex encoding: `0x7472696E2F302E312E312D32623030643733302F6C696E75782D7838365F36342F7275737463312E38312E30`
+
+#### Privacy Concerns
+Clients can optionally return an empty string for privacy reasons, this is not recommended as client info helps researchers understand the network.
+
+## Capabilities
+Portal clients can only have max 400 extensions enabled per sub-network.
 
 This payload provides a list of u16's each u16 provide in the list corresponds to an enabled extension type.
 
+## Payload Outline
+
 Ping and Pong Payload
 ```python
 
-MAX_CAPABILITIES_LENGTH = 500
+MAX_CLIENT_INFO_BYTE_LENGTH = 200
+MAX_CAPABILITIES_LENGTH = 400
 
-capabilities = SSZ.serialize(List[u16, MAX_CAPABILITIES_LENGTH])
+client_info_and_capabilities = SSZ.serialize(Container(
+    client_info: ByteList[MAX_CLIENT_INFO_BYTE_LENGTH]
+    capabilities: List[u16, MAX_CAPABILITIES_LENGTH]
+))
 
 CapabilitiesPayload = Container(
   type: 0,
-  payload: capabilities
+  payload: client_info_and_capabilities
 )
 ```
 

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

@@ -2,7 +2,7 @@
 
 ## Motivation
 
-Ping Payload Extensions. There is a minimal set of `standard extensions` which require a fork hard fork to change. This framework allows Portal clients to implement `non standard extensions` which don't require a hard fork to deploy to the network. A more flexible way to extend the Protocol without bloating the [Portal-Wire-Protocol](../portal-wire-protocol.md)
+Ping Payload Extensions. There is a minimal set of `standard extensions` which require a breaking change to update. This framework allows Portal clients to implement `non standard extensions` which don't require a breaking change to deploy to the network. A more flexible way to extend the Protocol without bloating the [Portal-Wire-Protocol](../portal-wire-protocol.md)
 
 # Type's
 
@@ -81,24 +81,5 @@ It is for Portal implementations which want to see what extensions a peer suppor
 
 Non-required extension offer a way for Portal implementations to offer extended functionality to its users without requiring every Portal implementing party to agree to a new feature. 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`.
 
-## Does implementing non-standard-extensions require a hardfork?
-No only changing a sub-networks standard extension requires a hard fork.
-
-
 ## 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 usage of 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.