Hi guys, I developed a tool to check and find domain names and have been using it for some time. Now, I put them into an application (for MacOS at the moment).
This Domain Tool can help you:
- Find one-word names (support English, Spanish, Dutch, and French)
- Bulk check those names with the flexible option with extensions
Available for MacOS, Windows and Linux
Why a desktop app? I used some name suggestion web app and someday, they just went offline or disappear.
Hope you find it useful. Feedback and question are welcome
Before anyone makes another comment about how and why this should be a webapp….
The author has answered and stated multiple time here that the reason he made this a local app is because if the website that the tool is hosted on is down or gone, then you are dead out of water.
That’s why he made a local tool.
And no, the tool does not still rely on some application/webserver. He has stated that it only requires reaching out to the Whois servers.
note I used “he” but probably should have used “they” as I have no idea on the gender identification of the author. What is the proper way to just use “the author” in place of he/she/they?
I think indigodaddy's comment is necessary since people keep asking why a desktop app.
For the people who don't looking for domain names at least once/twice a week, you won't need this app. I try to build it for people who like to look for available domains
(indigodaddy) Thanks and you're on point. Just to clarify, there are some features that can't run as JS on the client-side. ElectronJS allows using NodeJS code as well.
No need to make a separate comment thread about other the results of other threads. If the other threads have been truly resolved then there are already comment chains to read. On the other hand if they were not actually resolved then all of the discussion is now split and duplicated.
Regarding availability what exactly about making a web app restricts you from offering a downloadable copy?
Regardless it looks like a web version is now on the roadmap according to the site.
Sure, nothing is stopping the author from making a web app, and that would actually be fine and most people would use that, and it would probably be the best path and focus. I’m not discounting that.
I was just attempting to summarize the author’s reasoning for making a nonweb/local application. And in all honesty the author can and should do what the author wants and what they feel is best.
There just seemed to be unwarranted and frankly odd “outrage” about it in a lot of comments.
Creator can certainly create whatever they want but clearly target audience feedback on a paid product is valuable in steering the future direction of a product as is seen with the future goals so no need to discount it as unwarranted or paint it as unhelpful.
I didn’t realize it was a paid product, and I’d bet that most of the “complainants” didn’t know either, or weren’t framing it from that perspective in any case.
Furthermore, now that it’s being framed as a paid product for this discussion, in my view, I believe they will be more successful in sales of a paid “piece of software” vs a webapp/SaaS/monthly model.
Likely this was part of their reasoning of going down this path if I had to guess.
> I didn’t realize it was a paid product, and I’d bet that most of the “complainants” didn’t know either, or weren’t framing it from that perspective in any case.
No need to place or assume blame on the other commentors for not telling you about what was in the page.
> Furthermore, now that it’s being framed as a paid product for this discussion, in my view, I believe they will be more successful in sales of a paid “piece of software” vs a webapp/SaaS/monthly model.
This seems like another thing you are forcing onto "what a webapp must be". Nowhere in making a webapp is it required to use a subscription model.
Another way to think about it is since it's not using desktop integration specific functionality it's already an offline copy of the webapp right now as is with Electron. The app is just effectively browser restricted to that Electron version. Removing that restriction does not relate to changing the offline static site delivery model nor a change in the payment model.
> Likely this was part of their reasoning of going down this path if I had to guess.
No need to keep guessing. As you said the author has already responded to the comments. As I said the page already promises an upcoming web version. There is no need for theoreticals.
An alternative for researching domain names is to apply for TLD zone file access. "Trying to find a one word domain name," is unlikely to be an acceptable reason for access, though.
I applied (and received access on my second attempt) about a decade ago for .com access. Among other things, I ran a check for any words in my spellcheck dictionary that were not already taken as .com domains. There is a reason for all the silly spellings in domain names today; I don't recall the first words that were available, but they were not short nor desirable for a domain name. There were also no 3 alphanumeric ascii character domain names left, at the time.
I applied through Verisign. But, they are currently directing folks to apply via ICAN directly.
Note that DNS zone files don't include all registered domains, only ones that have DNS records. Depending on domain extension, a significant number of desirable short words are registered but not in the zone file, or held by the registry for a higher price. Also, you can't get complete zone files for ccTLDs.
This is part of the reason why domain search is often slow even on popular sites like GoDaddy or Namecheap. They want to give you very accurate results, which takes longer.
Source: I'm fighting this accuracy problem all the time for the search at https://domain.garden
> no 3 alphanumeric ascii character domain names left, at the time.
I went looking for a personal domain probably about 7 years back and wanted something short... it was disheartening to see the percentage of short domains that were just being squatted, and blatantly so. One guy even made his living off of brokering 1 letter domains. Eventually I found my first+last initials on a 2 letter tld that somehow hadn't been completely bought up (1 letter domains were long gone though) and have used that ever since with email reminders and calendar reminders everywhere so I never forget to renew!
Does it include WHOIS info? If so I bet it's impossible to get access.
Can you tell me if the info has registration dates? I have a use case where I'd love to do some bulk analysis related to domain squatting, but I've never been able to find a decent way I can make bulk queries against all the services I'd want to check.
That’s interesting. What type of reasons are typically accepted for getting access? I’m assuming if you are attempting to commercialize a domain website or project they may give you access?
I do not know what their criteria for acceptance are. My first, rejected, request discussed looking into distribution of available domains. My second, accepted, request was more carefully worded to indicate it was for general research.
The purpose of my request was for a personal research project to satisfy curiosity. My initial motivation was that there were things that seemed to be true about the distribution of available .com domains, and I wanted to see what the reality was. And, using NS queries would not scale.
I looked for the shortest English dictionary words available, percentage of various length domain names still available (alpha only and alphanumeric; with single numeral, two numeral digits, etc.), for non-words I looked at the distance from the closest English dictionary word, collected the patterns of common permutations of dictionary words into domain names, I monitored change rate, etc.
I've never "used" the information learned except to be able to speak with a little more authority in a single conversation where the subject matter came up. But, it was interesting to me :)
Not trying to hate on you, genuinely curious why you chose this route. Sometimes using the tools you are most comfortable with at the time is the path to the highest short term productivity.
If you mean why I choose ElectronJS: I wanted it be cross-platform, and ElectronJS was the easiest (partly because I already built and been using the main feature).
If you mean why a desktop app: I've been using some web-based tools. Somehow, they don't last (ie. namemesh, or domainsfortherestofus that @pwdisswordfish8 mention went offline for sometimes).
Then I thought having a desktop app would be great. For long term, you don't have to worry the site is down.
If it’s javascript-only, then surely it could run in the client and be hosted for free on github pages as a static site and not have to worry about going down.
You mean if the site is hosted on GH Pages or something? And in this scenario, the site hosted by GitHub goes down, so then I go to GitHub (which is down remember) and download the site, and use it locally, is that what you’re saying?
Yes, hosted on github pages. That’s what I said in my comment: hosted for free on github pages as a static site.
If GH pages goes down, you wait for it to come back. The point is that GH pages won’t disappear because of passage of time (ie you forget to pay hosting bill or something). It doesn’t guarantee 100% uptime but it doesn’t have to. The desktop download doesn’t guarantee 100% availability either.
If the tool is that critical to your workflow, you save it offline or host it on a redundant location (there are many free static site hosting services available: cloudflare worker sites, digitalocean apps, S3 — take your pick, maybe one has the uptime guarantees you desire, GH was just an example. Or host it in multiple)
So basically use the local application while you wait for GH pages to come back. Gotcha. 99% of people aren’t going to be downloading some GH pages site in case the site goes down….
Unimportant but it is a bit misleading coming from a Linux browser to only see Download for Windows & Mac call-to-actions. I thought it was incompatible before I saw the top right penguin. You might wanna use the User-Agent to show a more relevant CTA.
If you mean the website: I've been doing web development for sometimes and comfortable working with it. But most of the time, I find the inspiration from somewhere (by the way, I published the template here https://inverr.com/app-store/E1Yh4VtOL)
If you mean about the app: I use BlueprintJS, blueprintjs.com (similar to Bootstrap, pretty simple to use)
Mental note (after reading tons of Show HN), if I ever release an Electron app, the submission title must be preemptive and include the phrase "I don't care about your whines, if you want a native app you're free to start writing it right now, meanwhile this exists at all thanks to Electron, not despite of it" suffix!
This is cool. Never seen the local application take before. I'd be interested to know how people respond to having a dedicated app and if they enjoy that UX more than a website.
In a similar vein, but more focused around finding similar sounding names or creating a mashup of two words is Mashword (https://mashword.com). We're working on improving performance and reducing noise in the result set, but if you are patient, then even in its current incarnation, it produces some novel results.
Congrats on shipping and thanks for sharing with us! I'm going to try it, as recently the good old "impossibility dot org" (don't try that, it's NSFW now) went offline.
After a few tests it looks good but it reports some domains as registered when they are not (for instance kostikaable.com or kostikaition.io are marked registered but do not seem to exist when I manually run a Whois). Maybe the tool is running onto some rate limiting thresholds?
Also when there are a lot of domains to check you could check them in parallel, otherwise it gets quite slow to wait for the results (but that might be an inherent limitation of the Whois servers).
OP's project is literally the reverse of taking a traditional desktop software, e.g. a graphic editor, and making it into a web app. Here, it's something that naturally belongs to a web site, but instead packed up into an installable desktop app.
I'd be really curious to see the rationale behind this.
I've been using some web-based tools. Somehow, they don't last (ie. namemesh, or domainsfortherestofus that @pwdisswordfish8 mention went offline for sometimes).
Then I thought having a desktop app would be great. For the long term, I don't have to worry the site is down.
This still 100% relies on their servers being up, which is no different than a website. So you absolutely still have to worry about their servers being down, which makes it pointless.
Exactly. The author appears to be telling you (you being jaywalk) that the application only requires talking out to Whois servers, and does not rely on any application/webserver…
To me the ultimate key to avoiding superfluous comments like the ones you refer to, and resulting ones like yours, would be to add a tag into the subject line when presenting Software, like [Electron]. That would also be helpful for other categories, like [subscription], [ClosedSource], etc..
It looks interesting and I really do like this. But in a world of ransomware, I am not going to install any software on my machine just because it looks interesting.
I know I am echoing half of the other comments here, but this does really need to be a webapp.
I like the idea, and would use the service, as the domain is short and memorable. But, this is a low hanging fruit for HN critics, the argument of: "is an app so I dont have to worry about a website being down" is pretty poor, you can host your website assets on Netlify/aws amplify/firebase/.... many more.... , with close to 99.99 % availability. And also provide an electron app for those who prefer to use an app. I wish you luck, and I hope we get a site, I like your service.
Yes, it is for people love checking out for domains. I do it quite often myself. The price was one-time and I'll let people who purchased it judge.
The main feature is to generate one-word or short domain names with different recipes, and help you find the available ones. Domain providers don't have the name generator feature.
Yes I understand that, and think your approach makes a lot of sense. I was just trying to counter the "why native app" argument here - people looking for a power-user tool likely appreciate a more persistent app compared to a website.
- How do we know the search results are not hijacked/registered ?
- How do we know the queries are not sold as a database ?
- How do we know if and/or what third parties are involved ?
- Which jurisdiction are we talking about? ( Does GDPR apply? )
That's a valid concern. I (the desktop app) don't track, collect your data or activities when using the desktop app.
When using the desktop app, there are 3 situations the app communicate with online servers:
1. For WHOIS queries, the app communicates directly to the WHOIS servers, no middleman
2. For payment using Paypal's smart button. They might collect some data for fraud detection.
3. When checking for updates or form submissions. The app will send the only necessary information to our server. For updates, we need "platform" (i.e win32, darwin, etc.) and "version" (the current Domain Tool version, i.e "0.0.21"). For contact form submissions, we need "email", "message", and the "type" of form submission
Note that when submit a contact form, the server don't collect your IP. But as the nature of request, the server can read your IP.
Is this another electron app? Why? This is 100% doable in the browser and has been done before with other sites. Why do I need to spend 300MiB of ram to search for domain names?
Sorry to sound negative, it's just... the electron fad is getting really old.
Why not browser? As mention in the other comment, I've been using some web-based tools. Somehow, they don't last (ie. namemesh, or domainsfortherestofus that @pwdisswordfish8 mention went offline for sometimes).
Then I thought having a desktop app would be great. For long term, you don't have to worry the site is down.
I have no idea how people aren’t getting this. People, if the website that the tool is hosted on is down or gone, then you are dead out of water. That’s why he made a local tool. Get it?
The code can't run with only client JS. It needs a backend. ElectronJS allows running NodeJS as backend.
I tried React Native (only support JS on the client-side, need to build native modules to run some core functions for languages), Flutter (a few missing utilities, not so familiar).
I have answer why a desktop app in other comments so I won't repeat. Electron is the best fit in this situation.
I could be wrong but just firing up a modern web browser is going to use more ram than that. Theoretically if you shut down the browser and opened the app you would be using less ram? Personably would not be worried about ram on a modern device and electron apps run on most OS’s so a good choice overall.
No, you're simply not the target market, which is the reason why your criticism is discounted. The target market appears to be people who want an app that will still work if OP decides at some point he no longer wants to build/operate the service. They can still fire up the electron app. It's a valid choice that you needn't agree with.
but I'm not downloading an application just for a simple use case that a website could take care of.
(Otherwise I'd have a bunch of unnecessary apps I use rarely or not at all after the first one or few times. This is what happened with phone apps-- the phone app market got saturated and people rapidly stopped caring about phone apps).
Instead, I'd add your "Look up <some value proposition> domain name" website's link to a document I have on resources for marketing-- a document that includes links to business name generators.
But an app? Nah. That's overkill: Your app does not need access to my computer. I'll find an alternative (hosted online) and use it instead.
Not everyone is aware of things like https://www.w3.org/TR/offline-webapps/. Also, if you haven't downloaded the source, some hosted git server somewhere else doesn't help.
Ooooh, very nice. A welcome addition to my anti-personnel vocabularly. Let me put it right next to the tittle and somewhat more pedestrian compartmentalization.
The point is not that "backslash" sounds unrefined. "Backslash" is fine when you're referring to a backslash (reverse solidus). What's not fine is saying backslash when you are in fact referring to a plain ol' slash (solidus), as in URLs.
People who refer to domain "extensions" share something in common with people who misapply the term "backslash". Nerdy enough to have heard of (file name) "extensions" and "backslashes", not nerdy enough to care whether the term is actually appropriate for what they're trying to refer to in the present. TLDs are not "extensions".
The occasional domain registrar that refers to them this way in marketing copy make me wince the hardest. They don't have the excuse of co-opting technically incorrect but extremely popular misnomers. It's more like, if anything, they're most likely to be the cause of people using the wrong term, if ever it were to become a trend.
I share your sentiments entirely. I would like to unhelpfully add that some TLDs, like .com, .org, and even .rs are also file extensions (at least when considered as strings).
This Domain Tool can help you:
- Find one-word names (support English, Spanish, Dutch, and French)
- Bulk check those names with the flexible option with extensions
Available for MacOS, Windows and Linux
Why a desktop app? I used some name suggestion web app and someday, they just went offline or disappear.
Hope you find it useful. Feedback and question are welcome