beau

Given only a compiled binary and its documentation, agents must architect and implement a complete codebase that reproduces the original program's behavior.

Web: https://meta.ai/

iOS: https://apps.apple.com/us/app/meta-ai/id1558240027

Android: https://play.google.com/store/apps/details?id=com.facebook.s...

Most registrars expose people to way too much complexity. The Internet is the original social network, but no one has made it easy to use. I think there is a lot of opportunity here.

Thank you!

No, that'd be bad for business.

Shh, we are only two weeks into W22: https://instantdomains.com/

Filters are on the TODO, thanks!

Making this perfect is on the TODO, thanks!

They are sent through an affiliate link to Go Daddy. We hope to answer these queries ourselves -- soon.

Unfortunately, emoji domains are just not that well-supported at many registries: https://en.wikipedia.org/wiki/Emoji_domain

None of those sites existed when I first built this 17 years ago. WHOIS, even behind a cache, would not support our query volume. We focus on being really fast. Any specific features you'd like to see?

This should not happen for .com names (where we do a live "double check"), but can happen with others. We build our index based on zone files and DNS, so if a name is not configured, it will show as available.

That sounds like Go Daddy's annual price for .ai domains.

Hi! I'm the CEO of Instant Domain Search. I originally built it in 2005 after attending YC's first Startup School, and have maintained it as a side project since then. AMA!

Sorry, this page had a useEffect/setState render loop. We are running react@experimental with concurrent mode, and missed the error. Rolling out a fix now. Thanks!

These results are less accurate than Google Translate. But they are far faster to get, and far less expensive to generate: https://cloud.google.com/translate/pricing — our goal is here is speed. We want to search through many possibilities as quickly as possible.

The word vectors have been aligned in multiple languages. Using an approximate nearest neighbor search we are able to find the nearest vector to the input in multiple languages very quickly.

To keep the example simple, we did not try to filter the data through hand-built language dictionaries. In fact, we simply drop words in other languages that also appear in the English .vec file. Words like "ciao" appear frequently enough in otherwise English sentences that the example code drops it from Italian, and so is not shown in the results:

% curl -s "https://dl.fbaipublicfiles.com/fasttext/vectors-aligned/wiki..." | grep -n ciao 50393:ciao 0.0120 ...

One improvement would be to filter out any words that do not appear in a hand-curated dictionary instead of filtering out words that already appear in English. We decided not to show how to do this because we'd already introduced a few concepts, like aligned word vectors, approximate nearest neighbour searches, and wanted to keep the example as simple as possible.

Thank you!

We've released the underlying Rust implementation here: https://github.com/InstantDomain/instant-distance with Python bindings at https://pypi.org/project/instant-distance — feedback welcome!

I made Instant Domain Search.

Hi, I own/operate Instant Domain Search. We make plenty of money from GoDaddy and other partners by helping them find domain names.

We show results quickly because we check if your search is in the zone file. We keep a copy of the zone file in memory, and check searches against that. Some names are "unconfigured" for a variety of reasons, and do not appear in the zone file. So this means we might show a name as available, but when you go to register it, it's gone. This sometimes leads people to believe that we've registered it for ourselves. If you check the WHOIS record, you'll usually find that it's been registered for years before you searched for it.

The only major registrar that I know of that did this was Network Solutions. They did it for a few days in 2008 before getting trashed in the press:

https://arstechnica.com/uncategorized/2008/01/network-soluti...

More recently, when we show a name as available, we'll check again with VeriSign (who runs the .com registry) to make sure. And if it's not available, we'll switch the color from green to red -- a good example is eager.com. It's not in the zone, but not available to register.

This is great. Companies share these numbers with each other, good to see more visibility for employees.

Why do Apple and Google get a pass here? Who knows what apps are doing with your photos and contacts. Apple doesn't. Facebook was grilled for not aggressively shutting down an app that sold much less sensitive information.

The data in my Address Book is far more sensitive (and valuable) than the pages my friends like.

Do they mean "wall posts" or "messages"? Did Facebook ever produce an API that let any developer see private Messenger messages?

This is a good point. De-bounce, static results ordering, and static elements with placeholders help. Instant Domain Search has room to improve here.

Each request takes a second or two to complete. If you lose the connection, the client can send the same request again (with exponential back off).

Even with HTTP/2, sending a GET request is not free. Most of the benefit is that we can show the user results as they come in. Each query gets over 50 responses in random order from DNS, in-memory indexes of zone files, slower fuzzy searches over other data, and so on. Why wait to show them the .com result while .ca resolves?

Sure, but why keep state when you don't need to? Now that HTTP/2 is ubiquitous, sending new GET requests is no more expensive than sending bytes through a WebSocket.

IIRC, earlier versions of WebKit wouldn't emit data from each chunk when I sent a custom content type. Or maybe there was some conflict with gzip, I forget. Now that those browsers are gone, maybe ndjson? jsons?

You should get the iOS app: https://itunes.apple.com/us/app/instant-domain-search/id1068...

It uses the streaming API, and will work well for you.