Pics Start Date:
Notes Date (end):
CD_044+dump
We haven't posted photos in ages because we both switched phones and no longer had our FTP apps set up for where to put them.
However, we have gotten much better about documenting and building Ceptr, so you can go to http://ceptr.org for a much clearer picture of current progress on Ceptr.
Meanwhile, here is where photos from our whiteboard sessions have been landing lately: https://goo.gl/photos/Ngf6qj1kFH559hSLA
CD_044+juicy bits
We had a major strategic breakthrough when we split the grandiose Ceptr project up into sub-projects that people can actually understand and connect with. And this week in San Francisco, we're having our first Holochain Hackathon for building applications on the distributed data engine portion of Ceptr, but as a stand-alone system.
CD_044+keywords
view (naked) not supported for CD_044+pics
Pics Start Date:
Notes Date (end):
CD_043+dump
We have been doing a lot of coding work and even some writing/sharing/messaging work over these past months, but haven't made any updates here, and I suppose it's about time (just for the record).
So... obviously you should check our github repo, and also our Ceptr Revelation doc.
I have some good blog posts in progress about Crypto-Currencies too... and why we would implement them differently.
I'm not even sure what pictures are going to show to accompny this post (as I fear we've been delinquent in uploading them), but I want to capture some notes from some JavaScript UI work, some scheming about Scapes, and about the structure/format of messages internal to the VMhost, between VMhosts (CeptrNet) and for synchronizing between accumulators/data-engines for Byzantine Fault Tolerance.
Scapes & interfacing w/ RDF/Semantic web vocabs
RDF Properties (and subclasses) seem easy for us to represent in our semantic trees, but relationships (and membership in collections) seem to be a job of scapes.
The cool thing about this is that it seems like relational data can be more dimensional/topological rather than linguisticly asserted. E.g. intead of "knows" or "friend of" you could have a connection-scape based on actual frequency and/or quality of communications/interactions. This could give you much more powerful graphs in terms of strong/weak ties than the linguistic equivalancy of "friend."
SPARQL - SPARQL Protocol and RDF Query Language) is an RDF query language, that is, a semantic query language... Compatable
variant for planting listeners?
Types of Scapes & Implementation Notes
- Relationship within subtree (as we've previously described, basically larger item indexed/ordered/organized by a sub-element)
- Smart Scaping? Is there a way to identify queries on unscaped elements which should be scaped to increase query efficiency?
- Relationship by new assertion (e.g. Arthur adds Eric as a friend, QIVC adds Eric as a member?, ...) The issue here is this needs to be stored somewhere. It is a new instance of something and we've said scapes are built from instances. So... this seems like a kind of relational structure/symbol that we need to store instances of. But it is of the "linguistic" kind of assertions that RDF triples are, which seems much weaker than creating real relational spaces where we can model the dimensions of variability relevant in a scape/relational space.
- In one Relationship case (as described above) it's quite easy. Eric gets added as an address book entry in Arthur's streamscapes, and tagged? friend. Eric is a new instance in Arthur's space or address book. Same could apply for a QIVC space which Eric as added as an instance of a member.
- However, in the case of shared space where Arthur and Eric exist (e.g. CouchMatching), it seems we need to add a new relationship (structure) of as a symbol "friend" with a new instance (with Arthur as first-child & Eric as second). This relationship structure could be considered mutual by default or have an inverse label for describing 2->1. (e.g. "maker of" vs. "made by")
- Relationship by ad-hoc or on-demand complex computation. E.g. nearby couch-matching hosts, Most frequent contacts, Best authors in my newsfeed (based on my "likes" history, or ratings, or reading frequency or whatever). It would be nice to store this computational data someplace temporarily, but it gets stale and needs to be refreshed. But from a user experience perspective, may take long to calculate on demand the moment I want it. Where/how do we store this semi-ephemeral/relative data? In just that user's client instance? Akin to their transaction chain in a currency? How do we identify how frequently it needs updating? How do we identify how subjective it is (Do values apply reciprocally across the whole range or unilaterally? Meaning: Distance is reciprocal, but author-quality in news-feeds is not.) Do we create good defaults, and let individuals invest how much CPU/storage they want on having results be fast and ready for them when they look?
Nested Tree Mockup
This is just a quick experiment with the CSS (1 selector with 4 properties). I could probably make it sexier, but it's pretty darn readable from both text and tree perspectives, I think.
Try playing around with the width of the window and watch how the structure adapts. I don't think it's fully cross-browser compatible, but seems fine in Chrome, Firefox and IE 11 (9 and up, I think)
Noteworthy issues to consider when translating typed text to trees:
- I don't think we want to require parens when we can use syntactical context.
- For many processes, we probably want to have keywords indicate advancing to next branch (almost like parens, but not paired... we could manually pop up by typing a close_paren (or other special key) and not display the paren just change the tree formatting/placement of cursor).
- e.g. If {first-child} Then {second-child} Else {third-child}
- e.g. On {first-child} Expect {second-child} Do {third-child} With {fourth-child}
- In fact, I think we'd want to prepopulate the next child keywords and be able to tab into their slot to type (tab then press {delete} to delete optional ones like ELSE or WITH).
- Where/How do we store such keyword sequence associations? Label Table?
- It doesn't make a lot of sense to display Symbols as def trees like above. A label table view would be much more useful.
- It also seems like we could make a simple def-symbol button or something to generate those kinds of entries.
- Similarly, it seems fairly easy to build a Structure Def tool for everything up until the process defs... which is where we switch back to the coding style originally describe above. So "coding" is always for writing processes. We can make a pretty simple UI for def-building so that constructing the semantic trees for content which work slightly differently than code, don't get confused with process trees.
Possible Color Coding Approach for Semantic Tree Background Colors:
First Column (named) colors are for borders, controls, etc.Note: We probably want to use the inverted colors (right-most) so that color clarity is higher in the initial levels setting type context clearly. It also makes layering veary easy because you're always adding a new layer of transparent white. Every time you switch symbol contexts (Process, Symbol, Receptor, etc.), you start a new color context layering anew (That's why the inverted colors may make more sense.)
Second Column nested colors are for recursing tree levels. They need to be darker than expected because 10 steps of 10% opacity <> 100%
-
Process: seagreen12345678910Hand-tuned darker target:12345678910
rgba(0,100,0,.1) -
Receptor: gold12345678910Hand-tuned darker target:12345678910
rgba(190,175,0,.1) -
Protocol: tomato12345678910Hand-tuned darker target:12345678910
rgba(190,110,0,.1) -
Semtrex: crimson12345678910Hand-tuned darker target:12345678910
rgba(150,0,0,.1) -
Symbol/Label: blueviolet12345678910Hand-tuned darker target:12345678910
rgba(80,0,130,.1) -
Value/Literal: royalblue12345678910Hand-tuned darker target:12345678910
rgba(10,40,120,.1) -
Def/Structure: sienna12345678910Hand-tuned darker target:12345678910
rgba(90,60,30,.1)
CD_043+juicy bits
- JavaScript IDE / Tree Editor
- System Level Service Receptors (Clock, Filter, Sessions, Authentication, Signing, Semantic Translation Filter (in membrane)
- Membrane Receptors (edge receptors inside the membrane of inner receptors)
- Semantic Translation Membrane Interface
- Scapes and Relational Spaces
- RDF / SPARQL / Semantic Web
CD_043+cusp
New iteration of scape implementations
CD_043+keywords
Scapes, Semantics, Membranes, Filters, Translation, UI, GUI, Tree editor,
view (naked) not supported for CD_043+pics
Pics Start Date:
Notes Date (end):
CD_042+dump
The Ceptr Puzzle
Topics: sessions, connections, runtrees, protocol specifications, error handling, processing
Sessions vs. Connections: Provide continuity across membranes for multiple receptors for interactions and building responses. A connection actually comes from an open channel to a shared common carrier as something else (like an ethernet wire, or a mic in a room) Any mic in the room the room can hear a sound. Any MAC on an Ethernet segment can "hear" every signal on that segment. That is a "connection" distinct from a "session" for identifying an ongoing interaction in response to a particular signal or source.
Sessions: Are clearly necessary to maintain coherence of flux/log entries, depencies as we spawn into sub-receptors for processing. The sub-receptors need to identify their responses as bound for which parent receptor's runtree they were called by and needs the result. Therefore, Session IDs are going to be generated as the RUNTREE ID of the running process awaiting response. :)
Processing: Three main types of process spawning/breeding/iterating: Sequence/sequential/series, ALL, ANY... Meaning... we're going to perform all these things in order, or we're going to do ALL these things (possibly in parallel), or if ANY of these things produce an acceptible result, we're done (also possibly in parallel, hopefully with a way to tell the other processes to abort).
Protocol revamp: Basically, we'll add "interactions" (conversations, sequences, templates) to the receptor tree structure which are a fabric for pulling together sequences of steps with expectations/actions in a templaty manner. So they generate protocol runtrees by uniting the elements defined in this receptor (or in other accessible namespaces). Standalone protocols will emerge as a convention of sharing a set of these interactions with supporting definitions and processes as a stripped down receptor in the compository. That receptor may be INSTALLED in someone's VMhost to register the semantics of the defs/processes/interactions into their local semantic space even if that receptor is never LAUNCHED (awoken by receiving a signal directly to its flux). This seems like a pretty lightweight way to install/share protocols without creating a new kind of container that is separate from receptors.
When a signal is received on an aspect, the default response_runtree is launched (as well any other actions on triggered expectations). The session ID is set to the Runtree ID that is running and that maintains the coherence for any sub-receptor processes needed to complete the response.
Error Handling: Every Ceptr defined process will be able to have an error handling code in its def as a root level branch (code, signatures, error handling). When an error is encountered/thrown the default behavior could be to reduce the function to an error (symbol and structured values (including path to where error originated in runtree)
CD_042+cusp
A unified model for processing of SEQUENCE / ANY / ALL in the context of loops, processes, expectations/listeners, flux/log, receptors, scape updates, etc. Doing this well may really be our ticket to appropriate parallel processing and performance which makes up for other overhead.
CD_042+keywords
sessions, connections, runtrees, protocol specifications, error handling
view (naked) not supported for CD_042+pics
Pics Start Date:
Notes Date (end):
CD_041+dump
Catching up on long window of not posting core dumps to capture pictures
CD_041+keywords
looping process webinar
view (naked) not supported for CD_041+pics
Pics Start Date:
Notes Date (end):
CD_040+dump
We've done lots of cool stuff...
We've created a new Matrix optimization for representing trees with fixed length addresses and optimized for rapid serialization / deserialization.
Archive on event flux for updates/deletes.
Semtrex is working in lots of great ways and even parses Semtrex ASCII strings now to build Semtrex trees.
CD_040+cusp
Data Engine work for synchronization
view (naked) not supported for CD_040+pics
Pics Start Date:
Notes Date (end):
CD_039+dump
Label Table and contexts for semantic labels and addresses
CD_039+keywords
Labels, Label Table, Addresses, Namespace
view (naked) not supported for CD_039+pics
Pics Start Date:
Notes Date (end):
CD_038+dump
Okay... it has been far too long since we've done a Core Dump... We've been doing a lot of software development and the parts are all coming together in exciting ways! However, out of concern about losing some of the details from our design discussions before having a chance to implement the designs in code, I'm going to try to capture some of the design output here.
Protocol Specifications
Aspects
Compository Functions
Proxy Tunnels (entanglement / coupling)
CD_038+juicy bits
Matching of outward aspects to inward aspects of the receptor you are installing into.
Proxy tunnels as "Let there be light." base protocol
CD_038+cusp
Pluggable Security Model
CD_038+keywords
Protocols, Compository, Proxy, Proxies, Tunnels, Aspects,
view (naked) not supported for CD_038+pics
Pics Start Date:
Notes Date (end):
CD_037+dump
Trees trees trees...
So... if trees are to be a native or primitive type for us in Ceptr... they need to more closely paralell native Ceptr communications (like envelope / body) so they don't need to be serialized/deserialized to be placed into signals/fluxes.
We explored a couple methods (depth first & breadth first) of having a linear surface for data with a "skip table" providing relative indexing for structure and nodes within that data for navigating tree structure. Both seemed doable. Both seem not to quite be the right answer.
My gut says that in same way we do alternating definition of structure and semantics with defs and labels, that having similarly structured grouping for trees... some other dimension to the data that allows the linear surface data to be pulled into a relational shape.
TNF form
Akin to BNF grammars we made a TNF grammar to validate properly formatted semtrex trees. And again we started to get pulled down the path of thinking a BNF style notation could represent our semantic data.
Semtrex ::= Root [ / Child]
Root ::= Literal | Or | Any | Question | Group
Child ::= Root | Plus | Star | Sequence
Plus ::= "PLUS" / Semtrex
Star ::= "STAR" / Semtrex
Question ::= "QUESTION" / Semtrex
Sequence ::= "SEQUENCE" / Semtrex [, Semtrex]...
Or ::= "OR" / Semtrex1 , Semtrex2
Literal ::= "LITERAL(symbol)" [ / Semtrex]
Any ::= "ANY" [ / Semtrex]
Group ::= "GROUP(group_name)" / Semtrex
However, BNF notation is for constructing structures from structures, not from semantically named uses of structures. It fails to have the alternative structure/semantics that our defs do that seem to be vital to make the semantics work.
I think this is in fact how language works. Phones are structurally produced sounds by configuring mouth/tongue/vocal cords in certain positions, phonemes are semantically significant groups of phones considered to be equivalent / different from other phones. Word parts are structured sequences of sounds, that then have semantic significance based on where you place them in the sequence with other word parts. For example, think of the "in" sound which has very different meanings in "inquest" vs. "question."
The pattern seems to continue at each level. And may be vital to semantic protocols. I want to try thinking about subatomics and electro-magnetics in these terms and see if that sheds new light on the importance of this approach.
Semtrex Development
Eric has been making good progress on building a semtrex matching engine which constructs state machines from the semtrex for matching against semantic trees.
CD_037+juicy bits
It seems BNF grammars can't get us our semantic approach because there are distinct operators/operations.
We can think of it like this:
- ::= means "is comprised of" and is for constructing new structures out of semantically identified elements. e.g Latlong ::= tree ( lat, long )
- --> means "is a named reference to" and is used to creating a semantic use of a particular structure/construct. e.g. Lat --> Float [ranged -90 - 90]
- And maybe we need some symbole for instance. 43.2351, -103.2405 is an instance of a latlong
CD_037+cusp
Some way of representing trees which is more native to our serialized format and is possibly congruent with our defs/labels approach.
CD_037+keywords
trees, semtrex, BNF
view (naked) not supported for CD_037+pics
Pics Start Date:
Notes Date (end):
CD_036+dump
Getting Back to Coding: Starting with Semtrex
Tasks:
- Build "Label Table" for hashing semantic labels from human friendly (system default language, eventually with multi-lingual support) to generate fixed size hashes to be used as semantic identifiers by semtrex.
- Build semtrex that can parse a tree serialization format (ASCII text) to trees in memory.
- Build Receptor Skeleton: Define, Declare, Instantiate
- Build scape framework (so that the Flux/Log can operate off of a system scape for receptors)
- Build Flux / Log / Inter-Receptor Bus including sub-logger permissions for shared memory access, and status indicators & access/update timestamps for garbage collection
- Build Actions: Request, Respond, Transform (Exec)
Serialization:
We identified the beginnings of inter-receptor signal serialization headers (see photos)
Name Spaces & Label Tables:
Every receptor holds its own semantic symbol table (label table) and is a unique namespace. Namespaces can be traversed relatively, or at the local VMhost root. Also, the compository as a psuedo-global (local to all of CEPTR) identity space for composable elements with a UUID algorithm and approach comparable to joining the Ceptr network via triangulation and trust. This allows CEPTR network messages between VMhosts to maintain semantic coherence.
The contents of the Compository itself, should be implemented in a manner similar to a bittorrent DHT, with confirmation of distributed payload via SHA/MD5 from a trusted source.
Threshold is a better name than Membrane as it embodies the threshing and the holding and sense of a transformative boundary, rather than simply a covering.
view (naked) not supported for CD_036+pics
Pics Start Date:
Notes Date (end):
CD_035+dump
Getting back to Coding
- Resolve: What are the composable elements of Flow Control
- How do we properly separate, distinguish, and identify carriers and symbols for use in Semtrex
- What operations are at the Sub-Conscious (inalterable system service level) vs. Conscious Level (accessible to Ceptr coders)
Semantic spaces to refer to coherence that exists in the real world (as opposed to the digital world) but explicitly creating specification of the world-view that a particular semantics lives in, so as to take into account the "those animals which when seen at a distance appear as flies" problem.
What token is used as the semantic key that Semtrex matches on?:The index of a child entry in the symbol tree or a hash that's in a label table? To start with, we will use use index in the symbol tree with the trick of using negative numbers for structures (which have a single instance), positive number for symbols (which have many instances) and the first 1024 of them reserved for system level ones that are pre-coded for all receptors have access to (i.e. label, int, float, receptor, etc) via a "symlink" type approach.
CD_035+juicy bits
"B.C" before cepter (for the semantic space that hold defenitions for the traditional computing world :-)
CD_035+cusp
Exploring the compository: How is it structured? How do we identify and organize sub-parts of receptors that may be kept there? (Like scapes, enums, structures, symbols, etc.) How can they be assembled into installable collections?
Flow Control and Phases: like setup, process, teardown. It's likely that phases will be generalized pattern for protocol development. Also seems like definitions of structures vs. instantiations of named structures also corresponds with phasing.
Installer processes in VM host for instantiating receptors from compository.
CD_035+keywords
carrier, conscious, semtrex, namespaces, flow control, symbols, symbol keys, compository
view (naked) not supported for CD_035+pics
Pics Start Date:
Notes Date (end):
CD_034+dump
Semtrex matching an expectation pattern (subconscious):
When the subconscious "matches", it wakes up the conscious and "does something"
Core theme:
Coherence
Relational Integrity
Scapes are the embodied mechanism for those relationship
You have something that exists at an address (existence address - xaddr)
Your address scheme embodies the geometry of the existence relationship of things in that space.
Coherence space for this like a lat/long, physical address, etc.
A new node on the network only exists in the space of "nodes"
Family tree: hierarchical relationship geometry
Existence "scape" holds the relationships of existence
The first scape that every receptor must have is the existence scape, defines the geometry of things that come into existence.
How do you know deal with relationships of collections of things within that scape?
for example: How many houses are within a political boundary? You then have another scape that defines the boundaries of houses.
Think of a scape as an index in the database, where the PK is existence scape.
Semtrex: Semantic Tree Expression
R/
./
(m>2 /
(x=3 & y=2))
& n=4 /
(a=2 & b=3)
^ - begins with
$ - ends with
. - matches any element in...
/ - descend
postfix operators:
* - 0 or more what * is applied to (referring to the thing before it)
+ - 1 or more of what + is applied to (referring to the thing before it)
[m-n] - exactly between m to n repetitions of what [m,n] is applied on (the thing before it). For example, [0-5]: 0 to 5 repetitions of...
, - sequence
x|y - there is an x or a y
x,y - there is an x followed by a y (those two children in that sequence)
x&y - there is an x and y in any order
() - anonymous group (allows grouping across levels)
(:name ) - a named group, otherwise groups are anonymous and can be referenced using $1, $2, etc.
Structure (may be necessary, but not implemented yet):
n/x - selects child x in n
n/:int - selects any node with the structure "int" in n
:float/y - selects y from a parent node with the structure "float"
--------
Difference between xpath and semtrex: xpath carrier is ascii, semtrex carrier is semantic trees.
CD_034+keywords
semtrex, subconcious, coherence, overview
view (naked) not supported for CD_034+pics
Pics Start Date:
Notes Date (end):
CD_033+dump
semtrex, run-trees, code-trees, smtp
English mapping: predicate, noun, pronoun, subject, agent, agency
CD_033+keywords
semtrex, run-trees, code-trees, smtp, protocol, carrier
view (naked) not supported for CD_033+pics
Pics Start Date:
Notes Date (end):
CD_032+dump
TREES / TREES / TREES
There are a bunch of things we've covered since our last core dump... Lots of C development of low-level CEPTR protocols has been happening... structures of nouns and instances, scapes and listeners, logs and "conversations."
But we never built the low-level tree structure which has been hampering progress of building some other "elements" like Lists & Streams (which are actually trees of Patterns/Arrays/Lists/Streams).
As we began to see the tree like structure necessary for our "conversation" logs, we revisited the trees topic and it has leaped into centrality in a whole new and important way.
- Code is a code tree. When we represent it as human readable text it is actually just a human readable serialization format. Properly it is a tree.
- Conversations are signal/event trees
- Data is organized and structured as trees. It's a bit of a falacy that it is in linearly addressable blocks. Natively it is in L1/L2/RAM. RAM is structured on different ranges on chips. Files are stuctured in different blocks in sectors on platters. We normally force it into linear form because our computing models want to relate to it like that. What if we don't have to?
- Trees can contain contents which are again trees in a new context. This could be subaddressed like /3/5/7/0/1/2 (where 0 means entering the contents of the node at 3/5/7 and then navigating /1/2 into its structure)
- Noun Trees and Spec Trees can directly reference the pattern specs of the things they contain
Running an instance of a code tree happens like this:
- Put a pointer to the code tree into the new execution context (like a conversation log ... an HTTP_Request gets logged, so we drop a reference to the HTTP_Request processing code onto the conversation tree which references the signal as its input.
- We crawl the code tree instantiating the ports on our new "stack frame" as we process it.
- We reduce variables and function calls to their actual values as we go
- We slowly transform the code itself to its output. When the code is done running, the state of the tree that's left is the program's output.
CD_032+juicy bits
We can think of the data engine as waking on a log trigger, matching an appropriate code tree onto a conversation to "process" it. As it runs it prunes itself away until there is only the output which is reintegrated into the data engine..
This feels like a very organic "breath-like" process of expanding and contracting and if it doesn't have the right code-tree to run through the code-reducer... it can go look it up and add it to its repertoire. Receptive capacity.
CD_032+cusp
- Structure of conversation log and its processing states when running through and actually HTTP Request example (New, Open, Pending (parsed?, integrated?), Implanted, Completed).
- Thread safety for processing code trees with multiple threads
CD_032+keywords
Trees, Code Trees, Noun Trees, Spec Trees, Tries, Conversations, Logs,
view (naked) not supported for CD_032+pics
Pics Start Date:
Notes Date (end):
CD_031+dump
marketing in espanol
view (naked) not supported for CD_031+pics
Pics Start Date:
Notes Date (end):
CD_030+dump
Notes on Tech Architecture of semantic trees
New ideas for Gameshifting Board
Screen Layout for Streamscapes UI
view (naked) not supported for CD_030+pics
Pics Start Date:
Notes Date (end):
CD_029+dump
Marketing Brainstorming Session for Kickstarter Campaign and Streamscapes. (See photos in reverse order)
** Upgrade your Communication to Collaboration **
Kickstarter Goals
- be accountable to delivering a product (something we're excited to deliver, and preferably to likely first users)
- build interest, excitement, and participation (especially among those who may spread it further)
- Raise some money for covering food and flights for a deep dev session (ELL style?)
Profile of our First users: (See pics)
Actual candidates for Focus Group and First Wave of Kickstarter Outreach (see photo)
CD_029+keywords
marketing, focus group, early adopters
view (naked) not supported for CD_029+pics
Pics Start Date:
Notes Date (end):
CD_028+dump
- Notes from Carrier/Protocol/Data explanations
- Pattern Geometries
- Marketing strategy for Streamscapes
- Required features for Streamscapes
CD_028+keywords
features, geometry, marketing
view (naked) not supported for CD_028+pics
Pics Start Date:
Notes Date (end):
CD_027+dump
First week of ELL Ceptr/StreamScapes intensive
view (naked) not supported for CD_027+pics
Pics Start Date:
Notes Date (end):
CD_026+dump
On Eric's trip to NYC for the beginning of Agile Learning Centers / Manhattan Free School, we got some time to inquire into the deeper underlying "physics" that Streamscapes may embody and enable. This also involved bursts of decoding patterns in normal "physics" and looking for the lessons/patterns across them both. One juicy path of exploration was triggered by Paul Krafel's CAIRNS #73 and his thoughts on the "directionality" implicit in the 2nd Law of Thermodynamics.
This triggered Art's re-statement of the second law as: “Thou shalt not concentrate power.”
Energy flows down like water in a stream… USABLE energy becomes less and less usable because every party in an interaction gets some. Concentrated energy is subject to entropy and is forced to “share” energy in every interaction with every “party” to that transaction. Maybe this is part of the "fuel" that keeps atoms running and that's where it falls to.
Even in the dynamics of MATTER (not just energy) too much concentration is discourage. Gravitly pulls gasses together into stars. Atoms in a star collapse and fuse under the weight of gravity releasing ENERGY from the concentrated matter. The final result ends in a supernova which even scatters the concentration of matter.
Processing and storage will be finite (or at least limited in their capacity and rate of growth). There may be "entropy" to build into the system as almost a kind of "tax" that fuels the sustainability of the sytem.
Examples:
- Responses may be "cheaper" to send than requests.
- We may want certain kind of signals to "escrow" credit which are returned if the signal was welcome or "consumed" if the signal was unwelcome.
- To prevent scape updsate cascades from running infinitely by having a processing "budget" that runs out. But it may also be increased by the number of listeners.
The yin yang symbol as it relates to two-hands-writing... There's a spot of black in the white and white in the black. Our processing and storage may be similarly interwoven... a dot of processing in the data engine, and a dot of data storage in the processings space.
There is an interlock between these parts. I wonder if the "keys" can be encoded in this segment of the other to truly intermarry securely.
CD_026+juicy bits
"Thou shalt not concentrate power"
Some processing capacities in the data engine. Some data storage (mem) in the data system. Both interlocked securely.
The "physics" of the space must be intentional. There are lessons we can learn from the thermodynamic behavior of matter as a system which keeps things running. We may need to build our "physics" similarly.
Eudomonia
CD_026+cusp
- Sustainable patterns for running/fueling CEPTR networks.
- Eudomonia - finding the pattern that sustains the highest energy level across the system.
CD_026+keywords
Thermodynamics
Eudomonia
view (naked) not supported for CD_026+pics
Pics Start Date:
Notes Date (end):
CD_025+dump
Forking vs. Deprecation, outside-duplication vs. inside forwarding. This is related to the immune system's method of determinging what "stuff' is both "not-me" and harmful. Also related to mitosis/miosis.
Rehash of the registering your UUID onto the network protocol via triangulation: one person to give you the algorithm, yourself to create the UUID according to that algorithm, and another to register your address on the network (after confirming with the first person that you are legit).
Possibly using the hash of the registering-on-the-network log transaction as ID instead off UUID? Or as a portion of your ID?
How do we prevent (or do we need to) corrupt Virtual Machines for doing fake registrations/IDs, etc. Two hands writing where the Data Engine is the second hand? How to deal with data explosion if we are doing signed transaction chains for all data including RAM!!??
Rate limit at which you can sign people on to the network to prevent polution by data explosion a kind of Denial of Service attack.
CD_025+cusp
How to separate the processing from the data engine such that they can be two hands writing for eachother.
view (naked) not supported for CD_025+pics