Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Ceptr Tech Overview

Ceptr: Under the Hood

Arthur Brock

on 7 February 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Ceptr Tech Overview

Your Laptop
Web Browser
Serializes Receptors to Data Engine
to free up memory resources
User Interface
Developer Tools
Receptor Hierarchy/Bindings Editor
IDE / Tree Editor
Debugger /
Stepped Simulator
Definitions /
Semantic Labels
Developer Plug-in
UX Client Plug-in
User Interface
Ceptr Installation
Scape Cascade
(data indexing & optimization
of database operations)
Sovereign Accountable Commons
bound to
Ceptr starts by launching the Data Engine, which checks for updates to the VM Host, confirms hash match, and then forks a process to launch the Host
Tree Editor
Receptor Editor
Receptor Layout Editor
Semantic Trees
Symbols and Structures are assembled through a process of Semantic Alternation modeling how we make sense in the world outside of computers.
Self-describing Protocols
Protocol Chaining
Protocol Nesting
Aspects & Carriers
Receptor Elements
"Ceptr" is short for Receptor.
Receptors are Ceptr's core computing units.
Binds special Edge Receptors for OS services (network sockets, file access, Std I/0, etc.)
Manages resources for Receptors
- Process Pools / Threads
- Memory & Storage
Instantiates Receptors
for active processing from
Data Engine
The Data Engine provides protected database
& file system space bound to each Receptor
Inter-Receptor communication
happens through the Flux
The Data Engine places inbound signals
into a Receptor's Flux like an input queue
Memory Receptor Hierarchy
(They can be nested /
instantiated inside each other.)
The Receptor processes the inbound signal on the Flux,
preparing resultant state changes to be integrated as a single transaction
Changes are queued for sync
if it is a multi-instance Receptor
Semantic Registry
The Data Engine handles Byzantine Fault Tolerance and Distributed Hash Table for distributed multi-instance Receptors
(Inter-Receptor Transport/Bus)
Input buffer / message queue
Protected execution context
Stateful message processing
Signed message log
Receptors can also be serialized into their
data space and resume their activity later
System Services
(Clock, Console, etc)
Functions as:
Source Trees
Run Trees
Relational Assertions
On < aspect >
For < carrier >
Match < semtrex >
Do < action >
With < parameters >
Until < end condition >
Label Table
Symbol Addresses / Definitions
Ceptr's base data representation is Semantic Trees. We preserve semantics in the lowest layer as well as basic object structure by organizing in trees.
A self-eating Run Tree functions as a semantic stack which can be paused, resumed, or debugged directly since it retains data semantics.
For execution, Ceptr clones a source tree with its parameters to create a run tree which is processed by reducing itself to its result.
We've extended Regular Expressions (which match text patterns in linear strings) into a structural tree expression matcher. And since Ceptr uses semantic trees, we can match on semantics as well as literal values.
(lightweight VM's)
Memory Caching of common
disk / network resources
Interfaces w/ OS on physical machine
The VM Host is
the container for
running Receptors
Some Other
More Receptors
for external
OS services
file system
TCP Sockets
A new composition must be vetted by at least one other developer to be uploaded into the shared Compository
Ceptr is like a parallel internet that includes its own distributed Github
When a user downloads a composition Ceptr will also look for another user to verify the hash code
There is a code repository for Ceptr compositions called a "Compository"
Once signed by a second party a composition gets an address /ID in the shared Compository
Each installation has a local compository to store development work and compositions developers only want to share directly
Logical Structure -
Address Hierarchy

A composition address points to a root node and updates are added as subnodes upon that. This maintains semantic integrity across versions, and allows for notification or auto-updating when receptors are re-instantiated.
There is no orthodox namespace for the Compository. Users have control of the overlay for organizing between compositions.
When it's downloaded the installer acts like a phenotype. It takes a generic item and wires it to interact specifically with your local system.
There is a general shared Compository that stores compositions in a DHT and distributes or updates them among all network installations
Particular bindings are specified in the manifest.
Code Processing
The manifest has open slots / fields with default options supplied through configurable preferences
An item from the compository is like a genotype.

Data is stored as trees. Program code is stored as trees. Instead of operating on 32 or 64 bit ‘words,’ Receptors operate on semantic trees.
All semantic elements have definitions reachable through the system's semantic registry which define its structure, semantic labels (by language) and any related processes.
{Link for details: }
Process definitions are basically program code. Processes can
be embedded in operators or validation for Symbols or Structures, or standalone like callable procedures or functions.
Other definition types: Receptors, Protocols, SemTrex, etc.
After the item is installed the manifest can be modified to bond to other items.
Ceptr stores source code as Semantic Trees just like everything else, not as ASCII text.
So execution requires no lexing or parsing.
Because each Run Tree holds its own state and is being reduced down to its result, this architecture is great for concurrency and possibly in the future, massive concurrency via GPU Processing
So what do Receptors receive?
Any signal encoded on a carrier the receptor is connected to
Receptors define Aspects bound to particular Carriers, similar to ports expecting protocols (e.g. HTTP on port 80)
SemTrex functions as a universal parser to interface with any Protocol or API. Since it operates on semantic trees it doesn't need to lex or parse, but simply match on semantics, structure and values.
SEMantic Tree Regular EXpressions
How are these signals processed?
On <carrier>
Expect <semtrex>
Do <process>
With <params>
Ceptr Designed For:
Unencloseable commons ready: no forced mediation
Appropriate & Deep Decentralization

Mutual Sovereignty
Composibility & Mashability
Protocol for Protocols

Why & How

How do we achieve composibility?
Live/pluggable Protocols
(INITIATE (ROLE:MEMBER) (ROLE:GROUP) (ACTION:request_membership)))
*Obligatory UI Image
Local storage optimized for rapid
random access retrieval
Data Engine distributes data
to other Receptor Instances
Connects to Ceptr Installation on localhost
Plug-in renders items based on UI hints (for view or edit)
User can select/save their
UI preferences
Supports a growing library of shared UI designs/snippets/widgets
C based S/Kademlia implementation or similar viable alternative
Network addressing:
identity through triangulation
Signed message chains
Distributed public key infrastructure
Protocol hooks to reputation currencies like share ratios
Native support for "Intrinsic Data Integrity"
in cryptographically tamper-proof structures
BFT Sync
Full Sync (w/ delta shipping)
Invitation to a perspective
Computational biomimetics and semiotics
Receptivity over Ontology
Invitation to Action
Help Build Ceptr
Build stuff on Ceptr
Ceptr's Sovereign Accountable Commons
Ceptr story-telling
DHT for sharded distributed data
BFT for full synchronization
(like Merkle trees & hash chains)
A Sovereign Accountable Commons is
Ceptr's parallel to the Ethereum DAO
Reputation currencies will account for the value of Receptors in the ecosystem and crypto-currencies will be used to compensate contributing developers for the use of their work
The Compository will be managed through this form of open source governance
Email Inbox
SMTP Server
Email Inbox
Cloud Server
Email Inbox
Cell Phone
Web Browser
Impact Hub Oakland
Jan 25, 2016

Full transcript