This post is intended to offer feedback I first mentioned years ago, specifically regarding engineering considerations for the protocol.
The only network I currently view as a direct competitor to POKT is Lava. They’ve made some genuinely interesting design choices that I believe POKT should study and potentially adopt to enhance decentralization and censorship resistance.
Here are a few key ideas from Lava:
“Lava on Lava” (LOL): This concept minimizes the need for traditional gateways by allowing direct, peer-to-peer communication with nodes (e.g., via gRPC) to make queries. The network itself facilitates this direct interaction.
Offline Resilience: Their mechanisms enable P2P functionality even if the chain temporarily stops. Rewards can sync up later when the chain is back online.
Specs: A built-in protocol concept for describing any type of RPC/API service. This makes it permissionless for anyone to become a provider for arbitrary services.
Badge Server: I find this particularly important because it solves a FUNDAMENTAL chicken-and-egg problem: enabling end-users to pay for queries seamlessly. It acts as a funds delegation system. An entity with funds can delegate the ability to an account to make queries (“relays”) covered by the sponsor. This delegation can be time-limited or limited by query count. I’ve grappled with this exact problem in my own R&D. As a builder focused on creating an open web, I firmly believe end-users shouldn’t be required to manage wallets and treat internet access like a pay-per-view service.
Setting aside consensus approaches, Lava’s perspective on ensuring decentralized queries strikes me as fundamentally superior to POKT’s current “trustless portals” model. While technologically trustless, I feel the portal approach is flawed because it inherently creates points of liability and potential centralization vulnerable to top-down pressure. An actor operating the proxy still assumes risk, regardless of the trustless mechanism.
As a fellow builder developing my own portal service for community infrastructure, I can state with certainty that the only fool-proof, long-term solution is akin to BitTorrent: ensure all RPC access is direct to the providers. Any algorithms used for provider selection should not require a proxy equivalent to a WebTorrent WS bridge.
If the POKT community isn’t aligned with a more “BTC maxi” perspective prioritizing absolute censorship resistance, then please disregard this post. Consider it a statement on POKT’s chosen market positioning.
I am truly glad to see POKT moving towards greater decentralization and trustlessness; technologies like PATH are a valuable step in the short to medium term. However, I strongly urge the consideration of the ideas outlined above if the goal is to fully embody the cypherpunk and web3 ethos.
I’m not sure what you mean by “trustless portals”, but anyone anywhere can directly access the protocol. PATH is one option, but not the only one.
Shannon is fully permissionless. It doesn’t even require the API key that Lava does, and apps can stake directly to the network. No gateway needed.
Services can be staked permissionlessly on the network.
Using Path or another SDK, you stake against the network for access, and the burn is all on-chain. No humans required. It’s metered by query, so you stake for however much throughput you want.
It IS like BitTorrent. Think of your stake to the network using the SDK of your choice as your torrent client.
I’d love to get on a call with you and talk more about this. Unless I’m misunderstanding you, it sounds like maybe there is some disconnect around what PATH is or does, and its necessity to the network.
While it is not relevant to this convo, my project is in the Sia ecosystem and I have been full time grant-funded for years, this year included and view them as my home base for the most part.
I state this because given just frankly how large web3 is, I have not been watching how other protocols are evolving in the engineering decisions given ive been heads down building myself.
So im aware I may be missing a lot of nuance on what choices Pocket has made while ive been building myself.
I can say when I experimented with Pocket years ago, the primary R&D entity was soo busy the devs weren’t able to properly respond to everyone in the discord and it was verynoisy.
Back then it also was not clear how Pocket was going to do its decentralization. I have been kind of waiting a long time to see the fruits of labor here because I do want to see pocket win. I generally feel it is the more transparent and community-1st chain at present.
Saying all that, the largest criticisms ive had from pocket since ive known the project are the requirements for portals vs enabling direct P2P access. To make a comparison to my own tribe, Sia (decentralized data storage)… They are enabling direct browser access to hosts with their protocol by having the hosts operate over QUIC and effectively being browser 1st and are trying to actively minimize any kind of centralization as the default option to users.
Lavas P2P approach has been similar, though I checked back in with them tonight and it seems they have hidden? much of the experiments they created? Don’t know why, but the ideas I see are important.
This convo is less about PATH and more abstract on understand how Pocket is working now and what it does need to improve on.
Though some criticism is Groves docs on PATH basically have no info describing the engineer/technical approach/design decisions. As a non-native to this community, I am kind of running blind on understanding the current architecture…
I think you’ll find that much has changed in the ecosystem. We’ve been working towards a fully permissionless network for a long time, and your timing is great: our hard fork to the Shannon version of the protocol happens on Tuesday. Shannon is a ground up rewrite of how Pocket works to solve many of the earlier technical difficulties that resulted in needing a Portal to manage QoS and chain availability.
The old docs are getting completely rewritten too. They were, quite frankly, a mess.
Here are the new docs in progress:
Anyone can stake as a node (supplier), service, app, or gateway, with zero humans involved in the process. SDKs like PATH simply provide a quick start toolkit for a lot of common functions. We have more variations on the way, including DevDAO spinning up their ecosystem on Pocket shortly after the upgrade. By the end of the year, we’re targeting having dozens of special purpose SDKs to support many types of apps, allowing developers to fast track apps that rely on decentralized data for their back end.
We strongly believe in the cypherpunk ethos, which is why Shannon has removed any requirement for permissions or trust whatsoever. Literally everything is on-chain, including the burn you pay for using the network. And our tokenomics now treat it exactly as one might expect: no tokens are minted except as a function of the burn for an end user’s usage.
I’ve been on a ton of podcasts talking about my beliefs around decentralization, and what I call the “Free Speech Tech Stack”: fully permissionless stacks from top to bottom that are impossible to censor in any meaningful way. Shannon has been built with that ethos at its core.
I will look at this, but the one thing that hasn’t been mentioned is, does pocket have the ability to delegate funds to another wallet so an end user can be sponsored for RPC?
From my POV, this was originally for DNS queries, and the idea users need to pay to view the web puts the ideas of any sort of decentralized web browsing in the future as DOA.
My project has this as part of its very long term goals, and its something that I feel needs to be supported.
Besides that ill check the current design and give any technical feedback. I have learned a lot myself the past few years, and most importantly from that… I learned what the current limits are for creating a web3 and what doesn’t work now. That has shaped the direction my project has gone in for its own mission, and has informed me on what other fellow projects need to solve to enable an open web.
That’s fundamentally the purpose of gateways in the Shannon version of the network; to allow for any form of payment for access which is metered in whatever way the gateway supports, and allowing payments in whatever forms the gateway supports. It’s not a direct delegation function per se, but neither is what you’re describing, since the funds are ultimately spent. Delegation in Cosmos generally refers to staking your tokens on a validator. There are likely some semantic and functional differences there, but short answer, yes.
What I originally created as an experiment a few years ago was a component in system where a P2P peer could take a query/request for RPC and give a browser user access by covering all costs via a token/grant etc (I forgot the details lol).
However a key thing here is the browser still talked to the Lava network directly. It was not relayed through the sponsor. It was economic delegation only.
Yeah, if the connecting app is wallet A, and wallet B wants to sponsor connectivity for the connecting app, all they need to do is send tokens to wallet A to add to their app stake. It’s late and I’ve been working long days, so maybe I’m missing something, but pretty sure that meets the requirement you’re describing.
Sorry no, this is NOT about staking or any variant.
Its about a end user getting RPC resources by having a sponsor pay for it all and the wallet stays empty. The wallet ends up staying as more of an identity.
Another chain im involved in, Akash, actually does something similar where im talking directly with the network, but another wallet can do both an authorization of funds and fee delegation so that I never have to pay anything, and all my TX that I have to make, the funds get pulled from the sponsor.
I am actually using this now as a security setup so my main wallet holds a lot of AKT, and I use deployment wallets to own the hosting contracts. In that setup, I remove any risk of funds loss from using the deployment wallets in CI/automations. But for Pocket its more about letting users get sponsored by a big fish.
Aha! I understand. Essentially this is taking the non-custodial approach we already have for suppliers and applying it to app stakes. I think that’s a great idea, and something we could implement.
On suppliers, an owner non-custodially stakes on the network, and the operator actually runs the node. The owner is in control of the funds at all times, but the operator is who is actually participating in servicing data.
The app inverse would be exactly the same: a wallet owner (or “grantor”) would delegate access to an app operator (or “grantee”), and the operator would be able to access the network based on funds made available by the owner.
Also a user wallet is a mis-misleading because technically speaking you can generate a cosmos private key in typescript, and use that as identity to anyone wanting to give you sponsored resources. Don’t need a browser extension for that.
I have looked at the dev docs and they are the same page as grove.
What I am interested in is the technical architecture both on how gateways work and the protocol itself.
You say that you can treat Pocket like P2P and don’t need a gateway. I would like to understand how exactly. Does Pocket actors support web based protocol access (web-based GRPC, QUIC, WS/web transport).
Additionally… You may have overlooked the other ideas mentioned. One that I don’t think has been covered is Offline Resilience.
But the sources actor seems to be the same idea as lava specs which I think is cool. I also find it awesome your trying to build for AI in a real utility-1st way and not plastering that in marketing for “investors” :D.
Oh also, I think most of the other questions have been answered at this point, but I don’t have an answer for “Offline Resilience” yet. It’s been another 18 hour day and I can’t answer this adequately yet. I’ll circle back tomorrow after I’ve slept.
BTW nothing has explained how path itself works so when you have a fresh brain the docs really need architectural deep dives in additional to big picture overviews.
That’s something Grove built, so they’ll need to provide the docs for that. Each engineering team needs to support the SDK they’ve created. It is open source, so you can browse the repo.
Today I have zero time to explain, so I’ll make this quick.
You don’t need a Gateway in POKT, PATH et al. is an SDK, it is not part of the protocol and it is not needed to interact with POKT. You can create an app by using a simple stake tx and then get on talking with suppliers in a fully perimssionless manner. I have a whole service working without even a gateway entity.
POKT has “offline resilience” too, if you are in a session you can keep on talking to assigned nodes. If the chain halts, the session just last longer (there are some untested limits like merkle tree lengths, but is VERY unlikely to have a halt lasting days). No centralization here.
POKT can run anything, I got LLMs, embeddings, image generators and other nice stuff working on localnets. POKT just don’t care what you send.
If you want to create a free service and have people join, you can safely do it, just create a new service and put zero fee. No supplier will join, so you will have to go and pay them, but any app can consume for free. We don’t solve the payments for you, that’s right, but we provide a way for you to put free stuff if you will.
There is nothing as permissionless as POKT. In lava you cannot go and put a data source or create an app without going through a portal, for POKT that’s solved by a simple TX, the only thing that the blockchain will ask of you is to show the tokens.
I was not able to follow all your interactions with @Jinx but I feel you have been out of the loop for a very long time. Shannon changed everything and should be a much more crypto-first solution than LAVA.
