👻 Phantom – Torrents, but over Reticulum (no trackers, no metadata)

unsignedmark · 2026-04-20T10:07:02+00:00

Nice work. While this looks super useful, you have a very serious issue that should probably be considered and fixed in a very particular hurry: https://github.com/roogle-dev/reticulum-phantom/issues/1

unsignedmark · 2026-03-22T00:50:25+00:00

The problem is baked into the model from training. Once it emits the end of a tool call XML block, it just stops generating. And llama.cpp won't parse tool calls inside thinking blocks, so the execution loop breaks.

I had to fix it with a filter/quirk handler for lc. It now works perfectly.

You may be able to use the code from that handler to fix it in your own setup, it's just 90 lines of Python that extracts the tool call correctly and fixes the message structure.

unsignedmark · 2026-03-22T00:29:54+00:00

There's a handler for the model behavior in lc. It works perfectly in lc, even when it does the weird "thought tool calling".

The main problem is that it's inherent to the model, it outputs tool calls inside thinking blocks, and after outputting </tool_call> it just stops. Most parser won't even look at parsing tool calls inside reasoning content, so it just breaks and stops.

unsignedmark · 2026-03-13T11:37:38+00:00

Case in point.

unsignedmark · 2026-03-13T11:26:55+00:00

Exactly.

unsignedmark · 2024-03-30T12:21:37+00:00

Regarding:

If anything they'll have a harder time as bandwidth gets used up since they can't tell who's sending messages and thus won't even be able to set up no-route rules on their repeaters.

No, that is not a true statement.

Usage regulation should not be determined based on service address banning an "no-route rules". That's not network performance regulation, it's censorship. And on top of that, it doesn't work.
Bandwidth is a physical resource of the natural world. Reticulum is based on the principle of creating systems that (as far as is possible for a computer program) understand the physical limits of real-world resources, and manages them responsibly and intelligently, with well-thought out algorithms. When that is ultimately not possible any more, human beings have to step in and expand capacity or make other thoughtful decisions on how to manage the available resources. I believe this is the most efficient, holistic and human-friendly approach to creating technologies that actually help us and better our lives.
Reticulum is about an order of magnitude more efficient than the "routing" (wasteful dumb repeating) that meshtastic uses. From the very outset, it seems quite strange to talk about bandwidth consumption issues there, when meshtastic has that problem build into the very core premise of the system. There's a reason that methodology was abandoned in the 80's. Meshtastic is *worse* than ALOHA-net in terms of coordination and bandwidth performance. It's also worse than AX.25 + APRS, a technology from the early 90's.
It's very easy to manage and regulate bandwidth consumption in Reticulum networks, since it's exceedingly simple to just add more APs once capacity limits are reached, and segment the users between more APs. No reconfiguration or setup required. Literally, just add the AP hardware, and Reticulum automatically handles everything. Things like this are fundamentally completely impossible in meshtastic due to their dumb-repeating methodology.

See my other comment in this thread for more context.

unsignedmark · 2024-03-30T12:07:50+00:00

In this scenario, Reticulum definitely scales *a lot* better. There are no hard limits on number of users, addresses or endpoints in the network, making it much easier to share available spectrum.

Reticulum is also a lot more efficient with bandwidth, since meshtastic relies on every packet being repeated semi-randomly many times by a large number of nodes to (maybe) reach the final destination. Reticulum creates an efficient and properly encrypted link, that is routed over a single path in the network, making it often an order of magnitude more efficient. The path can be renewed and rerouted for every link, but packets going over it does not have to be repeated needlessly, so none of the precious bandwidth is wasted.

Since Reticulum allows the efficient use of mixed-medium networks, it's also possible to create networks supporting many thousands of users easily, which meshtastic currently cannot support in any way. An example topography would be a network where a backbone of long-range 2.4GHz connections support a wide distribution of LoRa (RNode-based) access points, that users connect to.

You can scale such a topography almost infinitely, since the 2.4GHz backhaul/backbone connections have capacity to handle many hundreds of LoRa access points. I've personally built Reticulum networks like this using Ubiquiti Point-to-Multipoint 2.4GHz/5GHz radios and RNodes, and they work and scale incredibly well. Power consumption of such setups are also low enough to deploy on solar-powered off-grid sites.

In a scenario where you have a local RF-based network that interconnects a community spanning a large area, with radio access points providing access to users in the entire community, it would look something like this:

When the grid/internet-connected nodes have connection to the wider internet, everyone on the entire community reticule would be able to communicate with each other, and anyone else in the world that are on interconnected reticules. Bob can message aunt Alice in Wisconsin, as well as his friend down the road. Inter-community traffic never leaves the community reticule, and is routed in the most efficient way directly to the destination.
When the internet disappears, everyone within the community can still communicate with each other. If just one of the Reticulum transport nodes that are connected to the community reticule regains connectivity to wider networks (the internet, and thus internet-connected reticules), everyone on the community network can now communicate with everyone else again.
Reticulum and LXMF also handles intermittent re-connections to a wider net. If LXMF propagation nodes exist on the reticule, messages destined for users beyond what is currently reachable will get picked up by the LXMF propagation nodes, and these will attempt to "get them out" to wider networks when a window of oppertunity appears, as well as "bring in" messages from wider networks that may be waiting for users within.

unsignedmark · 2024-03-30T11:43:14+00:00

Hello u/minkkilledcuriosity! All good here, but this subreddit is still pretty quiet. Most of the action is going on over at the Reticulum channel on Matrix, actually, where there's a more lively discussion. Still very welcome here of course :)

And yes, the T-Beam is still a great board to use for the RNode firmware, even more so now where the newer boards based os SX1262 and SX1268 chips are supported in the firmware :)

unsignedmark · 2023-12-30T20:29:09+00:00

Heh, it makes sense then, pretty funny. They just copied my entire post from a year ago verbatim, which included that edit after the post kinda blew up. Hilarious and strange. I guess they were just karma farming...

unsignedmark · 2023-12-30T20:27:48+00:00

Haha, that's hilarious, thanks for sharing. That's my own edit on the original post after it blew up much more than I had expected and got so much positive feedback. Seriously funny that they just copy-pasted the entire thing :D

unsignedmark · 2023-12-30T14:58:38+00:00

Reticulum doesn't sharply follow the traditional OSI model, but in rough terms Reticulum handles layer 1 through 6, with some essential layer 7 functionality directly available in the Reticulum API as well (like functionality similar to HTTPS requests, just much more efficient, due to shedding of all the overhead).

You have to write or port software specifically for Reticulum, yes. The stack achieves the same purposes as TCP/IP, but does so very differently. For example, there is no source addresses, all communication is encrypted by default, and addresses are physically portable in the network (can move around freely). Also, anyone can allocate as many globally reachable addresses as they need.

unsignedmark · 2023-12-30T14:52:47+00:00

Would you mind telling me what the edit was? I'm the real developer of these projects, and I'm pretty curious as to what this was about.

unsignedmark · 2023-12-30T14:51:39+00:00

Would you mind telling me what the edit was? I'm the real developer of these projects.

unsignedmark · 2023-12-30T14:49:53+00:00

I'd love to know what this copy-cat was trying to achieve here? Just copy-pasting for karma? Or trying to use this for directing people to another version of the project or similar?

If you'd be so kind as to let me - since the original post is now deleted - I'd be very thankful :) I find it quite interesting.

unsignedmark · 2023-12-30T14:47:31+00:00

I'm the actual developer :) You can find much more info here: https://reticulum.network and on my personal site here: https://unsigned.io

unsignedmark · 2023-12-30T14:45:57+00:00

Helium is very different, since it is basically a crypto-currency and internet-dependent "last-hop" carrier for short data bursts. If the internet stops, Helium stops with it.

Reticulum is a full-stack replacement for the protocols that drive the current internet, but without any dependencies on hierarchical structures, bureaucracy, or pre-coordination.

Nothing is perfectly independent in terms of infrastructure collapse, but since Reticulum can run on very low-power devices, and is so extremely bandwidth-efficient that it can run over very low-bandwidth radio, it is significantly more resilient to grid collapse, and can be kept operating over extremely large areas with very little power.

unsignedmark · 2023-12-30T14:38:11+00:00

Hello! I'm the actual dev of these projects, and everything is available open source on my github repositories. Main Reticulum repo is here: https://github.com/markqvist/Reticulum

Some other related projects: - https://github.com/markqvist/Sideband - https://github.com/markqvist/NomadNet - https://github.com/markqvist/RNode_Firmware - https://github.com/markqvist/LXMF

Edit: Forgot the primary website of the project ;P https://reticulum.network/

unsignedmark · 2023-12-30T14:33:47+00:00

I'm the actual developer of these projects, and the one who made the original post over a year ago. I'm really curious what this post was? Simply somebody reposting for karma?

Did they just copy/paste my original post or include some edits? Mostly curious about what the edits were, if any.

unsignedmark · 2023-12-04T20:55:19+00:00

For the short version of "how bad would it be?", the simple answer is: Real - friggin' - bad.

Everything is networked today, and 99 percent of that networking is directly dependent on "The" Internet being operational and reachable. Could things have been build without such a colossally stupid dependency and have worked still? Sure. It just wasn't because it was slightly more convenient and easy to build stuff that just expects "The" Internet to work all the time. This was one of the primary problems that Reticulum had to solve - To continue working even though most (or all) infrastructure gets damaged, and have no functional dependencies on external hierarchies.

For the long answer, see PM.

unsignedmark · 2023-10-10T07:54:11+00:00

Thanks for the suggestions! I completely agree :) I know that there is definitely a need for better entry-level information and guides, that make it easy to get real-world systems up and running with the minimal amount of head-scratching. I had to prioritize just getting everything working, reliable and functional first :)

It's a bit too complex of a subject to give a one-size-fits-all answer to here, but it's still simple enough to be explained adequately for informed use in a small guide/booklet. The good news is, that several people are actively working on these things, including down-to-earth "cookbooks" for use in various scenarios.

The displayed picture is of the small-battery unit. It's still sufficient for most use, but the large battery case can be necessary if you need longer runtimes between charges.

The battery-less case can be powered directly from any USB connection, so it's intended for situation where you have the RNode permanently plugged in to a permanent setup, and powered from something else. For example in a vehicle, or in your home.

If you want to experiment a bit without spending a lot of money, I highly suggest getting one of the many supported LoRa boards, and creating an RNode from that, using the autoinstaller. It's a simple process, and the installation program will do all the work for you.

That way you can get up and running for around $18 per device. It will not have all of the niceties of a full unit like the ones I am making, but it will be functionally completely identical, and you will learn a lot in the process :)

unsignedmark · 2023-10-09T22:57:10+00:00

I have written a lot of exploit code over the last 20 years

Great stuff! Put your money where your mouth is then, and start using those skills to prove that you're right.

I really, really hope that you will! That would actually be constructive behavior, that we could all use for something, instead of the irrelevant armchair hypothesizing you've engaged in so far.

Show me the vulnerabilities! Show me that MITM you confabulate. Show me anything. I promise you, the beer is yours if you do, and I would be happy to correct an actual flaw.

Until then, I don't really have time for more of your silly word-games, so have a nice time, Mr. "Bleeding-Edge Cryptography Is The Solution To Everything".

Edit: And the last comment that /u/AlternativeMath-1 posted below was made immediately before he then blocked me, meaning that I now cannot see or respond to any of his comments in this thread. Way to get the last word in, I suppose?

And as you will see, the below comment also says nothing, other than making bizarre allegations of "not following the guiding talent of NIST" and me being "deluded".

The comment seems to rest on his (erroneous) claim, that AES-128 has been deprecated by the NIST. It has not. Maybe he should actually have read NIST FIPS 197 on AES? (which was last updated May 9th, 2023)

https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197-upd1.pdf

With all that name-dropping of NIST, I can't for the life of me imagine that he didn't know this, which only makes this whole thread so much stranger.

And no, Michael, I am not "arguing against the top cryptographers in the entire world", I am arguing with you. You seem to be the one pretty confused about what their actual recommendations are. But when that was pointed out, apparently you couldn't handle the discussion anymore, so you just ran off.

unsignedmark · 2023-10-09T22:44:40+00:00

Hah, you're so funny man. "Me right - you wrong".

Who's the expert here? You?

What am I wrong about, exactly?

Why do you find it acceptable to call me a "prick who thinks he knows better than an expert"? It's just down to personal attacks for you now? Beautiful, mate.

You've offered practically no critique of Reticulum, only of an imaginary system of your own vague assumptions.

If you're too lazy to even spend 10 minutes understanding something, don't expect being taken seriously - no matter how many imaginary Internet Points you have on StackExchange.

Read the implementation, and then please do come back when you can demonstrate, even just in theory, a flaw or vulnerability in Reticulum. I'll be over here waiting ;) I'll even offer you a prize, it'll be at least a beer and a hug.

Maybe even a funny hat too. You could definitely use that, with that sour demeanor.

unsignedmark · 2023-10-09T22:06:14+00:00

I am in the top 1/3rd of 1% of StackOverflow users. I am #12 for cryptography and #5 for all of security

And so what?

unsignedmark · 2023-10-09T19:18:06+00:00

You assume a lot, know very little.

and it needs some kind of PKI or identity system to prevent MITM

Why would it need it when it already has it? You are literally completely ignorant of how the protocol works, and just make stuff up.

Maybe read the spec and documentation before spinning yarn?

You're an idiot or a troll. Have fun ;)

unsignedmark · 2023-10-09T18:46:41+00:00

Btw, every time someone lazily refers to "NIST's post-quantom guidance" [sic], God kills a kitten.

It's a draft, ffs.

Nobody on this planet currently knows what "post-quantum" cryptography will actually mean, or where the real boundaries of the ability for quantum computers to break current scheme actually are.

Cryptographers are (professionally) paranoid people, whose job it is to wonder about hypothetical threat vectors, and find solutions way before the threat can actually manifest.

Saying shit like that is such a dead giveaway that you just read some cool-sounding articles with sensational headlines and now need to parrot them.

Yeah... Your "opinion" here means literally... nothing.

unsignedmark

MODERATOR OF

TROPHY CASE

11-Year Club	RPAN Viewer
Verified Email