Engineering Considerations
This document will be developed to provide information about various Engineering related considerations and various thoughts and methodologies on how it is they're intended to be addressed.
NOTE: THIS DOCUMENT HAS NOT BEEN PROPERLY EDITED FROM ITS WEBIZEN DEVDOCS SOURCE.
Security Architecture
TBA - WIP.
Energy Related Economic Architecture
In-order to support EnergyCalcs and related economic architecture being built-in, as part of the ESG EconomicSystems that are in-turn supported via Currencies (re: BiosphereOntologies & in-turn also [[SustainableDevelopmentGoals(ESG)]] ); there's a desire to create agents that are reliably able to evaluate the amount of energy being consumed, which may then be ontologically defined in a far more comprehensive manner that may in-turn support complex semantically (ai) empowered frameworks, networking, etc.
Therein also; an architectural solution needs to be designed to both support Micropayments and in doing so in a manner that is likely to employ Non-HTTP(s)Protocols produce a solution that has the lowest possible floor price that is defined using a caculation that takes into account the amount of energy that has been consumed in-order to facilitate a transaction. These sorts of things are expected to be formatted as VerifiableCredentials or cryptographically secured caculations that are wrapped, providing a model that is produced by a trusted WebizenAlliance member whose expertise is in that area; yet, from an engineering point of view, there is a degree of importance in seeking to figure out which protocols and in-turn also, related methodologies; result in a FitForPurpose and effective methodology that can support the use of these sorts of considerations in the EconomicSystems.
Enterprise Database Systems?
In looking at how to create solutions for micropayment ecosystems in particular, i've ended-up having a bit of a look at [[Apache Kafka]] which is something that requires more investigation. In-order to support solutions that are less dependant upon cryptographic schema; related WebizenAlliance work needs to be significantly progressed; as to form an ecosystem that may in-turn offer hope of future sustainability. However, it shoulld also be noted - that part of the reason why the EnergyCalcs of Non-HTTP(s)Protocols is often considered acceptable; is due to the shadow costs of corrupt activities relating to the SocialFactors side of the equations.
Enterprise Webizen Services.
Via the WebizenAlliance related SocialFactors ecosystem solutions, another part of the solutions ecosystem to these sorts of problems is likely to involve forming ecosystems support for enterprise providers who are operating particular types of services that are made able to work via the [[PCT-WebizenTechStack]]. This is as much the case for addressing some of the many Currencies related EconomicSystems as it will be for future federated AI processing requirements that will start to be explored more fully as part of the [[Webizen 3.5]] stage of development - notwithstanding the importance of making foundational considerations earlier, including but not limited to the Centricity or 'entity relations' factors that are of great importance for SafetyProtocols, the management of [[Artificial Minds]] and other ecosystem factors at large; as does fundamentally relate to TheValuesProject.