# RFed Release Candidate _Showcase · started by jrl290 on Fri, Jun 5, 2026 12:37 AM_ --- ## Original post **jrl290** · Fri, Jun 5, 2026 12:37 AM https://github.com/jrl290/RFed I feel that I've done all that I can on my own to test what I hope will be a boon for Reticulum. I want to freeze the protocol. But I want to expose it to the harshness of the internet first Here's the premise: - RFed is an extension on the principles of LXMF store-and-forward propagation - a layer of nodes between backbone servers and endpoint devices collects and synchronizes data published to it - Endpoint devices then connect to a middle node to pull messages on the network designated for that device - RFed adds to this mechanism the ability to subscribe to a data channel in a global namespace. The RFed node then considers messages published to a channel to be designated for any device that has subscribed to that channel - In addition, RFed adds the ability to register a destination to be pinged when data designated for a device is available - Lastly, RFed has a built in LXMF store-and-forward service, completely compliant to spec. It is designed to replace the standalone LXMF propagation service Why it adds foundational capability to Reticulum: - It adds subscriber based communication to the Reticulum network itself. Instead of a single host being a single point of control and failure for message distribution applications, a mass of nodes stores and forwards data without any knowledge of what the packet contains - It expands the hard point representation for devices that are not always online. Sending notification pings to relays enables true mobile push notifications Privacy and data security is still paramount: - Packets are double wrapped the same way that LXMF propagation packets are. Intermediary nodes cannot see any data in any packet without the private key for the channel, which is shared out of band. All intermediary nodes are considered untrusted. - Even when a channel is considered "public", the destination address is hashed before an RFed node sees it, obfuscating the "public" part of the address - Stamp costs are configurable for both internode peering and publishing to channels Considerations: - It is currently still possible to spam messages over channels if their RFed node is given a stamp cost of 0. I'm not entirely sure how to protect against that, but channels are not just for chats so I didn't want to do any sort of naive filtering just. Maybe someone has ideas - It is possible to send large data packages over RFed. But each node does have configurable storage limits as well as transfer and sync size limits - When it comes to distribution to subscribers, each endpoint device has one RFed node that services it (although there isn't really a reason it couldn't have more than one I don't think). However, RFed has built in the ability to assign a backup node in case it goes offline. These nodes are supposed to be a highly available point that fills in for the highly unavailable endpoint devices. So redundancy I felt was important to build in Of course, currently the only up and running RFed node is mine. And the only app that makes use of it is my Retichat for iPhone and Android. But whoever is interested in tinkering with, vetting, penetration testing, or building on top of, I would very much appreciate the feedback Hopefully there aren't any more changes to be made and others can take advantage of the new capability --- ## Reply 1 **nim** · Thu, Jun 18, 2026 3:18 PM Has your node gone down? I cant seem to reach it. --- ## Reply 2 **jrl290** · Fri, Jun 19, 2026 3:31 AM **nim** wrote: > Has your node gone down? I cant seem to reach it. I am able to propagate send and channel send through it (through the backbone network). I'm not able to channel subscribe, it seems. So I'll have to check that out --- ## Reply 3 **Dio** · Sun, Jun 21, 2026 2:19 AM I can't join a channel from Retichat iOS ---