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. 

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).

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.