With this update from Jorge, I believe PoktScan team should be compensated approx. 1/5th of the requested amount now and then compensated additionally when it will be much more clear if Geo-Mesh can be used in v1 in any way. Work should be rewarded, but not in the amount which directly disrespects most important part of the Pocket - core V1 builders.
1 Like
I don’t think its pertinent to disclose things like hours if y’all even track that in the first place. I mean, how would such a metric even be verified? It might make sense to use hours on a project that is clearly scoped & that any average developer could do but when we’re talking about something as impactful as GeoMesh & taking in mind that it wouldn’t have been identified or made it to release without PoktScan, we can’t cramp that innovation with something like logging hours as if they are a consultant company. Let me give an example of why hourly rate is detrimental here. If Poktscan is to work on something less technical and could be very clearly identified by community members i.e. making discord bots for automating dao pathway, would it really make sense for the DAO to compensate them based on their hourly rate? We’d be charged hundreds/h for something with low technical requirements that a hobbyist developer could do(+% premiums don’t really solve this either). This is why we need to look through a different lens and abstract away from hours. The way I see it is the DAO voters are leveraging the treasury to “purchase” (in a loose sense) a client as opposed to “employing” a team and purchasing developer man hours.
The questions I ask myself are this:
Was this identified to the public prior to PoktScan’s involvement?
No. They made the first post about it and it is uncertain if anyone else would of stepped up to release the research.
Would it have been released without them?
Probably not in any reasonable time frame.
Has the value add of the client surpassed the asking amount?
100% yes. I’m not going to go deep on specifics here but its clear cut that this client has brought value well beyond the asking amount (even in the short time that its been released) and will continue to do.
which leads me to my conclusion as a dao voter…
The asking amount aligns with the value of the deliverables and I am in full support of this (pre)proposal.
4 Likes
First and foremost, I would like to thank all for taking the time to engage with this proposal and offer your insights, comments, and criticisms. We appreciate the diverse perspectives you are bringing to the table.
About Poktscan:
I’m sure that all have used the poktscan.com portal and know through the grapevine that at Poktscan we run nodes. What you probably don’t know is that for now, Poktscan is sort-of a pseudo social enterprise that combines the principles of a traditional for-profit company with the mission-driven focus of a non-profit organization. This is why, for example, poktscan.com is free for the community.
We have a team of ten talented engineers working on a number of products that will help the Pocket ecosystem grow and scale. More on that in the coming months. You probably know some of our most vociferous members - Jorge leading engineering and Ramiro leading data science and AI. The rest of the team is not very visible and like it that way. We have have Alan and Alexis working on pixel perfect UI’s (v2), Jeff and Seba on our backend and a ton of other stuff, Julio on our orchestration product, Vini on infra, Nico on data science and AI, Pablo on pure math, and last but not least Fede on design and keeping honest our engineers.
Genesis of Geo-Mesh:
The need to build Geo-Mesh does not come from a community or a PNI requirement but from a network anomaly identified through our data and algorithms monitoring network fairness and behavior.
The red flag for us was that a small number of nodes were being assigned relays beyond the limits established by our network models. Till then, you could not have the same nodes at multiple locations hence traffic per node per session was limited by response times. This was an important competitive advantage that only a few had. This anomaly led us down the path of discovery, and later building the product we launched last year. You can read more about this in our initial post (POKTscan’s Geo-Mesh).
Network fairness and equal playing field are at the core of our mission, so rather than reap the benefits of the technology for personal gain we decided to share with the Pocket community.
Estimates and Funding:
We decided to put forward this proposal at the request of several members of the community. Initially, I was particularly hesitant due to reasons not germain to this proposal, but was convinced otherwise due to its value.
Our proposal estimates are based on two components: 1) Cost to build, plus 2) Cost of opportunity. The cost to build is what they are and can be seen below. The cost of opportunity or benefit to the community was trickier given that there is no model to follow.
We looked at the following impact criteria: traction, benefit, and ecosystem-wide significance. We decided to use 25% of the total development cost vs ecosystem impact given the fact that it’s something unmeasurable at this time. We all concur that given the fact that Geo-Mesh provided an opportunity to compete for relays to small and large node-runners was worth at least 25% of development costs. Please note that we are requesting $325K and not $324,862.50. This will be adjusted in a final proposal to reflect the exact amount.
The path forward:
We believe that the funding request is fair, evaluated professionally and methodically.
Consensus and voting can be complex processes, especially in larger groups. While it provides a mechanism for making decisions that is transparent and democratic, it can also discourage participation and lead to frustration among members. In our particular case we welcome the engagement, however others may shy away from “town square” debate. Process guardrails may be necessary to encourage participation.
10 Likes
@michaelaorourke I appreciate the context and all the details around the team’s structure and the project. Given the size of the team and the scope of the effort, my main goal right now is to understand if we’re only reimbursing GeoMesh, or poktscan.com with support with forward-looking support.
The origin proposal state that Geomesh timelines were:
Looking at the numbers:
- T: Total number of hours across three months (sum) = 3208
- A: Average number of hours per week per individual (estimated) = 50
- N: Num individuals work A during T = 3208 / 12 / 50 ~= 5
tl;dr The proposal implies 5 FT employees working for 3 months.
I believe the asking amount is fair if we are framing it as GeoMesh + PoktScan V1 + PoktScan V2 reimbursement. Given that the amount of work something like PoktScan takes is significantly larger than GeoMesh, the asking amount could be seen as:
- A reimbursement for helping reduce the network’s latency. This is important for the quality of the service but is also a vanity metric on various sites that help in Pocket’s industry presence, even when 10ms don’t actually make a practical difference.
- A donation to help continued support of potkscan, an invaluable tool in more ways than one.
In my opinion, 5% of the DAO’s treasury is fair if re-framed as stated above.
4 Likes
When moving this to proposal stage, I recommend updating the asking amount language to the following:
The $POKT equivalent to US $325,000 (using 7-day trailing average of $POKT/USD price at time of approval) to cover development costs and initial maintenance.
Thank you @michaelaorourke for your willingness to disclose your numbers (labor hours etc). I think that is more than sufficient to answer various misconceptions that somehow it is more lucrative to contribute to the ecosystem as a community contributor as opposed to being a salaried or contracted core developer.
3 Likes
Here are my two-cents for what it is worth . I will post almost identically to PoktFund proposal (and TH proposal if/when that comes out).
-
Evaluating funding size in terms of percentage of treasury is good. Even better, IMO, is evaluating it in terms of how much of the inflow into the treasury it represents. The nuance of difference is important, because the first method tends to promote a “lack” mentality (i.e., “once 20 funding requests of 5% of the treasury are approved, the DAO will be broke”) while the latter keeps in the forefront of the mind that the DAO treasury is more like a river flow to be managed to match inflow and outflow. Currently DAO receives approximately 2M $POKT per month. So this ask represents 2 to 3 months worth of DAO budget. This, to me, seems like the right ballpark for an effort and an impact of this magnitude.
-
The benefit to the project and the ecosystem of open-sourcing solutions for mutual benefit rather than keeping proprietary to self-benefit cannot be overstated. What behavior does the DAO wish to incentivize. Reimbursing to the level that tells contributors that they will be rewarded adequately for open sourcing will incentivize more of the same in the future. Reimbursing at a miserly level tells contributors that in the future they are better off keeping innovation proprietary and milking every last competitive advantage they can for themselves. To me, the former is a vastly wiser and superior course of action.
-
Applying the “thinking in bets” idea, also results in the same conclusion. The value poktscan has brought to the ecosystem is tremendous. This is a multi-person effort and there has to be reasonable reimbursement in order to keep the team together and contributing.
-
Repeating myself a bit: this is a multi-person effort; some of the comments made to the effect that “we support funding but the ask is too high” are likely not taking into account this fact and instead comparing their salary or contract labor rate to this ask as if it were all going to one person. It is not.
4 Likes
Hey @Jorge_POKTscan and @michaelaorourke
Thanks again for your excellent contribution
Sharing this here so we can add this framing around impact to the debate too
2 Likes
We are grateful for all the great contributions that PoktScan made to the Pocket ecosystem. That said, we are not supportive of this reimbursement request for the following reasons:
1\ “Geo-Mesh” feature helps a subset of the service providers in terms of competition, but it does not make Pocket Network better in any significant way.
The network didn’t become more reliable, more cost-efficient, or improved its QoS as a whole because of Geo-Mesh. There were nodes in all high-value regions in the first place, and the CherryPicker chooses the fastest nodes regardless of Geo-Mesh. If anything, Geo-Mesh increased the overall cost of the network, because now, all providers must be on multiple datacenters just to be competitive. Free code is one thing, but provisioning all those gateways in multiple data centers is entirely something else, in most cases, ruling out any small providers with less than a few hundred nodes.
In fact, one could argue that a better proposal might be limiting nodes to a region, therefore helping reduce the cost and improve QoS (if a particular region is all you’ve got for a particular node, you do a much better job for that node in that region).
2\ Reimbursement amount of $325K USD is too high for the deliverable.
Just to put things in perspective, PNI recently asked for 20M tokens for the entire company (60+ personnel), for the foreseeable future, and for a high-value deliverable (i.e., v1), and promised they would deliver v1 even without the grant. Relative to that, this reimbursement request is too much. Finally, nitpicking: the calculation is made based on working hours i.e., “5 FT employees working for 3 months”. We believe that software projects should not be priced based on engineering hours --because less skilled engineers would be paid more.
3\ PoktScan, while a very valuable tool, was running ads for their own services until very recently. For all I know, they can start it again.
Just want to clarify some points. I will leave out all the discussion over pricing and over POKTscan (that is not part of this proposal as stated before).
Its OK to disagree with this proposal, but spreading false arguments is not acceptable.
In fact it did become more reliable, cost-efficient and inprobed QoS.
- It is more reliable because the probability of entering a session with a local node went up. This means that apps get less failures because of timeouts.
- It is more cost efficient as you dont need to pay for Pocket Nodes deployments in each region.
- It improved QoS, this is a fact and it can be seen in the original post of GeoMesh.
This statement is misleading. CP chooses among the nodes in its session. Session nodes are chosen randomly. Before GeoMesh the chances of an App being paired with 24 foreign nodes was very high for many regions.
This is already a feature for V1. But we wont get geozones until then.
And even then GeoMesh could be used to enable the same node to be staked in many regions.
2 Likes
Regarding the technicals of how the v0 cherry picker works and the benefits that geo-mesh brings given the limitations of the cherry picker, I just want to second what @RawthiL says above. It’s fine to debate over funding amount etc, but the solution does indeed increase reliability, cost-efficiency and QoS.
2 Likes
You can trust me on this, misinformation is not my goal. It never has been. I am a Pocket investor myself, and want the best for the ecosystem. I never target any particular person, project or entity.
Maybe I am missing something, but I genuinely think that GeoMesh overall doesn’t help the ecosystem much. It helps node runners who uses it at the expense of the ones who don’t. Sure. But from apps point of view, it doesn’t help much – the relay that is served by GeoMesh node would be served just as quickly by the native habitant of that region anyways.
This can also be supported by the deliberate removal of this type of functionality from v1. Specific quote from the v1 docs: “If an actor is everywhere, they’re nowhere.”. The expert team, who has been spending dedicated time and researching this for a long time decided against it.
Regarding the overall speed/QoS: There are 24 nodes in a session (btw, it is not the CP that picks them, it is the protocol itself). Statistically, there will be a few in that region or a region that is sufficiently close by. CP will choose the most performant one and apps will be served right with or without GeoMoesh. GeoMesh can help in some super unlucky / theoretical cases, and during the few seconds while CP figures things out. Sure. But does that really matter in the larger scheme of things? If so, is this the only way to achieve that? And at what cost?
Regarding the cost: How do you expect a small node runner to be able to afford multiple regions with all the backing gateways and additional ops? Even if the code is free (and apparently it is not per this proposal), they still need the HW and ops cost. Any node runner with less than lower 3 digit number of nodes are ruled out to run them profitably. They cannot justify to stand up 15 gateways in multiple location and maintain them. In the past, a node runner could pick a region, and take pride in that region and do their absolute best in that region. Not anymore.
Network strives for a delicate balance of decentralization, cost and perf. IMHO, GeoMesh hurts cost aspect notably. As a result, it hurts decentralization, too, by making smaller node runners unprofitable. I am sorry, but I fail to see enough perf improvement (from apps’ point of view) for the majority of cases to justify the notable cost increase and negative hit on the decentralization.
All this said, I must add, I appreciate the open source nature and trailblazing approach. I love people who experiment, and try new ideas, and share the knowledge with the community. Thank you. I think that aspect is worth some $ rewards. Pocket Ecosystem is better with more open discussions and sharing code. It should be recognized. I’d be happy to support another proposal at a smaller $ amount.
3 Likes
For sure it’s helped @bulutcambazi
You should have seen this list before Geo-Mesh. Right now its about 4 pokt between the bottom node operator and the top one. Without Geo-Mesh this list would be 10+ pokt between top and bottom.
And LeanPOKT has helped so much with node running costs that your points about Geo-Mesh making things more expensive are immaterial.
2 Likes
- Apps have a max amount of relays per session, that amount is split among the 24 nodes in a session, that say, when those “good nodes” the CP choose first, reach the max amount of relays, they are not able to handle more (by protocol) so, the CP need to move to the next ones that still can reply.
Without Geo-Mesh, after those “good nodes” on a region, the other nodes are faraway nodes, so with those nodes, the APP will get relays with a higher response time, so that lower the QoS for the applications, at the end of the day those apps are who pay to use this service (Pocket Network) - Geo-Mesh helps the node runners with enough clients/nodes to be competitive against Services like Coder, which was running the same thing as Geo-Mesh but does not share with anyone, so at that moment, they were getting x4 times more relays than anyone else. By the way, that was what alerted us that something was changing on the network.
- About the very small node runners is true, they may are not able to handle multiple regions, but they in the close future may have access services like the one @shane is creating. Also, they are always welcome to use the service of any provider to get better results, or even join anyone else and share infrastructure (chains). After all, this is a community, right?
2 Likes
To preface this post – I’m a small time node runner who didn’t implement the major upgrades of the past year (Geomesh and LeanPokt) for various reasons. I’ve had to stay afloat using other measures – playing the validator game, keeping my costs as low as possible, and supporting those chains with a large proportion of relay traffic coming from my specific region.
That said, I am inclined to support this proposal just out of principle – open sourcing a game-changing modification to the protocol to give the whole community the opportunity to use it is something that should be applauded and rewarded. I don’t know whether the ask is appropriate, and would defer to the bigger brains on this. My evidence is also anecdotal, but I do believe that GeoMesh has made it possible for other small time node runners to stay afloat – using a “buddy system” to share chain nodes and investing their sweat equity – and not throw in the towel in favor of a pooling solution or delegating their stake to a large provider. It’s great to advertise having a network of 20+ K RPC servicing nodes worldwide, but if they are ultimately controlled by only a handful of providers who have the economies of scale to stay profitable, that’s just centralization with extra steps.
On a semi-related note, I also find it peculiar that some large node runners who developed an in-house mesh client, and who subsequently sent me numerous advertising emails about how their nodes outperformed the network average, are now stating that an open source version doesn’t help the network. If that is their position, then, in addition to voting against this proposal, they should cease to use their mesh software, and call upon all other node runners to do the same. What’s good for the goose is good for the gander and all that.
11 Likes
@ Misskitty42 I agree with your principle. I love and support the contributions to the ecosystem. I totally support compensating that aspect, not only to do right by PoktScan team, but also to encourage future contributions. Just not at the amount they ask for.
1 Like
There would be no need of geo mesh if certain large node runners did not use their resources to game the system. Geo Mesh only evens the field, and allows for other small node shops and independent node runners stay in the game. This increases competition and bring node prices down benefiting the ecosystem.
Secondly, we need to absolutely support measures to bring such code enhancements out and regularize the code base. Each node operator specially a large one using a different client that is not open source is a big risk to the stability of the network.
3 Likes
100% agree with this. Requested amount is just way too high.
1 Like
A little late chiming in here but this proposal seems reasonable & fairly priced.
Geo-mesh made Pokt Network able to compete with any centralized node provider at scale in terms of QoS. This took significant engineering effort that had it not been open-sourced, would have left the network lop-sided in many ways.
$80/hr for these kinds of resources is extremely fair. True market value is probably more like $120-$150/hr. This is a deal.The investment by their team was made several months ago, so its not like a money grab here.
This community should be incentivizing MORE of this type of open-sourced development work. This is high quality work done that has had a clear positive impact on the reliability and capability of the network.
This is such an obvious yes vote.
5 Likes