# The "Golgi" Situation, or How To Stop d14f05add53c03486d6f869cda37afbf _General · started by Mark on Mon, May 25, 2026 2:10 PM_ --- ## Original post **Mark** · Mon, May 25, 2026 2:10 PM ***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. ```text > rnid -i d14f05add53c03486d6f869cda37afbf -H lxst.telephony Recalled Identity The lxst.telephony destination for this Identity is <184c754ddaf5750a653a605fc97fd2ea> The full destination specifier is ❯ rnpath 184c754ddaf5750a653a605fc97fd2ea Path not found ❯ rnid -i d14f05add53c03486d6f869cda37afbf -H lxmf.delivery Recalled Identity The lxmf.delivery destination for this Identity is <5954a9633c043df82b207e1a5dc3998a> The full destination specifier is ❯ rnpath 5954a9633c043df82b207e1a5dc3998a Path found, destination <5954a9633c043df82b207e1a5dc3998a> is 5 hops away via on AutoInterfacePeer[x/x] ``` --- ## Reply 1 **Mark** · Mon, May 25, 2026 2:12 PM 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: ```text ❯ python sc.py [2026-05-25 14:36:26] [Notice] Starting Has path : True Hops : 5 Identity : Destination : App data : b'\x92\xc4\x05Golgi\xc0' Display name : Golgi Stamp cost : None Compression : True Announce hash : fc845ad580916c147f46985d1113f164502be219485a21924133f0e005c7efb9 Announce pkt : 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). --- ## Reply 2 **Mark** · Mon, May 25, 2026 2:13 PM To investigate further, I wrote 10 gigabytes of /dev/urandom to a file, and shipped it off to "our calling-eager little friend" `d14f05add53c03486d6f869cda37afbf`: ```txt [2026-05-25 13:03:23] [Notice] Starting Has path : True Hops : 5 Identity : Destination : 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. --- ## Reply 3 **Mark** · Mon, May 25, 2026 2:15 PM 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. --- ## Reply 4 **Torlando** · Mon, May 25, 2026 4:07 PM Beautiful and hilarious. Thank you Mark! --- ## Reply 5 **aetherlab** · Mon, May 25, 2026 6:14 PM 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. --- ## Reply 6 **KenAKAFrosty** · Mon, May 25, 2026 8:11 PM 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 --- ## Reply 7 **CarstenBoll** · Tue, May 26, 2026 8:34 AM I do still get calls from them but only via Columba. Has it stopped for everyone else? --- ## Reply 8 **Mark** · Tue, May 26, 2026 10:02 AM Is it still from `d14f05add53c03486d6f869cda37afbf` or is it using other identities as well? It might have been started up again. --- ## Reply 9 **Torlando** · Tue, May 26, 2026 3:02 PM I got a call from golgi in MeshchatX about 12h ago --- ## Reply 10 **qbit** · Tue, May 26, 2026 4:20 PM 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? --- ## Reply 11 **Mark** · Tue, May 26, 2026 4:21 PM Ah well, here we go again - Golgi is back. --- ## Reply 12 **Mark** · Wed, May 27, 2026 10:42 AM 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. --- ## Reply 13 **Mark** · Wed, May 27, 2026 10:47 AM 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. --- ## Reply 14 **metrafonic** · Wed, May 27, 2026 10:55 AM 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. --- ## Reply 15 **Ahyrax** · Wed, May 27, 2026 11:08 AM **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* --- ## Reply 16 **metrafonic** · Wed, May 27, 2026 11:13 AM **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. --- ## Reply 17 **Ahyrax** · Wed, May 27, 2026 11:28 AM **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 --- ## Reply 18 **metrafonic** · Wed, May 27, 2026 11:36 AM **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) --- ## Reply 19 **Ahyrax** · Wed, May 27, 2026 11:40 AM **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. --- ## Reply 20 **AhyrCo** · Wed, May 27, 2026 11:41 AM See LXMF (first 8 letters) of this identity to see what I mean. It's identical to the stamp value of 32 iirc and it's unreasonable to see this achieved on any phone or generic pc even. But I have an ability/knowledge to do this for free or without actual hardware - other people might be able as well (And once I do it I'm free to use this identity for as long as I want while I could also make more in the background.) I just don't see how it's useful --- ## Reply 21 **Ahyrax** · Wed, May 27, 2026 11:46 AM **AhyrCo** wrote: > See LXMF (first 8 letters) of this identity to see what I mean. It's identical to the stamp value of 32 iirc and it's unreasonable to see this achieved on any phone or generic pc even. But I have an ability/knowledge to do this for free or without actual hardware - other people might be able as well (And once I do it I'm free to use this identity for as long as I want while I could also make more in the background.) I just don't see how it's useful rip it doesn't show the LXMF address. It's meant to be "c0ffeeee6fd4d0431f2f64feedce0dc7" --- ## Reply 22 **metrafonic** · Wed, May 27, 2026 12:09 PM **Ahyrax** wrote: > You just put access to Reticulum behind a paywall which is something it was specifically made to avoid. You are mistaken. Having your phone or laptop CPU run 100% for 30 seconds is not a paywall. Proof-of-Work is a well established security practice. The 10c example was just putting it into perspective. You can use the network without the stamp value, but you will not get access to *my* resources unless you show me you put in the effort creating that identity --- ## Reply 23 **Ahyrax** · Wed, May 27, 2026 12:18 PM **metrafonic** wrote: > You are mistaken. Having your phone or laptop CPU run 100% for 30 seconds is not a paywall. Proof-of-Work is a well established security practice. The 10c example was just putting it into perspective. > > You can use the network without the stamp value, but you will not get access to *my* resources unless you show me you put in the effort creating that identity That's fair, I agree with that and I see that it could be useful. My previous comments were related specifically to random identities calling everyone. Regarding *this exact situation* my belief is that it's overall not going to be very effective when applied to old/weak devices, but I guess we'll see what Mark figures out --- ## Reply 24 **joakim** · Wed, May 27, 2026 4:53 PM Cross-signed identities may be relevant: 9ce92808be498e9e05590ff27cbfdfe4:/page/forum/thread.mu`cat=general|thread=how-to-handle-compromised-identities|anchor=post-3 ([How to handle compromised identities](https://rns.recipes/forum/general/how-to-handle-compromised-identities#post-319)) I can't say I completely understand it yet (or ever will) but, unless I'm mistaken, it enables a chain of trust where your "root" identity could have a much higher stamp value than your "node" identities. --- ## Reply 25 **dreieck** · Thu, May 28, 2026 9:21 AM **Mark** wrote: > 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. When reading the "ZEN of Reticulum", I get the imagination that one fundamental philosophy of Reticulum and everything based on it is that messages reach the recipient _eventually_, and one should step away from expectations of instantaneous reachability. For Reticulum-based LXST this would mean "hey, your call will arrive eventually, relax and do not expect instant connection". So in my understanding, having to wait until a call is established would fit very well the philosophy, and some extra wait for stamp calculation might not be noticeable so much if you would have to wait anyway due to how the network is working. *(In IP networks I am also sometimes used to 60..120s round trip times, by the way.)* --- ## Reply 26 **oatmilk!** · Fri, Jun 12, 2026 7:24 AM https://lantian.pub/en/article/fun/ai-agent-bankrupted-their-operator-scan-dn42lantian.lantian/ it may be related to this ---