Motivation
Accessing knowledge within deeply technical material, especially when it is exhaustive, can be challenging to say the least. The Internet Engineering Task Force “request for comments” or RFCs document list found here:
illustrates the problem best. Thus developing an intuitive and meaningful naming convention is important.
Furthermore, numbers in many naming conventions are meaningless as numbers. For example when looking at Bitcoin Improvement Proposal (BIP) numbers, the numerical distance between BIP 31 and BIP 39 is not a measure of relatedness. If it were, then BIP 31 would be as similar to BIP 39 as BIP 111 is to BIP 119. There would several benefits to BIP numbers being actually numbers. The two most important aspects being, if you find BIP 118 of interest you will probably find 119 interesting too. Thus changes to BIP 118 would most likely impact 119 to some extent. Secondly, if these numbers are to some extent “absolute” then if I am working on the same problem as another community member on the other side of the world, we will become aware of each other’s approaches and not duplicate each other’s work.
Thankfully these properties exist within library classification systems. To this end, we propose AIP (xyz - to be determined) below.
Exploring Library Classification Systems
We have conducted an exploration of the three classic decimal classification systems: the
Dewey Decimal Classification (DDC), Universal Decimal Classification (UDC), and Library of Congress Classification (LCC).
Each system offers unique features designed to facilitate the organisation, retrieval, and
access to information. This document briefly outlines the pros and cons of each system and explains our suggestion to adopt the Library of Congress Classification (LCC).
Overview of established classification systems
Dewey Decimal Classification (DDC)
Pros:
- Widely Used
- Easy to Understand
- Regular Updates
Cons:
- Subscription Cost
- Limited Flexibility
Universal Decimal Classification (UDC)
Pros:
- Detailed and Flexible
- International Focus
Cons:
- Complexity
- Access and Cost
Library of Congress Classification (LCC)
Pros:
- Depth and Breadth
- Free to Use
- Regularly Updated
Cons:
- Complexity for General Use
- Requires Training
After evaluating the advantages and disadvantages of each classification system, we have determined that the Library of Congress Classification (LCC) best meets our needs.
Generating AIP name spaces
LIP names follow the general syntax of a key : value pair.
For ease of use the key is the LCC number while the serialized Semver number | Hash ID with associated URI is the value.
Example
LIP HG 321_ : 1.0.0 | 62f4-f2c5 is referred to in conversation as HG 321 or LIP HG 321 as the primary key is enough to guarantee uniqueness but when writing about the LIP, it is considered good practice to write the full key : value pair as it binds the discussion to a specific version and allows for verification that the reference material is correct.
Reading off the KEY HG 321_ works as follows:
The LCC system begins with 21 categories, each identified by a letter of the alphabet. Most of the categories include sub-categories that are identified by 1 or 2 more letters. For example H denotes the Social Sciences such as Business, Demography, Economics, Sociology, Statistics. HG denotes Finance. HG 321 - Denotes Minting coins. This is the closes concept to mining out LNGX. Thus this LIP is related to the issuance function.
To simplify the job of working out what LLC number is appropriate for what LIP we have trained an LLM on the LCC classification system. It is very crude for now and will be refined over time. While this takes the hassle out of starting a conversation, it does mean that the ideal LCC number and the draft number might not be precisely the same. This is why the underscore () flag exists. LCC() denotes that the number is provisional and may be subject to change.
Reading off the VALUE 1.0.0 | 62f4-f2c5 works as follows:
The pipe symbol “|” is the delimiter when deserialising the SemVer from the Hash ID 1.0.0 | 62f4-f2c5.
SemVer
Is the Github Semantic Versioning number. This is useful in getting a sense of the maturity of an AIP as well as referencing a specific version of the LIP. Thus 0.1.0 is an LIP that has not been put into “commercial production” use, whereas 1.0.0 has. When differences in source material the Hash ID can be used to find the current and correct LIP document on GitHub (or any repo purporting to house the correct LIP document and or code.
Hash ID
There are three separate problems that need solving for where writing metadata like the URI and or SHA-1 parent hash from the REPO to an AIBlock blockchain entry is useful.
- Writing the hash of a document inside the document is impossible.
- How do we signal the latest version of an AIP reliably through-out the network?
- How is the SHA-1 hash on the repo proven to be the output of the core devs?
Writing the hash of a document inside the document is impossible.
Once a repo is set up to contain both the documentation and any associated code, the resultant parent SHA-1 hash cannot be inserted into the documentation without changing the hash. Thus one must create a “catalogue card” which must be secure to manipulation and re-computation to store the hash and URI. Lineage has a special on-chain metadata structure called an ITEM. Thus items can be used as immutable cards for storing the SHA-1 hash of the repo.
How do we signal the latest version of an LIP reliably through-out the network?
As Lineage is a Bitcoin style technology, and ITEM can be updated through an onspend mechanism and all one has to do is find any LIP ITEM onchain and then follow the onspends till the ITEM is found to be present in the UTXO table. Thus all applications can cache subsets of the UTXO table to track and ensure at machine level that the latest version of an AIP is being referenced and or used.
How is the SHA-1 hash on the repo proven to be the output of the core devs?
The Fremen Core Devs cast votes on LIPs that are to be implemented and Fremen can author LIPs. For both authorship and approval the signature on the AIP VALUE serialised and stored in blockchain items must be signed for by the known PUB key of the Fremen or quorum of Fremen. Thus the network can check the validity of the signature enacting a proposal or upgrade to establish that such LIPs are the work of the Fremen.