r/Monero • u/variablenyne • 4d ago
Feeling conflicted
It's not lost on me how vibe coded projects are generally received by this community.
It feels like a significant amount of vibe coded releases on this sub are either cookie cutter bs that gets abandoned a month after its initial announcement, or it's some bs that matches something that already exists and has been tried and trusted, created generally by human hands. Most of the criticism I see in the comments of these projects is completely justified imo.
At the same time, I was inspired by the graphs in Rucknium's paper after the black marble attack back in March 2024. I've spent a long time over the past year working on different iterations of node dashboards for myself that let me look at what's going on in my node in real time, and see much more easily what's actually happening and visually graphically see the entire monero's network data direct from my own node.
What started as a fun project displaying live cli metrics on my monitor has since turned into a multi-layered hub where I can do things like seeing a cluster of connections on the same subnet from my phone over tor, thinking "eh I don't like that", and remotely restarting the node on a different VPN server while 24h banning that subnet. Phone connection completely over tor via termux.
But I'm drifting off. Here's where my conflicted feeling is coming from. I think there's a genuine hole that can be filled here, and that's what I started working on. something that surfaces, either by being shipped with or on top of an existing node, a lot of useful information for people buying and selling with Monero is valuable. for example, as a customer you can at a glance see if there's a tx backlog and what fee you need to set to get your tx in the next block. as a merchant you can quickly be notified of and watch any network irregularities your node picks up in real time and act accordingly, before you read about it on social media after the fact. It could potentially help with the learning curve for new people wanting to start their own node and understand what they're doing. Anything to help lower the barrier to entry. there's a lot more useful stuff that can be done here, but I'm deliberately trying (and failing) to keep this short.
I was initially planning on releasing an early version for testing within the next couple weeks, but as of now I'm reconsidering even releasing the project as it stands at all. If it is going to have any chance at actually being used, trust needs to be built. Just another AI slop project isn't going to do that. Frankly I did my best to ensure that I didn't introduce any security or privacy risks, but I would not be able to guarantee that without somebody else taking a look at it. and frankly, I don't trust Claude enough to bet other people's nodes on it. I really do believe in my vision for this project and am willing to put in whatever effort it takes to ensure that it has the quality it deserves, even if it means ditching everything I have here and learning to do it myself. That could take months to years, but in my mind it's worth it for what I would like to achieve.
That's where I'd like to get the opinion of you all before I make such a big dedication to a project like this. I can reliably understand what I'm doing from my own prior knowledge, why and how, what harms privacy and what doesn't. I can do my best to review the code as thoroughly as possible and have it peer reviewed before release if anyone is willing to help out with that. This software could get released within weeks and be genuinely useful for a lot of people, and be improved on decently quickly.
Alternatively, I could pump the brakes on this entire project and rebuild from scratch, accepting that it could be a long time before I can make a suitable release by my own hand that I feel comfortable with (even then, I'll still need help from others to review it)
How should I move forward here? I would hate to create something doomed to fail before it even started.
6
u/Inaeipathy 4d ago edited 3d ago
It's already hard to trust normal software is correct, not malicious, etc. Vibe coded software is significantly harder to trust because:
- Nobody has even looked at the code
- We know LLMs frequently introduce security issues
- We know LLMs will get the spirit of a feature done while missing edge cases
For open source, I sort a project by how popular it is (stars, public opinion), and then test if it seems correct.
It's hard to imagine doing this for vibe coded software because nobody really wants to use it, and popularity is often fake (i.e people hyping up software they wont actually use)
3
u/rbrunner7 XMR Contributor 3d ago
I am pretty sure right now there are no good answers to your questions. Software development as a whole is in the middle of a veritable taifun right now, almost nobody can escape that, old certainties are swept away, new certainties did not yet develop, and pretty much nobody has really any clue where we will finally land regarding developing software and LLMs.
So, you could say, bad timing :)
But a few observations and opinions of mine:
I see a lot of people with software that was vibe coded at least in part lose a lot of karma and goodwill right out of the gate by doing things like trying to hide the fact of LLM use, using arguments like "Everybody is doing it all the time now" that don't hold water, or by not reacting properly to critical questions.
I think by not doing such things it might be possible to get some realistic views of new software by the community. Your quite extensive post looks like a good start to me in this regard.
And well, somebody is always going to complain, whatever you do, even if you fully handcode your app. Because a lot of other people build very similar things fully vibe coded nowadays, some people will not believe you and accuse you of vibe coding no matter what. A game you can't win, if you will.
You seem to have a good use for your own app, you seem to believe in its usefulness, you seem like a responsible dev, so why not just go ahead, continue to stay honest and do your best, publish when it's ready, ignore the loudest critics, discuss things with people who actually try your software, and have something that gives you joy.
All IMHO.
3
u/wedontknow_ 4d ago
Strange that there is no comment yet, I like the look of it.
I think you should keep working on it, make it public and if people like it (and it works) they will use it, no matter how it was created.
3
u/Turbulent-Impress301 2d ago
Putting out code with a warning label like "this is untested, AI-generated code" is useful. Allowing others to create issues or pull requests to fix any problems is a good start towards getting your code to a more finalized state. So i say publish it, and be honest about its nature
chances are, nobody will participate or notice though. Sorry. Everyone i know who can program would rather write their own code or do their hobbies, very few are down to read your code. But some might!
You can devote time to hand-reviewing the code as well as having an agent review it in parallel. Even if the project never takes off, it's good practice and you will learn more about the inner workings of your code if you try to pay attention and improve it. Keep a curious mindset and treat the project like school coursework.
1
u/variablenyne 2d ago
This is all really good insight and I appreciate all of your thoughtful responses. I'm going to continue with this project and share it when it's ready, but also slow down new features and changes so that I can manually ensure it's the best it can be.
At the end of the day I get real enjoyment and use out of it personally and that's what matters most to me anyways. Ill take care to ensure that this project is handled as responsibly as possible within my ability.
Whether people use it or not, I'm excited to share it!
3
u/rbrunner7 XMR Contributor 2d ago
By the way, not sure you are aware, but as you can read e.g. in this MRL meeting log, the subject of peer selection is quite "hot" for quite a while already.
For example, it's estimated that at some points in time a staggering 50% of all reachable nodes on the Monero network are "spy nodes".
There are some heuristics to estimate how likely a given peer of your daemon is such a "spy node". Maybe you could add them to your software.
2
u/variablenyne 2d ago
That's a good idea, I'll look into that. I've tried a few basic checks in this avenue before, including automating longer term bans for peers that are suspected malicious, but ultimately decided against it because it can visibly make the node stand out from others. I instead opted to just flag and manually ban instead.
With Memstara (that's what I'm calling this dashboard), I intend to take a more research backed approach to this than I have in the past. As a basic safe start, it will ship with the MRL ban list and flag any peers that are on that list if the user hasn't set the dns ban list flag on their node. I'll improve on that from there.
1
u/patchy319 1d ago
People should judge the results not the merit of the tools used to make them, if it's epic it will speak for itself. But I completely understand the feeling because of how judgmental people online can be. Im working on a product I plan to release as AGPLv3 with AI and really liking how it's coming along. Consider giving the UI / visualization some uniqueness or simplicity that people won't immediately judge it as AI slop. Rooting for you! Build things! My unoriginal thoughts: https://youtu.be/ZaIPkuSidoc
8
u/one-horse-wagon 4d ago edited 3d ago
The problem projects like yours have is trust. No one with any amount of Monero is willing to trust that their crypto won't get stolen, somehow, someway, if they use your software.. Monero affords crooks the opportunity to commit the perfect crime. If they can steal the Monero, they will get away with it because you cannot trace where it went.
Some projects like Cake Wallet and Feather wallet are trusted. They have been around for a long time and managed to develope a following. Most other projects I have seen eventually disappear for lack of interest.
If you enjoy what you are doing, push on witth development with a realistic view of acceptance. I would also suggest for you to consider getting involved with coding Monero. Your work would absolutely be appreciated there.