Project Molecule
Project Statement
Project Molecule is a multi-node shared application environment for smart home systems.
Purpose
The creation of Project Molecule was motivated by frustration over incompatible smart devices on the market. It is intended to be used by 3rd party developers and enthusiasts to link such devices and create a connected home. The project forms a backbone for communication between different devices and handles concerns such as networking, availability, and security.
Deliverables
Project Molecule provides a runtime binary for the system and a common API with documentation for 3rd party app developers. Application creation and configuration tools will be provided to setup new projects and configure our system. An operation manual (Appendix I) is also provided to guide the user through setting up their system and creating an example application. All source code will be provided under the MIT license.
Overview
The System
is comprised of several nodes called Atoms
. Atoms
manage all communication in the System
and enforce permissions. Atoms
also manage and run 3rd party Applications
. These Applications
run in separate processes and can communicate by sending Messages
through the System
using a provided API.
Messages
Communication uses a Request Response architecture meaning that a Sendor will receive a response Message
for each request Message
sent. Messages
contain routing and protocol data, a sized data payload, and an optional data stream. The optional data stream can be used to send large files or other types of data.
Actions & Payload
Messages
implement User or System
defined protocols called Actions
. The Action
type is stored in each Message
and allows an Application
The type of an Action
is part of the header in a Message
stored as a String in the Message
to reason about the data that will be included in the payload and data streams. For example, when an Application
receives a "FILE" ACTION
, the message payload of a request will be the following enum:
pub enum FileAction {
LIST(String), //List all files in the directory name stored in the contained string
GET(String), //Get the file with the name stored in the contained string
}
The response payload will be dependent on the reqest. i.e:
- On a List request, the Response Message will return a Vector of Strings representing the file name in a given directory.
- On a Get request, the Response Message will contain the status of the request and a Stream containing the file data.
Routing
Message
routing information is only processed on a request. This processing sets up a path for the data to return. Once a request has been received, the response follows this path back to the requestor. If an error occurs, the requesting Application
is notified of the failure.
An Atom
routes a request by analyzing the following Message
parameters:
- The
Action
protocol - An
Application
identifier filter - An
Atom
identifier filter
The Identifier filter is one of the following:
Any - Resolves to one identifier
All - Resolves to all identifiers
One - Explicit identifier
Some - Explicit group of identifiers
Here are several examples of how a message would be for the given parameters:
Action | Atom | App | Description |
---|---|---|---|
T | ALL | ALL | Broadcasts message to all applications on all atoms which can receive Action T
|
T | ANY | ONE(id) | Routes a Message to an unspecified instance of the Application
|
T | ALL | ONE(id) | Routes a Message to all instances of the Application
|
T | ANY | SOME(ids) | Routes a Message to an unspecified instance of each Application
|
Applications
Applications
are 3rd Party Binaries that use our Messaging
API and are managed by an Atom
. They have a manifest file which specifies:
- A globally unique identifier
- A unique human readable name
- Supported
Actions
Permissions
A developer must declare the Actions
an Application
can send, receive, or broadcast in order for the Atom
to route Messages
and enforce permissions. If no Actions
are specified, the Application
will be effectively cut off from the System
.
Extensibility
Applications allow the system to be extensible and connect many different devices. To connect a Smart Thermostat, for example, an Application
could implement a "THERMOSTAT" Action
which wraps calls to a 3rd party API.