Non-HTTP(s) Protocols
Non-HTTP(s) Protocols are helpful for DecentralisedOntologies, PermissiveCommons, VerifiableClaims&Credentials and in-turn also support for various forms of Currencies (including Micro-Payments), although not exclusively.
A List of examples and candidates include; but are not exclusive to,
Non-HTTP(s) protocols that run over internet are various, some are 'blockchains' many are not; yet broadly, they're called Decentralised Ledger Tables.
Some examples include; in no particular order,
- LightningNetwork
- Chia
- Hedera
- IOTA
- obyte
- XRPLedger
- NYM
- WebCash
- DAT
- IPFS
- WebTorrent
- GIT as is used for GitHub / GitLab, etc.
Obviously also, there's also major 'crypto currency' focused protocols like BitCoin and Ethereum.
Others, are still useful and important; but not DLTs, for example,
- GUNECO
- WebRTC As is used for Live Audio/Video Streaming
- WebSockets As is used for real-time notifications
- EmailServices As does somewhat need to be supported somehow in the ecosystem.
and there are many others.
The methods are not seeking to suggest that any particular protocol (ie: web3 stuff) shouldn't be supported; but rather, that the design of these webizen systems requires HTTP(s) support.
HTTP based protocols are also alot faster than many DLT solutions (depending on networking issues, etc.); and, part of the objective purpose of the WebizenTechStack is to advance the 'World Wide Web' based ecosystems (Semantic Web --> Social Web) as is distinct to creating an alternative to the World Wide Web and/or potentially also by extension - an alternative to Internet - through the primary use of alternative protocols as a priority. There are many potential threats and underlying complexities that exist in relation to the emergence of new 'global' protocols, that are different to the sorts of characteristics that exist in relation to existing systems and services. As such, a balance needs to be struck as to support scalability, which is a technically dynamic issue that is mostly defined via SocialFactors.
As is noted otherwise in the EngineeringConsiderations document; there is a great deal of deliberation going into figuring out how to ensure optimidation of EnergyCalcs.