-
m-relay
<snowman:tetaneutral.net> These companies don’t give a shit about your data too. None of them. Foundation included.
-
m-relay
<snowman:tetaneutral.net> Buy some laptop or android on Craigslist for cash, don’t put it in the internet and just be done with it.
-
m-relay
<mmxxx:matrix.org> i think that's a fair point but it's like when you're moving with anything that's valuable, you do what you can to avoid drawing undue attention to yourself - don't speed, don't be loud or flash etc
-
m-relay
<snowman:tetaneutral.net> A million other ways to save your seed too. I’d be curious how others do border
-
m-relay
<mmxxx:matrix.org> thumb drives
-
m-relay
<mmxxx:matrix.org> lots of them
-
m-relay
<mmxxx:matrix.org> ohai duknukem, happy belated easter :)
-
m-relay
<mmxxx:matrix.org> ohai dukenukem, happy belated easter :)
-
dukenukem
hi sir, happy belated Easter to you as well.
-
nioCat
<•binaryFate> Binaries for v0.18.3.3 are now available at
getmonero.org
-
binaryFate
thx nioCat
-
m-relay
<ravfx:xmr.mx> * encrypted EEPROM, the small surface mount type, it's like 5-6mm long, just don't lost it else you wont find it lol
-
m-relay
<ravfx:xmr.mx> * In plain sight, like in your hard drive, stuff it in %userprofile%\Saved Games\CD Projekt Red\Cyberpunk 2077/autoSave-x/sav.dat... Or /usr/lib/libPNG.so.1.6, use the hiding theme you prefer, again don't forget where you stuffed it because you are going to have fun to search it. File should still be encrypted.
-
m-relay
<ravfx:xmr.mx> * Old DOS floppy disk, name it command.com and pad it with random so it about the size it should have
-
m-relay
<ravfx:xmr.mx> Many way to hide stuff in plain sight...
-
m-relay
<ravfx:xmr.mx> Just be creative ;)
-
m-relay
<dave.jp:matrix.org> Encrypt it and the use Steganography
-
m-relay
<ravfx:xmr.mx> in one of the image in your picture folder full of other pictures..., Not "alone"
-
m-relay
<ravfx:xmr.mx> clipboard.png
-
m-relay
<ravfx:xmr.mx> Do the people at the border even know how to read theses?
-
m-relay
<ravfx:xmr.mx> You can use a weirdos format too, so if you know how to read it you are going to think the floppy is dead
-
m-relay
<ravfx:xmr.mx> That append when it's 35 year old right...
-
m-relay
<ravfx:xmr.mx> You can use a weirdos format too, so if they know how to read it you are going to think the floppy is dead
-
m-relay
<ravfx:xmr.mx> That append when it's 35 year old right...
-
m-relay
<ravfx:xmr.mx> You can use a weirdos format too, so if they know how to read it, they are going to think the floppy is dead
-
m-relay
<ravfx:xmr.mx> That append when it's 35 year old right...
-
m-relay
<ravfx:xmr.mx> Can also put data in an audio tape.
-
m-relay
<ravfx:xmr.mx> Just use a normal old pink floyd or whatever tape and hide the data somewhere, should not take more than 1 second worth of tape.
-
m-relay
<ravfx:xmr.mx> Granted, that second will sound more like a old modem but I don't think the border guy will begin to listen to the tape you are going to bring
-
m-relay
<321bob321:monero.social> Lmao simcity
-
m-relay
<321bob321:monero.social> You got tank?
-
m-relay
<ravfx:xmr.mx> tank? that one don't ring a bell lol
-
m-relay
-
m-relay
<hardenedsteel:monero.social> 0.18.3.3 were already released weeks ago?
-
selsta
v0.18.3.3 was tagged weeks ago but only released now
-
m-relay
<hardenedsteel:monero.social> then why did we publish a blog post weeks ago about its released?
-
m-relay
-
m-relay
<mmxxx:matrix.org> i know, i've done it for many years :)
-
m-relay
<123bob123:matrix.org> what you talking about Willis
-
plowsof
hardenedsteel the pull request to add the 18.3.3 blog to site was merged 2 weeks ago here
monero-project/monero-site #2275 site was "deployed" today reflecting the changes
-
m-relay
<hardenedsteel:monero.social> should we change the date of the blog post?
-
m-relay
<shortwavesurfer2009:monero.social> I just updated my monerod to 0.18.3.3
-
m-relay
<sgp_:monero.social> <a data-mention-type="user" href="
matrix.to/#/@ofrnxmr[m]:libera.chat" contenteditable="false">@ofrnxmr[m]</a> I've said before, ill stop hosting the docs once you get docs.getmonero.org up and running with maintainers. Stop saying I'm squatting on getmonero.dev when I'm hosting something useful. Core hasn't asked me for the domain, but I'd offer it if they wanted to use it for something
-
m-relay
<sgp_:monero.social> Reread your comment here. You are acting very unwell.
-
m-relay
-
m-relay
<sgp_:monero.social> By comment, I mean several chained comments
-
m-relay
<sgp_:monero.social> Cake adding an optional service indicator is not "spyware" ffs. Leave Cake alone and use your own wallet. I'm sick and tired of you having temper tantrums every time you don't understand someone else's reasonable opinion. You're actively working to tear this community apart, but you think you're on a righteous crusade. It's maddening.
-
m-relay
<sgp_:monero.social> Cake got thousands of tickets each day during the transaction spamming. With the notification bell, the number of tickets dropped significantly
-
m-relay
<hardenedsteel:monero.social> can you elaborate more? what tickets are for?
-
m-relay
<syntheticbird:monero.social> I suppose bug tickets stating Cake wallet is unreliable/slow. There are a lot of folks out there that trust Cake wallet on the quality of the service and don't understand the intrinsic of monero's network. So as casual users, they thought cake servers were buggy/unreliable, they were frustrated and opened tickets to inform the team
-
m-relay
<hardenedsteel:monero.social> thousands is really big number
-
m-relay
<syntheticbird:monero.social> Cake Wallet is the biggest XMR wallet. And probably have a minor portion of BTC users
-
m-relay
<snowman:tetaneutral.net> There are Monero wallets with telemetry and massive amounts of bullshit. Stop bugging the cake people.
-
m-relay
<snowman:tetaneutral.net> Doesn’t edge wallet or one of the Monero wallets sell everyone’s transaction information? Maybe it was my monero
-
m-relay
<sgp_:monero.social> edge wallet uses a mymonero like setup with the view key, yeah
-
m-relay
<snowman:tetaneutral.net> They have your view key?
-
m-relay
<sgp_:monero.social> tuxsudo might be able to share the number of tickets for those days, if they are willing. I don't know exactly how many, but a large number was mentioned at the Finney Forum in discussions
-
m-relay
<snowman:tetaneutral.net> Oh that’s how they get the transaction information
-
m-relay
<hardenedsteel:monero.social> if **just** BTC user (like "maxis") they wouldn't ask that much basic question imo
-
m-relay
<sgp_:monero.social> monerod is reliable, but it's not built to deliver wallet sync data to thousands of users. It really slows down under load unfortunately. Fixing that is a very large, sensitive undertaking
-
m-relay
<321bob321:monero.social> Banned
-
m-relay
<tuxsudo:tux.pizza> Tickets people created since they were unable to sync their wallets partially due to performance degradation from the spam attack on the network. It was in the hundreds per hour
-
m-relay
<321bob321:monero.social> Noobs
-
m-relay
<321bob321:monero.social> Switch the node
-
m-relay
<tuxsudo:tux.pizza> Yeah that is most of the interaction, and then there would be a reply because other nodes weren't working either. It's was a firestorm, thankfully all is smooth waters now and even if the transaction spam took off again our nodes will be much more resilient thanks to Tanner's work.
-
m-relay
<sgp_:monero.social> yes, a bunch of noobs. That's why people need to be educated with things like this
-
m-relay
<rucknium:monero.social> IMHO, a good but expensive solution is to create separate software like bitcoin's (and cousins) Electrum server to serve data to remote wallet users. Let monerod sync and another program serve. Then you don't have to worry about creating bugs in monerod to let it serve more users.
-
m-relay
<sgp_:monero.social> Rucknium: yes, you're right. But that takes time to get right; it wasn't an immediate, deployable fix last month
-
m-relay
<rucknium:monero.social> The requirements to serve a remote Monero wallet are orders of magnitude higher than to serve a remote bitcoin wallet. But there is no Monero equivalent for Electrum.
-
m-relay
<321bob321:monero.social> Welcome to IT support
-
m-relay
<rucknium:monero.social> I was running a public remote node during the spam (still am) and my node fell behind sync like others because there is no logic to prioritize verifying and adding a new block instead of serving the wallet users. And wallet users not having rbrunner's fix made it a lot worse.
-
m-relay
<321bob321:monero.social> Cake could use k8s to scale up and down. But that wont fix if there is a “usage spammer”
-
m-relay
<rucknium:monero.social> tuxsudo: Does Cake have this fix?:
monero-project/monero #8800 It was in the v0.18.3.1 Monero release.
-
m-relay
<321bob321:monero.social> Hope there on latest
-
m-relay
<321bob321:monero.social> Also hope there is more then just tux involved
-
m-relay
<321bob321:monero.social> End up burnt out
-
m-relay
<tuxsudo:tux.pizza> long ago yes
-
m-relay
<tuxsudo:tux.pizza> yes it's not just me 🙂
-
m-relay
<tuxsudo:tux.pizza> Tanner primarily manages the node infrastructure, I just help
-
m-relay
<tuxsudo:tux.pizza> Unfortunately most of the bottlenecks still lie within monerod itself and no more optimization or load balancer or starting up nodes will help. Will try using a dedicated VPS for dedicated storage soon but at the moment our current nodes have so much RAM that most of the blockchain is in memory
-
m-relay
<321bob321:monero.social> Cache drive?
-
m-relay
<rucknium:monero.social> tuxsudo: Are you pruning your nodes? AFAIK that would help if you are all in RAM
-
m-relay
<rucknium:monero.social> I mean it would reduce your RAM requirements.
-
m-relay
<tuxsudo:tux.pizza> it's just that the VPS we use has NVME but it's ceph networked storage which gives it really bad IOPS
-
m-relay
<tuxsudo:tux.pizza> may have to consider it, they are currently full nodes
-
m-relay
<321bob321:monero.social> 😬
-
m-relay
<321bob321:monero.social> Vps or dedicated ?
-
m-relay
<tuxsudo:tux.pizza> currently a VPS, setting up dedicated ones to test this week
-
m-relay
<rucknium:monero.social> AFAIK, your can serve remote wallets from a pruned node with no downsides. You may want to double check that in #monero-dev:monero.social
-
m-relay
<rucknium:monero.social> IIRC running monerod from networked storage is not recommended. Sometimes it doesn't even work. You can check that statement in -dev too
-
m-relay
<321bob321:monero.social> Wonder if read orientated ssd are quicker
-
m-relay
<321bob321:monero.social> Where is rav
-
m-relay
<321bob321:monero.social> Yeah ceph is distributed
-
m-relay
<321bob321:monero.social> Someone here was trying glusterfs
-
m-relay
<tuxsudo:tux.pizza> Unfortunately the block storage being networked is not under our control and Akamai doesn't offer full dedicated CPU + large storage options.
-
m-relay
<tuxsudo:tux.pizza> which is why we're looking to better dedicated providers
-
m-relay
<tuxsudo:tux.pizza> but with 150GB RAM per node.... LMDB WILL cache and use all of it 😂
-
m-relay
<stnby:kernal.eu> Dedicated VPS aka VDS still uses ceph
-
m-relay
<tuxsudo:tux.pizza> Not dedicated VPS. Dedicated system is what I'm currently setting up
-
m-relay
<stnby:kernal.eu> Only difference is they allocate you a physical CPU core instead of sharing CPU core with 20/different VPSs
-
m-relay
<stnby:kernal.eu> 👍️
-
m-relay
<321bob321:monero.social> Yeah instead of vcpu
-
m-relay
<321bob321:monero.social> Just bought one
-
m-relay
<321bob321:monero.social> $35 usd
-
m-relay
<tuxsudo:tux.pizza> I think you suggested a dedicated server in the first place so thanks, hopefully it works better.
-
m-relay
<stnby:kernal.eu> Yes
-
m-relay
<321bob321:monero.social> LBLK] Xeon E3 Dedicated Server [Micro] (04/01/2024 - 04/30/2024) $55.00
-
m-relay
<321bob321:monero.social> CPU: E3-1270 v5
-
m-relay
<321bob321:monero.social> RAM: 32GB DDR4 ECC
-
m-relay
<321bob321:monero.social> Disk Layouts: (1) 480GB SSDs (1) 960GB
-
m-relay
<321bob321:monero.social> Bandwidth: 50TB @ 1Gbps
-
m-relay
<321bob321:monero.social> Thats aud
-
m-relay
<stnby:kernal.eu> That's a funny disk choice. No raid1?
-
m-relay
<321bob321:monero.social> Nah
-
m-relay
<321bob321:monero.social> Os on 480
-
m-relay
<321bob321:monero.social> Blockhain on 1tb
-
m-relay
<321bob321:monero.social> Blockchain
-
m-relay
<321bob321:monero.social> Doesnt bother me if os 💥
-
m-relay
<ravfx:xmr.mx> It's not like you could not download it back yeah.
-
m-relay
<ravfx:xmr.mx> BTW, read a little the buffer, I have no much experiance with networked blockchain storage, I did try back a while ago with an already synced monero node thru SMB and it was usually crashing while loading the lmdb thing.. and eventually corrupted it. I did not touch network blockchain storage since that
-
m-relay
<ravfx:xmr.mx> I do have 5 Monero full node on my one server for proper load balancing. Maybe eventually the thing will use more threads for the verifications and RPC?
-
m-relay
<321bob321:monero.social> S3 intergration when ?
-
m-relay
<321bob321:monero.social> Good for aws botnets
-
m-relay
<stnby:kernal.eu> I've heard best node setup is copying XMR block chain files to ramdisk. If you have 128GB you can certainly fit pruned chain. And on shutdown copy it back to disk.
-
m-relay
<syntheticbird:monero.social> that setup isn't failure proof. If DC have power outage or kernel crash. you loose everything and have to resync again
-
m-relay
<stnby:kernal.eu> *Not everything
-
m-relay
<stnby:kernal.eu> Last copy
-
m-relay
<ravfx:xmr.mx> That's my node setup so far, hugly AF but seam way more resilient
-
m-relay
<syntheticbird:monero.social> Oh yeah right.
-
m-relay
-
m-relay
<stnby:kernal.eu> Until last copy
-
m-relay
<syntheticbird:monero.social> running on windows I presume ?
-
m-relay
<321bob321:monero.social> Millenium or xp?
-
m-relay
<ravfx:xmr.mx> Naa, Alpine VM
-
m-relay
<ravfx:xmr.mx> Proxmox OS
-
m-relay
<ravfx:xmr.mx> Epyc server in a basement
-
m-relay
<321bob321:monero.social> If xp sp1 or sp2
-
m-relay
<ravfx:xmr.mx> SyntheticBird Windows I mentionned I think it's only good for Desktop shit behind nat 😂
-
m-relay
<syntheticbird:monero.social> I've so much to say about every one of your lines
-
m-relay
<syntheticbird:monero.social> musl => performance degradation ?
-
m-relay
<syntheticbird:monero.social> proxmox => coward
-
m-relay
<syntheticbird:monero.social> epyc server in a basement => EPYC SERVER IN A BASEMENT ????
-
m-relay
<321bob321:monero.social> Proxmox ?
-
m-relay
<321bob321:monero.social> Debian stable
-
m-relay
<ravfx:xmr.mx> musl = bloat reduction, enyway only installed package is docker lol
-
m-relay
<ravfx:xmr.mx> proxmox = it work for the job
-
m-relay
<ravfx:xmr.mx> epyc server in a basement = why not, it have a 2GB fiber and it's happy there
-
m-relay
<siren:kernal.eu> Proxmox OS (cracked)
-
m-relay
<ctrej:matrix.org> where else would you put your epic server?
-
m-relay
<ravfx:xmr.mx> Could also put it in a datacenter I don't own
-
m-relay
<stnby:kernal.eu> Its not cracking. Its doing whatever you want with your FOSS software.
-
m-relay
<321bob321:monero.social> Monero island
-
m-relay
<321bob321:monero.social> I am inspired by aws orbit. Lets send a seed node up to space.
-
m-relay
<ravfx:xmr.mx> I want node to space too.
-
m-relay
<ravfx:xmr.mx> CCS time?
-
m-relay
<ravfx:xmr.mx> Each space nodes could p2p to each other with lazers
-
m-relay
<321bob321:monero.social> Yest
-
m-relay
<321bob321:monero.social> But i need to escort it to space
-
m-relay
<ravfx:xmr.mx> We can ask Elon
-
m-relay
<ravfx:xmr.mx> Eventually he will be able to throw hundraids nodes in space in one go
-
m-relay
<ctrej:matrix.org> no chance
-
m-relay
<ctrej:matrix.org> starlink only supports doge 😭
-
plowsof
Do the nodes have a single point of failure if the master node somehow goes down ravfx?
-
m-relay
<ravfx:xmr.mx> Not true, was forced to use a prepaid CC to get one
-
m-relay
<ravfx:xmr.mx> Extra shenanigans because he lied like usual lol
-
m-relay
<ravfx:xmr.mx> having one node instead is the same exact single point of failure
-
m-relay
<ravfx:xmr.mx> But now the RPC don't bring the master node behind anymore when the spammers do his thing
-
m-relay
<ravfx:xmr.mx> I could put more master nodes and more slaves but I don't have enough nvme drive in there (yet)
-
m-relay
<ctrej:matrix.org> madman (in a good way)
-
plowsof
Are you running into a cpu bottleneck ravfx? It seems cakes issue is ram and bandwidth?
-
plowsof
Multiole.monerods handle the read/write lock issue better?
-
m-relay
<321bob321:monero.social> Ssd cache
-
m-relay
<ravfx:xmr.mx> CPU, during the attack with my initial single node setup.
-
m-relay
<ravfx:xmr.mx> my node was getting behind and two core where almost constantly stuck to 100% while the other where doing not much.
-
m-relay
<ravfx:xmr.mx> I don't know Cake setup, but I have like 8 channels for RAM.
-
plowsof
Multiple monerods on the same box is where im wondering why? I dont know about load balancing of course but i thought a proxy directing people to monerods on other boxes with their own bandwidth when they satsfy some "we are kinda busy" metric
-
m-relay
<ravfx:xmr.mx> monerod don't use enough threads so I used a different way to use more thread.
-
m-relay
<ravfx:xmr.mx> The p2p alone is not the bottleneck, people with there own private nodes did not get issue.
-
m-relay
<ravfx:xmr.mx> RPC is the issue and it's why I splitted the RPC into 4 nodes.
-
m-relay
<ravfx:xmr.mx> And the Master node don't do any RPC work for that reason
-
m-relay
<ravfx:xmr.mx> And for more oomph, you can indeed pin each slave to there own CCD (so they get two dedicated memory channels instead of making detours and stealing memory bandwidth of other CCD)
-
plowsof
Interesting hmm so we're using more cpu now. Would we need to research if the cpu is now doing more for the network? And not just duplication? The.4? Rpc nodes can now handle more rpc clients?
-
plowsof
More resources are now available for the network is the goal and i assume this achieves that?
-
m-relay
<ravfx:xmr.mx> exactly, so each slave can handle about the same as a single node, but each slave only have to deal with 5 p2p (one to the master and 1 per other slave).
-
m-relay
<mrcyjanek0:matrix.org> Iirc there was an issue where monero exchanged entire mempool every 20 seconds - so it could be the issue
-
plowsof
I try to have 1 node per data canter, and my only bottleneck has been bandwidth (if the box hasb109Mbit?) ive yet to see my 1gigabit nides bandwidth be used yet (forgive units).
-
m-relay
<ravfx:xmr.mx> My bandwidth utilization record so far was about 240Mbits during the attack
-
m-relay
<ravfx:xmr.mx> That could easily be the issue, don't wallets ask mempool informations? that could explain why RPC could bring down the node?
-
plowsof
Old.clients ask for entire mempool every 29 seconds
-
m-relay
<ravfx:xmr.mx> yeah, I did read that the other day
-
plowsof
24 .. 20* seconds
-
m-relay
<ravfx:xmr.mx> during the attack (mild)
-
m-relay
-
plowsof
So a given vps box with > 240Mbit bandwidth benefits from running multiple monerods (so a box with alot of bandwidth)
-
m-relay
<mrcyjanek0:matrix.org> Yeah, or targeted ddos, I had my node on a pi zero (exposed to internet) and it was able to keep up for the most part
-
m-relay
<ravfx:xmr.mx> During the attack (one of the two mega peek)
-
m-relay
-
m-relay
<ravfx:xmr.mx> That was the second mega peek that gave me the idea to make a "reinforced node"
-
m-relay
<ravfx:xmr.mx> At that point get a dedicated server, you want at least 4 cores par node right?
-
m-relay
<ravfx:xmr.mx> and you want 16GB minimum per node, but 64 ideally for some extra caching.
-
m-relay
<ravfx:xmr.mx> That's the first mega peek
-
m-relay
-
m-relay
<ravfx:xmr.mx> get_transactions was winner in both case
-
plowsof
A ccs for this load balancing work should be popular but "niche", for a 'power user' not the layman at home, or to keep featherwallet listed nodes online.. stackwallets.. cakewallets
-
plowsof
But it also points to monerod being broken / not able to scale
-
m-relay
<ravfx:xmr.mx> My node is in the feather wallet node list.
-
m-relay
<ravfx:xmr.mx> But you made the point, your node don't get much RPC if at all and so had no problem to keep up even on a very anemic system
-
plowsof
The 100Mbitndid go offline but ye a bandwidth capped system isnt the use case right?
-
m-relay
<ravfx:xmr.mx> Yeah, I think you want that kind of node only for wallet nodes.
-
m-relay
<ravfx:xmr.mx> Normal nodes don't get near the needed amount of traffic to overload
-
plowsof
The internet cable was effectively unplugged
-
m-relay
<321bob321:monero.social> Thought of something. Inspired by haveno front end. Could i not just run a reverse proxy and point to other nodes
-
m-relay
<321bob321:monero.social> I will have 100% uptime
-
m-relay
<321bob321:monero.social> Muahah
-
plowsof
One exists on github created by... Dugavo sec
-
m-relay
<ravfx:xmr.mx> Could work too, you just want to split the RPC so you have less rpc hamering the node.
-
m-relay
<ravfx:xmr.mx> But I was thinking that P2P could also play something (P2P go down when the RPC kill the node), it's why I splitted it up.
-
m-relay
<ravfx:xmr.mx> Plus it use less bandwidth for the P2P and so keep more available for RPC
-
plowsof
-
plowsof
Not dugavo sorry, false memory?
-
m-relay
<ravfx:xmr.mx> Ideally in addition to the fail over, you want that each new connection go to the next node, that way they are going to stay fast until they all get overloaded... in the same time ;)
-
m-relay
-
plowsof
E.g. we could connect to a feather wallet proxy run by tobtoht
-
m-relay
<ravfx:xmr.mx> That could work, it could use the same node selection algorythm than feather wallet
-
plowsof
Still the underlying problem of monerod not scaling ? :(
-
plowsof
,
-
m-relay
<ravfx:xmr.mx> Yeah, that is the main problem indeed
-
plowsof
The proxy just ddos' everyone offline
-
m-relay
<syntheticbird:monero.social> C++ is hard we have stop lying to ourselves
-
m-relay
<syntheticbird:monero.social> let's rewrite monerod in perl
-
m-relay
<ravfx:xmr.mx> Ideally the best would be that each wallet have a good list of trusted node.
-
m-relay
<ravfx:xmr.mx> How much node did Cake had?
-
m-relay
<ravfx:xmr.mx> Ideally nodes that can absorb more... until the monerod scallability problem is addressed
-
plowsof
Last man standing
-
m-relay
<321bob321:monero.social> We can move db to cockroachdb?
-
m-relay
<ravfx:xmr.mx> That could be nice, I could have one DB for all my nodes 😂Assuming is efficient enough to become the single point of failure
-
m-relay
<ravfx:xmr.mx> Or a way to have a lmdb server node and all node connected to that
-
m-relay
-
m-relay
<321bob321:monero.social> Not me btw
-
m-relay
<mrcyjanek0:matrix.org> Just use mysql and calculate hashes using stored procedures
-
m-relay
<mrcyjanek0:matrix.org> 3306 for the new monero p2p port
-
m-relay
<321bob321:monero.social> Fck that. They dont encrypt passwords
-
m-relay
<321bob321:monero.social> Postgres scram-256
-
m-relay
<321bob321:monero.social> Thought of something. LMDB is key value store? We can use redis!!
-
m-relay
<cx_:matrix.org> What's a cheap VPS I could get to host a node
-
m-relay
<syntheticbird:monero.social> hyc would like to find you and torture you for what you just said
-
m-relay
<321bob321:monero.social> Noooooooo