From 313c97727e80908cb86bfa2973c0ca745698084c Mon Sep 17 00:00:00 2001 From: Kolby Moroz Liebl <31669092+KolbyML@users.noreply.github.com> Date: Fri, 22 Nov 2024 06:33:45 -0700 Subject: [PATCH] fix: resolve PR concerns --- ping-payload-extensions/extensions.md | 3 +- ping-payload-extensions/extensions/type-0.md | 33 +++++++++++++++--- ping-payload-extensions/extensions/type-3.md | 34 ------------------- .../ping-custom-payload-extensions.md | 21 +----------- 4 files changed, 30 insertions(+), 61 deletions(-) delete mode 100644 ping-payload-extensions/extensions/type-3.md diff --git a/ping-payload-extensions/extensions.md b/ping-payload-extensions/extensions.md index ea6ec21..3ecd8dd 100644 --- a/ping-payload-extensions/extensions.md +++ b/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 | diff --git a/ping-payload-extensions/extensions/type-0.md b/ping-payload-extensions/extensions/type-0.md index 3e20089..96afef2 100644 --- a/ping-payload-extensions/extensions/type-0.md +++ b/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 ) ``` diff --git a/ping-payload-extensions/extensions/type-3.md b/ping-payload-extensions/extensions/type-3.md deleted file mode 100644 index 93bed92..0000000 --- a/ping-payload-extensions/extensions/type-3.md +++ /dev/null @@ -1,34 +0,0 @@ -# Get Client info - -This payload MUST be available from all sub-networks. This payload allows you to figure out peer's client info. Which will be useful for censuses. - - -### Type Specifications - -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` - - -Max length of a client info we should accept -- MAX_CLIENT_INFO_BYTE_LENGTH = 200 - - -Ping and Pong payload -```python - -client_info = SSZ.serialize(Container(client_info: ByteList[MAX_CLIENT_INFO_BYTE_LENGTH])) - -ClientInfoPayload = Container( - type: 3, - payload: client_info -) -``` diff --git a/ping-payload-extensions/ping-custom-payload-extensions.md b/ping-payload-extensions/ping-custom-payload-extensions.md index 29c69c6..b6cc6cb 100644 --- a/ping-payload-extensions/ping-custom-payload-extensions.md +++ b/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.