construct0, the first steps of an organisation with great aspirations
 |
| learn, develop, improve |
[Update 0412023: MIT license references are no longer applicable, more about that soon]
That's the spirit of construct0, let's shed some light on the internal structure first; construct0 is (pending approval) registered as a unincorporated association (hereafter coined as an organisation) in Flanders, Belgium.
The common goal of the organisation is to unify software designers, architects, engineers, developers and polymath visionaries in order to build open-source and closed-source software solutions.
The open-source solutions are intended to be made available to the public under the MIT license and partially, to our disappointment, due to legal ambiguities, intertwined with an inherited The Unlicense license for some projects.
Moving forward any modifying or extending development done to forks of repositories licensed under The Unlicense license will be performed under the MIT license.
More information on this subject: https://softwareengineering.stackexchange.com/questions/147111/what-is-wrong-with-the-unlicense
Changing the license of a repository to an MIT license does not imply that the whole repository now falls under this license, as prior commits were performed under prior license.
The merit of the The Unlicense license is clear and in line with the MIT license but contains legal ambiguities and contradictions, as long as the intentions of the contributors remain within scope of the MIT license, I do not foresee problems in regards to liability. Any further contributions will fall under the MIT license and any possible prior development liabilities rest with the contributors of those who participated while the The Unlicense license was active.
Moving aside from the licenses which pertain to the open-source domain of the organisation, I'd like to shed some light on the structure of our presence on GitHub:
The "construct0" organisation on GitHub contains new or forked repositories on which development will occur and contains both open-source and closed-source repositories.
Current open-source repositories
- HetznerClient.NET repository, a new .NET SDK which will allow the .NET ecosystem to interact with Hetzner's API endpoints and infrastructure.
- openai, a fork of betalgo's OpenAI .NET SDK, it will mostly inherit from the upstream repository but modifications and extensions by contributors are accepted.
- nyzoVerifier, a fork of the n-y-z-o's distributed computing (blockchain) Java repository, this repository has inherited the The Unlicense license which was changed to the MIT license. We do wish to respect the authority of the core Nyzo team, merge requests to the upstream repository however will only be possible if the Nyzo team wishes to accept that any modified files and new files will fall under the MIT license. The MIT license of construct0's fork fully respects their work and attributes the Nyzo team as the primary entity, and mentions "contributors" to include further contributions made under the construct0 umbrella or it's successors.
My humble request to the Nyzo team would be to adopt the MIT license - or to atleast - allow merge requests under this license.
Current closed-source repositories
- Nyzo.org repository, this new multi-faceted repository contains source code and files to create a unified non-profit platform to enable the full potential which the Nyzo network, with respect to the methodologies and core values of the core Nyzo team.
Current status: design and development. The domain is inactive, refer to nyzo.co for a network overview.
It will leverage the open-source HetznerClient.NET SDK in order to allow for one-click deploys (and in a later stage, orchestration through a self-hostable management client) of verifiers, sentinels, relays, clients and documentation servers.
Hetzner's policies do not allow cryptocurrency related activities on their platform, yet most of the active network participants use Hetzner as their go-to cloud provider and historically staff has been lenient, yet not permissive in the legal sense. The Nyzo verifier is not a "cryptocurrency miner" and does not act as a noisy neighbour, it is in the case of the verifier and sentinel "merely" a node which contacts other network participants to reach consensus in order to produce blocks, it manages incoming transactions, has on-chain storage capabilities and by design, allows for on-chain governance which allows the network to vote for proposals, for which rewards from its community fund are awarded to beneficiaries, without the potential of being overruled in the event of a sybil attack (it is possible, but draining the community fund for shell proposals devalues the network in its entirety).
A sybil attack has occured on the network in the past, yet the owner of this cluster of nodes has respected the rules of the consensus mechanism and understands that stealing from the community fund is meaningless. The core Nyzo team has published a statement in this regard, further analysis will be made publicly available on Nyzo.org as the current status may deviate from the findings back then (many nodes have entered and left the network since then, increasing diversity).
Irregardless of the findings, the stance of the construct0 team (currently just me, come join on Discord!) is that the community must discuss the further direction of the entry mechanism as the bear market of the industry has given the owner of this cluster the opportunity to establish themselves as the leader.
Good news, the market is turning up.
Bad news, the network has a small amount of queue nodes, the current status of the sybil attack is uncertain and the seed fund has been depleted (there are currently no rewards for active network participants other than transaction fees; yet they are still rewarded for the, albeit low amount, of transactions being processed by the network and the value of a vote is still significant considering the aforementioned on-chain governance and community fund).
The network is currently at a cross-roads; either the network keeps stagnating until no more transactions occur on the network and active participants have lost confidence, or we come together and come to a solution to increase diversity of further network entrants.
I currently propose: - allowing all previously dropped (aka left the active network | the cycle) to enter the network again, by subdividing them into 1-month slices (inspired by the 30-day incubation period under which queue nodes are currently subjected), giving these slices a weight, randomizing order within these slices and by determining the percentage of influence on the entire list
- allowing new cycle entrants and determining the percentage of influence on the entire list
- assesment of the sybil attack, identification of current in-cycle and out-of-cycle nodes of this participant and excluding the presence of these nodes in the list (this does not mean removing active nodes in the cycle!)
- the creation of a voting script to be adopted by the active cycle participants
- the creation of three lists:
- dropped nodes as described above
- possible to adopt an initiation_timestamp in the slice accompanying the expire_date, yet the processing_order is easier to interpret
- if possible, preferably provably-fair randomization, if not possible, the slice's size should establish trust in its order, which may be subjected to analysis by members if they so desire
- new cycle candidates as described above (queue members | new cycle entrants)
- stemming from the classical queue mechanism, including excluded nodes (to be cross referenced by the next list by the proposed script)
- regularly updated to keep in sync, I propose a daily interval - this should be sufficient with the incubation period in mind
- excluded nodes as described above
- must be well-justified, voting about it is illogical, analysis must rule this part and disregard any communications or cycle transactions, ofcourse the schema and contents may be up for debate
- example schemas
If you are related to the Nyzo network, or were before but lost your nodes, or are otherwise interested in the determining of the weights or the general composition of the schemas, join the construct0 Discord!
The core Nyzo team suggested a composition of a preferential KYC-ish list based on provable cryptography or cryptocurrency contributors. This should be respected and is a possibility.
My personal take on this is that a different addition is also possible, a variety of GitHub repositories related to other cryptocurrency projects (Bitcoin, Ethereum, ..)'s have their stars and issues scraped and their profiles identified and may be given an opportunity to participate when contacted.
The lists will be provided as files on a construct0 repository, which in its raw form can be used as an endpoint source for the script.
It has to be discussed whether the script should contain some sort of cross-referencing with a node's queue perspective and the contents of the queue list to avoid fraud. The weight and order may also be incorporated in the script itself if deemed undesirable to hand over this control to the repository owner.
Other lists are mostly static.
Moving on, let's take a look at the proposed structure (sneak peek) of the future Nyzo.org website.
- Explore - blockchain explorer, will visualize mesh queue, entrants history (based on the blockchain contents cross referenced with the nicknames and identifiers on the core Nyzo team's explorer to verify and enrich the data), network health metrics, live feed of blocks being produced; the tx amount; live overview of rewards for verifiers as they occur, reward per verifier per multiple timeframes, live visualisation of queue node and verifier node threading time spans and calls, live logging output per logging verbosity level, live node overview (pct cloud, pct residential, age, removal scoring aka node health, ..), wall/spiral viz tbd depending on device, active cycle txs and votes, ...
- Learn - Documentation server content in a fresh UI, expanded upon by construct0 where necessary and with attribution to its author
- Trade - Overview of prices across exchanges, volume, potentially a SWIFT one-click buy module when deemed possible within the legal framework of an unincorporated association (could be an intermediary module leveraging exchange API's, with a premium to account for volatility, order book spread, previous end results, service provider costs. Any remainder will be used to further construct0's causes and can not be interpreted as profit for an individual due to the legal entity's characteristics)
- Transact - Overview of wallets, key tools, libraries, pointer to documentation server, best practices, protocols, ..
- Verify - Instructions on how to deploy a verifier and/or sentinel, ranging from a person's technical understanding and capabilities.
(e.g. scripts, manager client, one-click cloud deploy, ..) - Vote - Live overview of historical and currently pending cycle transactions, live overview of historical Nyzo team expenditures predating the existance of the decentralized community fund.
Chat room and/or discussion forum whereby individuals can choose to verify that they are the owner of a verifier, displaying verifier age, ..
Chat room would be [[proposal column][verified verifier chat][unverified chat]].
More TBD. - Discuss - In conjunction with the above of #Vote, more leaning towards a forum. Includes references to social channels. Current status: attempting to recover the old community forum's database from a community member.
Moving on, the "construct0-forks" organisation on GitHub contains forks of repositories for referential purposes only.
https://github.com/construct0-forks
In order to achieve the mission:
- combined open-source and closed-source development for non-profit purposes which enable the organisation and others to grow along
- supporting existing open-source projects
Funding is required. The Nyzo on-chain governance is a solace for its contributors in that they may be eligible for rewards in the Nyzo currency, yet the current status of the Nyzo.org repository and the uncertainties surrounding the sybil attack's existence, accompanied by the current value of the network's currency make's this an unviable channel of initial funding.
construct0's legal status is currently pending approval, which should be resolved in approximately 2 weeks.
As the currently sole member of the organisation I do accept donations or contracts.
In any case, you are more than welcome to initiate dialog either by email, through LinkedIn or preferably, on Discord.
Thanks for your time and attention.
Benjamin Van Renterghem @ construct0
My special thanks goes out to:
- All programming lectors of HoGent and its students
- Nyzo team and community
- AllPhi management members and consultants
- Software development ecosystem as a whole
Comments
Post a Comment