4.3 Maintenance and Future Development
Current Limitations of Project
The two most substantial limitations the project faced were the choice of programming langauge for the node software and the time in which I had to complete the development of the project. Although due to the fact that in order to progress much further past the point at which I reached in the development of the node software I would have to completely refactor the software into another language which would take time it can be summarised that the only real limitation is that of time, which sadly is a limitation that all projects have to face, although I will go into how the project could progress if it was given more time and that is what I shall do in the rest of this document.
Straight away we can disect what limitations in the project's current state of development this language limitation has caused:
Node Software:
Performance:
Crashes under continued or heavy use.
Limited by the computer/server that the software is ran on.
Primarily operates on a singular cpu core rather than all that a computer has to offer.
Platform Support:
Must have websockets disabled in order to operate on Linux.
Is currently only precompiled for macOS ARM systems meaning that other systems have to spend longer setting up nodes.
Will only run on ARM and x86 systems (desktops/laptops) and not mobile devices.
Usability - Very little documentation or explanations on how to use various parts of the software which raises the entry level of users who can actually use the software.
Internet Access - The node software requires internet access to communicate with other nodes on the network.
Web portal:
Features - Missing various features (wallet access, online market) due to node software not being far enough on in development to allow this to be used.
Platform Support:
Only accessible on a browser with access to the internet.
Some parts of the site do not work on mobile or tablet devices.
Internet Access - The webportal servers are ran on the internet and as such internet access is required in order to request the website from these servers and to view it.
The majority of these limitations can be assessed and changed in future development to meet the direction in which the project is growing.
Maintaining the Project
Based upon the project's current state one of two primary strategies can be followed depending on wether the aims for the project remained to complete all that was originally conceputlised and further expansion past that point or to optimise and fix what currently exists of the project so as to use it as some form of decentralised communication system as is done in the messaging demo.
Optimising it's Current State
In order to optimise the project for it's current state then it would need to undergo the short term development plan alongside the optional aspect of rewriting the node software in a new language as according to the long term development plan if the plans for the project require a differnet level of higher stability that is out of range of what is currently possible with VLang without significant and perfect optimisations.
If the software was to be rewritten it should then be brought up to atleast the standards set by the previous version whilst ensuring that it fixed all the problems addressed in the short term development plan whilst hopefully improving the stability significantly. If the software is not rewritten then it should still have had some form of stability increase but it is unlikely to be as significant as rewriting the entire thing would do.
After these issues have been addressed and the stability of the node software has been increased as mentioned in the above paragraph the project should then go through another, more thorough testing phase that includes seperate usability testing by technical and non-technical users. This version of the project can then be implemented in whatever way was planned, whether that be simply the messaging demo being used as a decentralised chat room or something more advanced.
In order to do this, the project could be developed by a singular person or it could be completed by multiple developers working together, especially since all of the code of this project is open source and publically available on GitHub. This means that other developers could publish changes that are as small as fixing a singular bug they discovered or as vast as rebuilding a chunk of the project. If it was only a singular developer working on the project, the only maintencance that would need to be continually carried out past the point of publication would be ensuring the service is still working and fixing any bugs that occour following user reports. On the contrary, if multiple, open source, developers were contributing to the project, more comments would likely be required to explain the code in further detail so as to allow as many people as possible to be able to understand it and one or more developers would need to be dedicated to reading through and checking the other developer's contributions so as to ensure they aren't acting maliciously or accidentally breaking other parts of the project.
Growing into an Ideal Blockchain
Initially all of the optimisations and fundamental upgrades mentioned in the other strategy can be used so as to bring the project up to a stable level, with the requirement that the node software is rewritten in a different langauge that fully supports all that the project requires so as to ensure that there are no (or minimal) further issues with the node software that are not due to the project itself.
The intial short term bug fixes and even the node software rewrite could be completed by a singular developer if they were given enough time, however based upon the current size of the project and the knowledge that it is approximately half way to becoming a working blockchain and that the long term development plan expands past this, it is likely that additional developers would be needed. This could occour in two ways: A small team of dedicated developers, starting at 2-3 but could then expand further if the project continued to grow past this; and through a large body of developers contributing via the "open source model" which was mentioned briefly in the other maintence strategy.
The small team of dedicated developers would intially require heavy training and assistence by myself such as to bring them up to speed with the inner workings with all of the code such that they understand it signicantly enough to not cause issues for each other when working on the code, as the different parts of the project should integrate into each other signficantly by the later sections of the long term development plan. The individual developers could also be designated to seperate parts of the project so as to optimse their skill sets, such as one developer working to make the webportal as high quality as possible with the others working on the node software. As the code base expands it would also be important to ensure that the code is commented at an increasing rate since it would be getting increasingly complicated.
Alternatively, a larger team of open source developers could be adopted past an initial rewriting of the node software. This would require that all parts of the code are well documented and commented and that these comments/documentation are kept up to date as frequently as possible, this is because open source developers can contribute as little as a singular line change to patch a bug or as much as rewriting an entire module to optimise the software on the whole, therefore meaning that lots of people will need to be able to read and understand individual parts of the project without having to see any other part. It would also be important that as the number of developers contributing increased as with the size of the project, that there are designated developers who are given control over who's changes are actually contributed to the project and these developers would have to check through and run any code that has been changed in order to ensure that it does not break any other parts of the project and is not malicious.
Future Development
Short Term Bug Fixes
Bug Fixes
The first stage of continuing developement for this project would be to fix the bugs that currently limit the project, these bugs are listed below.
Webportal has visual glitches on some tablets or phones - To fix this, different components should be used for the node setup tutorial just like the navigation bar and the home page buttons should be configured to switch modes to mobile mode based upon the screen aspect ratio rather than the raw pixel width.
Node software's dashboard doesn't work very well on mobile - To fix this, the dashboard and login screens should react to the size of the screen and change component sizes to make it more usable like on the webportal.
Messaging demo isn't stable while using websockets - To fix this, the way in which the http and websocket servers interact should be changed to reduce the chance of triggering a memory issue (which currently happens due to Vlang's websockets module being very new and not as stable as I would like.)
Linux Versions cannot use websockets at all - To fix this, I would look for some work around that does not cause the issues encountered or edit Vlang's websocket module further to fix my own problems like I did in cycle 14, although this is very time consuming.
Documentation and Information
Following the bug fixes, the documentation and information throughout the project should be increased. It was found throughout usability testing that the individual sections of the project are not expalined in enough detail and this needs to be expanded so that all users understand the very basic information about all parts of the project and understand which parts are aimed at them and which aren't.
Furthering on from this the node software needs significant improvement both internally and externally. Internally more commenting is required to explain how different modules interact with each other since this is somewhat lacking. Externally documentation should be written for all parts of the configuration handler alongside a general briefing on how the node software is doing so as to ensure users have a much more solid idea of what they are actually doing. Alongside this the login sequence for the node dashboard needs some basic information to explain step by step how to login and use the dashboard, alongside the dashboard having some additional information added to the page to further clarify what everything means.
Testing
Assuming both of the stages above are completed, a full and detailed testing should be completed similarly to the testing done in section 3, with a significant difference being that user testing should be completed with a separate standard/technical user focus groups to see the difference between the two groups and ensure the users can accomplish what their group should be able to do.
If any tests or criteria that were planned to be met are not met at this stage then suitable bug fixes and improvisations should be made to pass those test and/or criteria. If not then development can be continued or hatled as according to the maintence plan.
Long Term Addressing Limitations
Rewriting the Node Software
One of the fundamental issues with the current project is the node software and the langauge it is written in, specifically the maturity of the language. Although I did do some research into VLang before I decided to rewrite the node software from typescript into it, most of the decisions were made on what I read on the language's website, although it turns out that most of the features and claims made by that website are intended for the first full release version, V1, and the language is currently in beta, at V0.3.2 as of writing.
This means that various features and the standard library modules are not as polished as I would like them to be, primarily the websockets module which has various issues including the incompatability with it's servers being treated as purely an object in memory and passed around through varying components as such, even though VLang allows this to happen and does not prevent alternative methods to access those servers from multiple places at once.
Therefore, Although rewriting the node software to perfectly match what is recommended in Vlang's documentation would increase it's stability, it would likely not fix it's underlying issues and may still allow for the software to not be as stable as would be required to meet the criterion.
The solution to this is then to rewrite the software in a different programming language, of which is not decided, except for the requirement that the language is fundamentally stable and is in a fully released production version, unlike VLang. Some options include Rust, Go, C and even going back to Typescript - although that would have the same issues as is mention in cycle 2 since it is not primarily intended to be ran directly on an operating system itself but rather through some kind of browser or replacement. If I were to have continued this project for a longer period of time I would have chosen to rewrite the node software in Rust somewhere around cycle 12, which is where I started to discover some of the more serious issues with VLang, since Rust is much more modern than C yet is supposedly so stable that it has been included in the Linux kernel, which is as high a praise as a low level language can recieve.
Regardless, rewriting the node software into a more stable langauge is essential to expanding further onto completing all the inital goals of the project.
Producing a Working Blockchain
After the node software has been rewritten and the websocket and http communication methods have been proved to be working consistently, a solid, decentralised communication layer will have been produced, since the current code for the node software is essentially an unstable, decentralised communication network. This means that past this point the next step in the projects development is to introduce the protocol ontop of this layer, converting the messages from the messaging demo into transactions, grouping those transactions into blocks and building up the actual blockchain.
Then continiuing onto introduce trust, grudges and everything else that is needed for the proof of worth system to work properly. After which the network should be secure enough that wallets and root state can be added, which allows the webportal features that were originally planned to also come into fruitition.
At this point the network will have gained a reason to gain users, with the webportal's market and wallet viewer allowing non-technical users to purchase and sell digital contracts and items.
Introducing Additional Features
After the blockchain functionality has been introduced and the project has exceeded the original plan presented in this series of documents, additional features can begin to be introduced. These features can be based upon how the system is being used so as to best fit the users and encourage the growth and spread of the system, however a suitable next step may be a market exchange for users to be able to exchange betwen their monocoins and fiat currency by buying/selling them to other users, since this would allow users who do not wish to run a node to also gain access to the items on the blockchain and introduce 'real world value' to the items.
Additional features will need to be carefully decided so as to prevent the introduction of a flood of mediocre yet somewhat interesting sounding features that have no real use, and to ensure the security and stability of the system is not compromised.
Testing and New Versions
As the project expands and adds new features, it is important that all new code and changes are carefully tested and presented to users for their opinions before proper release. All Node software changes should also be grouped into major releases so as to prevent users having to download new versions all the time and should also aim to remain backwards compatible such that node servers can continue to run old versions of the software for very long periods of time without having to be interrupted. Although this is only required after the system has reached the point at which it's contents have monetary value and the user count has reached a point at which it is clear that it is no longer in an alpha/beta state. Therefore only after changes have been carefully examined and all tests passed should new versions of the various parts of the proect be released.
Future Limitations
After the project has reached this far expanded point, the points mentioned in the testing section begin to take effect, meaning that the limitations that the system faces will be somewhat changed.
Backwards Compatibility - After the node software meets it's planned state and the number of users has increased, it should be capable of communicating with and working with versions of itself that may be many months old so as to limit the disruption to those servers for as long as possible without sacrificing security and stability.
Hardware Requirements - The project may reach a point at which the node software exists in multiple languages so that it can run in a variety of places, at this point the hardware requirements of the devices that run it may vary, but they will likely need to remain somewhat modern to meet the cryptography and memory requirements of the nature of the software.
Platform Support - As the project gains users, it becomes increasingly logical to ensure that the node software is available for as many different systems as possible, so different versions of the software should be compiled and packaged for each release to support a wider array of systems.
Internet Access - Both the web portal and node software will both still require internet access to operate and communicate with the network.
Last updated