10.2 Apps and Tools for H=N
This group is run as a decentralized, hierarchy free “WAO” - Working Autonomous Organization - currently operating on 5 goals:
- Help Curate the Toolyverse
- Empower Diversity
- Create Quality Txtz, Apps and Tools. As an example hicdex by @marchingsquare is an independently developed indexer / query tool that now powers a lot of other tools and even H=N itself.
- Advocate with and for Devs
- Grow and Support the Community
► How can hicdex maintenance be made sustainable?
Maintaining hicdex requires a lot of work. What does the community suggest to support its development?
- community donation pot for hicdex
- monthly fee paid by hic et nunc to hicdex
- hicdex in the list of projects you can donate to through the upcoming profit-sharing swap contract
Discuss it here and then go to vote: H=N VOTE
There are many collaborators which build tools around the ecosystem. It’s important to have some tools open sourced as batch minting, SDKs with some common used operations/queries for the “public good”.
Regarding hic dex I would suggest to optimize the infra that we have to meet some basic requirements. Having all metadata, as well token transfers, op hashes in a public DB regularly dumped. This can be part of the overall architecture of the system also. It’s important to have the build of the dApp I believe.
Donations for the development of such tools are interesting and are under study. But it’s important to develop token economics around such WAO efforts to persist value on-chain/in the ecosystem. An possible example for hicdex token economics if it were to expand also would be https://thegraph.com/
It’s still interesting to implement collabs contracts, swaps with other tokens, as well possibly auctions/offers. Part could be supported by the hicathon/hicetnunc2000lab/community. Support regarding OBJKT:hDAO swaps can come from hDAO holders.
I’ll try to particularly experiment indexing myself some contracts. A bit uninspired in doing this research and decentralising learning processes though. This service could be offered at least until the end of this year.
About the general topic of the community I can agree it is an interesting development, people develop new things all the time and surprise us with their creations. I think what we are able to do is to connect and to support developers - through hicdex but also through the other initiatives like developer events ([WG 10.2] Towards a H=N developer-oriented event?) or tutorials([WG 10.2] Work towards 5 tutorials).
What we are aiming for is:
- Make it easier to develop apps for and around H=N. Hicdex is an important part of that goal.
- Increase the diversity of developers, bring new people to Tezos blockchain development.
- Improve coding practices and code quality, and therefore also security.
To develop token economics around such an endeavor - this WAO - I think this must evolve in step with the efforts mentioned before so we keep it non-hierarchical, flexible and useful.
In order to make an informed decision on this topic it would help to get an idea what “a lot of work” means. How many people are working on hicdex for how many hours a day/week? Are there running server costs involved?
I’m the only one working on it and the workload is very uneven.
When HEN asks me for a new feature, the time it takes depends on the feature. Adding the ophash to the swaps took something like 2h, indexing the split contracts took 3 days and it’s not done yet.
When the chain is behaving properly there’s only 5-10 block rollbacks per week and they don’t always require reindexing everything or immediate intervention. Reindexing everything take around 1h of work. When the chain doesn’t behave, like last weekend with the granada issue, I had to fix the indexer up to 3x per hour for 48h. Without these manual fixes in the data, HEN is basically down (only serving stale data).
Maintenance is definitely what’s taking me most time, keeping it up-to-date, bugfixing, reindexing when a bad rollback happens on-chain. A weekly average of 1h/day seems like a reasonable guesstimate.
I keep server costs at the bare minimum because I’m not aiming at high availability and because it’s my money, so it costs me less than 100$ a month. The goal of hicdex never was to be HEN’s backend, and I don’t think it should be. HEN shouldn’t 100% rely on a single volunteer’s work, it’s dangerous and not only because of the indefinite downtime if I couldn’t take constant care of it, also because if I were malevolent I could manipulate everything from trade history to current prices of objkts, making people who don’t always check the details of their purchase transactions spend much more than the listed price or buy different things than they expected, or show counterfeit things on famous artists’ profiles, or ban people and pieces… well, total control over the data.
First of all - I must say that I just LOVE hicdex and everything about this crucial initiative (big up @marchingsquare !).
Secondly - based on your last part (starting from “The goal of hicdex never was to be HEN’s backend, and I don’t think it should be.”), I don’t think there can be any other option than paying constant fees for maintenance and even more importantly - spread the development keys/accesses to a group of trustees who will review pushes and get on board with this tool’s continuation. We must stick to a more decentralized approach when it comes to such a critical backbone of the whole platform.
Completely agree with what was outlined and thank you so much to both @crzypatchwork and @marchingsquare for all you do.
I agree that what is needed here is a system that works like The Graph which serves as a cheap piece of public infrastructure that people can pay to use, and functions as a decentralized entity. Unfortunately it would be virtually impossible for us to develop a comparable solution, so personally I actually think the ideal solution is to wait for The Graph to support Tezos. Once it does, anyone can create a “subgraph” to index data for any smart contract, which can then serve data in a decentralized manner that is really well designed and already working today as a decentralized service. Developers would then make micro-payments to perform queries, but have costs that are way way lower than any kind of real infrastructure like @marchingsquare is running themselves. And nothing really different in the approach one needs to take as a developer which is really nice, just a matter of including an API key in the endpoint URL. I know The Graph has been making a lot of great progress in the area of including more networks (they support 24 in total now), and about 2 weeks ago they gave a 80M GRT grant to “Figment” which is a super awesome website/service which already supports connections to Tezos among many others, see the announcement on their blog: Figment Awarded 80M GRT grant to join The Graph as a Core Developer
So personally I believe the best path forward is to wait for The Graph to implement Tezos mainnet as a supported network, move HEN to use a subgraph as soon as that becomes an option, and compensate @marchingsquare appropriately until that is the case. This solution would be cost effective, decentralized, highly available, performant, never require a code change to pull the data, and trustworthy - so in my opinion pretty hard to beat. Let’s hope they add Tezos support really soon! I will update this thread if/when they do since I keep a really close eye on The Graph.
Compensations were distributed and can be verified in the public ledger. Every intelectual effort towards this project is appreciated even tough it doesn’t authorise one to rip off concepts from hic et nunc ecosys. The outcome of this discussion, for documentation purposes, is that hicdex instance wasn’t “viable” for running in production and Integro Labs (teztools) is running an instance of such indexer, possibly to be renewed while other indexer solutions/implementations/improvements are also being researched.