Hello! Thanks for the follow-up @Josh-StreamingFast and @thanpolas.
I am conscious that the scope of the discussion has gone from quite a focused consideration of UX and barrier-to-entry (i.e. how can we make sure that developers who want to query subgraphs can do so) to a larger consideration of the overall architecture of the protocol.
To stick on the initial topic, as I said before I agree that this is something that we should address. I agree with you that faucets are not a great UX, so something that looks more like an automatic “free tier” could definitely make sense, and I think there is some interesting thinking to be done there.
As you mention later on, the gateway is currently a centralised service, so a short-term “free-tier” solution could be quite easily achieved via the gateway. However to address the reason you brought it up (“The Graph service, is very much centralized”) - the current architecture is not the end-state for that reason, as the overall approach is one of progressive decentralisation over time. For this reason, solving the “subgraph consumer barrier-to-entry” problem in the gateway is maybe not a desirable approach.
To quickly jump back to some of your broader points:
-
It seems that you would generally prefer the subgraph creators pay for query fees, rather than consumers? (i.e. “I know it can be tracked in detail, which graphs attract the most queries, and split the costs fairly this way.”) Subgraph creators have already invested time and money in creating subgraphs (as you point out), so I am interested that you think they should pay even more if their subgraphs are widely used, and wanted to verify that was your recommendation?
On that point, with the current gateway architecture, it is the case that developers can and do pay for query fees on their subgraphs (see billing: Billing on the Subgraph Studio | Graph Docs), though for the most part that is being paid for end users of their dapps, rather than for other developers to query the subgraphs for their own purposes. -
The use of GRT as a utility token in the protocol is pretty core to the overall protocol design. Obviously GRT price volatility does introduce some challenges, but that is not a unique problem to The Graph protocol - the same is true of Ethereum itself of course (where the 20% price move you give in your 10 to 12K example happened in the last 7 days). I am interested in what your preferred approach would be? My personal perspective is that there are interesting solutions to be built managing volatility and costs between tokens for web3 developers in general.
-
Whether the query is a good unit of billing is certainly an interesting topic, though it is a pretty common pattern by which to pay for APIs. You describe it as an unfair unit, partly because it penalises less optimised applications, but that in particular would seem like a good thing (subgraph consumers should be incentivised to build optimised solutions).
On your final recommendation: “To conclude, what I am suggesting is, that the graph, touches base with its constituents and stake holders. Hear them out, and together formulate a strategy and policies to move forward.”
As a community we try to stay in touch, either here on the forum, or on Discord, or during the Monthly core devs meetings. I certainly welcome you to join the next core dev meeting in the first week of next month. As I said at the start of this message, it seems that you have misgivings that are deeper than simply wanting to be able to make some queries without paying GRT. Like all web3 protocols, The Graph Network is a work in progress, and can certainly improve - see this thread for information on the GIP process: GIP-0001 and Getting Started with GIPs, GRPs, GRCs, etc. Would you be able to summarise your suggested change as a GIP, even if very briefly? That would give the community something more concrete to react to than this forum thread, which by its nature is more discursive.
Thanks again for taking the time to reflect on The Graph Protocol!
Adam