Thanks for providing more details Jack From the sound of it, Nodies is being contracted to build three specific tools thus far:
An SDK for using AppStakes (what is being called “Bare Bones Integration”)
Node Registry (a historical record of how providers respond to RPC calls)
Nodies Cop (a health/liveness checker)
Those are pretty straightforward modules. I hope that these modules are being designed in an fashion where folks can pick and choose which ones they want to use, and which ones the want to use their own modules. I know that for CC we already built our own version of #2 and #3 and could potentially make our own modules available. If Nodies’ modules are primarily designed to only work with their modules, then that would limit how others could design gateways IMO.
I do hope more POPs will be utilized as well, since these types of modules could be built others, especially ones like #2 and #3.
In Nodies presentation, they focused heavily on their gateway’s primary value proposition will be the Opinionated APIs, which indubitably requires backend indexing and catching tools. Will those tools also be open sourced as part of this initiatives? Perhaps @giantfrog may be able to provide more insight?
Also, could you expound on this @giantfrog? The idea of Secret health checks doesn’t make sense since nodes need to know how to identity if they are not hitting a specific performance. Example, if a “Secret health check” is actually a getlogs call and their node is failing, the node runner needs to be able to know what call they failed with to troubleshoot. A heavy call like getlogs could be effected by a number of variables, but if it’s considered a “secret” then how can anyone troubleshoot or improve their nodes? How could that also be fair if a provider like Nodies knows what the Secret health checks are, but no one else does… then Nodies node’s would have preferential treatment within your own gateway.
It also seems to be hinted that Secret health checks could be part of Watchers. Has that concept been vetted by the protocol team? Again, I’m not entirely sure what Secret health checks really means, so any further explanation would be great
This is something we will have to live with in a multi-gateway landscape. If we want gateways and apps to be permissions, we cannot control that. In the end it is the gateways reputation for fair distribution of relays what is at stake.
We plan to check how each gateway is distributing their relays and show if there is favoritism in their “secret checks” , but in the end is up to the portal user.
I would not mix watchers here, it is a completely different topic (and a large one). Checks at portal level have nothing to do with checks at protocol level (watchers). The first ones decide on the distribution of the traffic and the later ones on the amount being paid for those relays.
I get your point, but it is in the spec of what they are creating for the DAO, so I’m asking for clarification on how all will benefit from “secret” health checks, as it’s not immediately obvious what they are. They obviously have thought it through to put it in the spec, so I’m just asking for clarification.
I agree with your point. Since it was mentioned in the spec, I am wanting clarification as this would have to be a larger topic that involves the larger community.
Thanks for this, I gave it a read and I have some comments.
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.
Grouping nodes by provider name has some drawbacks:
Node runners like to change and/or have multiple domains to obfuscate tracking.
The QoS features distributions of nodes is not well defined, we have found multi-modal distributions under a given domain name.
We suggest to use a per-address registry, as it is more flexible and provides better data. We have done this in the past (when QoS data was available), we can help you with it, it is a rather large DB but is the correct way to do it (IMO).
Nodies Cop - …
I think that you read all the watcher-related data, but just in case I will add some comments here.
This highly overlaps with the watcher and you will face very similar chalenges. Specifically I recall one relates to:
… performs “checks” for all the nodes on the registry periodically …
Periodicity of checks is not wise and is easily detected, randomize this.
is constantly looking for infractions and pulling nodes in and out of rotation
Delay actions (removal) from checks, or hide actual check among other “bloat” requests to the node before kicking them out of rotation.
I’m looking forward to see your gateway up and burning some tokens!
Emphasis on why it’s a secret check! We will start by incorporating our secret checks based on our clientele’s requests and needs, and we expect that other gateway operators will do the same. For us this is a fine balance between gamers and ensuring that we are able to ensure to our clients a specific level of assurance quality and security. It is very possible that in a world of gateway verse, some gateway operators will be more strict, and some gateway operators (i.e. non-profit or loss-leader gateways) may be less strict. Nodies DLB sits in between offering Pocket as a decentralized offering to our client base and accelerating Pocket Network’s goal of multiple gateways. I believe the spec is sufficient enough in what we will actually deliver. The mechanism for how secret checks are shared and distributed is up to gateway operators to decide. It can be further iterated by future gateway operators as Pocket continues to evolve. We’re not opposed to releasing our mechanisms, but at the same time, we have to balance that with what our clients require for security since the network has no effective slashing mechanism at the time.
Absolutely!
I’m personally not a fan of the per-node system we have in the Pocket ecosystem right now. It is often a sign of confusion about what the number of node counts actually means when in actuality, there is only a certain amount of blockchain nodes operating behind them. Ethereum is also going through a somewhat similar issue where they’re proposing to allow for stacking vertically instead of horizontally for nodes since many nodes map back to a single identity, anyways. That being said, it’s a pretty minor detail for us right now and can always be iterated on.
There have been many ideas we’ve floated around (i.e: an open dataset from us of ranked nodes that node operators can use as a baseline then build and train their own model, but this is likely not to make it into the initial bootstrapping budget, perhaps as a continuation and evolution of the initial gateway-verse). Any collaboration we can have with the best data science team in the POKT ecosystem sounds great , and just shows the potential of what the world of multiple gateway operators would look like. I’m really excited to start forth on what we can do for the ecosystem and the opportunities it opens up for others.
An update on our end:
I’m happy to say we reached terms with PNF, and the last action item is a formal execution on contractual agreements in regards to our deliverables. We will finish this today and will have news to share with the community after our roadmap planning (1-2 weeks), and our first payment received for this budget will be started on the 1st of September
A brief but crucial update in spirit of open data and transparency!
POKT <> Nodies Integration Public Tracker can be found here , this tracker outlines all the tickets we are currently working on. This dashboard can singlehandedly be used to track all our progress.
POKT MVP Integration date is preliminary slated for October 31st & we’re currently a week ahead in progress.
User onboarding guidelines and baseline benchmarks published on our docs. We will have material for POKT before integration is complete.
https://nodies.app website was revamped both from a code perspective, observability, and UI enhancements. We are working towards another addition to highlight Pocket, which is staged on https://dev.nodies.app
@Jorge_POKTscan is graciously working on Testnet implementation for Poktscan so we can leverage it for gateway testing. ( kudos to Poktscan team for taking this on). I cannot stress the importance of testnets.
Marketing for multi-gateway awareness is a work in progress in collaboration with @Adrienne (PNF) and our BD team!
4 of us, including myself, will be in Permissionless II, so if you will be attending and want to connect - please on Twitter/X!
Track our progression in our discord, public project tracker, through DM’s, or our socials.
Can you explain why the QoS framework module will only “partially implement the ‘Cop’ model”? Why does the QoS module not include the whole Node Registry and Nodies Cop functionality that Nodies is currently building?
I understand that the you will be providing “technical documentation on how we’re currently identifying good actors”, but since only part of the code will be open source, this means that future gateways will have to spend their time and resources reverse engineering all the parts that aren’t open source.
As Dermot recently shared in PNF’s ambitions update, our Gateway-verse objectives for Q2 2024 are as follows:
Onboard two new high-potential gateway operators, each capable of delivering 1B+ daily relays to the network
Build a pipeline of 5+ additional high-potential gateway operators, each capable of sending 500m+ daily relays to the network - to be onboarded at the launch of Shannon
All new gateway operators (excluding Grove) sending an aggregate of 5B+ daily relays to the network
With these ambitions laid out, and some Gateway-verse milestones recently hit, it’s time for an overdue update on where we’re at with Gateway-verse. Moving forward we’ll be working to uphold a higher standard of update frequency from both PNF and Nodies.
This update outlines 1) what has been worked on so far in the Gateway-verse and, 2) how we’ll work towards achieving our Q2 2024 objectives.
What has been worked on so far:
Onboarding Nodies: PNF defined a standard gateway operator agreement, which will enable wider onboarding of other gateways, as well as a grant agreement with Nodies. The grant began September 1st.
App Stake Management: PNF has been working with Grove to free up app stakes for other gateways. Nodies now has enough app stakes to do more than 400M requests/hr, matched with 624 nodes every hour.
Nodies Integration: Nodies completed their integration with POKT on October 31st, which included
Optimized Golang Client: Nodies has been focused on extracting as much performance as possible for their gateway, building their own custom minimal Golang client to their relay specification. They’re experimenting with FastJSON) and FastHTTP) to optimize on latency rather than use the standard Golang packages. This has led to 2-4X performance boosts in the relay process, which should translate to more efficient gateways in the long-run as these optimizations will be embedded in the OSS Gateway Stack and will carry forward into Shannon. We’re expecting Blade to share more detail in this thread later this week.
Dispatcher Management: they’ve set up their own dedicated Pocket dispatchers to enable better scaling of traffic through to POKT
Load Balancer between Nodies and POKT: Nodies has the ability to serve endpoints from their own nodes as a backup, so they have built an internal load balancer to enable dynamically shifting between their own nodes and POKT
QoS Checks: they’ve implemented basic QoS checks within their own systems, including a height checker, a latency checker, and a simple node registry
Observability: they’ve implemented observability on all their backend and frontend systems to allow them to determine how a request is performing in terms of success rates, requests per second, per chain, etc. This allows them to be alerted whenever there is an issue and to ensure a high standard of QoS. They’ve migrated their observability away from postgres and into a more purpose-built time-series database using Prometheus, Influx DB, Posthog, and Grafana. These are all open source technologies that anyone can integrate and will lay the foundation for the Observability Service within the OSS Gateway Stack, as well as upgrades to the data provided to customers in their frontend.
Public Endpoints: Nodies completed their integration with POKT in time to take over the role of maintaining public endpoints from Grove. These are now serving just shy of 100M daily relays. Thanks to their work on building an efficient baremetal gateway, we’ve observed a 60% reduction in costs to maintain the public endpoints.
Gateway Dashboard: POKTscan updated their dashboard to display per-gateway relay performance. Here you can view gateway relays per-chain, in time series, and as a % distribution.
How we’ll work towards achieving our Q2 2024 objectives:
More Frequent Updates: Both PNF and Nodies will be providing more frequent updates here in the forum and on community calls. For the latter, the Node Runner Office Hours have evolved into Ecosystem Office Hours in part to make space for gateways to be discussed on those calls.
Optimizing the Integration: Nodies has been paying close attention to their POKT integration, tuning their performance with POKT using real traffic, adjusting their QoS checks, and ramping up the traffic that is coming through the network.
Building the OSS Gateway Stack: The vision for the gateway stack has evolved from a barebones integration and QoS framework, into a modular architecture powered by GRPC, with simple Docker deployments and the flexibility for developers to choose only the services they need and/or plug-in other services. Now that Nodies has completed their vertical integration and are sending traffic through POKT, they are focusing on modularizing it. The repo in which this will be developed should be shared by Blade this week, starting with the optimized Golang client that we described above. Everyone will be able to follow the progress in GitHub and we expect the stack to be ready for onboarding by early adopters by late December, then completed (RC ready) in January. You can read more about Nodies’ vision for the stack here.
Headhunting Gateways: PNF has begun deploying a headhunting GTM strategy targeted at ideal gateway personas, meeting with high-value gateways, understanding their needs, and establishing an onboarding pipeline with a view to onboarding them starting in January. Please get in touch directly with either myself or Dermot if you can introduce any established RPC businesses capable of sending 1B+ daily relays through to the network that might be interested in building a gateway on POKT Network.
Public Applications: PNF will launch a public application process for becoming a gateway operator, so that anyone interested in building a gateway can be considered for the opportunity. If you don’t want to wait for the application process, feel free to get in touch directly with either myself or Dermot.
Preparing to Onboard Gateways: PNF is preparing an onboarding/support package for gateway operators, including one-pagers, ecosystem support offerings, public docs, and economic models (cost, breakeven).
Consistent Gateway Marketing: PNF will establish gateway marketing guidelines for use by all existing and new gateways, including “Powered by POKT” assets and requirements to mention POKT in materials/promotions.
Sockets/POPs: PNF also plans to use the ERA Allocation to create more grant opportunities for parallel community projects that complement Nodies’ OSS Gateway Stack work (rather than duplicating it), such as QoS monitoring solutions.
I’m excited to see the gateway space moving forward! OS-Gateway looks like a great start to this budding ecosystem.
All these are great accomplishments, however they don’t translate into anything tangible for the community or other gateways, since these are only relevant to the setting up of Nodies own gateway.
I understand that more modules are currently being built to address some of these areas, but it’s not clear what the full stack of a gateway will look like with these modules in a production environment. Very basic info has been shared, but none of that is actionable or detailed enough to fully understand how a production stack is suppose to work.
How does this stack lay out? (Example: Does OS-Gateway go right behind your firewall, or does it go through an LB, or call filter, etc?)
Where do future modules expect to be placed in your stack? (Example: Will the QoS module connect into OS-Gateway, or does is interface directly with an LB like HAPoxy?)
What dependencies will these modules have?
What tech will these modules interface or integrate with (HAProxy, Promethius, etc)?
I replied that without code being openly developed and without technical details on what how this stack is supposed to work, contributors like myself cannot get involved. I’m trying to understand the envisioned architecture and see where folks like myself can get involved.
Open-sourcing OS-Gateway is an awesome start, and from my understanding all future development will be in public repos, which will be great as well, but folks like myself need specifics so that we can participate.
Today it was mentioned that a forum update is in the works from Nodies, so I wanted to get my questions out ASAP
Thanks @JackALaing for this recap. To add more to the Gateway Stack:
The Nodies Gateway Stack aims to streamline the integration of applications with the POKT Network, reducing the complexity associated with directly interfacing with the protocol with an all-inclusive stack that any developer can contribute to. This allows for mass adoption across multiple personas such as application developers, existing centralized RPC platforms, future gateway operators, and more.
Whenever proposing and pioneering the pathway to multiple gateways and its benefits to the Foundation, they opened up with open arms to enable us. Whenever we wrote the initial technical specification, the reason why it felt “ambiguous” to some was to prevent being locked into a granular statement of work given that the potential scope of this project is extremely large and to reduce the friction of unnecessary bureaucracy. The specifications were structured in such a way that the ecosystem would always benefit. Our team continues to push the limits of what we can actually do for the ecosystem based on our expertise and experience with the protocol and as a RPC provider, ultimately leading us to the gateway stack.
So what exactly is the gateway stack right now? The gateway stack kickstarts off as a light-weight process that enables developers of all kinds to be able to interact with the protocol and engage with 50+ blockchains without the need of storing terabytes of data, require heavy computational power, nor understand the POKT protocol specifications with a simple docker compose file. The rhetorical question that we pose to future actors who want to maintain a blockchain node is: Why spin up an Ethereum node and maintain it yourself whenever you can just leverage POKT natively using the Gateway stack? Afterall, using POKT would require a fraction of the required resources and technical staffing.
We envision that the stack will be used as a foundation for their entirety of the ecosystem to continue to build on top of such as:
Building their own frontends and extending their backend to include POKT by using the Gateway stack for their own SaaS business
Using POKT as a hyperscaler whenever they need more computational power or access to more blockchains (sticking the process into their LB rotation)
Using POKT as a backend as a failover whenever their centralized nodes goes down (sticking the process into their LB rotation)
The use cases are limitless and we expect that over time, community contributions into the gateway stack will enable some of the aforementioned use cases natively. Below is an example persona we’ve created to illustrate how existing RPC providers can use POKT through the Gateway Stack.
Our plans for this December and January to transition from alpha to RC ready ordered by priority:
Enable QoS checks that will allow Pocket responses to return with a 99% success rate.
Enable Observability on the gateway server to measure success, error, session dispatching rates (Allow for Prometheus to scrape these metrics)
Create E2E test coverage that allows for a reliable release process.
Create documentation and architectural diagrams to elaborate on the existing state of the stack
Assist the Foundation to help onboard more gateway operators
Our goal is that by the end of the 6 month period, the fundamentals of the Gateway stack are sound, and there is a sustainable and realistic way for many more community contributions down the road. Our team will continue to own the direction and vision of the project to prevent any unnecessary thrashing. However, we welcome any discourse within reasonable bounds and our roadmap will continue to be shaped by future gateway operators who will onboard the network.
Please note that the actual deliverables that we are committing to has not changed, the Nodies Gateway Stack exists to house these deliverables but as well set a long-standing vision for future contributions. The end state of the Gateway stack will continue to evolve, however the next two months are now granularly set to baseline the expectations.
Objectively taking a step back and looking at the larger picture…
To dive deeper into our accomplishments, we frame it in respect to the objectives outlined in the OP and the timeline which is about the hafl way mark of the total engagement as far:
There was a clear need to define processes for future gateway operators (i.e gateway docs, relay specification, app stakes distribution mechanism, identifying the need to securely rotating the app stakes, contractual agreements, etc). We have been actively working with PNF to help remove these logistical barriers. As a result, these processes will be then distributed to the next 2-5 gateway operators that will be onboarding the network in the upcoming quarters.
On track
The grant’s purpose allowed us to build both inwards and outwards. Both of these characteristics go hand to hand, and the POKT ecosystem does benefit from both. It was always our intention that https://nodies.app would directly integrate with the protocol as a first step and to focus time and energy on building out BD/Sales for POKT. Then we would fan that out into a more open source-project to help further gateway operators onboard.
We are now powering anywhere from 50m to 80m POKT traffic a day at a 60% cost reduction in comparsion to previous gateway offerings. This only cements that multiple gateway operators will be a net add for the ecosystem. Furthermore, this is a huge step forward for the POKT ecosystem because:
POKT’s traffic is now more resilient than ever. Gateways now are operating on multiple different infrastructure stacks leading to a further resilient network as gateways are spread across multiple PoPs ranging from GCP to Bare Metal.
By directly integrating, this has led us to learn more about what it actually takes to become a gateway operator and ultimately strategize on what we would need to solve for in order to reduce the friction in gateways. Ultimately, this was one of the major contributing factors to our open source gateway stack vision and the actual OS Gateway stack.
On track
By directly integrating with the protocol and serving real world traffic, this has given us sufficient information on more QoS checks we would have to perform, and where we can optimize. This has already been reflected in our cost savings for the Network and why the gateway stack is so focused on performance and effiency. Furthermore, the prortocol team has already reached out to us to talk more about Gateways in general and where the OS Gateway stack fits in a post Shannon world.
On track
We already have our platform hooked into the network powering public RPCs. By the end of Q2, the foundation has set a goal of 2-5 gateway operators being able to also power POKT RPC. There have been numerous queries behind the scenes from both ecosystem members, node runners, and even centralized providers on leveraging our gateway stack. The rate that we are going, there will be plenty of actors who can potentially be tapping into the network for RPC on the demand side, ultimately cementing that the POKT Protocol is the only decentralized RPC network on both the supply and demand ends.
On track
Closing Statement
Our recent efforts have made significant strides in achieving the outlined objectives within the past ~3 months. From removing logistical barriers for future gateway operators to supporting a second-mover gateway, learning about gateway operations, fostering innovations in technology, and diversifying revenue sources, Our integration and contributions have demonstrated tangible progress. The achievements so far continue to pave the future for a multi-gateway ecosystem that enhances the overall resilience, efficiency, and value of the Pocket Network
@poktblade This is a perfect way to sum up how the past 6 months have been from someone on the outside
From what I got from the initial announcement, I don’t believe this was supposed to be a Nodies only “direction and vision”. I saw it as the DAO bootstraps Nodies to be a steward of leading it’s development, but once it actually began, it has morphed into a Nodies only show.
From an outsider’s perspective, who’s been trying to get a handle for 6 months now on the technical aspects of the stack being built with DAO resources, there is the same level of exclusivity and siloing that reflect what many criticized when POKT was under a single company. Why do we want to repeat history? While I’m glad that the protocol team is getting all the technical information, this “picking and choosing” who gets to understand your actual gateway or tech stack is wrong IMO.
If I’m to take your comment at face value, your stack is now effecting protocol design, yet it’s architecture is still secretive? Though PNF has exclusively paid Nodies to built it, I don’t believe it’s design or architecture should be deemed exclusive for only some teams.
Overshadowing The Good
I’ve already expressed before that I believe you do solid work, and the code from my initial review of the OS Gateway was positive… but for me, it is overshadowed by the fact that any technical questions have been ignored (at least from the public) and we are now being told that we will only get transparency at the tail end… after it’s been built and the funds have been mostly spent.
On one hand, I should be excited that more gateways could be on-boarded next quarter… but on the other hand, the technical side is an exclusive club, and any attempt to make it inclusive (through questions) are ignored, while the exclusivity is being framed through a lens of justification. All this is worth addressing IMO, instead of pushing down the road to address in some other future intuitive that adopts a similar approach. Large 6 month initiatives (which represented nearly 1/4 of an ERA’s budget) should not be treated as some small initiative that are finished in a few weeks.
@poktblade, I think your stack probably has a straightforward architecture, and the gateway stack vision likely makes absolute sense… so I have no idea it can only be selectively shared. Whatever is being shared with select teams (like the protocol team) should be shared openly IMO.
Looking forward to when the gateway ecosystem doesn’t have gatekeeping
I’d suggest making your #4 priority, your #1 priority, as that is more in-line with the initial spirit of this initiative. Since it already exists (deriving from your comment), why not just communicate it now, instead of at the tail end of this initiative?
There seems to be this framing that any meaningful technical sharing is burdening of progress, and it should only happen at the end… but that is not a precedent that should be re-introduced into POKT, IMO.
@poktblade how many of these relays are from the public endpoints that are being paid for by PNF? Do we have a track on how much of your gateway burn is from the DAO resources vs other traffic?
Critical Disposition
You’ve shared some impressive stats about your gateway and it sounds like a good overall vision, but I struggle to get excited about something that has been shrouded in exclusivity. I’ll probably lean toward a critical disposition until this is no longer exclusively a “Nodies + select others” initiative, which I don’t believe follows PNF’s original vision shared in June.
I honestly wholeheartedly disagree with your message. The repository is open and there isn’t any gatekeeping. There is nothing new with maintainers within an open source project and early vision and developments require controlled development to make measurable progress from the initial get-go.
Our team will continue to own the direction and vision of the project to prevent any unnecessary thrashing.
Just to clarify, this does not mean that contributions are not welcomed. There are drivers to a project and then there are contributors and maintainers overtime. If there was serious contributors looking to come in early and be drivers, then we are open arms to letting them come and help assist. The idea of the multiple gateways and the gateway stack came from us, so it makes sense for us to be the drivers. We generally have an amazing relationship with the key developers in the ecosystem and when the time is right, I’m sure they will contribute.
Before Shannon became a thing, there was extensive research done behind the scenes, and I assure you it was not with the entire community. Yet… no qualms on your end about that (nor do we mind either). If you take a look at their development team, it is primarily composed of a single team as well for software development as well. Literally the same with WPOKT as well. So why are you so critical towards our approach and the negative framing? This is a reoccurring theme where you try to paint out a negative light starting off with keeping “LeanPocket” and “Geomesh” closed source. Then once open source, you don’t contribute to any of the repositories. Then you single us out with senseless framing.
But fine, let’s assume that your message is not bait. If you are so excited to contribute so early on, please send a message to me on Discord/Telegram/etc with an inquiry. We can talk about more in depth about how much developer resources you can contribute, what your team’s capabilities are, followed by an initial discovery call for some of the tasks we have now published. If it is within reasonable timeline that does not conflict with our deliverables for the next 2 months, and PNF will sign off on it, then I see no reason to not assign you the task. Sounds like a plan? Let’s find a time to discuss your bandwidth and commitment, and then we can move forward on next steps.
or… perhaps you’re just stirring the pot with senseless controversy and targeting us?
I agree with @shane that it is desirable to have every decision-making process more open and plural, including developing. However I think that the project is not yet mature enough to enable this without stagnate.
During the last 6 months a lot of work has been put behind the scenes to make this whole thing grow, a lot big decisions were made outside pubic discussion. One of the greatest decision ever made was probably the migration to Celestia, and this was done completely isolated from the community (both figuratively and geographically).
Today the landscape has not changed, there is a ton of work behind the scenes (I can think of at least 6 MAJOR features being developed). There is no person that has the bandwidth to keep up with everything, even I struggle to keep up with the main ideas floating around and I have a full-time job within the Pocket ecosystem. How can we expect to make the community take part in this process? it is just unrealistic.
I think that @poktblade is right and I get why he seems a little mad. I’m very thankful for them to take ownership of such a big thing, and I don’t think anyone in the community can deny them the right to take ownership of the vision and direction of the project. I think that the PNF is paying them because they trust their leadership, so do I, and if we make a vote probably the whole DAO.
Now is the time to move fast, when Pocket matures and stabilizes, we can create a lot of bureaucracy around it, but tight now we must follow the french and laissez faire.
Firstly, thank-you for a direct response. I’ve asked some very basic technical questions multiple times over the past 6 months (July, September, and this week) and there has been no response from you and your team. Literally not a single response to those questions. None of them are unreasonable by any account and it has been far from any kind of barrage (like maybe 4 questions ever 2 months… and most were repeats since there wasn’t an answer ).
I’m glad it’s open-source, but that is one piece of “the stack”. There are a number of modules that are supposed to attach right? That what isn’t clear… and why I asked:
That question honestly shouldn’t take more than a minute to answer and would provide a lot of insight. Just understanding how your stack works allows us to properly understand the technical goals (not the high level, non-technical vision talk that has been the only thing shared).
Your updates definitely lean towards you already having a solid idea of how this stack fits together, so I feel it’s perfectly natural to ask a few basic questions. You need to understand, that while some folks get excited about press release like updates, POKT is also a community of highly technical folks, and this initiative always encouraged asking questions.
Questions aren’t being answered however, and instead there is an announcement about it influencing Shannon… so it is perfectly inline to ask questions, especially when it looks like there is some kind of gatekeeping.
As I said, this initiative sounded much more open with information when it was announced, so it should be expected to have there a few questions.
Consistency
It was actually very open… especially right when they started writing actual code. The prior protocol team hosted research community calls, and even posted their internal research calls. @RichCL and I would geek out to those on the drive to Tampa (good times my guy ) This team has been very open as well, especially with the architecture (which is what I’ve always been passionate about).
It’s been very easy to be a part of Shannon in areas of interested, by asking questions both publicly and privately. I wrote the original ADR in public to argue that gateways should be a central part on the protocol level, and that came after talking about it months prior. It was accepted by the team and no doubted had a place in starting this intuitive.
WPOKT team was great as well. We built the wallet alongside them and getting access to information and resources while they were building was fantastic. Props to them as well.
So like you, I have no issue with how their teams has been, and like you have been passionate about gateways (and literally from the start).
We don’t do client work directly… that has never been our focus. The reason I pushed back on LeanPocket when it was closed source was because the DAO was told that it would be made open-source, only after pay $2M… which also didn’t include the contributions from the Feather Client which addressed the Tendermint/validation issue. There is a lot there to have an opinion on, especially when it had to do with more than 10% of the DAO resources Suggesting my participation in the conversation was simply to stir drama is misguided.
Regarding your version of Geomesh… I already stated my reasons very clearly above. That too was about DAO funds, not about the tech itself. I’ve never had an issue with folks building their own stuff, but it is totally fair to be involved in DAO discussions when it comes to funding and expectations.
Let us not conflate my technical questions today with those other things in the past that were focused around DAO resources. I’ve been critical of POKTScan being closed source and receiving DAO resources… though they are very consistent with answering questions. If anything I’m consistent to a fault
Moving Forward
lol… nope. We have built numerous products and tools that fit into the gateway ecosystem (QoS, LB automation, deployment automation, etc) and have been consistent with being in 99% of community calls. We are currently doing more wallet work, but after that there is a very good possibility we would to get our hands dirty in gateways. This type of deployment stack is literally in our MO (CC is literally a distributed gateway for POKT nodes).
PNF asked for folks to let them know how they can be a part of the OS Gateway stack… but that is impossible if the basic understanding of the architecture is unknown and any technical questions are ignored.
It would be shortsighted to see gateways as a whole as a Nodies vision, or to judge who you think will be able to participate. Being interested in gateways isn’t like a bluff or something
Overall, any technical questions or criticism from my side should not be taken personal. You were critical of the DAO paying for altruist relays (which totaled around 4% of the value of this initiative), but it’s all part of the DAO process.
If that is the way to have discourse on the basic architecture, then we can setup a time to talk. Seemed less efficient to me, but thanks for giving an option.
Is all of the code necessary to frictionlessly launch a POKT gateway open-sourced and publicly available now, @poktblade ?
Which parts of the code are missing, what else should be open-sourced, @shane ?
Here is the link to the github repo. What exactly is missing?
There are only 2 options possible. Either @poktblade has not provided all of the code necessary to become a gateway operator and launch it easily, or @shane is stirring the pot way above acceptable levels. Time to put the facts on the table.
The core code has been open-sourced, as I mentioned and linked to above. What wasn’t obvious was the architecture of how modules are supposed to connect to it, or what else is expected in a gateway stack. Past announcements talked about other products, like Nodies Cop, and Nodies Registry, which were a mix of open-source and closed-source, so I asked basic questions to understand the full stack. I don’t see anything wrong with that.
So those are the facts. You are welcome to revisit my questions and see if any of them are out of line.
I have published more concrete information on the GW Stack Initial Release Candidate - Nodies DLB, which is a summarization of our update and provides more color to the identity of the gateway stack (since many devs don’t read the forums). Long term, this will sit in our GitHub repository. Furthermore, now that the GW stack is open, the issues and what we’re working on are also open.
We spoke to Shane and unfortunately, they are tied up for this month to help in contributing with the open issues. However, if there are self-motivated developers who are interested in contributing, then we are more than happy to consider you as well. Please keep in mind, that we have to balance this with our deliverable timelines, so we are looking for developers who already have historical context with Pocket and are willing to do self-research and self-drive. There will be an amplitude of more opportunities coming down the road for more contributors and new developers.
From the sound of it, Nodies is being contracted to build three specific tools thus far:
, and just shows the potential of what the world of multiple gateway operators would look like. I’m really excited to start forth on what we can do for the ecosystem and the opportunities it opens up for others.
kudos to Poktscan team for taking this on). I cannot stress the importance of testnets.
On track
).
) This team has been very open as well, especially with the architecture (which is what I’ve always been passionate about).