arrsingh

How does this work? Do you have an agreement with Apple to connect to their iMessage service? If you do then kudos thats a real differentiator.

However if you're hosting your own mac mini farm and running bluebubbles or other such things that are not approved by Apple what is your plan to handle the case where you're sending enough traffic through Apple's services that they disable / ban / block you?

If its the former then awesome but if its the latter then Im not sure I'd want to depend on your service knowing that apple could ban you at any time.

What was the terminal app though and what was special about it that Ghostty didn't already provide?

edit: Found this one article (via google) that talks about the terminal. I guess it was a terminal that you could "prompt" to do things and it would figure out the shell commands.

https://thenewstack.io/developer-review-of-warp-for-windows-...

I believe soon a day will come when the agents will chat with each other to get things done. Agents running on different machines, behind firewalls, on phones, laptops, servers etc will all want to chat with each other.

So there is going to be a need for Instant Messaging for AI Agents - Launching soon. https://agent-socket.ai

I noticed that too and did roll my eyes as well but I'm glad I kept reading - its actually quite a good article. Maybe the author used an LLM to help do some copy editing but should have probably given it less editorial agency.

Either way I'm glad I read it and waiting for the other parts of the series. Really curious how to get access to this airline booking data so I can write my own bot to book my flights and deal with all the permutations and combinations to find the best deal.

Interesting to note right at the start of the article that they sat on a plane next to each other in 1953 but the formal partnership between AA and IBM was not till 1959 - 6 years later! The article makes it look like all this happened magically fast but in reality a reminder that things take time!

> is almost mythological. In 1953, C.R. Smith, president of American Airlines, was seated next to R. Blair Smith, an IBM salesman, on a cross-country flight. By the time they landed, the outline of a solution had been sketched. IBM and American Airlines entered a formal development partnership in 1959.

edit: oh and then the actual system didn't actually go live another 5 years later - in 1964. Over a decade after the two of them sat next to each other.

Reminder to myself when my potential customers don't sign the deal 5 minutes after my pitch!

I don't understand why claude code (and all CLI apps) isn't written in Rust. I started building CLI agents in Go and then moved to Typescript and finally settled on Rust and it was amazing!

I even made it into an open source runtime - https://agent-air.ai.

Maybe I'm just a backend engineer so Rust appeals to me. What am I missing?

anytime. Feel free to email me and remind - email in profile.

Love it! Bookmarked for the next time I need to sign a PDF and then will pony up the $$.

I signed up and gave the product a spin and its clear that its not some vibe coded weekend project. Clearly a lot of effort has gone into it and OP also was clear that they've spent 10 months on this.

This looks really nice! Congratulations on building something awesome, especially in a space that's "crowded" with the big players.

I want to give kudos to two things:

1. It took you 10 months to build this. This is focused product development and craftsmanship which is very different from Vibe coding something. So let this be a reminder to all the "I can vibe code this or that in a weekend". Good products / experiences take time.

2. You've pursued building something in a space that anyone would normally dismiss right away: "Why would anyone use this? Google Docs/ Word etc already does this" or "MSFT / GOOG will destroy you". Good on you for picking something that is hard and building it well. I actually had this idea and almost built it but dismissed it myself for the same reasons as above. So reminder again for the builders in the back: Doesn't matter if there is a 800lb gorilla building this, if you can execute it better go for it.

Kudos!

It’s an approach that works and I’ve thought of implementing the same thing but stopped short because I feel it just pushes the underlying problem around. Now I have to share my creds with a black box that I know very little about and it’s not a real vault.

This should be solved by the vaults (hashi corp / AWS Secrets Manager).

The one thing that I did build was based on a service that AWS provides (AWS STS) which handles temporary time bound creds out of the box.

https://timebound-iam.com

It took me a minute to recognize this as satire (thank you HN comments). However it does actually make sense - maybe this could be a way for OSS devs to get paid.

What if we did build a clean room as a service but the proceeds from that didn't go to the "Malus.sh" corporation, but to the owners / maintainers of the OSS being implemented. Maybe all OSS repos should switch to AGPL or some viral license with link to pay-me-to-implement.com. Companies that want to use that package go get their own custom implementation that is under a license strictly for that company and the OSS maintainer gets paid.

I wonder what the MVP for such a thing would look like.

Oh I didnt know about this. Very cool. Is hcker.news only on web? Or is there a mobile app as well?

There should be a "flag as AI" link in addition to "flag" and then a setting for people to show flagged as AI. Once the flagged as AI reaches a certain threshold then it disappears unless you enable "Show AI".

Maybe once enough posts have been flagged like that then that corpus could be used to train an AI to automatically detect content generated by AI.

That would be cool.

Maybe the HN site wouldn't add this feature but if someone wrote a client then maybe it could be added there.

I think the way its supposed to work is the agent (AI) will email the recipients saying "Bob is available Thursday at 8:00 AM or Tue at 9:00 AM"

Then the recipients can reply to the email thread with "Thursday works".

Not affiliated with vela - just what I understand from their site and the comments on this page.

Age Verification is very hard to do without exposing personal information (ask me how I know). I feel it should be solved by a platform company - someone like Apple (assuming we trust apple with our personal information but seems like we already do) - and the platform (ios) should be able to simply provide a boolean response to "is this person over 18" without giving away all the personal information behind the age verification.

Now the issue of which properties can "ask to verify your age" and "apple now knows what you're looking at" is still an unsolved problem, but maybe that solution can be delivered by something like a one time offline token etc.

But again, this is a very hard problem to solve and I would personally like to not have companies verify age etc.

I think item #2 in your list is the real kicker here. Given that AI can write code the threshold for "trivially replicable" is going down.

Unless your thing has strong network effects or a large capex requirement (ex: GPU infra) its easily replicated and I think that's really what makes things hard.

This is not new. When I started my first company in 2012 it was bootstrapped and getting anyone to pay attention to what I was building was almost impossible. I had to pound the pavement and meet people in person at coffee shops and pitch to get my first few users.

Then when I raised from a16z and had some money in the bank it didn't get any easier. The money didn't help (maybe it wasn't enough). Ad spend or content marketing or paid channels were all hard regardless of the free vs paid.

Maybe I just wasn't good at it.

That was before AI and you had to manually pound the bits into place.

Now with AI yes there are a lot of people shipping a lot of things but humans can tell when someone's put effort into something vs not and the time to traction is still as high as it always was.

Someone should do some analysis on number of things that go "viral" or gain adoption quickly today vs 5 / 10 years ago.

Getting traction has always been hard. Thats just business.

Maybe there should be some sort of filter for certain high volume posts types - for example: Github repos. A Github Repo (or OSS) project must have a certain number of stars / forks / watchers whatever before it will appear on Show HN.

If you can't get atleast 20 stars then its probably not ready for the wider world to see it.

I'm sure there's problems with that approach but the current situation doesn't seem to be working.

Disclaimer: I tried to do a Show HN today and it didn't make it (and to be fair I wouldn't have made it past the filter I proposed above so I guess its working).

I actually did this (around 2006) after reading this article by Joel and I was skeptical but I used excel and wrote down all the tasks that needed to be done and kept breaking it down till each task was in hours.

It took me a few hours to do and as Joel says in the article, it was not a fun thing to do (jumping right into code was more fun) but I stuck with it and did the whole thing.

Then I followed that list of tasks and kept track of when tasks started and ended and I was pleasantly surprised when after a few weeks the project was done right on schedule as predicted by the excel sheet. So my experience (data point of 1) was that it works if you do it exactly how he says to do it in the blog post.

I did it only that one time so take that for what it is.

I was in the same boat as you. I tried Fastmail and they have a really great tool that just did it. I was skeptical but after I tried it was very pleased. Give it a shot.

I moved my custom domain from google workspace to fastmail a few years ago and didn't look back. Very happy with that decision.

The only two downsides:

1. A few people have reported my emails from fastmail (calendar invites mostly) going to their spam folder. Not enough reports so I'm not worried.

2. Google won't let me sign in and create / edit /comment in google docs with my custom email hosted at fastmail so I have to have a random@gmail.com account just to use free google docs to collaborate with people who only send me google docs.

Overall I think AI features are going to be great but give me the ability to pick and choose which I enable / disable and we should be good. If not then I agree with OP - Bye Bye Gmail.

oh, and don't read my emails and protect my privacy google! - no? Ok bye bye!

I remember when I was at the CMU Robotics institute in the graduate program (Robotics / AI) in 2003 and Google came on campus and they wouldn't even consider anyone without a PhD - the campus recruiter advised me to apply when I had completed my PhD.

Glad I didn't spend another 8 years and instead took a job at AWS.

My how things have changed!

https://arrsingh.com

A few blog posts and a series of AI Tutorials from my time at CMU Robotics.

Nothing special or too sophisticated. On the one hand I use Just (a command runner) to standardize specific build and test commands that call cargo with various flags. Here is a simple example from one of my repos: https://github.com/deepmesa/deepmesa-rs/blob/mainline/justfi...

Then I have a bunch of elisp code that calls just and / or generates boilerplate code right in the buffer - M-x new-macro or M-x run-test (asks for a test to run) etc. I keep writing more elisp as I go along and add specific key bindings to specific things and now its too hard to move away from it all.

yes its rust. Looks like you're right. Well is back to good old emacs for me!

I've been using emacs for 30 years and have tried VS code several times but the muscle memory on Emacs has prevented me for switching. I've gotten LSP on emacs working well enough but the performance just isn't there. So today thanks to your suggestion I tried it once more with the Awesome Emacs Keymap extension and right away I ran into not having dired mode to switch files.

A quick google search got me vscode-dired (incase anyone else runs into it):

https://marketplace.visualstudio.com/items?itemName=rrudi.vs...

Quick Tip: I set C-x C-d, C-x C-b and C-xb all to call extension.dired.open per this stackoverflow: https://stackoverflow.com/questions/62235792/how-to-add-mult...

that seems to satisfy the muscle memory... and it seems at first glance that this time the switch to vscode might actually stick. (thanks for the link to the emacs keymap extension)

We'll see how it goes!

edit: After even 5 minutes of building some rust code I ran into too many issues! I love the syntax highlighting in VS Code and everything else but I have way too much custom elisp to build and debug Rust/Go/C++ and recreating all that in VSCode or learning the new bindings is a bridge too far! I would pay real money to someone who would build an amazing performant experience for emacs. Sigh.

I'm the founder at Distelli and I just want to add a quick bit of background around the original python decision (2.6 vs 2.4) as well as the decision to "rewrite in Lua".

1. I started the company as a single founder and wrote the first version of the agent. See this HN post that gave me the encouragement to keep going (thanks HN!) - https://news.ycombinator.com/item?id=6059481.

2. I wrote the original agent in python 2.6. It was great because I could use things like python-requests (which was awesome!). However my first encounter with an enterprise customer showed me that was not feasible because they were running only python 2.4 and would not be upgrading for another 2 years.

3. I had the choice of either not getting the customer or back porting the code to Python 2.4. I chose to back port the code to python 2.4 and get the customer. This was a lot of work but worth it because I was able to then raise a round with a16z. - https://www.distelli.com/blog/distelli-series-a-funding

4. When Brian joined Distelli, he actually worked on the Python code for many months and made many improvements and added many features. When it was time to add the streaming logs feature he built the prototype in Lua just to prove that the idea would work and then we talked extensively to figure the direction we should go in.

5. We decided to move to Lua because Brian was very familiar with it and it was a lightweight language and we could ship a single download with zero dependencies. We also looked at using Go. At the end of the day the decision was Brian's to make and own as the senior engineer on the project. The passage of time has convinced me that was the right decision.

I'm sure we could have stayed with Python with all the suggestions on this page, but we decided to go with Lua. It was a good fit for what we needed and honestly I felt that my original code was not in great shape and would need a lot of work to refactor and a rewrite felt like the right decision at the time. Looking back I still think it was the right decision and I'm very happy with the end result.

edit: grammar

> But in pursuit of this, don’t loose sight of your goal

I don't know why, but every time someone writes "loose" when they mean "lose" really bothers me. I need to work on that!

EDIT: Quote the relevant line from the post