COCO solves the problem of Data Privacy for apps and devices being installed in the network owned by the user. This is achieved in two ways:

1. Decentralizing the connectivity, so data doesn’t have to reside on any servers (not even COCO servers)
2. Anonymizing the data traffic while sending it over to the application layer, so any application that aggregates data from its users doesn’t have any user identifiable information. 

Users must note that there is no privacy guarantee in networks owned by developers as data anonymization is not possible in such networks. 

COCO is a low level Peer-to-Peer middleware that enables decentralized communication over both TCP and UDP networks. For making it easy to develop on top of this P2P middleware, COCO provides 4 popular semantics that covers a plethora of use cases:

1. Pub-Sub: popular for IoT based devices and applications
2. Messaging: popular for any Application to Application communication, e.g. chat apps, dating apps
3. Streaming: popular for multimedia content delivery application.
4. Tunneling: popular for using existing protocols like HTTP, RTSP, MQTT, over a P2P network.

Blockchain is an application that relies on P2P communication over TCP. So a developer could use COCO to implement his own blockchain. He will have to implement the layer that implements an open and distributed ledger that can record transactions in a verifiable and permanent manner. To effectively implement the distributed ledger, he will need to create a protocol that validates new blocks using the messaging interface of COCO.

The COCO Network of Every Thing allows you to create multiple private P2P networks using the COCO App. The COCO App is the single point from which you can maintain your various COCO networks a.k.a COCONet.

Some of the network maintenance operations available are:

• Add/Remove Buzzed on COCO devices to any of your networks
• Add/Remove resources from Buzzed on COCO gateways that support dynamic resource inclusion/removal, e.g. add/include Zigbee resources on the COCO gateway that is included in the Developer Edition
• Add/Remove “admin” and “guest” users to your various networks
• Limit resource data access provided to guest users
• Authorize a device to update its firmware Over-the-Air (OTA updates).

COCO’s Developer Edition also referred to as the Smart Home Automation Kit is available in two forms. One that best suits the smart home needs and compliance of the USA and another that is best for European and Indian needs. Both versions include

1. IoT multi-radio gateway
2. Motion sensor
3. Contact sensor

Other components are specific to each version.

You can explore both versions and further technical specifications on the Developer Edition page.

Applications may communicate to devices or between each other through a network. By P2P App installations, this is referring to the applications that are using the network to communicate with each other.

A VPN or Virtual Private Network is a centralized remote connectivity technology that provides machines the ability to connect into a common network using secure and encrypted tunnels via a central server. This central server is typically maintained by a networking specialist. When your machine is connected to a VPN, you are able to access all the services and data hosted on other machines in the VPN.

In contrast, the COCONet is a decentralized remote connectivity technology that provides software services the ability to connect into a common network using secure and encrypted tunnels in a cloudless and decentralized topology. Managing your COCONet doesn’t require an IT specialist, instead, you can simply use your COCO App and perform various Network Management functions in the COCONet. Further, rather than a machine-level connection, you can have connectivity sandboxing at an application level, so if one App running on the machine is connected to the COCONet, the other apps running on this machine cannot access the COCONet. This ensures your data remains private and within the COCONet.

If you are behind a unique network topology with some firewalls that are blocking UDP packets OR a symmetric NAT, the direct connection using UDP hole punching will fail. Under such conditions, the COCONet will provision a fallback to a NAT traversal technique using a relay node. The security architecture in the COCONet is such that every node exchanges keys when they form the connection, and so even the relay node is unable to decrypt the data and the security of the network is maintained.

Such an architecture, empowers Device makers (OEMs) and App developers to provide connectivity to their customers that is designed-for-privacy. The COCO platform handles all the communication routing, network transitions, security, encryption, and graph management so that the nodes remain connected to the P2P network with very high availability.

As the ARPANET transitioned to the public internet, the client-server architecture became prominent. This was driven by various technological limitations of the early 1990s:  the high cost of computing made the thin-client fat-server architecture inevitable the high cost of memory and storage promoted centralization, i.e. clients were consumers of information, while servers were storage houses bandwidth is a very limited resource, and given the client-server architecture, ISPs provide asymmetric bandwidths that have better DL (downlink) speeds compared to UL (uplink) speeds.

Further as scaling the internet continued to increase the addressable range of the IPv4, NAT units were introduced into the internet architecture and have since taken prominence, they are included in every Access Point (AP) in every home. Introduction of NATs made it virtually impossible to form P2P networks between machines that were behind different NATs – the only way to achieve this is to take help from central control servers using protocols like STUN and TURN [read more about the Control Plane].

Fast forward from the early days of the internet and it’s clear that the technological landscape has changed tremendously over the last 25 years. In just the last decade of cell phones (comparing typical phones from 2009 to 2019):

• There is an over 30x compute performance improvement on client-side processing
• We officially have cell phones with storage of 1.5TB
• There is a 700% increase in average UL bandwidth

We believe we are at a point of inflection in technology that can disrupt the existing client-server architecture. While the client-server architecture works very well for Internet browsing, it severely limits use cases that require low latency and high bandwidth communication, e.g cases like Video, AR, VR, etc. Further for cases like IoT, the value of IoT is only derived when you have a network of things interconnected to each other in secure and private ad-hoc networks. For all these use cases, a P2P network architecture is the right technology option rather than using a client-server architecture.

The goal of the COCO platform is to simplify decentralized communication and help create a developer community that can solve various cases using P2P network topologies. The mechanism used by COCO to perform NAT traversal and P2P cloudless data transfer is via using a technique known as UDP hole punching.

The COCO platform provides developers both options of TCP and UDP semantics over the decentralized IP network.

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?

COCO’s security is based on the TLS protocol that is widely used over HTTP, but with the added simplification of removing cipher negotiation and instead of using a very strong cipher suite, using the Chacha-Poly1305 authenticated encryption algorithm, with Ed25519 signatures and ephemeral Diffie-Hellman for the key exchange.

COCO is built from the ground up with security in mind. All traffic is encrypted and authenticated end to end using a custom security protocol developed primarily for peer-to-peer networks. We developed this protocol and its implementation in collaboration with a 3rd party partner security consulting company. The protocol has also been scrutinized for penetration testing by independent 3rd parties.

Through its hybrid P2P architecture, COCO enables apps and devices to interconnect through IP networks, without any central server in the path. This network enabled by the COCO software stack is what we refer to as “COCONet”.

There are two types of COCONet:

• Developer COCONet
• User COCONet

One of the features of the COCO solution is to enable onboarding and removal of apps and devices automatically, without any burden to those using COCO. This is what we refer to as dynamic node management.

A private home network is one where you have your own dedicated communication link that connects all your smart home devices. The physical connection mechanism is through the internet, but it is entirely dedicated to you, only those whom you authorize will have access.

A gateway provides connectivity to the internet. Some devices may not have the capability to connect to the internet, but if they can communicate to the gateway, then the gateway can provide access to the internet to those devices. Such connectivity is what is meant by P2P device gateway installation.

P2P stands for Peer to Peer. This refers to a network architecture where apps or devices may communicate with each other directly, without going through a central server. This provides benefits such as data privacy, low-latency, offline access, and many more. etc. which are at the core of what the COCO stack brings to market.

The COCO software stack can be incorporated into apps and devices, in order to benefit from all the features of COCO. If an app or a device has the COCO software stack incorporated, we call it to be “Buzzed on COCO”.

COCO works with all devices, apps, and gateways that are ‘Buzzed on COCO’. You can get in touch with us for a Device SDK.

It should be possible to deploy COCO in a variety of networked scenarios, so chances are that your device should work with COCO (in COCO parlance, we call a device that has COCO functionality as being “Buzzed on COCO”). Having said that, if there is something that is preventing your device from being “Buzzed on COCO”, it could still work with COCO if it is connected to the internet through a gateway of some sort that is “Buzzed on COCO”.

Yes, this is one of the key differentiating features of the COCO solution. While the COCO solution works over TCP/IP, one need not have a functional public internet, for facilitating communication on-premises. Especially in India, where the reliability of the public internet connection may be spotty in residential environments, COCO can enable on-premise smart home communication even if there is an internet outage.

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.

Yes, COCO can reduce costs by minimizing the amount of data that is exchanged over the public internet. Given the P2P nature of the COCO network, data that is exchanged between entities on-premises stays within the intranet. Anyone on your private network can access data and communicate offline.

Peer-to-Peer (P2P) or decentralized communication enables applications or devices to communicate with each other directly, without requiring a central server to facilitate communication. Data transfer and communication are kept private, secure, in real-time with low latency, and can be accessed offline too.

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.

Oh yes! COCO can be used for many use cases pertaining to Hospitality, Real Estate, Healthcare, Manufacturing, Retail, Banking, and Finance. Choose your preferred type of communication and you will find some quick ideas to use COCO for your unique need.

•  App-to-App
•  App-to-Device ​
• Device-to-Device

A gateway is a device that allows devices that are not connected to the network directly to have such connectivity. For example, Zigbee or Zwave devices such as light bulbs may not have the sophistication to have direct network connectivity, but they can be connected to a Zigbee or Zwave supported gateway, which then provides network connectivity. The term “gateway” simply refers to an entity that is connected to a network, that enables other entities to be connected to that network through it.

The COCO Network of Every Thing provides a COCO Device SDK that can be used to create a ‘Buzzed on COCO’ device. Such devices can be provisioned and added into a network by the “owner” of the network. On doing this, the device gets networked with all other devices and apps in the network of the “owner”. These devices can be placed geographically separated and even across countries, but to all the users connected to the network, these devices and their resources appear as a single network. Each device would be considered as a device node on the network (COCONet).

In the context of the COCO Network of Every Thing, any COCO network can have applications and a network of devices communicating over that network. The P2P App nodes are created using the COCO Client App SDK. When connected to a network by a user, these application access resources that are hosted by the network of devices that the user has access to.

When a developer is creating an isolated network for the decentralized communication of his own app, a P2P App Node is created and destroyed by making API calls from the developer’s application.

A Data Plane provisions for all data transfers within the COCO P2P network occur using a cloudless data transfer mechanism. So, in essence, all data transfers go directly between the two nodes under most network topologies. The Data Plane of the COCO P2P network is used for various data transfer activities like:

• Message routing
• Message encryption
• Message signing
• Message authentication
• Providing direct channels of communication between all nodes
• Providing a pub-sub framework of communication between all nodes
• TCP semantics over a UDP connection

Using well-known techniques, the data plane connections can also be used when the two nodes are behind NAT devices. This is achieved by taking help from a third node with a public IP address aka “network management node” that is part of the control plane to perform UDP hole punching [https://en.wikipedia.org/wiki/UDP_hole_punching]. Even though 85% of the traffic in Control Plane (CP) is likely to traverse using UDP hole punching, CP provides TCP semantics to applications that require QoS guarantees provided by TCP. 

The Control Plane of the COCO P2P network is used for various network management activities like:

• Onboarding of new nodes into a network
• Removal of nodes from a network
• Discovery of nodes for performing UDP Hole Punching during data plane transfer
• Packet Relay as a fallback for NAT/Firewall Traversal when UDP Hole Punching fails

Under typical usage for Home Automation we expect users to be well within the free limit of 100MB/month on the Control Plane. You can use the COCO App to track your control plane bandwidth usage. Download COCO App.

When you create an App using the COCO Client SDK, it creates a Node for each network it participates in. So using an App, if you connect to 3 distinct networks, you have 3 nodes created. Creating separate nodes provides connectivity sandbox to ensure the best practices of security during App development.

When you create a Device using the COCO Device SDK, it creates a Node for the device. Unlike an App, a Device can only be part of a single network, and not part of multiple networks simultaneously.

Here is an example of how the pricing would work:

• You purchase the Developer Edition
• You create your first and only P2P network, and call it the “Home Network”
• You connect your COCO App to your “Home Network” and add the Buzzed on COCO Gateway into it.
• This creates two P2P nodes: one on the COCO App and the other on the COCO Gateway.
• You invite your partner into your “Home Network”
• They join your network using the COCO App and that creates a 3rd node in your network.

In the Free version of subscription you have 1 network and 3 nodes (1 gateway node in the COCO Gateway and, 2 app nodes in the COCO Apps). You could try different combinations to suit your needs.

Yes, using the COCO communications API, developers can now leverage App to App communication and add decentralized communication into their own apps. These apps do NOT need to use the COCO Login system and do NOT need to be released on the COCO Grove.

The COCO Grove is only used for those apps that can be used by the COCO Network of Every Thing system. The COCO Network of Every Thing system provides the ability for developers to create Apps and Devices that network together to provide the most value to the end-users. Y​ou can learn more here.​

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.

The P2P network is owned by a single user in the COCO system. The “owner” has the ability to perform all network management operations on the COCO Network like add/remove devices, add/remove resources, add/remove users, etc.

The “admin” users of the network can perform all the operations of the “owner” except that of add/remove of devices, add/remove resources and OTA updates. Admin users can invite other users into the COCO Network.

The “guest” users of the network can only connect into the network and use the resources that they have been granted access to. For example, if you have a maid service that is scheduled twice a week, you can grant access to the Front Door Lock resource specifically for that “guest” user to your network. Such users cannot see or control or change any resources other than the ones that they are granted access to.

Who can be added as guest users?

You can add anyone as a guest user.

Using a P2P (peer-to-peer) network enables cloudless data transfer. The benefits of which are:

Low latency for real-time applications

​Robust communication infrastructure, e.g. working in LAN-only mode even when the internet is disconnected

​Designed for privacy communication

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.

You can s​ign up​ for FREE to get started with your initial learning lessons. Begin your learning with the Getting Started guides. Sign up as an ‘Early Adopter’ which is free forever. With this free subscription you get all this:

• Join COCO’s developer community and learn from other like-minded developers in there.
• Access the forum that encourages discussion with other developer peers.
• Download the Client SDK to create applications and the Device SDK to develop software for devices.
• Create up to 3 customized private networks.
• Invite users, share data and communicate seamlessly within the networks that you create and own.

Yes, COCO can reduce costs by minimizing the amount of data that is exchanged over the public internet. Given the P2P nature of the COCO network, data that is exchanged between entities on premises stays within the intranet. Anyone on your private network can access data and communicate offline.

P2P communication enables applications or devices to communicate with each other directly, without requiring a central server to facilitate communication. Data transfer and communication is kept private, secure, and in real-time with low latency. It and can be accessed offline too! No kidding. Check out this video.

Your free account does provide connectivity to a certain extent. If you feel that you would benefit from unlocking additional features, we invite you to upgrade your license to either Hobbyist, Entrepreneur, or Expert plan. Should you wish to Whitelabel COCO, fill in your details h​ere​. Details about licensing may be found ​here.​

As the name suggests, P2P enables communication directly between peers. Peer entities may be apps or devices created using either the COCO Client SDK or the COCO Device SDK respectively. We refer to such apps and devices as being “Buzzed on COCO”. For example, an app running on a smartphone communicating with a smart doorbell in your home. Or a chat app that is completely designed for privacy with no central server storing or inspecting the messages.

If you are a deep diver, then start exploring the self-help guides here .

Unlike the client-server architecture that defines distinct roles for clients and servers, in P2P networks there is no distinction, and all network participants are called nodes. A P2P node is both a client and a server and maintains a connection with at least 1 other P2P node to participate in the P2P network.

That’s great news. We have opened the bookings for the COCO’s Developer Edition. Please visit COCO Grove for more information or book your Developer Edition.

It is super simple. Follow these steps:

• Sign Up into the COCO’s Developer Platform
• Choose the type of communication you want to work with App-to-App / App-to-Device/ Device-to-Device
• Download the relevant SDK: the Client SDK to develop Apps and the Device SDK to write your software.
• Create and customize your private network.
• Publish your creation on COCO Grove.

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.