Quien – A better WHOIS lookup tool
github.com

・

100 points

・

bretthopper

・

3 days ago

45 comments

notepad0x90 ・ 3 days ago

Nice to see first-class RDAP support.

Feature Request: BGP route lookup using looking glasses of your choice, and Peeringdb lookup for the ASN. https://www.peeringdb.com/apidocs/

  • retlehs ・ 3 days ago

    Thanks for the request! Shipped both in https://github.com/retlehs/quien/pull/4

    • indigodaddy ・ 3 days ago

      Another feature request. Why not have a nice webui interface to this? Obviously could just vibecode something on top of what you did but putting it out there that that would be cool

      • retlehs ・ 3 days ago
        ・ 6 more

        The goal was a fast terminal tool, and I'm not ruling it out, but considering how hard it would be to compete in the SERPs with other whois sites, I don't think I'd spend the time on it right now

        • indigodaddy ・ 2 days ago
          ・ 5 more

          Why would you care about competing with other whois sites? I don't think it's going to be a money making venture in any case, and you could easily host it for free on fly.io

          • retlehs ・ 2 days ago
            ・ 4 more

            This was really just a personal tool I built because I got tired of parsing default whois output. Don’t have the bandwidth for a web UI right now, maybe down the road.

            It’s not about making money. It’s more that there’s no real way for people to discover it by competing for visibility on whois-related searches against established sites.

faangguyindia ・ 2 days ago

Thanks for this, it's very useful to me :)

gigatexal ・ 3 days ago

Everyone asking was this vibe coded should calm down. Instead we should just have automated ways to audit the code to see if it’s secure, see if it’s going to steal our keys, etc.

If it provides value who cares?

I mean we could read the code to see if it does anything nefarious. Or have a bought do a check or checks.

But asking every time there’s a show HN is it vibe coded is such gatekeeping elitest nonsense it makes me angry.

  • mapontosevenths ・ 3 days ago

    You are trying to rationalize with people who hold irrational beliefs. It won't work because their objections aren't based on reason.

    It's ok for people to just hate things. I hate spinach for example. Listing all the reasons that my distaste for spinach is irrational won't change that.

    Similarly, explaining to the new amish that AI with TDD writess better code than most of the devs I know isn't going to get you anywhere. They don't really care about code quality at all. It's a religious or political belief.

    • d0liver ・ 3 days ago

      Someone saying they vibe coded a thing is like them saying they were hammered when they wrote it. Maybe they did a great job, but probably not; it's definitely cause for concern.

    • nozzlegear ・ 2 days ago

      Frankly, your screed comes off just as ridiculous as the people you're attempting to paint as "the new amish." Those people have valid concerns, which you disregard as irrational because your own irrational, religious/political beliefs don't allow you to consider them.

      • mapontosevenths ・ 2 days ago
        ・ 3 more

        If the concerns were valid they would mention them. They don't.

        Instead they pop up in every single thread to complain endlessly about anything that wasn't written using only their preferred tools. They never talk about actual issues with the code. Just the tooling used.

        It adds nothing to the conversation, and frankly is boring now.

        If you see a problem with the code say that. If the problem is that the author used vim and you prefer emacs, or they used AI and you prefer copy/pasting from stack overflow just go stick your head in a bucket and scream as loud as you like. You'll influence exactly as many people and the only headache you cause will be your own.

        • nozzlegear ・ 2 days ago
          ・ 2 more

          Concerns have been mentioned, in this very thread that you were already replying to. One concern that I share with another user upthread is that vibecoded projects tend to be dumped out into the public and then abandoned, because the effort to produce them is practically zero – there's no investment, the "maintainer" has already moved on to the next ten shiny things.

          https://news.ycombinator.com/item?id=47729572

          > It adds nothing to the conversation, and frankly is boring now.

          It seems to me the boring conversation could've been avoided if the project included a disclaimer that it was vibecoded. I suspect you'll continue to be bored by such trite conversations until that becomes commonplace.

          > If you see a problem with the code say that.

          Nobody is going to read the code, especially if it's shat out by an overly verbose LLM. @exorcist had a better take on this:

          > Perhaps this is a matter of different perspectives? Every tool I use is an investment for me, it might be light if I only use it once, it might be heavy if I use it for years. That investment is all the time I take to learn the various concepts involved and how to think about problems to fit the tool. But it is also all the time needed to constantly keep in mind if that tool is affected by the latest security vulnerability, how changing trends in the industry affects my use of the tool, and what to do if the tool becomes abandonware.

          > Reading code is hard. Writing can sometimes even be faster than reading, especially when there are many unknowns involved. So saying "you can just read it" doesn't really work for me. There's no "just" in reading. Taking in new tools is an investment, a burden, and I am perfectly entitled to avoid tools where that burden is harder than the expected outcome. It's impossible to know for sure, of course, but you can often guess pretty good very early.

          https://news.ycombinator.com/item?id=47729329

  • mathfailure ・ 3 days ago

    I do. I care. And there are dozens of us.

    Lots of infected programs provide value. It has nothing to do with being or not being infected.

    If a project was vibecoded in a weekend - there are less chances that it will still be maintained in a, say, year or two.

    • mvdwoord ・ 3 days ago

      But if it is open source you could maintain it? It could be "done" for a given state of affairs (protocol/API versions etc)?

      • Leomuck ・ 3 days ago

        Of course you could, but if it was indeed vibe-coded in a weekend, why wouldn't you want to start from scratch to make sure everything is up to your standards (especially security)?

        I'm definitely not going to jump in on a vibe-coded project. I'd much rather start from scratch if I found the use-case to be relevant.

        Not to say vibe-coded projects can't be alright. If the engineer behind it knows their stuff, it's fine to me. But we don't know that. So to get a general idea, I think it's fair to ask how this was done.

      • imcritic ・ 3 days ago

        Such action has non-zero cost/effort. Do I really want to pay it? I am not sure.

    • synotna ・ 3 days ago

      Don't give programs unnecessary access - problem solved

      • d0liver ・ 3 days ago

        Unnecessary access isn't a solveable problem. In order to restrict permissions to exactly what a program needs, in general, you'd have to define exactly what a program does. In other words, you'd need to rewrite the program with self-enforcing access restrictions.

        So, permissions are always going to be more general than what a program actually needs and, therefore, exploitable.

        Producing incorrect information is an insidious example of this. We can't simply restrict the program's permissions so that it only yields correct outputs -- we'd need to understand the outputs themselves to make that work. But, then, we're in a situation where we're basing our choices on potentially incorrect and unverified outputs from the program.

      • imcritic ・ 3 days ago

        That's a good advice in general to treat any software as untrusted black box as much as possible. But it raises (slightly, but still does) the cost/effort for the user: the user now has to make extra steps and take extra caution.

        These concerns were great valid even before vibecoding becoming a thing, but now the estimated probabilities of malicious code's presence have changed, simply because nowadays the cost/effort of writing software plummeted.

  • CaptainFever ・ 3 days ago

    There's probably value in a web extension that uses a small embedded LLM to filter out comments that complain about literally any AI that's used in the submission.

    To make it really funny, that extension should be vibe coded.

    Seriously though, it should just be against HN guidelines. It's annoying to see that 90% of the comments are just people fighting over vibe coding on a completely unrelated topic. On this submission? There's only 1 (one) on-topic comment.

  • mannanj ・ 2 days ago

    I think you're right, onto something. The responsibility is on vibe coders to do that work though, not the audience they are sharing it with. If you share something insecure and sloppily put together, its your duty to make it right and not deceive people about the nature of it.

johng ・ 3 days ago

Looks well done, nice looking TUI. Does not specify if it's vibe coded or not, which I think should be normal practice now ;(

  • davidodio ・ 3 days ago

    why would it be normal? the code is there for you to look at and use or not. It is open-source, licensed as open source and is very clear about that. Why would you feel that the author(s) should need to specify anything else at all to satisfy your curiosity?

    • xorcist ・ 3 days ago

      > the code is there for you to look at and use or not

      Perhaps this is a matter of different perspectives? Every tool I use is an investment for me, it might be light if I only use it once, it might be heavy if I use it for years. That investment is all the time I take to learn the various concepts involved and how to think about problems to fit the tool. But it is also all the time needed to constantly keep in mind if that tool is affected by the latest security vulnerability, how changing trends in the industry affects my use of the tool, and what to do if the tool becomes abandonware.

      Reading code is hard. Writing can sometimes even be faster than reading, especially when there are many unknowns involved. So saying "you can just read it" doesn't really work for me. There's no "just" in reading. Taking in new tools is an investment, a burden, and I am perfectly entitled to avoid tools where that burden is harder than the expected outcome. It's impossible to know for sure, of course, but you can often guess pretty good very early.

    • ssl-3 ・ 3 days ago

      There's a Kroger grocery store near my house. It's very convenient -- I'm near it almost every day I'm alive. They have all kinds of things there, including factory-made bread and factory-made eggs.

      There's also a tiny little Amish bakery that I know of. They make all kinds of things there, but the most interesting to me are the loaves of plain white bread that they bake every day (except Sunday) in their wood-fired oven. It is not near to me and is also off the beaten path a good bit, but I try to make a point to go there when I'm in the area. I usually just get a loaf of that plain white bread along with a dozen eggs from the chickens that they have roaming around outside eating bugs.

      I wouldn't call any aspect of it artisanal or anything like that, but it's definitely not made by machines.

      And for reasons I can't really rationalize or explain, I enjoy having things from the Amish bakery in my kitchen more than I do the superficially similar things that I get from Kroger.

      And yet: I usually eat the factory stuff from Kroger. On a strictly functional basis it's about the same to me.

      ---

      Anyway: Software. Did a bot write it? Did a person? Was it a combined effort? Does it even matter?

      I can accept that folks might prefer to have software in their library that is written by people. My acceptance of this does not require them to rationalize their preference, or for me to agree with it or even understand it.

      It's fine when someone cares about that kind of thing. And it's fine if they don't care, too.

      We're allowed to like what we like. It's good to have options, and it's OK to prefer one way over another.

      • davidodio ・ 3 days ago
        ・ 2 more

        > Does not specify if it's vibe coded or not, which I think should be normal practice now

        I am trying to say that when people freely share software with the world, I do not think you are entitled to try to add conditions. People are free to share whatever they like, in the conditions they like - in this case the MIT license. Everybody else is free to take the code AS IS.

        There is a difference between a commercial transaction and software which is shared without any expectations in return. With software shared without any expectations in return. I don’t believe that we should be trying to create normal practices on top of existing licences or trying to specify under what conditions somebody can share something

        > It's fine when someone cares about that kind of thing. And it's fine if they don't care, too. > We're allowed to like what we like. It's good to have options, and it's OK to prefer one way over another.

        I agree and never said anything different, but if somebody wants to share under different conditions, then their conditions will always trump yours

        • ssl-3 ・ 3 days ago

          Perhaps.

          If it's free (libre) software, then it is shared freely. Others are free to take and use it. They can also change it; they don't have to accept it as it is. The existing code can be molded to be something different, or the ideas copied and used in some new implementation.

          We're free to hype it up and become huge supporters. We're free to be critical and dismissive of of it. We're free talk about these things.

          We're even free to leave the software where it is and walk away from it while bitching and moaning the entire time we do so.

          People aren't beholden to the author, and the author isn't beholden to the end-user. We're all mutually free of those kinds of chains.

          > Does not specify if it's vibe coded or not, which I think should be normal practice now

          That's just a preferential statement wrapped up in a critical package. It could be stated with a greater abundance of tact, but it's no better nor worse than stating "Doesn't have a GPL-compatible license, which I think should be normal practice now".

          (We're free to act tactlessly.)

      • charcircuit ・ 3 days ago
        ・ 2 more

        Kroger has bakeries within their stores where they bake bread they sell.

        • ssl-3 ・ 3 days ago

          They do.

          But the things from that bakery are made as the product of a soulless megacorp. The process may occur in-store, but it is prescribed from on-high, not invented or tweaked locally. And bread from the Kroger bakery costs more to buy than bread from this Amish bakery does.

          So for those reasons, and some others that I could probably never properly articulate, having bread from the Kroger bakery in my kitchen does not enhance my joy. It instead diminishes it.

          Personal preferences can be weird. In this instance, I prefer to actively avoid things from the Kroger bakery.

    • darqis ・ 3 days ago

      because it matters. Why would you intentionally choose to ignore that fact if it was provided?

      I have been using LLMs since August last year, and I know the output they can produce. And I know that the initial output requires refinement in most cases. And that's coming from someone experienced in Software development. LLMs in the hands of people who are not experienced lead to skip a proper review process.

      Additionally, it's unreasonable to assume one can take a large codebase and will spend hours on examining the code before. It's not only unreasonable but downright ridiculous.

      LLMs are a part of reality right now and they're not going away. Code should be labeled as such. Not doing that is inconsiderate.

      • kube-system ・ 3 days ago

        Should we label code written by humans who don’t know what they’re doing?

        > it's unreasonable to assume one can take a large codebase and will spend hours on examining the code before.

        This seems to be an issue with your security posture that exists regardless of how the software was written. Do you think malicious or broken software was invented with the advent of LLMs?

        People and organizations serious about security absolutely do evaluate unknown software before use. You don’t have to read the code, there are many other ways to evaluate software depending on your risk profile.

  • JimDabell ・ 3 days ago

    Not every conversation has to be a conversation about AI.

  • unsnap_biceps ・ 3 days ago

    it ships with a SKILL.md file, so if they're trying to enable AI to use it, it's a good bet that they used AI to build it.

  • Zetaphor ・ 3 days ago

    If the tool meets your needs, does that matter? Were you planning to make a meaningful contribution to the source? My assumption is that the vast majority of the people making these comments would have never even bothered to read the code, nevermind contribute to it.

    To put it another way, if you're enjoying eating sausages then what difference does it make how they're assembled?

    • multjoy ・ 3 days ago

      If I'm eating a sausage, I like to be certain that no asbestos was used in its production.

      • janderland ・ 3 days ago
        ・ 4 more

        This is a ridiculous analogy. Test the app. Read its source code. Developers could always write toxic instruction in your tools. AI may write inefficient or messy code, but it’s far from nefarious. “Asbestos” code is written intentionally by humans, not unintentionally AI.

        • tgv ・ 3 days ago
          ・ 3 more

          That's a good way to guarantee nobody will use it. Who is going to test the app in a sandbox with godknowswhat kind of tooling needed to find malicious behavior and read the code? For a tool that's convenient once per decade?

          • kube-system ・ 3 days ago

            At no point ever in history could you guarantee that third party code downloaded from the internet was not malicious without some sort of security review.

            Software security assessments exist for this very purpose. You may personally lack the rigor to do this at home but those who have rigorous security processes absolutely do implement security reviews.

            There is a whole industry of professionals who do this work.

          • Zetaphor ・ 3 days ago

            Nobody, and that's my point. 99% of people going to install the tool and never bother with the source. This was true before AI and is still true now.