This is an old revision of the document!
Table of Contents
F1x Architecture
Overview
Terminology
- Site - F1x node installation
- Identity - public/private keypair
- Realm - set of objects that belong to signed by Identity private key. All shards in realm have the same realm ID.
- RealmID - hash of Realm public key
- Epoch - positivie number representing version of the object
- Shard - contains specific version of Object of Data or Code (Handler) kind with unique address ~ShardID.
Published shards have addres RealmID:ShardID. For security reasons, normal and published Shards have different location on disk.- mandatory fields: name, kind, epoch
- Data shards have _handler
- Code shards have _code attribute
- Handler PubSub has method listener_SOMENAME and callback_SOMENAME. The callback method of Handler is called if result of the corresponding listener method changed. Internal logic might intentionally call listener method to invoke subscribed callbacks.
- Handler - Code shard that knows to execute methods for certain Object kind
- Handlers Set - Handlers published by the same Realm
- Reflector - Object sole purpose is to subscribe to a listener method of referenced PRIVATE Shard. On every change - new public shard of kind “ReflectorUpdate” is created, with the new result value is stored, the shard is signed and made available for external subscribers.
- Publish - procedure to create Reflector
- Subscription - Object that specifies rules to invoke methods of other Objects. The invokation is done on
- to Reflector: specifies Object and method to call on each new shard of kind “ReflectorUpdate” and specific ReflectorID
- to Objects: specifies Object and method to call on each new shard of kind “X” and possibly other conditions (like geo “Y”, gender “G” or age range MIN/MAX)
- Router - Caching/Routing/Matching Server (CRMS) - intermediate server, usually sits on internal network or at ISP
- Router - keep track of objects its children sites are subscribed to, forward objects to sites. Allows Sites to register as children based on IP.
- Cacher - cache frequently accessed objects
- Matcher - Attraction/Proximity role
Site
Site is compute infrastructure that enables users to operate Identity Realms. It consists of events routing server and presentation (like web server).
Web server (presentation) functionality:
- authenticate the site user (a site normally has one user, preferably with unique domain)
- communcate with core on objects CRUD
- visualise and manage content in user-friendly way
- show notifications
Events routing server performs functions below:
- Storage for shards
- Execute methods
- provide pserver interface for exported Shards
- Keep track of subscribers, notify CRMS on changes
- garbage collect “foreign” Shards that are not referenced anymore
Data Shard
Data Shard is on-disk representation of object with fields that has associated data handler (Code Shard), similarily to data and code separation in OOP.
Code Shard methods is written in Lua and is executed in sandbox. API methods to read and call referenced Objects allows writing sophisticated applications.
Published Shards
Normal shards are accessible to Realm owner only. The owner might choose to publish methods of some objects using special “Reflector” objects. These also might be encrypted with public key of intended recipients, thus limiting who can see the content.
pCache server
Every Site is connected to a pCache server. It might be discovered by asking centralized “pCache servers registry”. It is publicly accessible and should be at location with good connectivity. The pCache servers perform functions below:
- retrieve list of subscriptions from sites under its control, send back matching Memos
- retrieve “exported” data from sites and share it to sites that request it. Cache the data.
- receive notifications from children sites about data change, forward them to upstream pServers or other sites
Publish/Subscribe
Frequently object want to know when something changes in other specific objects. To maintain encapsulation principle, this is done by “listener” methods. When other objects indicate desire to get notifications of a “listener” method, result of the method is remembered, together with list of “subscribed” object/methods. When Object wants to “notify” subscribers on a change, it invokes listener method that returns different value, thus causing methods of subscriber objects to be called.
The subscribers might then recalculate a value, compare with threshold and raise nofification to user or alter return value of their own listeners, thus “publishing” a change.
Attraction/Proximity
To discover other objects of same kind, there is attraction-proximity “wandering search query” mechanism.
Task "match riders that go from Jerusalem to Eilat"
Objective: My Object “Intend to travel from Jerusalem to Eilat by car, 2 empty seats” need to find other objects “Intend to travel from Jerusalem to Eilat somehow”. TBD
JQ queries
Microapps need to access data from other Memos. They can run jq queries on “known” Memos:
- what is default measurement system of the owner? Imperial or standard
- get list of neighbours who know me:
- find Memos of kind People and have homeAt geo and have Memo of kind Subscription where (site=me and kind Memo=Message)
- remove ones that have distance between me and homeAt more than 100 m
Stored queries (subscriptions) also use jq to find matching Memos: TBD How?
Security
For the system to be popular, users must trust the system to be able to protect their data. That means that Handlers must be trusted not to misuse data.
During setup Site owner is assigned “default” set of Handlers, that been carefully audited. He might change it or “overlay” it with other Handlers sets.
In addition to trusted Handlers set, data sharing must be permitted for each case. Initially Handler has “Unknown” security level. Once it reads from internal object, it is assumed “restricted” level, and it can not publish (write into public objects), unless permitted by Site Owner. The allowance might have a checkbox “remember this choice”, thus allowing the particular combination of Handler and Object to publish.
Site security
Handlers are executed in sandbox, with access to Object fields (in the shard). Some fields are volatile, e.g. they are stored in cache area, separately from the shard. For POC we use Lua for Handlers language (RestrictedPython is possible).
