Build your next private network with decentralized communication, using COCO for FREE

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

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

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.

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

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.

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.

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.