Between my ‘day job’, unikernel development, and R&D on NoM Smart Contracts I have been… busy. Recent discussions and development efforts have prompted me to step back and reassess the best path forward in terms of prioritizing resources and energy. Here’s where I believe the focus should be:
Building a Developer Base & Ecosystem
We need to attract and support developers, providing the resources and tools necessary for them to thrive. A strong developer ecosystem will unlock innovation and bring new energy to the Zenon Network.
A new developer’s portal devoted entirely to the ecosystem (developers.zenon.org) with technical documentation, tutorials, dev sandboxes, etc.
Smart Contracts on NoM
The future of zApps lies here, and advancing smart contracts on NoM is key to creating a robust ecosystem.
Will only be meaningful if #1 is eventually achieved.
Bitcoin Interoperability
A massive undertaking but one that will take Zenon to the next level. However, it is a substantial effort that will require a solid developer base (as in #1) before we can begin making meaningful progress.
Now, the reality is that I can only focus on one major initiative at a time in the near term. Both #1 and #2 are realistic projects I can take on personally, but #2 relies heavily on successfully building a developer community first.
I have decided to take to this forum in attempts to gain perspective on which direction the community thinks I should prioritize.
Please participate in the poll below and vote for what you believe should be the given a higher priority. Once we determine the community’s preference, I will submit a request for funding to support the winning initiative.
WHICH SHOULD BE GIVEN A HIGHER PRIORITY IN THE NEAR-TERM?
I personally think #2 will be required to achieve #1. And if we can have an open dialogue while you are doing #2 I think the marketing folks here can help with #1 (while you are doing #2).
In addition, @aliencoder is working on docs. The community has agreed to help when he makes the docs public.
So if you work on #2 and keep an open line of communication with the community we can parallel path #1 to the best of our ability. If you tackle #1 yourself, there is NO way the marketing community can help with #2 so it’s likely to take longer (unless you can sell some 10x devs on the vision).
Actually I’m reading this again. Can you elaborate on this a little? Do you require assistance to complete #2 and will these devs need to be able to solve this puzzle first?
I think attracting new “devs” is different that attracting devs that can help with #2. You have been involved with the project for years. You understand it from the ground up. Also I assume the experience required to help with #2 requires someone with highly specialized skills. Maybe only a hand full of people on earth can help?? Can #1 really help you attract the type of people needed to work on #2?
We are perpetually stuck in the Chicken & Egg problem. LOL.
I am hoping to have a working WASM runtime prototype on my own in a short period of time. Some insight from other devs may be needed, especially with regards to gas metering mechanisms and cryptographic methods and proofs (I am thinking zk-snark)
Once I have a testnet running, the real value of the devs will become apparent. We will need people to build on the platform.
Once the initial version of the documentation is live, I truly believe the community is more than capable of maintaining, improving, and expanding it to cover tutorials, deployment and maintenance of testnets/sandboxes, etc…
Even without programming expertise, anyone could leverage LLMs to analyze source code and create really good documentation. The barrier will keep dropping.
Efforts like the Supernova extension chain, allows us to leverage the tooling and much larger ecosystem of Ethereum/Cosmos, making it easier for developers to build in our ecosystem. I can’t think of a better introductory playground. All that is required is a lot of copy pasting and slight adaptions to proven developer experiences.
Take this as feedback from a long-time community member, who basically took on learning how to program after I discovered Zenon, in a pre-chatGPT era. It would have been nice to have proper SDK documentation then. Now, it’s also great to have one, particularly for big picture stuff, but not as critical. I can take the Zenon Dart SDK and use a LLM to walk me through the code.
Pursuant to what @coinselor said, the poll voting might be more of a reflection of what the community sees as priorities, than where @EovE7Kj 's skills are best employed.
Perhaps @aliencoder can chime in here regarding where he sees himself focusing his energy. That might provide some perspective on how can we can best dedicate our alien resources.
As to what coinselor had indicated, I think your skillset would best be utilized working through smart contracts on NOM. Evidently #1 is a priority however that could be worked through by other community members that are not capable of building out smart contracts. Just my 2 cents
I’m here to help with #1 – technical docs would be helpful to kickstart this initiative. I propose this architecture:
intro.developers.zenon.org / intro.developers.zenon.network = an ORG funnel framework lander which sets the NoM referral to a default address (we can chose which), and also gets included in Attribute for anyone to market plus receive NoM bridge referrals. The landing page shape and purpose is really to set the referral + guide the user into the technical docs / initiatives. Its first page resembles something like satoshisl1.com (graphics + buttons to technical docs and other initiatives). Think of it like a linktree type of page, where the NoM bridge referral is set for marketers / default fallback. Multi-lang supported, can be iterated in due time.
developers.zenon.org / developers.zenon.network = technical docs platform deployed by whoever, I can point the domain, someone else can host the actual docs if they wish. Happy to contribute to its management as well.
my recommendation is docs for the project should live at zenon.network. It’s more likely that devs will maintain them in that location. That is where those repos are, so makes sense the docs for syrius and go-zenon are there too. In addition, John Maxwell is going to comment syrius code in a way that code comments will roll into docs automatically. I don’t know what domain that will resolve to, but the docs will live in the code.
I assume docs for other repos (like the orchestrator) will live in that repo (HCT) for the devs to maintain the docs.
I looked into this a couple of months ago when you initially shared and think it shows a lot of potential. I am also exploring the possibility of using Zig with WASI. I have spent a bit more time fooling around with Rust recently and am having some reservations re: dependencies, cross compilation and compile times… memory safety is the beacon of ‘Rustaceans’ but the language is only memory-safe insofar as the developers using it will make it. Many crates that I have been using recently are largely memory-unsafe, and I haven’t been able to see the benefit of using Rust in those cases over C (the compile-time for a trivial program was about the same)
It ultimately comes down to personal preference… Maybe it’s because C is my native language, Zig feels better to me.
I have played a lot with Unikraft in the last 6 months, and I think it is great. I actually have a znnd uk that I built with unikraft that I think is still running on my NUC. This is probably the avenue we will take to automate deployment of zApps in production
@EovE7Kj you mentioned early on that you have been hanging around the hoop for many years. In your time here I assume you’ve come across some pillars you are frens with. Maybe some pillars that don’t normally vote.
How about you help us a little and ask your frens to look at this AZ and vote. You want devs, we want votes… We have been trying very hard to get devs, can you help us get some votes.
