I know @aliencoder has an approved AZ for this work but he is very busy with Supernova and the BTC Bridge work. We need to step up and help get the docs done. Anyone with AI and some extra time can help audit and write docs. Not every page is technical.
I would like for this to be a community effort. Anyone in the community can write pages or review (proofread / correct) draft pages. We can track our contributions on this page with the goal of allocating the AZ according to the work summary.
On March 1, 2025 we can make the docs live and manage them from the zenon-network repo going forward. Over the next 60 days I plan to work on the docs every day and post my additions for review or comment. You can either comment here in the chat or submit a PR directly in my repo to suggest changes. If you want to ask for an allocation of the AZ for the work, please update the contribution page.
DRAFT pages that are ready for review & comment. I’ve been moving quickly focusing on getting as much work done as possible. So I expect there are errors. Please help me find them.
Would you guys mind reviewing this page on SDK Status? It will take just a minute or two.
I would like to add a comment on what is missing. For example @digitalSloth I think PHP is missing PoW for TXs? If you can add a quick response for the SDK you cover I can add a comment and if you need help will mention that.
I wanted to share an idea to improve how we track the progress of our SDK implementations. Instead of using a single completion percentage, which can make it seem like the SDK isn’t fully ready, we can break things down by functionality.
Each functionality would have its own progress percentage, showing what’s fully implemented, what’s still in progress, and what hasn’t started yet. This should give a much clearer picture of where things stand.
To make things consistent, this template can serve as a standardized method for tracking SDK progress. Every maintainer would be responsible for maintaining and updating this status in their respective repository. This ensures the status of each implementation is transparent and accessible to everyone.
Additionally, by standardizing the format and location of this status file, we could enable our documentation system to automatically scan through the list of repositories and retrieve the status directly from a specific file. This would streamline the process of keeping documentation up-to-date and provide a centralized overview of all implementations.
Here’s an example of the proposed format:
SDK Status Template
SDK Name: [SDK Name]
Repository URL: [Repository Link]
Maintainer: [Maintainer Name]
Functionality
Status
ABI Encoding
Completed
ABI Decoding
Completed
Argon2
Completed
Ed25519
Completed
Bip32
In progress
Wallet
In progress
PoW
Not started
Ledger API
Completed
Stats API
Completed
Accelerator API
Completed
Bridge API
Completed
Htlc API
Completed
Liquidity API
Completed
Pillar API
Completed
Plasma API
Completed
Sentinel API
Completed
Spork API
Completed
Stake API
Completed
Swap API
Completed
Token API
Completed
Unit tests
In progress
Documentation
In progress
By adopting this approach, maintainers can easily share the current status of their SDKs, and our documentation system can ensure that this information is always up-to-date and centralized.
Let me know your thoughts or if there’s anything we should tweak to make this even better!
This basically boils down to creating a boilerplate template for SDK implementations. We could start by setting up a repository for this. I’m thinking to use a Json file for the status information and try to automatically process it in the docs.
Create a Central Boilerplate Repository
This repository serves as the starting point for all SDK implementations.
Include the necessary folders and files (e.g., README.md, CONTRIBUTING.md, etc.) to ensure consistency across all implementations.
Add a Standardized JSON File for Status Tracking
Define a file (e.g., status.json) that every SDK implementation must include in the root directory.
I can parse the json into the docs and can create a script to pull in the status.json from other repos.
How can we standardize the README.md for all the SDKs if they will each be different? Or is this a README.md that describes the status.json only?
Are you thinking we create a repo in /zenon-network that is something like /sdk-status? In that repo we have the README.md, CONTRIBUTING.md, and config.json which explain how each SDK needs to include these files? The confg.json will have the full structure (provided above) for each SDK author to maintain? We would ask each SDK dev to keep the config.json up to date and we can scrape that data every day and pull into docs if anything changes?
Consensus is updated and ready for review. I received some feedback from TG to make it simple and generic. I have done that. I also discuss the transition to Phase I by introducing N&T with a generic definition.
Yes the main plan is to create a repository, probably called /sdk-boilerplate, that acts as a starting point or template for all SDKs. This repo would include some key files:
README.md: A guide for developers that explains what the SDK needs, with examples they can use or adapt.
CONTRIBUTING.md: A file with instructions on how to contribute or keep things consistent.
A metadata file: This would define important details about the SDK. Developers would be responsible for keeping this file up to date.
A script or tool would regularly check these metadata files from all the SDKs, gather the info, and automatically update central docs whenever something changes.
I’m leaning towards calling the repo /sdk-boilerplate instead of /sdk-status, because it’s more flexible and leaves room to add extra tools or resources in the future, like linting tools, CI/CD templates, or testing guidelines.
Concerning the config.json file name. I’d go with sdk-metadata.json or metadata.json because it’s clear, specific to SDKs, and flexible enough for future changes. If the file is more about settings than descriptive info, then config.json could be a good second option.
