| Internet-Draft | CNP | March 2026 |
| Ribeiro Silva | Expires 23 September 2026 | [Page] |
CNP is a decentralized general purpose network protocol, meant to allow the seamless production of decentralized yet internet dependent applications.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 2 September 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
At this point in time, web applications (critically, ones regarding communication) are highly centralized and often rely on a single entity. As a means to make decentralized applications easier to implement, this protocol defines a standard for such.¶
Over the text, the words "crystal", "node", "packet", and "blob" will be used. In the said order, to describe an inter-connected network, a member of the crystal, a blob with the CNP format, a contiguous sequence of bytes. Also, this document follows the [RFC2119] definitions.¶
A packet is a blob with a fixed-length of one kibibyte, the starting byte signaling the method, 64 bytes being a key, 12 bytes for nonce, and the remaining 947 bytes being the cipher text. The cipher text being preferably AES-GCM-SIV derived, the nonce stored at its field.¶
This field is used to identify a packet, which has to be derived from a hash, which is preferably blake2b. There is no verification regarding the hash algorithm used, specifically because since the key is for identification purposes, if the implementation uses argon2id or does not use a hashing algorithm, what would happen is a higher likelihood of collisions, thus poor behavior.¶
Cipher text is a preferably encrypted blob, and the nonce field SHOULD be used to store a nonce.¶
The use of an encryption method is highly recommended to maintain security, and it is recommended to use AES-GCM-SIV since it has built-in authentication and nonce mis-use protection.¶
Even so, the protocol itself is not dependent on the implementation that derived the packet, as the server is agnostic about the contents of the cipher text and nonce. As for the key, it is used as a blob.¶
A node SHALL keep IPv6s for running the protocol, MAY have a method to keep these persistent, the data-structure SHOULD have a limit of items, the node MAY store IPv6s it contacts in any shape or form (preferably yes, for the crystal to grow), the node MAY drop IPv6s it identifies as permanently shut down, and the node SHOULD be listening to port 3017 by default and accepting connections.¶
When a node registers a packet by itself, it sends the packet to all the nodes it has (IPv6s) with the method "insert". Those which MAY retransmit their packets to any other node.¶
Upon receipt of an "insert", the packet SHOULD be stored in the node in some manner, but MAY refuse if the node assumes that doing so would be problematic for it.¶
When a node encounters itself on a position of needing a packet, it sends a "get" to all nodes it holds. This request MAY be retransmitted to their own nodes.¶
Upon receipt of a "get", the node SHALL seek if it has a packet with the key of the received packet. If it does, the node SHALL "insert" it on the sender.¶
If a node receives a packet, and it already has one with the same key, the new one is ignored.¶
All implementations that by any shape or form retransmit a packet SHOULD limit retransmission rate to prevent flood behavior.¶
The retransmission of a "get" SHOULD be sequential.¶
Given that "get" and "insert" neither require a response to work. If a "get", after sending this request to all of its nodes, and the crystal does not have the requested key, instead of responding "not found", the node simply does not receive a packet with this key. Same for insert, it simply can be inserted, no guarantee.¶
Used to guarantee the delivery of packets. For sending a packet, a node SHALL make a connection with another, send the packet, and either one MAY close the connection right after.¶
All packets SHALL be deleted after an hour, but MAY be deleted before.¶
The protocol by itself is insecure, it does not guarantee any sort of security. Even so, it is recommended (and explicitly said so) that encryption is used on the data blob (mentioned as cipher text), and for the key to be derived from a cryptographic hash. These do increase the safety significantly.¶
Another problem could be DoS related, but these can be mitigated with proper firewalls, and out-of-spec solutions.¶