Coder Social home page Coder Social logo

markqvist / reticulum Goto Github PK

View Code? Open in Web Editor NEW
1.6K 57.0 106.0 50.89 MB

The cryptography-based networking stack for building unstoppable networks with LoRa, Packet Radio, WiFi and everything in between.

Home Page: https://reticulum.network

License: MIT License

Python 99.89% Makefile 0.11%
networking-stack packet-radio lora mesh-networks reticulum rns mesh network

reticulum's Introduction

Reticulum Network Stack β

Reticulum is the cryptography-based networking stack for building local and wide-area networks with readily available hardware. It can operate even with very high latency and extremely low bandwidth. Reticulum allows you to build wide-area networks with off-the-shelf tools, and offers end-to-end encryption and connectivity, initiator anonymity, autoconfiguring cryptographically backed multi-hop transport, efficient addressing, unforgeable delivery acknowledgements and more.

The vision of Reticulum is to allow anyone to be their own network operator, and to make it cheap and easy to cover vast areas with a myriad of independent, inter-connectable and autonomous networks. Reticulum is not one network. It is a tool for building thousands of networks. Networks without kill-switches, surveillance, censorship and control. Networks that can freely interoperate, associate and disassociate with each other, and require no central oversight. Networks for human beings. Networks for the people.

Reticulum is a complete networking stack, and does not rely on IP or higher layers, but it is possible to use IP as the underlying carrier for Reticulum. It is therefore trivial to tunnel Reticulum over the Internet or private IP networks.

Having no dependencies on traditional networking stacks frees up overhead that has been used to implement a networking stack built directly on cryptographic principles, allowing resilience and stable functionality, even in open and trustless networks.

No kernel modules or drivers are required. Reticulum runs completely in userland, and can run on practically any system that runs Python 3.

Read The Manual

The full documentation for Reticulum is available at markqvist.github.io/Reticulum/manual/.

You can also download the Reticulum manual as a PDF or as an e-book in EPUB format.

For more info, see reticulum.network

Notable Features

  • Coordination-less globally unique addressing and identification
  • Fully self-configuring multi-hop routing
  • Initiator anonymity, communicate without revealing your identity
  • Asymmetric X25519 encryption and Ed25519 signatures as a basis for all communication
  • Forward Secrecy with ephemeral Elliptic Curve Diffie-Hellman keys on Curve25519
  • Reticulum uses the following format for encrypted tokens:
    • Keys are ephemeral and derived from an ECDH key exchange on Curve25519
    • AES-128 in CBC mode with PKCS7 padding
    • HMAC using SHA256 for authentication
    • IVs are generated through os.urandom()
  • Unforgeable packet delivery confirmations
  • A variety of supported interface types
  • An intuitive and easy-to-use API
  • Reliable and efficient transfer of arbitrary amounts of data
    • Reticulum can handle a few bytes of data or files of many gigabytes
    • Sequencing, transfer coordination and checksumming are automatic
    • The API is very easy to use, and provides transfer progress
  • Lightweight, flexible and expandable Request/Response mechanism
  • Efficient link establishment
    • Total cost of setting up an encrypted and verified link is only 3 packets, totalling 297 bytes
    • Low cost of keeping links open at only 0.44 bits per second
  • Reliable sequential delivery with Channel and Buffer mechanisms

Roadmap

While Reticulum is already a fully featured and functional networking stack, many improvements and additions are actively being worked on, and planned for the future.

To learn more about the direction and future of Reticulum, please see the Development Roadmap.

Examples of Reticulum Applications

If you want to quickly get an idea of what Reticulum can do, take a look at the following resources.

  • You can use the rnsh program to establish remote shell sessions over Reticulum.
  • LXMF is a distributed, delay and disruption tolerant message transfer protocol built on Reticulum
  • For an off-grid, encrypted and resilient mesh communications platform, see Nomad Network
  • The Android, Linux, macOS and Windows app Sideband has a graphical interface and focuses on ease of use.
  • MeshChat is a user-friendly LXMF client, that also supports voice calls.

Where can Reticulum be used?

Over practically any medium that can support at least a half-duplex channel with greater throughput than 5 bits per second, and an MTU of 500 bytes. Data radios, modems, LoRa radios, serial lines, AX.25 TNCs, amateur radio digital modes, WiFi and Ethernet devices, free-space optical links, and similar systems are all examples of the types of physical devices Reticulum can use.

An open-source LoRa-based interface called RNode has been designed specifically for use with Reticulum. It is possible to build yourself, or it can be purchased as a complete transceiver that just needs a USB connection to the host.

Reticulum can also be encapsulated over existing IP networks, so there's nothing stopping you from using it over wired Ethernet, your local WiFi network or the Internet, where it'll work just as well. In fact, one of the strengths of Reticulum is how easily it allows you to connect different mediums into a self-configuring, resilient and encrypted mesh, using any available mixture of available infrastructure.

As an example, it's possible to set up a Raspberry Pi connected to both a LoRa radio, a packet radio TNC and a WiFi network. Once the interfaces are configured, Reticulum will take care of the rest, and any device on the WiFi network can communicate with nodes on the LoRa and packet radio sides of the network, and vice versa.

How do I get started?

The best way to get started with the Reticulum Network Stack depends on what you want to do. For full details and examples, have a look at the Getting Started Fast section of the Reticulum Manual.

To simply install Reticulum and related utilities on your system, the easiest way is via pip. You can then start any program that uses Reticulum, or start Reticulum as a system service with the rnsd utility.

pip install rns

If you are using an operating system that blocks normal user package installation via pip, you can return pip to normal behaviour by editing the ~/.config/pip/pip.conf file, and adding the following directive in the [global] section:

[global]
break-system-packages = true

Alternatively, you can use the pipx tool to install Reticulum in an isolated environment:

pipx install rns

When first started, Reticulum will create a default configuration file, providing basic connectivity to other Reticulum peers that might be locally reachable. The default config file contains a few examples, and references for creating a more complex configuration.

If you have an old version of pip on your system, you may need to upgrade it first with pip install pip --upgrade. If you no not already have pip installed, you can install it using the package manager of your system with sudo apt install python3-pip or similar.

For more detailed examples on how to expand communication over many mediums such as packet radio or LoRa, serial ports, or over fast IP links and the Internet using the UDP and TCP interfaces, take a look at the Supported Interfaces section of the Reticulum Manual.

Included Utilities

Reticulum includes a range of useful utilities for managing your networks, viewing status and information, and other tasks. You can read more about these programs in the Included Utility Programs section of the Reticulum Manual.

  • The system daemon rnsd for running Reticulum as an always-available service
  • An interface status utility called rnstatus, that displays information about interfaces
  • The path lookup and management tool rnpath letting you view and modify path tables
  • A diagnostics tool called rnprobe for checking connectivity to destinations
  • A simple file transfer program called rncp making it easy to transfer files between systems
  • The identity management and encryption utility rnid let's you manage Identities and encrypt/decrypt files
  • The remote command execution program rnx let's you run commands and programs and retrieve output from remote systems

All tools, including rnx and rncp, work reliably and well even over very low-bandwidth links like LoRa or Packet Radio. For full-featured remote shells over Reticulum, also have a look at the rnsh program.

Supported interface types and devices

Reticulum implements a range of generalised interface types that covers most of the communications hardware that Reticulum can run over. If your hardware is not supported, it's relatively simple to implement an interface class. I will gratefully accept pull requests for custom interfaces if they are generally useful.

Currently, the following interfaces are supported:

  • Any Ethernet device
  • LoRa using RNode
  • Packet Radio TNCs (with or without AX.25)
  • KISS-compatible hardware and software modems
  • Any device with a serial port
  • TCP over IP networks
  • UDP over IP networks
  • External programs via stdio or pipes
  • Custom hardware via stdio or pipes

Performance

Reticulum targets a very wide usable performance envelope, but prioritises functionality and performance on low-bandwidth mediums. The goal is to provide a dynamic performance envelope from 250 bits per second, to 1 gigabit per second on normal hardware.

Currently, the usable performance envelope is approximately 150 bits per second to 40 megabits per second, with physical mediums faster than that not being saturated. Performance beyond the current level is intended for future upgrades, but not highly prioritised at this point in time.

Current Status

Reticulum should currently be considered beta software. All core protocol features are implemented and functioning, but additions will probably occur as real-world use is explored. There will be bugs. The API and wire-format can be considered relatively stable at the moment, but could change if warranted.

Dependencies

The installation of the default rns package requires the dependencies listed below. Almost all systems and distributions have readily available packages for these dependencies, and when the rns package is installed with pip, they will be downloaded and installed as well.

On more unusual systems, and in some rare cases, it might not be possible to install or even compile one or more of the above modules. In such situations, you can use the rnspure package instead, which require no external dependencies for installation. Please note that the contents of the rns and rnspure packages are identical. The only difference is that the rnspure package lists no dependencies required for installation.

No matter how Reticulum is installed and started, it will load external dependencies only if they are needed and available. If for example you want to use Reticulum on a system that cannot support pyserial, it is perfectly possible to do so using the rnspure package, but Reticulum will not be able to use serial-based interfaces. All other available modules will still be loaded when needed.

Please Note! If you use the rnspure package to run Reticulum on systems that do not support PyCA/cryptography, it is important that you read and understand the Cryptographic Primitives section of this document.

Public Testnet

If you just want to get started experimenting without building any physical networks, you are welcome to join the RNS Development Testnet.

The testnet is just that, an informal network for testing and experimenting. It will be up most of the time, and anyone can join, but it also means that there's no guarantees for service availability.

It probably goes without saying, but don't use the testnet entry-points as hardcoded or default interfaces in any applications you ship to users. When shipping applications, the best practice is to provide your own default connectivity solutions, if needed and applicable, or in most cases, simply leave it up to the user which networks to connect to, and how.

The testnet runs the very latest version of Reticulum (often even a short while before it is publicly released). Sometimes experimental versions of Reticulum might be deployed to nodes on the testnet, which means strange behaviour might occur. If none of that scares you, you can join the testnet via either TCP or I2P. Just add one of the following interfaces to your Reticulum configuration file:

# TCP/IP interface to the RNS Amsterdam Hub
  [[RNS Testnet Amsterdam]]
    type = TCPClientInterface
    enabled = yes
    target_host = amsterdam.connect.reticulum.network
    target_port = 4965

# TCP/IP interface to the BetweenTheBorders Hub (community-provided)
  [[RNS Testnet BetweenTheBorders]]
    type = TCPClientInterface
    enabled = yes
    target_host = betweentheborders.com
    target_port = 4242

# Interface to Testnet I2P Hub
  [[RNS Testnet I2P Hub]]
    type = I2PInterface
    enabled = yes
    peers = g3br23bvx3lq5uddcsjii74xgmn6y5q325ovrkq2zw2wbzbqgbuq.b32.i2p

The testnet also contains a number of Nomad Network nodes, and LXMF propagation nodes.

Support Reticulum

You can help support the continued development of open, free and private communications systems by donating via one of the following channels:

  • Monero:
    84FpY1QbxHcgdseePYNmhTHcrgMX4nFfBYtz2GKYToqHVVhJp8Eaw1Z1EedRnKD19b3B8NiLCGVxzKV17UMmmeEsCrPyA5w
    
  • Ethereum
    0xFDabC71AC4c0C78C95aDDDe3B4FA19d6273c5E73
    
  • Bitcoin
    35G9uWVzrpJJibzUwpNUQGQNFzLirhrYAH
    
  • Ko-Fi: https://ko-fi.com/markqvist

Are certain features in the development roadmap are important to you or your organisation? Make them a reality quickly by sponsoring their implementation.

Cryptographic Primitives

Reticulum uses a simple suite of efficient, strong and modern cryptographic primitives, with widely available implementations that can be used both on general-purpose CPUs and on microcontrollers. The necessary primitives are:

  • Ed25519 for signatures
  • X22519 for ECDH key exchanges
  • HKDF for key derivation
  • Modified Fernet for encrypted tokens
    • AES-128 in CBC mode
    • HMAC for message authentication
    • No Fernet version and timestamp fields
  • SHA-256
  • SHA-512

In the default installation configuration, the X25519, Ed25519 and AES-128-CBC primitives are provided by OpenSSL (via the PyCA/cryptography package). The hashing functions SHA-256 and SHA-512 are provided by the standard Python hashlib. The HKDF, HMAC, Fernet primitives, and the PKCS7 padding function are always provided by the following internal implementations:

Reticulum also includes a complete implementation of all necessary primitives in pure Python. If OpenSSL & PyCA are not available on the system when Reticulum is started, Reticulum will instead use the internal pure-python primitives. A trivial consequence of this is performance, with the OpenSSL backend being much faster. The most important consequence however, is the potential loss of security by using primitives that has not seen the same amount of scrutiny, testing and review as those from OpenSSL.

If you want to use the internal pure-python primitives, it is highly advisable that you have a good understanding of the risks that this pose, and make an informed decision on whether those risks are acceptable to you.

Reticulum is relatively young software, and should be considered as such. While it has been built with cryptography best-practices very foremost in mind, it has not been externally security audited, and there could very well be privacy or security breaking bugs. If you want to help out, or help sponsor an audit, please do get in touch.

Acknowledgements & Credits

Reticulum can only exist because of the mountain of Open Source work it was built on top of, the contributions of everyone involved, and everyone that has supported the project through the years. To everyone who has helped, thank you so much.

A number of other modules and projects are either part of, or used by Reticulum. Sincere thanks to the authors and contributors of the following projects:

reticulum's People

Contributors

4c3e avatar acehoss avatar attermann avatar blackjack75 avatar cobrapa avatar connervieira avatar erethon avatar faragher avatar gdt avatar huyndao avatar jacobeva avatar jooray avatar joshuafuller avatar jschulthess avatar liamcottle avatar markqvist avatar nothingbutlucas avatar npetrangelo avatar sebastianobi avatar thatv avatar thiaguetz avatar violeteternity avatar xtoddx avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

reticulum's Issues

Improve I2P interface SAM exception handling

Some failure conditions signaled over the I2P SAM API are currently not caught by the I2P interfaces. One known example of this is when the I2P network does not yet know the public key of a newly created destination, and raises an exception as a result.

This needs to be implemented.

Problem with receipt class

Hi Mark,

today I saw the following error in the log:

nexus-test_node01    | Exception occurred during processing of request from ('172.25.0.1', 50998)
nexus-test_node01    | Traceback (most recent call last):
nexus-test_node01    |   File "/usr/local/lib/python3.9/socketserver.py", line 683, in process_request_thread
nexus-test_node01    |     self.finish_request(request, client_address)
nexus-test_node01    |   File "/usr/local/lib/python3.9/socketserver.py", line 360, in finish_request
nexus-test_node01    |     self.RequestHandlerClass(request, client_address, self)
nexus-test_node01    |   File "/usr/local/lib/python3.9/socketserver.py", line 747, in __init__
nexus-test_node01    |     self.handle()
nexus-test_node01    |   File "/usr/local/lib/python3.9/http/server.py", line 425, in handle
nexus-test_node01    |     self.handle_one_request()
nexus-test_node01    |   File "/usr/local/lib/python3.9/http/server.py", line 413, in handle_one_request
nexus-test_node01    |     method()
nexus-test_node01    |   File "/bsb/nexus_server/nexus_server.py", line 1322, in do_POST
nexus-test_node01    |     command_result = process_command(post)
nexus-test_node01    |   File "/bsb/nexus_server/nexus_server.py", line 1386, in process_command
nexus-test_node01    |     success = cmd_add_message(message)
nexus-test_node01    |   File "/bsb/nexus_server/nexus_server.py", line 1495, in cmd_add_message
nexus-test_node01    |     distribute_message(message)
nexus-test_node01    |   File "/bsb/nexus_server/nexus_server.py", line 1800, in distribute_message
nexus-test_node01    |     NEXUS_LXM_SOCKET.send_message(
nexus-test_node01    |   File "/bsb/nexus_server/nexus_server.py", line 745, in send_message
nexus-test_node01    |     self.lxm_router.handle_outbound(lxm_message)
nexus-test_node01    |   File "/usr/local/lib/python3.9/site-packages/LXMF/LXMF.py", line 1110, in handle_outbound
nexus-test_node01    |     self.process_outbound()
nexus-test_node01    |   File "/usr/local/lib/python3.9/site-packages/LXMF/LXMF.py", line 1634, in process_outbound
nexus-test_node01    |     lxmessage.send()
nexus-test_node01    |   File "/usr/local/lib/python3.9/site-packages/LXMF/LXMF.py", line 285, in send
nexus-test_node01    |     receipt.set_delivery_callback(self.__mark_delivered)
nexus-test_node01    | AttributeError: 'bool' object has no attribute 'set_delivery_callback'
nexus-test_node01    | -------------------------------

at the code the error was at:

    def send(self):
        self.determine_transport_encryption()

        if self.method == LXMessage.OPPORTUNISTIC:
            self.__as_packet().send().set_delivery_callback(self.__mark_delivered)
            self.state = LXMessage.SENT
        
        elif self.method == LXMessage.DIRECT:
            self.state = LXMessage.SENDING

            if self.representation == LXMessage.PACKET:
                receipt = self.__as_packet().send()
->            receipt.set_delivery_callback(self.__mark_delivered)
                receipt.set_timeout_callback(self.__link_packet_timed_out)

            elif self.representation == LXMessage.RESOURCE:
                self.resource_representation = self.__as_resource()

        elif self.method == LXMessage.PROPAGATED:
            self.state = LXMessage.SENDING

            if self.representation == LXMessage.PACKET:
                receipt = self.__as_packet().send()
                if receipt:
                    receipt.set_delivery_callback(self.__mark_propagated)
                    receipt.set_timeout_callback(self.__link_packet_timed_out)
                else:
                    self.__delivery_destination.teardown()

            elif self.representation == LXMessage.RESOURCE:
                self.resource_representation = self.__as_resource()

I have no clue why that hapens.
I does not happen all the time, so probably is a kind of corner case when something goes wrong with the send() function above.
The code runs not in my IDE but within a docker container.
And I see that one once in a while ...

Any idea whats happenenig here?
How can the member beeing called not be there?

The callback is set like this:

        # Create lxmessage and handle outbound to the target Nexus server with the lxm router
        lxm_message = LXMF.LXMessage(
            to_destination,
            destination_hash=destination_hash,
            source=self.socket_destination,
            content=content,
            title=title,
            fields=fields,
            desired_method=LXMF.LXMessage.DIRECT
        )

        # Register message handler
        # This is the good case - message is processed successfully
        lxm_message.register_delivery_callback(NexusLXMSocket.lxmf_delivery_callback)
        # Log delivery failure
        lxm_message.register_failed_callback(NexusLXMSocket.lxmf_delivery_callback)

And of course works for all other messages sent.
So I think it might be a problem somewhere around the receipt handling of LXMF in case something goes wrong or is run in parallel...

Any help would be appreciated.
Cheers
Stephan

Porting to C

A question more than an issue.
Can Reticulum be ported to C? It would benefit all those uC like the ESP32 or the NRF52840 that power many low power LoRa transceivers. Micropython is quite expensive CPU-wise and increases power consumption.
What are the main problems to be faced when porting it to C? I can do it myself but I'll need support throughout the process.

Data radio legality

In the manual, it lists amateur radio digital modes as a medium that reticulum can use. However, I'm fairly sure most countries (definitely the US and UK) ban the use of encryption on amateur bands. Is there some edge case in the law I'm not aware of? Did it mean to use amateur equipment in ISM bands (I don't know if that's legal either)? Is there something else I'm missing?

Communication Issues with Multiple Interfaces of Same Type

In a three node setup, with the first node being in subnet A, the second in subnet A & B, and the third being in subnet B, I cannot figure out a way to configure the second node that allows proper bidirectional communication with it having two UDP interfaces. Previously I found that having listen_ip as 0.0.0.0 for the default UDP interface and the forward_ip of whatever the broadcast address for the respective subnet of the broadcast interface would properly work and broadcast to the right network (on a multiple interface machine). After testing it specifically, specifying listen_ip to be the IP that the node was assigned on the subnet that should be transmitted on just breaks it entirely and no communication can be had. So, having listen_ip = 0.0.0.0 seemed to be the only way for it to work.

However, here comes the problem I am having specifically... if you specify listen_ip as 0.0.0.0, you cannot have another UDP interface whatsoever, because it will give the following error message: "[2021-07-26 06:54:25] [Error] The contained exception was: [Errno 98] Address already in use". This happens if both the listen_ip is 0.0.0.0 or the assigned IP address on the node for the second subnet you wish to transmit on.

understanding question: decentralization or P2P

Hello and many thanks for your inspiring project and your impressive work,

I'm sorry to write such message a bit impatiently, which maybe wrong/lazy due to me not learning/playing enough with the project, but there a quite a few such networking/communication stacks that have pop up recently, so digging deeper into all require a bit too much of time for me...

I have just discovered the project through a recommandation, which stress that Reticulum is decentralized rather than distributed/P2P.
Reading though the manual section on nodes, it seems to be indeed the case, isn't it?
If this is correct, I would agree with the following point that if a peer is not required to serve, such networks tend to centralize (control) due to self-interested users being the (vast) majority, as history has empirically shown. On the other hand I understand the argument to leave maximum control to an operator on what data/computation goes on on its machine.

My consequential question would be:
what do you think about a optional mechanism that allows to check if a peering node is a transport one and to only build network with (through after-check, non-acceptance to communicate further with nodes which are not transport ones)?
It would keep the existing feature (allowing to choose to be only an instance node for people who want to) and networks you can build upon,
but add the optional feature to build P2P networks through coersion for people who believe in problems aformentionned in the previous paragraph.

Unable to get link from response generator callback

I was working on a request/response application that maintains a session state for the lifetime of a Link. When the requester identifies on the link, a session is started and this session state lasts until the link is torn down.

Digging through the source code, I didn't find any way to get back to the link from the response generator callback.

response_generator(path, data, request_id, remote_identity, requested_at)

It would be possible to find the correct link by remote identity, but this limits the application to identified links only and only one link per remote identity (which wouldn't work for this application). I realize it would be a breaking API change, but adding the link_id to the parameter list would resolve the problem.

As a workaround, I used a big hack and wrapped the RNS.Link.handle_request function:

_link_handle_request_orig = RNS.Link.handle_request

def link_handle_request(self, request_id, unpacked_request):
    global sessions
    for session in sessions:
        if session.link.link_id == self.link_id:
            RNS.log("Associating packet to session", RNS.LOG_DEBUG)
            session.next_request_id = request_id
    _link_handle_request_orig(self, request_id, unpacked_request)

RNS.Link.handle_request = link_handle_request

Adding support to other LoRa boards/device hats

I saw that there was support for the author's RNode LoRa device, but would the same Interface work with other LoRa boards?
Like this one, for example: https://www.amazon.com/Frequency-Spectrum-Modulation-Raspberry-Interface/dp/B07VS47RQZ

Would I need to change any of the code from the RNode Interface to use this device?
I saw that the RNode uses a Semtech SX1276 Chip, but the example board uses a SX1262 Chip. Would that change the syntax needed?

Thanks for any replies.

clarify LXMF message format vs LXMF routing?

am i understanding correctly that LXMF is a general purpose message format?

in documentation, it seems that the message format is a bit conflated with the routing functions provided by lxmd.

this makes it a bit tricky to build a mental block diagram for the reticulum network since it seems to create a dependency cycle.

disambiguating the two uses seems to produce something like:

  • LXMF (message format) can be used standalone and is independent of Reticulum/RNS.
  • LXMF (router) depends on RNS / Reticulum for mesh networking and LXMF (message format)
  • NomadNet / Sideband depend on LXMF (router), and (transitively and directly) Reticulum and LXMF

am i interpreting the moving bits correctly?

#bug#: Is this a always true if clause

In RNS.Identity.py file, fuction:

 @staticmethod
def validateAnnounce(packet):

...
if len(packet.data) > Identity.DERKEYSIZE//8+20+Identity.KEYSIZE//8:
...

Since the last index of packet.data which has been stored into variable 'signature' is:

[Identity.DERKEYSIZE//8+20+Identity.KEYSIZE//8],

and array index in python starts at 0.
Is that the if clause shown above will always be true?
But fortunately, this seems no harm in the next steps , even if there is no app_data part in packet.data at all. The codes in if clause assign nothing to variable 'signature' since

[Identity.DERKEYSIZE//8+20+Identity.KEYSIZE//8:] equals to NULL.

app_data = packet.data[Identity.DERKEYSIZE//8+20+Identity.KEYSIZE//8:]

But anyway I guess the expression of if is wrong, the right one should be:
if len(packet.data) > Identity.DERKEYSIZE//8+20+Identity.KEYSIZE//8 + 1:

Am I right?

Missing RNode at startup causes RNS/NN termination

If a defined RNode is not present at RNS/NN startup, the RNS/NN will terminate with an error:
[Error] The contained exception was: [Errno 2] could not open port /dev/ttyUSB0: [Errno 2] No such file or directory: '/dev/ttyUSB0'
It would be advantageous if the USB port could be treated as a plug device, such that RNodes could be plug-n-play at startup, similar to their behavior after startup with "panic_on_interface_error = No".

I can foresee situations where one or more RNodes could be added to a running RNS node on an AD-HOC manner, i.e., to expand the transport node's capability to support another frequency. Essentially a "bring-your-own-radio" scenario. This would be especially useful if RNS could be configured to use the pre-configured RNode radio characteristics. I thought this was the case, but when I comment out the radio configuration in the 'config'. I get these terminal errors:
[2022-07-27 11:17:30] [Error] The interface "RNode LoRa Interface" could not be created. Check your configuration file for errors!
[2022-07-27 11:17:30] [Error] The contained exception was: '<' not supported between instances of 'NoneType' and 'int'

Thanks for your time and efforts.

Tor as a transport

I probably can't implement this immediately, as I am still getting familiar with the software, but I noticed it already supports I2P tunnels as a transport layer.

It probably wouldn't be particularly hard to implement Tor support - it would just be a change to the tcpclient interface implementation to use a SOCKS proxy, and for the tcpserver interface implementation, just spinning up a hidden service (probably using the Stem library) pointing to the tcpserver port (bound to localhost by default in Tor mode?).

Unless I am missing something?

Love the project by the way, I hope at some time to pick up some of the associated hardware.

Consider Crystals Kyber and Crystals Dilithium, Upgrade to AES-256, upgrade to SHA3-512

You are not using the strongest version of the encryption algorithms available. For instance, you are using AES-128, which can be weakened using a quantum computer. The simplest method to combat this would be to use AES-256. You are using SHA-256, although I do not know whether you are using SHA2 or SHA3. If you are using SHA2, then you should be using SHA3, which is more recent and widely regarded as more secure. SHA3 supports an option for a 512 bit hash, this is widely regarded as more secure than SHA256 in regards to collision attacks. I would also recommend integrating Crystals Kyber into the asymmetrical cryptography, as doing so will make your network quantum resistant, but the Crystals developers recommend using Crystals Kyber with an already established algorithm. Irregardless of whether you encrypt with Elliptic Curve Diffie Helman or Crystals Kyber first is of no consequence so long as the keys used to encrypt them are generated separately. You should also consider using Crystals Dilithium as a hashing algorithm in addition to SHA3-512. This will provide two layers of security in terms of message authentication. I would recommend Dilithium5, although there is a faster version that uses AES in counter mode instead of shake to expand the polynomials, it is called dilithium5-AES. It uses AES to take advantage of hardware accelerated AES when possible, although I would stick with Dilithium5 becuase SHAKE is an irreversible function, unlike AES. There is an open source library called liboqs created by the Open Quantum Safe project. It has a python wrapper and is written in C. All of the algorithms I have mentioned in this issue ticket are available in OpenSSL if not in liboqs.

Other than my crituqe of your cryptography choices I would like to congratulate you for fighting the good fight and proving that a more decentralized and secure internet is possible. I would also like to congratulate you on not selling out to the Web3 craze. Hopefully reticulum gets the attention it deserves.

Porting to Android?

This is probably silly, but now Rnode is running on generic ESP32, could Reticulum be ported to Android as an app? Would a USB or even Bluetooth connection to the ESP32 then work?

documentation warning

on https://reticulum.network/manual/gettingstartedfast.html
is duplicated [[RNS Testnet Dublin]]
trouble is when somebody copied it and need using in this same time.
i get

[2023-02-01 13:43:51] [Error] Could not parse the configuration at /home/user0/.reticulum/config
[2023-02-01 13:43:51] [Error] Check your configuration file for errors!

no tell me where ;)
please correct it.

Synchronization between multiple devices with a shared identity

a good starting point might be to come up with an example reticulum config that would produce the desired behavior. i'm willing to help with implementation once we have this.

from @markqvist in the matrix channel:

An interesting quality of Reticulum is that, partly because we don't use source addresses, and partly just because of the way Reticulum is put together, you can do stuff just fine that seems completely alien and counterintuitive in IP. Imagine two devices, that both have the same LXMF address. You can connect from one of them, to it's own LXMF address, on the other device. Then you just do a normal LXMF sync between them, and you have updated the conversations. This works for any number of devices, and the complete message store will eventually converge on all devices.

They don't even have to take turns being the instance that holds the active path to the LXMF address. As long as there is an active path to one "primary device", all other auxillary devices can eventually sync conversations through that device. If another device becomes the active path holder, syncing will just start occurring through that.

and some more context from @markqvist:

Letting different devices just not remove the messages from the propagation nodes is the most simple way of acheiving this. I think we also need to make sure that it happens in the context of letting devices themselves sync directly between each other, without having to use the propagation nodes.

Reticulum allows this already, ie., you can have the same LXMF address on several devices, and those that are not the currently active path owners will be able to connect directly to the one that is, and then sync messages. This needs a few things added to LXMF to work.

The reason I have not done this yet, is that it ties in very well with another feature we could call "sneakernet queues", where all mobile clients can act as a sort of physically moving propagation nodes, and sync message stores with each other when in close contact. This needs to be implemented so it only happens over fast interfaces though, as to not fill up slow LoRa/packet radio interfaces with unnecessary traffic.

the TODO here is one of the things which would need to be addressed: https://github.com/markqvist/LXMF/blob/390cac84e3863627542ed3c723ad5d9d74b5f305/LXMF/LXMRouter.py#L782

Bluetooth roadmap?

bluetooth

I spotted a placeholder setting in Sideband for bluetooth. Is the intention for this to

  1. Connect with Rnode devices over Bluetooth?

  2. Or to use Bluetooth as a networking layer in itself?

The first seems like the more interesting option to me. I like to keep my Android device in my pocket, keeping a reliable USB connection is not really practical.

The meaning and range of txpower

I've been checking the whole repository but was not able to find what is the range of possible txpower setting for a LoRA TTGO 1.6 device. Is there a range that is acceptable for HW?

Proposal: i2p interface

"The Invisible Internet Project is an anonymous network layer that allows for censorship-resistant, peer-to-peer communication."

The i2p community created a couple python libraries for easily sending data over the i2p network through their SAM protocol:

An i2p interface for the RNS would allow for anonymous communication between reticulum nodes over the internet and it would allow users with non-static IP's to host internet accessible reticulum nodes. An i2p interface implementation would probably resemble the current TCP client/server interface.

If there is any interest in adding this to the core reticulum project, I could begin work on a pull request.
Regardless, I'll probably experiment with adding this feature as an add-on because it sounds useful to me 👍

Adding LoRa config causes "Android-specific interface was used on non-Android OS"

Hi, I'm currently running 0.3.16, and as soon as I add the LoRa config to the reticulum config file, I get this upon starting nomadnet or sideband:

nomad@rpi4b:~/.reticulum$ nomadnet 
[2022-10-21 20:21:36] [Error] The interface "RNode LoRa Interface" could not be created. Check your configuration file for errors!
[2022-10-21 20:21:36] [Error] The contained exception was: Android-specific interface was used on non-Android OS

My LoRa config snippet:

 [[RNode LoRa Interface]]
    type = RNodeInterface
    interface_enabled = True 
    outgoing = true
    port = /dev/ttyACM0
    frequency = 867200000
    bandwidth = 125000
    txpower = 7
    spreadingfactor = 8
    codingrate = 5
    # id_callsign = MYCALL-0
    # id_interval = 600
    flow_control = False

With the auto generated config, nomadnet and sideband start as expected.

RNode auto-install on Windows

Autoconfig can't install. Using the menu options, he says that there isn't internet connection. I'm not at home, so I can't copy paste the error but it's something like this. Thank you.

Multiple devices in same subnet via UDP broadcast

Binding broadcast UDP interface to 0.0.0.0 with multiple network devices in same subnet causes sequencing errors on resources due to hashmap packets being received multiple times and not being filtered.

Can any app that uses LXMF communicate with any other app that uses LXMF?

I assume that users on Nomad and users on Sideband can both message each other back and forth?

The Nomad app is called the "Nomad Network" on your website, so that is what makes me think maybe the app is its own self-contained network, separate from the Sideband app.

In my head, the whole ecosystem is Reticulum Network, with LXMF being the preferred format for message-sending, and any app that speaks LXMF can talk to each other.

I2P interface on android

I am getting a big chunk of error trying to use I2P interface on android. I tried to install the package from the link, the i2p python package through pip3 and also the i2pd package by pkg.

Error message:

Exception in thread Thread-14 (tunnel_job):                                
Traceback (most recent call last):
  
File "/data/data/com.termux/files/usr/lib/python3.10/threading.py", line 1009, in _bootstrap_inner                                                      
self.run()
  
File "/data/data/com.termux/files/usr/lib/python3.10/threading.py", line 946, in run                                                                    
self._target(*self._args, **self._kwargs)
  
File "/data/data/com.termux/files/usr/lib/python3.10/site-packages/RNS/Interfaces/I2PInterface.py", line 571, in tunnel_job
    self.i2p.server_tunnel(self)                                             
File "/data/data/com.termux/files/usr/lib/python3.10/site-packages/RNS/Interfaces/I2PInterface.py", line 143, in server_tunnel
    i2p_dest = asyncio.run_coroutine_threadsafe(coro, self.loop).result()    
File "/data/data/com.termux/files/usr/lib/python3.10/concurrent/futures/_base.py", line 446, in result
    return self.__get_result()                                               
File "/data/data/com.termux/files/usr/lib/python3.10/concurrent/futures/_base.py", line 391, in __get_result
    raise self._exception                                                    
File "/data/data/com.termux/files/usr/lib/python3.10/site-packages/RNS/vendor/i2plib/aiosam.py", line 67, in new_destination                            
reader, writer = await get_sam_socket(sam_address, loop)                 
File "/data/data/com.termux/files/usr/lib/python3.10/site-packages/RNS/vendor/i2plib/aiosam.py", line 28, in get_sam_socket
reader, writer = await asyncio.open_connection(*sam_address, loop=loop)  
File "/data/data/com.termux/files/usr/lib/python3.10/asyncio/streams.py", line 47, in open_connection

[2022-05-19 08:32:26] [Notice] Started rnsd version 0.3.6                      
transport, _ = await loop.create_connection(
TypeError: BaseEventLoop.create_connection() got an unexpected keyword argument 'loop'

enable_node ? syntax ? sorry marshmallow mode here!

dont see anything documenting the syntax or variables for enable_node

i added , and guessing, the doc says enable node and give it a name
enable_node = Yes
node_name = SomeName

can you please enlighten us ?

Using LoRa Interface throws occational errors

Hi Mark,

actually I see some weird errors in my container log while using my ESP32 LillyGo T-Beams with the LoRa Interface:

[2022-06-11 16:54:15] [Error] A serial port error occurred, the contained exception was: index out of range
[2022-06-11 16:54:15] [Error] The interface RNodeInterface[RNode LoRa Interface] experienced an unrecoverable error and is now offline.
[2022-06-11 16:54:15] [Error] Reticulum will attempt to reconnect the interface periodically.
[2022-06-11 16:54:15] [Error] Error while transmitting on RNodeInterface[RNode LoRa Interface]. The contained exception was: an integer is required (got type NoneType)

The interface config I use looks like that:

[[RNode LoRa Interface]]
type = RNodeInterface
interface_enabled = True
outgoing = True
port = /dev/ttyRNODE
frequency = 867200000
bandwidth = 125000
txpower = 7
spreadingfactor = 8
codingrate = 5
id_callsign = myCallSign
id_interval = 600
network_name = myNetworkName
passphrase = myNetworkSecret
flow_control = False

Interessting is, that both netwoked PIs throw this error exactly at the same point in time.
At least the log entries are always have identical timestamps.
I guess the last line of the error message given above indicates the cause of the issue.
It looks like something shall have a default or needs to have assigned a value in the config or like.
But what?
This one did not show up on my servers before the last update of RNS.
Since I updated to the most recent version and started using the beacon and name/password functionality this error startet to appear regardless if I run RNS within a dockerized environment or by running RNS on the host without docker.

Any idea or advice how to fix that would be appreciated.

Cheers
Stephan

anonymity?

Is there any definition of anonymity for what's said in the readme? Anonymity typically demands a global authoritative network map, ala Tor or mixnets, which mesh networks typically lack.

How to run a Propagation or Router node?

It's not clear who runs these nodes that are seemingly required to ensure reliable communication (in cases where destinations are offline at the time of sending).

If I run the Nomad application, does that automatically use my own device as my own router?

Add packets over TTN/Helium

TTN and Helium (to some degree) already provide coverage in many regions of the world.
It could be useful to be use these LoRa-based networks to transmit Reticulum packets.

If routing Reticulum packets over other LoRa based networks is already possible a manual page/example would be useful.

Error in the documention for the wire format

Discussed in #148

Originally posted by thatv November 5, 2022
Hi there, currently i am looking at the doc of the project and trying to understand the wire format. I am not sure if i get something wrong or I have found an error in the section with the Packet Examples. The second and third example stating a Hop count of 00000111 which is stated as zero hops. shouldn't it stated as 7 hops?

+- Packet Example -+

HEADER FIELD DESTINATION FIELD CONTEXT FIELD DATA FIELD
| | __| _|
| | | | | | | |
00000000 00000111 [HASH1, 16 bytes] [CONTEXT, 1 byte] [DATA]
|| | | | |
|| | | | +-- Hops = 0
|| | | +------- Packet Type = DATA
|| | +--------- Destination Type = SINGLE
|| +----------- Propagation Type = BROADCAST
|+------------- Header Type = HEADER_1 (two byte header, one address field)
+-------------- Access Codes = DISABLED

Thanks for the Clarification. And a nice Project btw.

Selecting specific network interfaces for UDP and TCP

There is currently no elegant way to limit a Reticulum UDP or TCP interface to one or more specific system network interfaces (i.e. eth0, tun2, etc.).

It should be possible to specify this in the configuration file.

Broadcast Example not working

Hi Mark,
today I tried to get the Broadcast.py example up and running.
To achieve a proper test I did set up a test environment as follows:

DeltaMatrix -> Unsigned.io
NexusServer 1 -> TestNode 1 -> DeltaMatrix <- TestNode 2 <- NexusServer 2

All links are TCP/IP links and the arrows (Client -> Server) are indicating which node acts as server and which one acts as client.
DeltaMatrix is linked as a client to Unsigned.io (Reticulum TestServer provided by you) to give you the opportunity to access the Test Network.

The whole Testnetwork is alive for quite a while and works smoothly if used by nomadnet.
And as usual I checked those new NexusServer Nodes by running nomadnet on them as well.
All is fine. All anouncements are traversing the net as expected which I take as an indication that those nodes are fully functional.

Now I lauchend Broadcast.py on NexusServer 1 and NexusServer 2 with the following statement:
python3 Broadcast.py --channel Public_Broadcast

Output from NexusServer 1 was:

[2022-03-11 19:43:32] [Verbose] Configuration loaded from /root/.reticulum/config
[2022-03-11 19:43:32] [Verbose] Loaded 22 known destination from storage
[2022-03-11 19:43:32] [Verbose] Loaded Transport Identity from storage
[2022-03-11 19:43:32] [Notice] Broadcast example <d646696e18a31c104ccb> running, enter text and hit enter to broadcast (Ctrl-C to quit)
> [2022-03-11 19:43:42] [Verbose] Path to <39dc5820b09489c5e59f> is now 4 hops away via <fc0f105055cc1d4d5da9> on LocalInterface[37428]
[2022-03-11 19:43:50] [Verbose] Path to <5e3c89869609c35a8030> is now 4 hops away via <fc0f105055cc1d4d5da9> on LocalInterface[37428]
>

Output from NexusServer 2 was:

[2022-03-11 19:42:47] [Verbose] Configuration loaded from /root/.reticulum/config
[2022-03-11 19:42:47] [Verbose] Loaded 9 known destination from storage
[2022-03-11 19:42:47] [Verbose] Loaded Transport Identity from storage
[2022-03-11 19:42:47] [Notice] Broadcast example <d646696e18a31c104ccb> running, enter text and hit enter to broadcast (Ctrl-C to quit)
> [2022-03-11 19:43:22] [Verbose] Path to <39dc5820b09489c5e59f> is now 4 hops away via <4be6e824f5fabd4444d1> on LocalInterface[37428]
>

Typing someting on NexusServer 1 like ...

>Hello from Node 1
>

and NexusServer 2 like ...

>Hello from Node 2
>

Simply resolved in displaying another caret.
None of the messages entered showed up anywhere.

This behavior is independent from running nomadnet on those 2 NexusServer Nodes or not.
Nothing is received by both Broadcast.py scripts.

Can you pls adv what I'am missing here?

Best regards
Stephan

PS:
All those nodes indicated above are alive 24/7.
Actually the Broadcast Scripts are alive 24/7 as well - and will stay so at least until Monday to give you the opportunity to check them via the network with the IDs loged above.

Transport Attached Sharable Links

One usability issue I've run into using Reticulum, is adding new Transports to my config in order to reach an RNS destination I want to send packets to. One way we could try and remedy this issue is by having RNS links that share Transport configuration. Once some kind of standard is realized, we could make RNS utilities that export current Reticulum "server" configs into a sharable link, and one that parses config links.

For most of the transports, there are pretty straightforward ways to embed the config info into a URL and URL params. For LoRa radio settings, the "Data URL" spec might be useful here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs

This format could then be combined with the Reticulum Internet Protocol URL scheme to provide shareable "Absolute" links that provide the RIP destination hash and the transport properties to reach that destination directly.

Edit: A quick example of an "absolute link":
rip://ykzlw5ujbaqc2xkec4::ykzlw5ujbaqc2xkec4cpvgyxj257wcrmmgkuxqmqcur7cq3w3lha.b32.i2p

represents RNS destination "ykzlw5ujbaqc2xkec4" reachable at i2p peer "ykzlw5ujbaqc2xkec4cpvgyxj257wcrmmgkuxqmqcur7cq3w3lha.b32.i2p" with default i2p settings.

ifac_netname not working on TCPServer Interface (Incomming connection)

Yesterday I tested the "ifac_netname" functionality. Thereby I found an error. The TCPServer interface does not work for incoming connections. Because with each incoming connection a new TCPClient interface gets created but missing the assignment of the "ifac_identity" and "ifac_signature".

I have solved this as follows..:
My code is only a suggestion for a solution :)

TCPInterface.py

     def incoming_connection(self, handler):
        RNS.log("Accepting incoming TCP connection", RNS.LOG_VERBOSE)
        interface_name = "Client on "+self.name
        spawned_interface = TCPClientInterface(self.owner, interface_name, target_ip=None, target_port=None, connected_socket=handler.request, i2p_tunneled=self.i2p_tunneled)
        spawned_interface.OUT = self.OUT
        spawned_interface.IN  = self.IN
        spawned_interface.target_ip = handler.client_address[0]
        spawned_interface.target_port = str(handler.client_address[1])
        spawned_interface.parent_interface = self
        spawned_interface.bitrate = self.bitrate
        spawned_interface.ifac_size = self.ifac_size
        spawned_interface.ifac_netname = self.ifac_netname
        spawned_interface.ifac_netkey = self.ifac_netkey
        if spawned_interface.ifac_netname != None or spawned_interface.ifac_netkey != None:
            spawned_interface.ifac_key = self.ifac_key
            spawned_interface.ifac_identity = self.ifac_identity
            spawned_interface.ifac_signature = self.ifac_signature
        spawned_interface.announce_rate_target = self.announce_rate_target
        spawned_interface.announce_rate_grace = self.announce_rate_grace
        spawned_interface.announce_rate_penalty = self.announce_rate_penalty
        spawned_interface.mode = self.mode
        spawned_interface.HW_MTU = self.HW_MTU
        spawned_interface.online = True
        RNS.log("Spawned new TCPClient Interface: "+str(spawned_interface), RNS.LOG_VERBOSE)
        RNS.Transport.interfaces.append(spawned_interface)
        self.clients += 1
        spawned_interface.read_loop()

AutoInterface not discovering any peers between Manjaro and PostmarketOS

I have "enable_node = yes" in my config on both clients on my LAN. But when I go to Network and view the Announce Stream there is nothing there on either one. Even when selecting Announce Now again nothing shows up so I can't get my nodes/clients connected to each other.

Have I missed something?

RNodeInterface[RNode LoRa Interface] hardware initialisation error (code 01)

I am running into a problem when I am trying to set up the Rnode Daemon.

[2022-10-13 13:24:59] [Notice] Opening serial port /dev/ttyACM0...
[2022-10-13 13:25:03] [Notice] Serial port /dev/ttyACM0 is now open
[2022-10-13 13:25:03] [Error] RNodeInterface[RNode LoRa Interface] hardware initialisation error (code 01)
[2022-10-13 13:25:03] [Error] A serial port error occurred, the contained exception was: Radio initialisation failure
[2022-10-13 13:25:03] [Error] The interface RNodeInterface[RNode LoRa Interface] experienced an unrecoverable error and is now offline.
[2022-10-13 13:25:03] [Error] Reticulum will attempt to reconnect the interface periodically.
[2022-10-13 13:25:03] [Error] Radio state mismatch
[2022-10-13 13:25:03] [Error] After configuring RNodeInterface[RNode LoRa Interface], the reported radio parameters did not match your configuration.
[2022-10-13 13:25:03] [Error] Make sure that your hardware actually supports the parameters specified in the configuration
[2022-10-13 13:25:03] [Error] Aborting RNode startup
[2022-10-13 13:25:03] [Error] Could not open serial port for interface RNodeInterface[RNode LoRa Interface]
[2022-10-13 13:25:03] [Error] The contained exception was: RNode interface did not pass configuration validation
[2022-10-13 13:25:03] [Error] Reticulum will attempt to bring up this interface periodically
[2022-10-13 13:25:03] [Notice] Started rnsd version 0.3.14

and I get the rapid flashing and have to reboot. How can i tell what is wrong with my LoRa configuration? I have changed the frequency to 900000000Hz as well (900 MHz). I have verified that the LilyGo Chip is a SX1262 and shows 868/916.......
Here is the config file
config.txt

Here is the output to
rnsd -vvvv

rnsd.txt

Any interest in adding static code analysis?

If you run: pylint RNS | wc -l you get 11,109 lines of warnings. Most are trivial to fix. There are some that may take some effort. Other warnings could be ignored with settings.

I can make PRs that would bring the code into compliance, if that is desired.

I have done efforts like this in the past. They make the code more consistent and sometimes even find latent bugs.

LoRa does not support packet of 500 bytes

As the title says, LoRa (at least Semtech's component) are limited to 256 bytes packet. Also, using such giant packets size takes a lot of air time to transmit and should be avoided since it'll decrease considerably the available duty cycle.

Move to private, resilient code hosting

The project bills itself as private and resilient, yet hosts and issuetracks on GitHub, which is neither.

Suggestion: move to privately hosted GIT repo or at least Codeburg.

Integrating with software modems

Hi all,
I'm planning to create an interface of Reticulum to software modems (like FreeDATA and Ardop), but most of these software modems just support point-to-point. Is there a problem of this in working with Reticulum?

Eg. of how a network operating in HF with UUCP works today: open a connection to host XX, sync the data, close connection, open a connection to host YY, sync the data, close connection... and so on. Is this model ok to work with Reticulum?

My plan is to use UUCP over Reticulum. Can anyone see a problem with it?

Make rnodeconf available in android

Now rnodeconf is integrated into rns, so it should be in the android app. If you now make it available from the GUI, you can update rnode's or init new one's. This would make it very easy to manage everything without need for a second device in a mobile scenario.
Thx for your work

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.