Thanks for following up @shane . We’re still ironing out the details but here is what we’ve currently defined that Nodies will provide in return for the grant:
The Gateway Operator shall:
1.1 open source technical documentation on integrating with Pocket Network including the steps below and to allow for an agnostic language implementation:
(i) Using an app stake to retrieve a session,
(ii) Generate an Application Authentication Token,
(iii) Obtain hosted dispatcher URLs or spin up own dispatcher (Full Pocket Node),
(iv) Send a request to a dispatcher for the latest nodes in a session,
(v) Sign a relay and submit it to one of the nodes in a session,
(vi) Receive a response from a node, and
(vii) Proxy it back to the user;1.2 open source relay client implementation of the technical documentation described in clause 1.1 above in Golang,
1.3 Open source technical documentation on the QoS and data integrity measures intended to be implemented by the Gateway Operator, as well as the open source implementation of the QoS framework implemented by the Gateway Operator;
1.4 provide any additional information and documents as reasonably requested by PNF to help any other gateway operator portals launch on Pocket Network;
take all necessary actions to open source their Gateway Operator Portal in the manner that PNF sees fit as soon as reasonably practicable after the Effective Date;
The Gateway Operator must provide details that allow POKTScan, or any other data aggregator that PNF may reasonably choose to support from time to time, to verify the number of relays that the Gateway Operator Portal is sending to the Pocket Network, including for which Chain ID, as well as all relevant details about the Gateway Operator Portal’s key operating metrics such as its reliability (uptime and correctness) and performance (latency, success rate and proportion of relays sent to Pocket Network, any altruist network, or any other destination other than the Pocket Network protocol).
To expand on the QoS and data integrity measures to be open sourced:
Node Registry - consists of the current staked nodes separated by operator identity (not address) and provides long-term historical data about an operator. This will also give us information on any potential “bad actors” in the network.
Nodies Cop - Once the servicers are registered on the Node Registry, there is no guarantee that the servicers are in healthy shape. Nodies Cop will be a construct/ideology that performs “checks” for all the nodes on the registry periodically to ensure they are healthy. In the event that one of the checks fails, Nodies Cop will pull the servicer out of the servicing rotation. Once the servicer is pulled out of the rotation, Nodies Cop will periodically test the node still, exponentially increasing the retries until the servicer is healthy again. In summary, Nodies Cop is constantly looking for infractions and pulling nodes in and out of rotation. These checks would be classified as public/secret:
- Public - health checks that users can see in order to diagnose if their servicers are healthy.
- Secret - health checks that only administrators of the application can see. It is only important to know that we have secret checks because we do not want malicious users to ‘spoof’ or ‘workaround’ our checks to trick us into thinking their servicer is healthy. This can be further iterated to become how the first “watcher” will be implemented within the network if successful.
Here’s a working doc detailing more: Nodies DLB <> POKT Specifications - Google Docs
Note that this is a starting point and more technical details will be shared as it progresses, through channels like Gateway Office Hours, blog posts, and forum updates. Nodies also has a point person in @giantfrog who anyone is welcome to reach out to.