Off sick and working on my #cyberdeck in between fits of coughing and sneezes.

Just added an #RNode to the build, which means it can use low-range radio (LoRa) to send and receive messages and browse the NomadNet (a sort of alternative internet).

All thanks for #Reticulum.

Damn! This guy did quite a good job for porting self contained #reticulum LXMF messaging on t-deck in c++. This should be much speedier than my project. https://github.com/ratspeak/ratdeck One thing though - mine is easily customizable because it’s micropython - just change the code upload the file and you’re ready to go. With his, on the other hand, you could just flash the firmware and you should be ready to go. I’ll try it and report my findings.
GitHub - ratspeak/ratdeck: Standalone Reticulum on LilyGo T-Deck, all-in-one.

Standalone Reticulum on LilyGo T-Deck, all-in-one. - ratspeak/ratdeck

GitHub
#ClaudeCode on my laptop machine can, after a couple of pop-ups, see below, #ssh into my #pizero and monkey around with it..... not bad. The pi zero #lora #rnode is connected to the laptop via a hotspot that the pi zero generates to serve #reticulum #meshchat. The laptop is connected to that hotspot via a dedicated wifi dongle TP-Link Archer T3U Plus AC1300 for dual wifi https://amzn.eu/d/04oLHUGr (running nixos but works for any device with browser). #raspberrypizero info https://loramesh.org/subpages/piboxnode/build_pi_box.html
Todays t-deck #reticulum app update: added screen off timer for battery saving and optimized UI drawing by dynamically switching SPI bus speed between 80mhz for the screen and 10mhz for sx1262. Kinda feels better now.

Chris Boden released a short video about meshtastic, and alluded to future videos on meshcore and reticulum!  

https://youtube.com/shorts/oUkBUACALFY

#meshtastic #meshcore #reticulum

Meshtastic 101 #chrisboden #comedy #engineering #diy #educational #science #radio #tech #gear #edc

YouTube

В пошуках економічного (на end-to-end компах) способу передачі UDP/TCP трафіку, поліз курити #CRXN, суто за прикладами реалізації маршрутів на базі якогось реєстру типу Git:

https://codeberg.org/CRXN/docs/src/branch/master/docs

Відкрив там для себе два нові рішення легкого тунелювання: #GRE і #fastd. Тепер думаю: якщо я збільшу розмір пакету даними маршрутизації, то чи не відтяпає цей аналіз стільки ж енергії, скільки на декодування підписаних даних.

Тим не менше, консенсус - він всюди. Різниця крипти лише в тому, що її важко моніторити, від того легше ганяти нею не модерований траф. По великому рахунку, будь які рішення можуть бути легко заблоковані, тому я думаю що вони працюють рівно доти, допоки їм дають можливість працювати центральні регулятори.

Проблема відомих мені криптографічних маршрутизаторів полягає у тому, що вони фактично декодують увесь мережний шум, відбираючи тільки частку корисного трафіку. Найпростіший приклад тому - BitMessage, коли до рою DHT потрапляє увесь трафік переписок, а вузол намагається відшукати у ньому валідний підпис. Це працює, допоки в рої десяток користувачів, але росте мережа - падає коефіцієнт корисної дії, майже у всіх без виключеннях "автоматах" #P2P. Досі живий приклад - IPFS, де системний трафік зашкалює за 1 Мбіт на пустому локальному сховищі.

Мораль у тому, що мені не подобається розкидатись часом CPU для цілком відкритих задач. Для прикладу, передача публічних файлів засобами FTP і sFTP має колосальну різницю в продуктивності. Те само з медіа-потоками або ігровими стрімами. Я зовсім не хочу відкусувати ядро на 4 гравця халфи, тоді як не шифровані дані - можуть тягнути тисячі онлайну. Мене тупо душить жаба давати стрім на одного слухача радіо, який відбирає 25%.

Більше того, марнотратство у вигляді купівлі додаткового заліза має пряме відношення до фінансування видобутку та виробництва енергетичних ресурсів, а згодом - неминучих війн за конкурентні, і як наслідок, монополістичні інтереси.

P.S. Поліз читати доки для самих маленьких, і зрозумів що мережного сіса - мені ще як до неба рачки. Але я не здамся, бо вже не вперше тікаю з іги (як і P2P в цілому, що по суті є голодним авто-пілотом) через усвідомлення її марнотратства та ілюзії свободи.

P.P.S. Ці висновки в мене формуються, виходячи з енергетичних реалій, де усі ці іграшки що звичайно вісять на фоні - в "бойових" умовах, не витримують жодного краш-тесту, не кажучи вже про якийсь там пост-апокаліпсис, де працювати нормально зможе тільки макро / лампова електроніка.

P.P.P.S. Опинившись якось в умовах повної заборони радіо-сигналу (привіт, #Reticulum і тарганам) я в серйоз задумувався про оптичні канали на базі імпульсного генератора фотонів з підручних засобів, на рівні Морзе. Еволюція складних рішень - має критичну точку свого розвитку, і сучасні експериментальні роутери перебувають десь близько неї. В мене є певні сподівання на пост-квантові / спінові рішення, але в цій сфері я ще більший нуб, аніж в технологіях 50-річної давнини.

docs

The Official CRXN website

Codeberg.org
I have an Acer laptop in the loft running a #lora #rnode on #reticulum and #meshchat on #nixos since over 200 days and it still works. So Nixos was stable did not fail for over 200 days. For info about Reticulum etc. one can consult https://loramesh.org
lora radio mesh communication

Does anyone have an idea if the npm worm issue affects the most recent #reticulum #meshchat packages in view of the dependencies? Can one use #meshchat version 2.3.0 without any worminess concerniness? My current version is v2.2.1-era code. The JavaScript JS dependency tree really stayed the same, so upgrading to MeshChat 2.3.0 does not appear to add new npm-specific exposure that could be relevant. It seems to leapfrog the Shai-Hulud
What do you think of the #cyberpunk #reticulum interface facelift? 😁
I think there’s potential for #Reticulum [https://reticulum.network] to piggyback on HFC networks, including decommissioned ones.
Reticulum Network