rns.recipes

Hi everyone,

I want to share a Websocket interface that might be interesting for purely browser based applications that don't support raw TCP/UDP connections.

Feel free to have a look: https://github.com/nilu96/rnsWebsocketInterface

I'd love to hear your thoughts, and feedback or contributions are definitely welcome. Let me know if you find it useful!

There's also https://github.com/liamcottle/reticulum-meshchat/blob/e6ff5097c07fe09e90a392acb516f033b2a637de/src/backend/interfaces/WebsocketServerInterface.py

WebSocket would be great support for the JavaScript Reticulum library I'm sketching right now.

I too would like to see a standard websocket interface for python rnsd

But since many people were already tossing that idea around, I put together a POST only web interface, also with browser applications in mind:
https://github.com/jrl290/Reticulum-post

You can see it up and running here:
https://retichat.com

I would also love to see a websocket interface in standard rnsd!

I think the meshchat websocket implementation is not „plug and play“ compatible. So the files can not just copied into the interfaces folder inside of the reticulum config folder.

WebRTC Data Channels might be interesting to experiment with as an interface. You need a signaling servers, but otherwise it is P2P.

I needed exactly this to support microReticulum transport node management over RNS.

@nilu96 I looked at Meshchat and found the same to be true about the WS interface. It's very specific to each feature that Meshchat supports. I proposed an extension and offered a PR to support more general operations but the maintainer has not been very responsive, so I decided to break out my extension into a self-contained app and build on that instead.

ReticulumAPI

This has. lot more utility IMO. It's not a complete API but it does provide support for Links and basic Packets+Proofs, etc. I'm happy to accept help improving and extending it to support more use-cases.

bergie wrote:

WebRTC Data Channels might be interesting to experiment with as an interface. You need a signaling servers, but otherwise it is P2P.

This and other hole-punch-style techniques are top of mind for me, too. Big thing is the peer getting your rough location so needs to be for trusted contacts or for those who already publicly disclose their general region publicly, something like that

@gdane I think your ReticulumAPI is much more than the interface I shared. My shared repo only provides a simple WS interface for RNS to send raw packets over web sockets. It is not an API for external tools and does not contain any "translation layer" between raw RNS packets and readable JSON (or something similar). I experimented with running a full Reticulum node in the browser and needed a quick and easy interface for allowing a connection to other nodes.

@bergie I agree, WebRTC could be interesting. I've always found the need for a signaling server to set up the connection between peers a bit clunky, especially since there is no standardization for such a signaling server. But it might worth a deeper dive.

nilu96 wrote:

My shared repo only provides a simple WS interface for RNS to send raw packets over web sockets. It is not an API for external tools and does not contain any "translation layer" between raw RNS packets and readable JSON (or something similar).

And that sounds like the right thing to do. I'm working on a Reticulum JavaScript library (and there's also the older one from Liam Cottle). If WebSocket interface exists, web apps can be proper participants Reticum network. And given that web apps run everywhere, this would increase the potential reach or Reticulum immensely.

I understand, these are two very different approaches to solving the same problem. What I've built is a REST+WS API to a local Python RNS for thin clients to utilize an adjacent Python RNS node. What I understand you @bergie and @nilu96 are talking about is a WebSocketInterface for a local Python RNS that enables a browser-based RNS implementation (a thick client if you will) to exchange packets with the network via that adjacent Python RNS node. Seems like a Python WebSocketInterface would be a pretty light lift if it hasn't already been done.

nilu96 wrote:

@bergie I agree, WebRTC could be interesting. I've always found the need for a signaling server to set up the connection between peers a bit clunky, especially since there is no standardization for such a signaling server. But it might worth a deeper dive.

Actually, I wonder if slower Reticulum connections like LoRa could be useful for exchanging signaling information before setting up the faster WebRTC data channel. Could be useful in environments where autointerface is not available.