rns.recipes

TL;DR: Full investigation below, but the spam-calling nuisance that's been annoying everyone for the last couple of weeks is probably yet another failed piece of "AI" slopware. I would love to know what the actual idea was here.

An entity on the network with identity hash d14f05add53c03486d6f869cda37afbf has been spam-calling every LXST telephony destination since the beginning of May. The behavior seems perfectly weird.

If this is intentionally malicious, the frequency and operation mode is very strange. From initial observations, it is doing the following:

• When an lxst.telephony destination announces on the network, it will establish a link to this destination.
• It then sends an on-link identification, identifying itself as d14f05add53c03486d6f869cda37afbf.
• Keeps the link open, but does nothing else.

This results in the receiving lxst.telephony destination ringing, but on picking up the call, nothing happens. To make things even weirder, consider the following:

The spam-calling d14f05add53c03486d6f869cda37afbf identity has never announced an lxst.telephony destination on the network, but it does announce an lxmf.delivery destination every 5 minutes.

> rnid -i d14f05add53c03486d6f869cda37afbf -H lxst.telephony
Recalled Identity <d14f05add53c03486d6f869cda37afbf>
The lxst.telephony destination for this Identity is <184c754ddaf5750a653a605fc97fd2ea>
The full destination specifier is <lxst.telephony.d14f05add53c03486d6f869cda37afbf:184c754ddaf5750a653a605fc97fd2ea>

❯ rnpath 184c754ddaf5750a653a605fc97fd2ea
Path not found

❯ rnid -i d14f05add53c03486d6f869cda37afbf -H lxmf.delivery
Recalled Identity <d14f05add53c03486d6f869cda37afbf>
The lxmf.delivery destination for this Identity is <5954a9633c043df82b207e1a5dc3998a>
The full destination specifier is <lxmf.delivery.d14f05add53c03486d6f869cda37afbf:5954a9633c043df82b207e1a5dc3998a>

❯ rnpath 5954a9633c043df82b207e1a5dc3998a
Path found, destination <5954a9633c043df82b207e1a5dc3998a> is 5 hops away via <a5d6fc0d5669f4151ff944fca58aeafc> on AutoInterfacePeer[x/x]

So, this looks like something trying to be an LXMF-based program or services, but failing utterly.

A probing script was written to investigate a bit of the entity's behavior:

❯ python sc.py
[2026-05-25 14:36:26] [Notice]   Starting
Has path      : True
Hops          : 5
Identity      : <d14f05add53c03486d6f869cda37afbf>
Destination   : <lxmf.delivery.d14f05add53c03486d6f869cda37afbf:5954a9633c043df82b207e1a5dc3998a>
App data      : b'\x92\xc4\x05Golgi\xc0'
Display name  : Golgi
Stamp cost    : None
Compression   : True
Announce hash : fc845ad580916c147f46985d1113f164502be219485a21924133f0e005c7efb9
Announce pkt  : <RNS.Packet.Packet object at 0x7fe7cd982180>
Timebase      : 45900
Established over 5 hops

The announce timebase included in the lxmf.delivery announces is strange. The reference implementation would never send announce timebases like that, so this must be a custom "implementation". It looks like it is based on a timer that starts from 0, and increments with uptime. As of the above capture, the entity would have been up for 12 hours and 45 minutes. New announces are sent every 5 minutes.

The entity does accept link requests, and does at least seem to receive LXMF messages as both packets and resources. After initially probing whether any real person was actually on the other end, asking what in the world they were up to with this, and receiving no replies, I extended the probing script below to attempt larger resource transfers to observe the behavior.

The entity does seem to support split resources, and happily keeps accepting 1 megabyte resource segments, for a while (as we shall see).

To investigate further, I wrote 10 gigabytes of /dev/urandom to a file, and shipped it off to "our calling-eager little friend" d14f05add53c03486d6f869cda37afbf:

[2026-05-25 13:03:23] [Notice]   Starting
Has path      : True
Hops          : 5
Identity      : <d14f05add53c03486d6f869cda37afbf>
Destination   : <lxmf.delivery.d14f05add53c03486d6f869cda37afbf:5954a9633c043df82b207e1a5dc3998a>
App data      : b'\x92\xc4\x05Golgi\xc0'
Display name  : Golgi
Stamp cost    : None
Compression   : True
Announce hash : 5444487903a1e9ffa355c716c3845c4310a8dd1babf420aaeb7e73b47ad260a6
Announce pkt  : None
Established over 5 hops
Creating resource
Resource advertised
Resource progress: 548.56 MB
Timeout
[2026-05-25 13:35:36] [Warning]  Attempt to cancel a non-existing outgoing resource

This possibly caused an OOM or similar failure on the remote. After 548.56 MB of transferred data, the link became unresponsive and timed out. Since then, I have not been able to re-establish a link with the entity, and the announces from its associated lxmf.delivery destination have ceased.

Again, this is very strong indication that the entity is running a custom implementation, and not RNS, which does not handle resources in such an inane way.

I really do hope I managed to crash that piece of junk, and that whoever operates it will read this before they enable that crapware again.

More importantly, whoever "wrote" that piece of slop should come forward and explain what the hell they were thinking.

The OOM-inducing script is available upon request, for anyone who's as tired of this bullshit as myself. Or maybe, I'll just set it up to listen for announces from its LXMF destination and trigger the kill every time it hears one. Yeah, that's probably the most sensible course of action, actually.

Great thing about these LLM-spewn slopware implementations, though, is that they're so phreakin brittle you can tip them over by sending them half a gig of data. What a fucking joke.

Beautiful and hilarious. Thank you Mark!

Maybe some specialized AI is probing the network and the reactions of the people behind it, albeit in a dumb way. ;) Joke aside, people doing stupid shit, while thinking they have found an easy shortcut trough life, will always cause damage.

Especially with a name like "Golgi". Sounds exactly like the kind of "cute" name that an AI system would give to something interacting with [endoplasmic] reticulum

I do still get calls from them but only via Columba. Has it stopped for everyone else?

Is it still from d14f05add53c03486d6f869cda37afbf or is it using other identities as well? It might have been started up again.

I got a call from golgi in MeshchatX about 12h ago

I got angry at it a while back and went to look for a stamp cost in lxst. Didn't find one - but maybe that would be a worthwhile thing?

Ah well, here we go again - Golgi is back.

In the upcoming RNS 1.3.2, if you have blackholed an identity, and it identifies over a link, that link is immediately torn down before anything reaches application logic. That should effectively deal with things like Golgi. So locally, you can just do something like:

rnpath -B d14f05add53c03486d6f869cda37afbf --reason "Call spam"

And it will never reach applications again. LXST itself has had caller blocking from the start, though - any client application can simply set blocked identities via an API function, as well as enabling a "trusted callers" only mode. Not all clients implemented both or any of these options though, which made it a bit annoying to deal with. Sideband only had the "only trusted" option, for example, but no way to set per-identity blocking.

Now it's much easier to handle globally, being tied directly into the blackhole functionality. For example, you can have a canonical blackhole list published on one of your nodes, and have all your devices pull blackhole updates from that, automatically blocking unwanted callers.

I also tied the blackholing into LXMF in the same way; if a message is received from a blackholed identity, it is now dropped immediately without having to implement anything extra in the client application.

Stamps, in their current form are not as useful for LXST as they are for LXMF, which is why I didn't add them to LXST initially. In general, when you want to do a call, you want it to go through more or less instantly, so computing a new stamp on every call is not the best solution.

But, I've been working on integrating stamps directly into RNS in a more useful way, by optionally allowing identity stamps. This will mean you can stamp an identity, and have applications require a certain stamp value, for example for incoming calls from that identity. The stamping is then a one-time process (per new identity) on identity creation, and you can target a relatively high stamp value here. This means, that it's much more effective to block spam calling identities, since every time they make a spam call and get blocked, they will have to expend large amounts of CPU resources on creating a new identity and stamp, effectively turning the attack around.

I really like the idea of identity stamps, a sort of Proof-of-work for identify creation. Even stamps that cost minutes of compute time could be interesting.

One could argue that social media sites have this too by requiring the user to give revealing information about themselves at sign-up, or put up the work to create burner emails etc.

metrafonic wrote:

I really like the idea of identity stamps, a sort of Proof-of-work for identify creation. Even stamps that cost minutes of compute time could be interesting.

One could argue that social media sites have this too by requiring the user to give revealing information about themselves at sign-up, or put up the work to create burner emails etc.

I feel like this is mostly meaningless and would only impair legitimate users or weak devices (e.g. microcontrollers) while doing nothing to stop people who actually want to break the system.

Also Golgi has been happening for over a month with the same identity. Making new indentities wouldn't help while we're trying to do something with one

Ahyrax wrote:

I feel like this is mostly meaningless and would only impair legitimate users or weak devices (e.g. microcontrollers) while doing nothing to stop people who actually want to break the system.
Making new indentities wouldn't help while we're trying to do something with one

However you as an individual can make an identity once, and take it with you on all your devices. You have access to more compute than your microcontroller.

Ahyrax wrote:

Also Golgi has been happening for over a month with the same identity.

This is in addition to the work on limiting what damage one identity can make.

metrafonic wrote:

make an identity once, and take it with you on all your devices

IIRC (I may be wrong) it's not recommended to have the same identity on multiple devices since it makes delivery inconsistent (not exactly relevant to the discussion but still)

You have access to more compute than your microcontroller.

I do. I also have an ability to print more identities than I would reasonably want or need. I don't see how these defenses would apply to an attacker, I only see the implication of "if users want to join this network they are required to have a beefy PC or use cloud compute". If they do use cloud compute, then so could the attacker, so this precaution becomes meaningless

Ahyrax wrote:

I do. I also have an ability to print more identities than I would reasonably want or need. I don't see how these defenses would apply to an attacker, I only see the implication of "if users want to join this network they are required to have a beefy PC or use cloud compute". If they do use cloud compute, then so could the attacker, so this precaution becomes meaningless

They still have to put down the cash to make those 100-1000 identities. Not every attacker is a nation state actor. Some are just script kiddies armed with an AI. Lets say worst case one identity costs 10c of compute, 100 identities becomes $10 and 1000 $100 etc

Nothing is ever 100% secure, information security is about making things more expensive to break (time, resources etc)

metrafonic wrote:

They still have to put down the cash to make those 100-1000 identities. Not every attacker is a nation state actor. Some are just script kiddies armed with an AI. Lets say one identity costs 10c of compute, 100 identities becomes $10 and 1000 $100 etc

You just put access to Reticulum behind a paywall which is something it was specifically made to avoid.