COCO supports a variety of use cases. A few examples are Peer-to-Peer chat application without needing public internet connectivity, serverless file sharing between peers on the same COCO network, serverless remote connectivity to your network from anywhere in the world. COCO’s technology stack can be deployed in a variety of networked scenarios, not just home automation.

We would humbly suggest that your apps do not need to be on the Cloud for global connectivity. Using COCO, you can enjoy global connectivity while keeping your apps and data off the Cloud. It is possible of course to secure your Cloud-based apps and data, however, why run the risk of having such data hacked when you can remain Cloudless using COCO?

You are referring to the notion of data privacy. COCO enables data privacy, but how any particular solution uses data privacy is completely up to the implementation. If you wish to enable personalized ads through Google or Facebook or similar, there is nothing in COCO that is going to prevent that. We do believe however that using COCO, you may enjoy not being forced into sharing your data with central servers.

Glad you asked! The COCO developer edition comes with an IoT Gateway that is already “Buzzed on COCO”. We highly recommend this gateway as an excellent way to get started on building out your P2P IoT Apps.

The multi-radio, wireless gateway is designed for quick home automation solutions. It connects smart devices with each other featuring Zigbee, Z-wave, Bluetooth Low Energy, Wi-Fi and Ethernet, and lets you create innovative IoT applications, services, and products.

The modular construction of the COCO gateway can be customized in radio standards as well as the look and function of the device. The IoT smart hub can be applied to different smart home use cases to create smart energy, home security, home safety, elderly care, and other similar smart home needs. It measures energy, temperature, illuminance, and relative humidity. 

Perhaps the best way to explain fine-grain resource control is through an example.

Let’s assume that you have COCO installed in your smart home, and would like to control your smart door lock remotely through your COCO network.

Let’s further assume that you would like to provide your maid access to enter your home by unlocking the smart door at around 9:00 am. Your maid is not to have access to any other resources on your network, for example, she may not access a storage device on the same network.

This is possible because of fine-grain resource control, where specific resources such as your smart door lock can be unlocked, for specific durations of time, while no other resources on the same network are accessed. This is as opposed to full network access that you may find in an enterprise VPN solution.

To enable rapid IoT development, the COCO App SDK is available on Operating Systems like Linux, Android, iOS, OS X, etc. and in various languages like C, C++, Java, Swift, and Javascript. Device manufacturers may use the COCO Device SDK on Operating Systems like Embedded Linux, FreeRTOS and ThreadX, and can be cross-compiled into various MCU and ARM architectures.

Yes, we are happy to partner with you on your marketplace. COCO’s marketplace (aka “COCO Grove”) is simply a list of apps and devices that enable COCO functionality. You can explore different apps and devices that are Buzzed on COCO and access the same for your network.

You can access COCO Grove also from the COCO App which is designed to help you get started with smart home automation, define resources, zones and capabilities based on your custom needs.

User COCONets are relatively smaller networks, owned and managed by users registered with the COCO User Login and Authorization systems. Such COCONets allow Enterprises and Individuals to control the Apps and Users within their own Private Network. Network management capabilities like inviting users into their COCONet can be performed using the COCO App. Invited users can join the COCONet using any application built for Private Networks. The app instances installed in a COCONet form a sub-cluster and can discover and communicate with one another.

Developer COCONets are owned and managed directly by a Developer who creates a global network with a very large number of nodes. Apps built for developer COCONets can by-pass COCO’s User Login and Authorization systems, but still, leverage the P2P communication between the various nodes of the network. For e.g. a global chat app where every user in the world has a node in the network. The App Developer can maintain a cloud with his Service App calling into COCO’s REST APIs for managing his instances of COCONet and the nodes installed in it.

Rule is a group of one or more actions and one or more conditions, where the actions are automatically performed on the conditions being satisfied. A condition can be a resource condition (for e.g. Light Bulb Color = Red or my motion sensor has detected occupancy), or a schedule condition (for e.g. Every Monday at 9am, or every day at 6am). At least one schedule condition AND all resource conditions must be met in order for a Rule’s actions to be executed. An action can be a resource action (e.g. change my bulb’s color to Blue) or a Scene action (e.g. trigger my party scene). With this background, here are two examples of rules:

1. Switch on your geyser (resource action) at 6am every morning (schedule condition), or
2. Toggle all the lights in a room (scene action) when motion is detected (resource condition).

Scene is a group of one or more resource commands that are executed at the same time when the Scene is triggered by a user. For e.g. you want to switch off all the lights in a room (this is a grouping of the ‘Off’ action for every light bulb resource in the room), or perform the setup for a party (which may include many different resource actions such as turn-on disco lights, dim the main lights, turn-on the stereo system, play my playlist and so on). A scene is typically provided as a single button on a user interface which performs all of the predefined actions on being triggered.

Zone is a group of one or more resources. It is similar to the usage of zones in Home Automation systems to designate regions within the home like the living room, bedroom, etc. where devices are physically located. In our platform, it can be used for any kind of categorization of resources, so that they may be browsed by zone and located more easily.

A peer-to-peer network derives its name from the topology of the network. In such a network topology, all networked machines are neither clients nor servers, they are instead peers (both clients AND servers). Historically, during the ARPANET days, all networks were designed to be peer-to-peer (P2P). In a peer-to-peer network, any machine on the network can communicate directly with any other machine on the network without requiring an intermediary to help exchange the data.

A node is part of only one cluster, and can only communicate with other nodes of that one cluster. Communication between different clusters is not possible. Having said that, It is possible for an application to start two instances of the Control Plane (CP), so it appears as two nodes. While from the cluster protocol point of view there can be no communication between two different clusters, the application will have access to two clusters in this case, and can in principle relay messages from one cluster to another.

Fig. Three different Apps/IoT Devices that are part of a cluster. 

In this example, A and B communicate directly with each other, as do B and C. Nodes A and C can also communicate with each other through node B (grey line).

Each node in a cluster has a unique name and its own public/private keypair. Each node maintains an encrypted database of information of other nodes that are visible to it, i.e. part of the same sub-cluster and the core cluster. This encrypted database does not always have to contain information about all nodes that belong to a cluster; it just has to know a few other nodes so it can make connections to them. When a connection is established between two nodes, they will exchange their knowledge of the cluster with each other, and potentially complement the information in each other’s databases.

The database contains information like the names of nodes, their public keys, and their last known IP addresses. Using this information, nodes can try to establish connections with each other over the Internet. Information about established connections is also shared with other nodes, such that all nodes have knowledge of the whole graph of connections within the cluster at any given point. If there is a path between two nodes in the graph, these two nodes can always communicate with each other.

Attributes are specific features os a resource’s capability. Each capability could have attributes specific to each capability of the resource. One such attribute in a lighting app could be to ‘turn-on’ or ‘turn-off’ the light; to change the color to RED, etc.

Resources have capabilities that perform a few functions. For instance, a lighting app would have capabilities such as to light up, change color, dim or brighten the light.

Yes, using our SDKs and APIs, we allow a developer to programmatically create and control their own network. Note that the developer has​ to be an owner of the network to be able to programmatically control the network. S​ee the API documentation here.

Resources within a COCONet include the devices and apps on a given network. Each resource could have unique capabilities. For instance, in a smart home network, a light bulb or a smart home app could be a resource.

A mesh topology used by COCO is refered to as a ‘Cluster’. A mesh topology is the fundamental principle that connects the infrastructure nodes in a COCONet which makes it completely customisable for a given application while considering trade-offs around costs, on-device computing and storage capabilities, bandwidth availability, reliability and latency requirements.

In contrast to a star or a tree network topology, a unified P2P IP Mesh Overlay Network that works over TCP/IP and UDP/IP self-organises, auto-heals and provides low-latency communication between the nodes.

A mesh topology enables developers to eliminate this single point of failure and spread the data storage across user devices. This helps reduce their risks of security breaches and data theft that can attract large fines via new data privacy legislatures like GDPR and CCPA.