Functions

[richburdon]

Functions

Status

As of Q4 2023, we have a prototype of functions running within the Agent as a plugin. The implementation does not address scalability or security considerations and all functions have access to the user’s client and spaces.

The next phase of the project will include the creation of a product requirements specification, technical design, and project plan targeting a Q1 2024 release. The plan should also include research experiments to evaluate prior art and get feedback about requirements.

Background

ECHO is a decentralized realtime graph database made up from an unbounded number of Spaces, which represent individual database realms. Spaces control user permissions and contain a graph of typed Objects and References that have data consistency within the Space. Users can run special peer nodes called Agents, which have access to the user’s Spaces. Agents can be configured to run DXOS infrastructure services, and user-programmable functions that can query and mutate the user’s data graph.

Functions are short-lived single threaded subroutines that implement a similar programming model to AWS Lamba and other serverless platforms. Functions are triggered by various kinds of events, which may represent external HTTP requests, platform API calls, timers, message queues, and ECHO database updates via subscriptions. Functions may directly and indirectly trigger other functions, forming a dependency graph, which we may call a computational hypergraph.

Use Cases

Functions may fall into the following categories:

• Syncers provide a bridge between Spaces and external data sources to synchronize objects either unidirectionally or bidirectionally. ECHO objects can individually track foreign GUIDs in order to facilitate synchronization; objects can additionally be associated with a schema definition and may make use of emergent middleware (e.g., Ink and Switch Cambria) to map ECHO and external objects. Examples of syncers include OAuth services (Gmail, calendars, contacts, etc.), SaaS systems (e.g., GitHub, Salesforce), enterprise assets (SQL, NoSQL databases, LDAP, etc.).
• Resolvers may map realtime requests like search to identify sets of objects that are relevant. Resolvers may use Agent services like a full text index, or call out to external services (e.g., search engines, enterprise GraphQL endpoints).
• Generators may also respond to realtime requests in order to generate and dispatch prompts to local or remote LLMs. Request may include explicit user input (e.g., chat) or realtime signals such as presence or context information regarding the user’s current activity (e.g., active document, workflow).
• Functions can be configured to implement map-reduce pipelines. Reducers operate over updated objects to maintain secondary datasets like indexes or reports. Agents use functions to maintain a full text index across all of a given users’s Spaces to provide a universal search services. Reducers may be chained to perform complex decentralized calculations across user data.
• Functions may implement transactional operations, such as interaction with bookings and reservations systems (esp. travel, purchasing), payments gateways, and blockchains.
• Functions may be configured to implement business workflows, where business logic is executed in response to a state change on and ECHO (or external) object. For example, a recruiting pipeline may be set-up to trigger a calendar scheduling request whenever candidates are selected from an intake pool.

User Stories

• A small company uses DXOS to manage their recruiting process.
• A space is created to track open source projects and developers. A second space is create to track the interview pipeline for candidates. A kanban is set-up to track the status of candidates from the prospecting and contact phase, through scheduling, interviews, and offers. A form enables employees to enter interview feedback.
• The team creates and/or subscribes to paid functions to:
  • Crawl GitHub to find and sync information relating to developers who work on projects entered into the system.
  • Search public and paid services (e.g., LinkedIn, Crunchbase) to augment information on developers in the pipeline.
  • Call LLMs to summarize candidate information (incl. PDF resumes) and interview feedback.
  • Call LLMs to write job postings.
  • Schedule interviews.

Design Considerations

Execution Model

• To limit operational complexity and to help control resource utilization functions are short-lived and subject to early termination by the execution container after a predetermined timeframe. This should limit the scope for runaway processes and deadlocks.
• Functions may be created in different programming languages, and possibly compiled into WebAssembly.
• Functions may run within browser, mobile and agent (server) execution contexts.
• Functions are single-threaded and isolated from other functions and processes.
• ISSUE: Detecting recursion and circuit-breaking.
• ISSUE: Resource allocation and metering.
• ISSUE: Determine possibility for multi-tenancy and auto-scale.
• ISSUE: Security model to invoke function (e.g., API-keys, restricted IP, etc.)
• ISSUE: Metering for the development of paid services.

Programming Model

• Functions are scheduled in response to events generated by different subsystems. Events may correspond to external HTTP requests, platform API calls (e.g., via the Client API), timers, message queues, and ECHO database updates via subscriptions.
• Functions are passed the incipient event object and a context object that includes the peer’s Client API object.
• ISSUE: Retry on failure (e.g., retry function call if external API call fails.)
• ISSUE: Workflow/pipeline definitions (e.g., see AWS Step functions).

Security

• Functions may run under their own identity or as a device belonging to a user. Therefore, they may have access to the same access control credentials as the associated user, although these may be limited by the function’s configuration on deployment.
• Functions should be isolated from each other and other processes outside of the execution container.
• Access to system resources (disk, network, etc.) may be restricted by function-specific configuration.
• Functions may require access to secrets, including private keys to access local and remote services, and possibly high-value account information such as blockchain addresses.
• Functions should not have access to the whole client?

Development

• Developers can simulate the execution environment to developer and debug functions.
• Functions can be dynamically deployed to running agents. Additionally, it may be possible to deploy functions to browser-based execution containers.
• Functions are versioned with semver backwards compatibility semantics.

Misc

• Functions may be triggered from Composer Scripts and notebooks.
• Functions may be integrated into other notebook-like environments like VSCode.
• Functions may designate their requirements of the execution environment (e.g., memory, disk, network usage). These requirements determine the portability of function components across execution environments.
• We may consider a global decentralized function registry that can be used to register and discover functions and their associated build, configuration and runtime metadata.

[mykola-vrmchk]

Spec for functions #4743