45 Followers
12 Following
50 Posts
Creator of weird and wonderful things. There is another world, but it is in this one.
LXMF Messaging Address8dd57a738226809646089335a6b03695

🚨 Google wants to kill Android freedom: Starting 2027, unverified apps can’t be DOWNLOADED.

➡️ No installation of independent apps

➡️ Destroys alternative playstores like F-Droid

➡️ Google decides what runs on YOUR phone

Help us fight this plan! ✊

https://tuta.com/blog/google-wants-to-kill-android-freedom

@foosel So... Maybe the submitter actually just was an LLM, no human involved?

Thanks for all the work you've done over the years, it's helped me out on many a print :)

This maintenance release adds improved handling for RNodes with a PA/LNA combo.

Changes
-  Improved handling for RNodes with PA/LNA combo
- Added interference detection stats to rnstatus output for RNode interfaces
- Updated documentation

Release Hashes
7a2b7893410833b42c0fa7f9a9e3369cebb085cdd26bd83f3031fa6c1051653c rns-1.0.4-py3-none-any.whl
ee647e7b3b94abdf1fab618a861390531a4aacc93eecce12c9e97280195c0e2d rnspure-1.0.4-py3-none-any.whl

Get this #release via pip or GitHub.
The Hub

This release initiates migration of Reticulum from AES-128 to AES-256 as the default link and packet cipher mode. It is a compatibility/migration release, that while supporting AES-256 doesn't use it by default. It will work with both the old AES-128 based modes, and the new AES-256 based modes. There's a very slight penalty in performance to support both the old and new modes at the same time, but only for single packet APIs (not links), and it really shouldn't be noticeable in any everyday use.

In the next release, version 0.9.6, Reticulum will transition fully to AES-256 and use it by default for all communications. That means that both single packets and links will use AES-256 by default. The old AES-128 link mode may or may not be available for a few releases, but will ultimately be phased out entirely.

The update requires no intervention, configuration changes or anything similar from a users or developers perspective. Everything should simply work. This goes both for the 0.9.5 update, and the next 0.9.6 update that transitions fully to AES-256.

Changes
- Added support for AES-256 mode to links and packets
- Added dynamic link mode support
- Added temporary backwards compatibility for AES-128 link and packet modes
- Added get_mode() method to link API
- Added tests for all enabled link modes
- Added instance_name option and description to default config file
- Improved ratchet persist reliability if Reticulum is force killed while persisting ratchets
- Fixed interface string representation for some interfaces
- Fixed instance name config option being overwritten if option was not last in section
- Fixed unhandled potential exception on fast-flapping BackboneInterface connections

Release Hashes
ae6587c86c98cae0df73567af093cc92fe204e71bb01f2506da9aec626a27e97 rns-0.9.5-py3-none-any.whl
96208c1d1234e3e4b1c18ca986bad5d4693aeb431453efd7ade33b87f35600e1 rnspure-0.9.5-py3-none-any.whl

Get this #release via pip or GitHub.
The Hub

With a #RaspberryPiZero2W & #usbhub https://www.waveshare.com/wiki/USB_HUB_HAT_(B) possible to use 4 #lora #radio #rnodes at same #reticulum #meshchat interface. Can use 4 different sets of radio parameters at one #LoRa #radio interface. Can use 1 radio with low #spreadingfactor #sf for short transmissions at high data rate for large payloads like images or accessing #nomadnet #pages and 1 with larger SF for longer range. No need to choose between #meshtasic presets https://meshtastic.org/docs/overview/radio-settings/ ! just use them all ! Magic
USB HUB HAT (B) - Waveshare Wiki

@adingbatponder What you might be able to do is solder wires from the 5V pads on the bottom of the Pi 4 PCB to the 5V USB input pad on the Pi Zero. If the PSU can provide enough current for them both, that should work.
@adingbatponder Yes, depending on what you want to do, it may also be worth looking into just using lxmd, since it's easier to script and interact with externally. It can host propagation nodes, but also receive messages and just run external commands when those messages are received. So if this is for some kind of testing setup or similar, that may be a more flexible option.
@adingbatponder Normally the program would set that option when initialising the LXMF router instance, and it shouldn't really be overridden by something in the environment. Both Sideband, nomadnet and the lxmd program supports setting the delivery limit via config file options or user preferences. Isn't there an option for that in MeshChat as well? I'm thinking it would be a lot easier to simply provide a modified config file to MeshChat before startup that sets the delivery limit correctly, instead of trying to patch the source code.
@adingbatponder @smurfy Nice! Good to hear!
@adingbatponder You should be able to link them with AutoInterface if the VMs are on the same bridged network (ie., can hear ethernet multicast packets from each other. I'm not terribly familiar with Proxmox, so don't know if that is standard there. On KVM/QEMU, you need to enable it in the VM configuration at least, since it defaults to a routed, NATed network for each guest.