DⒶ Protocols
The Development Protocol Series
The DⒶ protocols are the first, and simplest, protocols made to demonstrate the Ⓐ protocol language and routines that implment it for applications and test suites. They are NOT meant for live use on the open internet. Especially at the simpler levels they lack robust precautions against attackers. Before a protocol is released as an Ⓐ "live" protocol, it should undergo documented testing as a TⒶ protocol*the point of documenting testing is to provide a baseline for future testers to expand on. The testing documentation should be linked as a parent block for the protocol definition. DⒶ might be linked as parent to a TⒶ protocol, but more often the parent of the TⒶ protocol would be another, somewhat less developed protocol that the TⒶ protocol was developed from.
.
DⒶ0 defines four roles: writer client, writer server, reader server and reader client. There are four message types that can be exchanged: write request, write response, read request and read response. The write request merely contains data to be written. The write response tells the time at which the data was written, which becomes a unique key with which to retrieve the record. The read request sends a unique key, and the read response sends back the data associated with that key, or no data if there was any kind of problem. There is no defined error reporting. Any application which intends to interpret and implement generalized Ⓐ protocols can start out by trying out DⒶ0.DⒶ1 adds identification of the clients. This enables implementation on message passing exchanges like AMQP and MQTT as implemented by RabbitMQ and similar exchanges. Servers listen to all messages on an exchange, and clients can subscribe to a topic that matches their I.D. so they only receive messages of interest to themselves.
DⒶ2 adds identification of a database
*Many Ⓐ servers will handle transactions for multiple blockchains.
to write the record into / read it from, segregating records by database id and laying some groundwork for selective service of chosen databases. DⒶ2 also starts adding error and error type reporting.
DⒶ3 adds identification of the protocol in use within each message. While a short name would be sufficient in a "friendly" environment, DⒶ3 adds a hash of the entire protocol definition to prevent confusion in the case of short name collisions between diverse protocol developers.DⒶ4 adds a query/response for protocols supported by servers. Rather than define optional elements of a given protocol, it is preferred to fully implement a given protocol and define a new protocol lacking any optional element not supported. This way, full protocol definitions can be independently tested / approved and if there are serious problems identified with any protocol, it can be deactivated without complications. Clients wanting to implement a "lite" version of a protocol can define that lite version, and hope they find servers willing to speak that protocol with them
*Removing some elements from a protocol can make it less secure, or outright incompatible with blockchain records that require more information. For the most part, the blockchain will define which protocols are acceptable for transactions on that chain.
.DⒶ5 adds a requirement for read response payload contents to be timestamped and hashed.
DⒶ6 adds a requirement for recorded payloads to include the hash of parent block(s), marking the start of actual "blockchain" operation.
DⒶ7 adds definition of how to include separable items and their hashes.
DⒶ8 adds client id cryptographic signatures to the block to be recorded.
DⒶ9 adds server cryptographic signatures to the blocks retrieved, making communications more traceable / secure. Hobbyist protocols branch off from here.
DⒶ10 adds definition of shares in the blockchain, marking the start of value store operations.
DⒶ11 adds expiration of share value over time - preventing infinitely extending chain records.DⒶ12 adds definition of a fixed number of "coins" or "tokens" expressing relative ownership of the chain that increases as un-maintained shares expire.
Many more to come.
Assign Onward
14 November 2021
MIT License
Copyright (c) 2021 Assign Onward
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Copyright (c) 2021 Assign Onward
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.