From 5b81ecce04b678fff4827531791713bfcfab2418 Mon Sep 17 00:00:00 2001 From: Dionysis Grigoropoulos Date: Thu, 26 Jan 2023 02:56:20 +0200 Subject: [PATCH] Update documentation to match reality --- LXMF/LXMessage.py | 12 ++++++------ README.md | 4 ++-- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/LXMF/LXMessage.py b/LXMF/LXMessage.py index 3c1188c..6ab264f 100644 --- a/LXMF/LXMessage.py +++ b/LXMF/LXMessage.py @@ -33,9 +33,9 @@ class LXMessage: DESTINATION_LENGTH = RNS.Identity.TRUNCATED_HASHLENGTH//8 SIGNATURE_LENGTH = RNS.Identity.SIGLENGTH//8 - # LXMF overhead is 99 bytes per message: - # 10 bytes for destination hash - # 10 bytes for source hash + # LXMF overhead is 111 bytes per message: + # 16 bytes for destination hash + # 16 bytes for source hash # 64 bytes for Ed25519 signature # 8 bytes for timestamp # 7 bytes for msgpack structure @@ -53,7 +53,7 @@ class LXMessage: # field of the packet, therefore we also add the length # of a destination hash to the calculation. With default # RNS and LXMF parameters, the largest single-packet - # LXMF message we can send is 294 bytes. If a message + # LXMF message we can send is 288 bytes. If a message # is larger than that, a Reticulum link will be used. ENCRYPTED_PACKET_MAX_CONTENT = ENCRYPTED_PACKET_MDU - LXMF_OVERHEAD + DESTINATION_LENGTH @@ -63,13 +63,13 @@ class LXMessage: LINK_PACKET_MDU = RNS.Link.MDU # Which means that we can deliver single-packet LXMF - # messages with content of up to 332 bytes over a link. + # messages with content of up to 320 bytes over a link. # If a message is larger than that, LXMF will sequence # and transfer it as a RNS resource over the link instead. LINK_PACKET_MAX_CONTENT = LINK_PACKET_MDU - LXMF_OVERHEAD # For plain packets without encryption, we can - # fit up to 388 bytes of content. + # fit up to 369 bytes of content. PLAIN_PACKET_MDU = RNS.Packet.PLAIN_MDU PLAIN_PACKET_MAX_CONTENT = PLAIN_PACKET_MDU - LXMF_OVERHEAD + DESTINATION_LENGTH diff --git a/README.md b/README.md index b7310d8..ca0ba1d 100644 --- a/README.md +++ b/README.md @@ -32,7 +32,7 @@ LXMF messages are stored in a simple and efficient format, that's easy to parse In some cases the actual message-id cannot be inferred, for example when a Propagation Node is storing an encrypted message for an offline user. In theses cases a _transient-id_ is used to identify the message while in storage or transit. 2. __Destination__, __Source__, __Signature__ and __Payload__ parts are mandatory, as is the __Timestamp__ part of the payload. - - The __Destination__ and __Source__ fields are 10-byte Reticulum destination hashes + - The __Destination__ and __Source__ fields are 16-byte Reticulum destination hashes - The __Signature__ field is a 64-byte Ed25519 signature of the __Destination__, __Source__, __Payload__ and __message-id__ - The __Payload__ part is a [msgpacked](https://msgpack.org) list containing four items: 1. The __Timestamp__ is a double-precision floating point number representing the number of seconds since the UNIX epoch. @@ -100,7 +100,7 @@ Assuming the default Reticulum configuration, the binary wire-format is as follo - 64 bytes Ed25519 signature - Remaining bytes of [msgpack](https://msgpack.org) payload data, in accordance with the structure defined above -The complete message overhead for LXMF is only 99 bytes, which in return gives you timestamped, digitally signed, infinitely extensible, end-to-end encrypted, zero-conf routed, minimal-infrastructure messaging that's easy to use and build applications with. +The complete message overhead for LXMF is only 111 bytes, which in return gives you timestamped, digitally signed, infinitely extensible, end-to-end encrypted, zero-conf routed, minimal-infrastructure messaging that's easy to use and build applications with. ## Example Paper Message