※ 본 게시물의 목적, 취지, 이력에 대해선 맨 밑의 비고를 참조(Please go to the bottom to see the purpose, intention, and prior history of this typed reproduction of an original─& incomplete─contribution by the MetaCurrency Project).
3.4 Self-Describing Protocol Stack
(Still to write / expand:)
─. Pattern of signal / carrier / protocol / flow & geometry of addressable space or existence scape that repeats throughout all of computing (and nature).
─. [DIAGRAM] Carrier / Signal / Protocol + Flow / Sequence / Pattern / Series (reference ‘CAS working paper’) C→S/P
- cf. CAS working paper: Eric Harris-Braun & Arthur Brock, "Grammatic Capacities and the Evolution of Complex Adaptive Systems", status: Pre-release draft (자료 형태: 구글 문서).
─. Make a chart of examples─both in technological terms and bio/physical.
─. Base Ceptr protocol which identifies the protocol being used as well as semantic identifiers for the symbols. Anything which can speak the base Ceptr protocol can then communicate with / interact with anything else that speaks the base protocol.
─. What is typically called a “protocol” in a specification is for us an EMPTY protocol template which does needs to have its endpoint connection slots be connected upon instantiation.
- A full Ceptr protocol specification actually has the ability to function─to be installed and do what the protocol is supposed to do.
- What good is a self-describing protocol stack if the protocol don't actually have functioning descriptions which make the protocol work.
─. Slots in: connections, roles, goals & usage ─ description of all this.
- basic gist is like this: In an abstract description of a protocol there are always slots which need to be filled when that protocol is installed or instantiated for use.
- CONNECTION: is an endpoint binding for a protocol (could be used at either end).
- ROLE: specifies the RECEPTOR_ADDRESS of an agent (including another receptor as agent).
- GOAL: specifies a PROCESS to be run.
- USAGE: specifies some semantic data to be used / passed in the signal.
─. protocol chaining & embedding─description of how that works using CONNECTIONS and such.
─. Semantic Context for interpretation of symbols. Local symbol tables or contextual reference via Ceptr Compository for non-local (Ceptr network) communications. Always alber to receive carrier, but not necessary signal. Could install the components to process received / logged signals.
─. SemTrex(SEMantic Tree Regular EXpressions) provide lexical and syntactic parsing at all layers of a protocol stack.
- In order to have a self-describing protocol stack that can interact with ANY protocol, we needed to build a universal protocol parser.
- It turns out that wasn't as difficult as it might seem because Ceptr relates to data natively in semantic trees.
- In typical computing, we regularly dehydrate and rehydrate data ... like when we serialize objects or read objects back into memory from serialized storage. The Ceptr base protocol provide consistent methods for serialization / deserialization of semantic trees, so we can always relate to data in its semantic tree form.
- ASCII text is used as a generic linear storage format for things like writing programs. For those programs to run, a complier or interpreter needs to identify all the meaningful sequences of carriers (lex the tokens) and then build a representation of the relationship between those tokens (parse them to build the Abstract Symbol Tree).
- When your signal come as semantic trees, a universal parser is easier because we already have the signal lexed and parsed (tokens are identified by semantic IDs and the parse structure is embodied in the tree structure).
- This allows us to simplify the representation for parsing any signal into a format similar to how regular expressions match sequences in ASCII strings.
- With this we can match signal components by 3 dimensions: (1) their semantic identifier (such as SHOE_SIZE) (2) their value (such as 45) or (3) their grammatic placement in the symbol hierarchy of the semantic tree (such as /HTTP_REQUEST/*/HOST="ceptr.org" ... find any HTTP_REQUEST with a child node with a semantic ID of HOST where its value equals "ceptr.org").
─. EXPECTATION Statements: ON 〈carrier〉 EXPECT 〈semtrex_expression〉 [DO 〈action〉] [WITH 〈Parameters〉] [UNTIL 〈time_condition〉]
─. Receptor aspects can be bound to protocols.
─. Expectations can be placed on particular aspects ... or even be requested to be planted as remote listners in other receptors.
3.5 Intrinsic Data Integrity
(Still to write / expand:)
─. Breaking data access [on the basis of] data integrity through cryptographic ─. structures. We call structuring data this way “Intrinsic Data Integrity”. [introductory paragraph]
- Signed transaction chains with multiple levels of integration. (akin to bitcoin blockchain) [one para w/ the below simply identifying other approachers]
- Merkle trees with accumulating hash akin to git repositories.
─. Applications can enable individuals to be primary authorities over their own historical data by storing progressive hashes of that data in a shared DHT with adequate redundancy to make tampering impracticale without controlling most of the nodes. ( ... ... )
─. Signing is a low-level, always available Ceptr system function.
─. All CeptrNet communications are signed, it is possible to keep signed transaction / interaction logs / chains for various purposes.
- right now a log is pretty bogus record. just and ASCII file. if you're sys admin you can very well tamper with that log.
- Non-repudiation: if you want to keep tracks of audible histories of things you can create audible histories that show that at least someone had the person's sig / public keys. Doesn't mean for sure that person, it does mean they were using that person's public keys. Makes or a smaller number of people that could potentially have those keys.
─. Byzantine Fault Tolerance / distributed consensus across instances of a receptor.
- Multiple realities (versions of hash tree history which are different across nodes) are an option and are sometimes exactly what is desired. The integrity of each forked reality can be assured / maintained. Sometimes the descrepancies may be easily resolved, other times not.
─. Configurable levels of data assurance / redundancy in distributed patterns based on application requirements.
At the core of cryptocurrencies is the tamper proof nature of historical record. Accomplished through cryptographic data structures which have self-referencing hashes to ensure the data can't be changed. Such as Hash Chains and Merkle Trees. This enables us to handle data access distinctly from data integrity, because people can be allowed to host / access data without being able to break its integrity.
This means we no longer need to hide important data behind firewalls. We can share it openly and even in distributed storage structures such as DHT (like bittorrent, IPFS, etc.)
Historically, computing architectures have conflated data access with data integrity. If you can write to it, you can change it. So we build sophisticated security systems to keep unauthorized people out. Imagine what people would do if they could alter their bank's database.
However, structuring data in countersigned, linked chains creates a kind of Intrinsic Data Integrity where the integrity of the data is structured right into the data itself instead of the firewalls and access controls separating you from that data. If you tried to alter your most recent tranaction, you'd break the continuity of your hash chain.
Since you can't tamper with your chain of transaction records, you are able to be a trusted authority to represent the standing of your account. Quite unlike the world of bank accounts where the bank is the only authority of your account's standing with them, this provides autonomy without any central authority.
3.6 Fractal Sovereignty
( ... ... )
※ 비고(This Reader's Remark): 메타커런시 프로젝트(MetaCurrency Project)의 개념과 역사에 대해 탐색해 가면서 아울러 현재와 미래에 걸쳐 동반 탐색자의 출현을 기대하는 공개적인 탐구용 게시물(A personal exploration to learn about something related to the ideas of the MetaCurrency Project and its history, having some hope to find some people interested esp. in Korea though).
- 추적 문서의 위치: The MetaCurrency Project(Ceptr) 또는 https://ceptr.org/revelation/ > 문서명: Ceptr Revelation(자료 형태: 구글문서)
- 최초 탐색: '메타커런시 프로젝트'를 찾아서 1: '보이지 않는 대학 연맹'에 집결된 자료들
- 직전 탐색: 메타커런시 프로젝트를 찾아서 8 - Ceptr Revelation 읽기
- 다음 탐색: 메타커런시 프로젝트를 찾아서 10 - Ceptr Revelation 읽기