탐색: 메타커런시 프로젝트를 찾아서 12 - Ceptr Revelation 읽기

hsalbert (48)in #metacurrency-project • 6 years ago (edited)

※ 본 게시물의 목적, 취지, 이력에 대해선 맨 밑의 비고를 참조(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).

제5절 CeptrNet and Routing

§. A writer's remark: “Strange loop-ness”:
“I exist in your processing space and you exist in my address space.” ... Unclear the best order to explain these next subsections.

§ Note from Arthur: I have a hunch that my first attempt to explain this will be a bit confusing because my thoughts are not even assembled on what is the best strategy... so this initial outline is just a first attempt to muddle through it. And I'm going to abbreviate to “CeptrNet” instead of writing “Ceptr Network” each time.

If you recall the strange loop section above, there's an unusual logical inversion in the way the network communication in Ceptr is implemented.

[On the one hand,] Each VMHost─that wants to communicate with any other VMHost via the CeptrNet (Maybe standalone devices don't have to do this?)─must get a CeptrNet address. You could say that each VMHost instance exists in the address space of CeptrNet.
Yet [, on the other,] CeptrNet is itself implemented as a receptor. All the code for managing routing, communications, filtering, address and key management, etc. are implemented in a CeptrNet receptor which is installed in any VMHost that wants to communicate via the network.

[Diagram of Network of Physical Machines, VMHosts, CeptrNet receptors goes here.]

“Protocol” : Speaking across VMHosts via replication between sharded CeptrNet instances

There are two completely different types of communication within Ceptr: front-end protocols, and back-end protocols.

Front-end protocols are all those things we think of as protocols for receptors to send messages to each other: like HTTP, SMTP, FTP, etc.
Back-end protocols are how different instances of the same receptor talk to themselves─for synchronization, verification, validation, mirroring, redundancies, etc.

Front-end protocols are customizable, programmable ways to send communications in various formats. Back-end protocols are built into Ceptr for managing its internal functions.

Normally, network protocols are all thought of as these front-end things ... and indeed they are when Ceptr interacts with people or programs via internet protocols (like serving web pages via HTTP, or sending emails via SMTP). But remember, within Ceptr, we don't have to speak differently structured protocols, receptors communicate via the self-describing Ceptr protocol. So every message is a Ceptr style message which just identifies the different protocol it's using semantically.

But when a receptor mirrors or synchronizes with instances of itself, it uses special internal maintenance protocols “within” the receptor, even though the data synchronization is happening over the network. This is exactly what the CeptrNet receptor does to send messages. It synchronizes, routes, and manages other instances of itself to have the message pop out of a CeptrNet receptor on the VMHost on the network to reach a local receptor there.

CeptrNet addresses are huge UUIDs. They're in a big unique address space, that's a sparse space (there are gaps / holes in it). And the UUIDs are based on agency (who created the receptor, who is in charge, NOT physical topology of the network). So, your different streamscape instances are all a part of the “jarod holtz agency and ID space, buy they could physically be very remote from each other. Even though on one level they have an equivalent address (and can be considered delivered if it reaches any one), the physical topology is scattered around the world. [주]†

[주]†. 따옴표 “jarod holtz agency ... : 닫히지 않음.

Efficient routing of non-topological addresses can be a very challenging problem.

Ceptr's back-end synchronization protocols [주]§ track a lot of information about the physical topology and routing of the network and paths to “sibling” nodes. The processes for synchronization use non-sparse / tighter instance / sibling addresses, and retain routing information to peers. So, CeptrNet uses this “internal” peer management system to accomplosh the delivery to “external” addresses.

[주]§. Mi Tar의 코멘트(2016년 7월 11일): You could use IPFS's services for back-end protocols.

Arthur Brock의 코멘트(2016년 9월 23일): I know Juan and am familiar with IPFS and we'd love to re-use existing tech if it solves our problem. So far we haven't found a way for IPFS to do that for us. As a FILE system it has such a fundamentally different orientation to the problem (including everything being content addressable) that doesn't mesh so well within living dynamic frequently changing data organized into fractal membranes.

Via the back-end “I'm taling to myself” protocol [:]

(Bookmark explaining: the problem we're solving that others find difficult to solve.)

[독자 주] 여기서 더 이어질 이 소절(또는 문단)의 내용 역시 미완성으로 추정.

There's a protocol for inter-receptor communication on a single VMHost [link to message format?]. To communicate between receptors on different VMHosts there are a few additions to the local Ceptr protocol which require CeptrNet source and destination addresses and for messages to be signed (for authentication, validation, data-integrity purposes).

When a receptor sends a message to a remote receptor it actually sends the message to its local CeptrNet receptor to provide a destination address. The CeptrNet receptor handles the network communication.

Triangulation for joining / registering

CeptrNet addresses are not managed by a central authority or even delegated to Internet Service Providers, they are structured as a UUID so that unique addresses can be generated with no central authority. However, you can't exactly create a new address all by yourself either. It actually takes two friends to “triangulate” you onto the CeptrNet. [주]§

[주]§. Mi Tar의 코멘트(2016년 7월 11일): I think this concept that it requires only two other people to “triangulate” you seems a bit hard-coded design choice into a system. I would feel much better if this could be something which could evolve [through] time. There are different ways to reputation bootstrapping and this is only one of those.

Arthur Brock의 코멘트(2016년 9월 23일): Yes. You are right. Ceptr can evolve over time... just like the versioning of any receptor, so we could change it. And this seems to me more like a minimum viable start, which is why we were thinking of this as the initial configuration.

Here's how it works. You, Carl, would like to create an identity / address that can use CeptrNet. You have your friend Alice generate a new UUID address for you via her CeptrNet receptor, and your friend Bob, register your address with its associated public signing key, authorized identity service, and key revocation process into his CeptrNet receptor. This begins your ability to start to communicate via CeptrNet.

Routing strategies and algorithms for non-topological UUID space

Probabilistic algorithm... Not a guaranteed route, but a high-probability method for discovering routes. [주]§§
Examples of what info is kept and tracked about physical network topology, bandwidth, throughput, reliability, latency, etc.

[주]§§. Mi Tar의 코멘트(2016년 7월 11일): You might want to simply reuse Cjdns for this part of the stack.

Arthur Brock의 코멘트(2016년 9월 23일): Cool. I'll look into it further.

※ 여기가 제5절 CeptrNet and Routing의 끝이다. 다음은 제6절 Optimizatin for Evolution.

제6절 Optimization for Evolution

( ... ... )

※ 비고(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).