# RNS Websocket Interface _Showcase · started by nilu96 on Mon, Jul 6, 2026 9:38 AM_ --- ## Original post **nilu96** · Mon, Jul 6, 2026 9:38 AM 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](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! --- ## Reply 1 **bergie** · Mon, Jul 6, 2026 5:09 PM 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. --- ## Reply 2 **jrl290** · Mon, Jul 6, 2026 8:33 PM 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 --- ## Reply 3 **nilu96** · Tue, Jul 7, 2026 8:42 AM 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. --- ## Reply 4 **bergie** · Wed, Jul 8, 2026 4:02 AM WebRTC Data Channels might be interesting to experiment with as an interface. You need a signaling servers, but otherwise it is P2P. --- ## Reply 5 **gdane** · Thu, Jul 9, 2026 3:33 PM 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](https://github.com/attermann/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. --- ## Reply 6 **KenAKAFrosty** · Thu, Jul 9, 2026 3:59 PM **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 --- ## Reply 7 **nilu96** · Thu, Jul 9, 2026 8:22 PM @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. --- ## Reply 8 **bergie** · Fri, Jul 10, 2026 3:48 PM **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. --- ## Reply 9 **gdane** · Fri, Jul 10, 2026 5:45 PM 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. --- ## Reply 10 **bergie** · Tue, Jul 14, 2026 4:01 AM **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. ---