DerJacques

This is really cool! What a neat little exploration.

I didn’t know about the history of the iOS keyboard, and this was a great insight.

I agree that some parts of the process now seem more like “open”, but there is definitely a lot more magic in the new processing. Namely, threads can have an arbitrary length, and OpenAI automatically handles context window management for you. Their API now also handles retrieval of information from raw files, so you don’t need to worry about embeddings.

Lastly, you don’t even need any sort of database to keep track of threads and messages. The API is now stateful!

I think that most of these changes are exciting and make it a lot easier for people to get started. There is no doubt in my mind though that the API is now an even bigger blackbox, and lock-in is slightly increased depending on how you integrate with it.

Awesome! Thanks a lot for the feedback. Syntax highlighting sounds like a great idea, and I wouldn’t expect it to be a big performance hit.

Exposing more API options (such as temperature) is definitely on the list! I just added custom function support (running small JS scripts, Wolfram Alpha and Shell commands), and more options is next!

Oh no, sorry to hear that. If you could send it to manuel<at>manuelt.de, that would be lovely! Thanks.

That sounds like a bad time! Glad you were able to resolve it at the end.

I do feel that being in the App Store can give a lot of value (and downloads), but it definitely comes at a cost (mainly uncertainty).

Looks super clean! Great work. The idea of always having the Chat GPT a shortcut away is very neat.

I have a similar toy-app called Chitty (https://chitty-app.com), and recently decided to pull it from the App Store and offer direct downloads instead, because Apple kept throwing wrenches my way. Most notably, in a random app update review I was told that I could no longer reference ChatGPT or OpenAI, and I was not allowed users to "unlock" functionality by letting them provide their OpenAI API key. Note that I don't monitize the app in any way, so asking people to enter their OpenAI key is the only way to make the app work without causing a major bill for me.

It seems like your app get's around the API key issue by offering in-app purchases, which is good! I would recommend also making sure not to reference ChatGPT and OpenAI too much in the app or the App Store page, though the details may depend on the specific app reviewer you're assigned :)

I built https://chitty-app.com/, which is a free client for MacOS (available via the App Store). It supports GPT-3.5 and GPT-4 in a simple iMessage-like UI.

Chitty also allows you to create custom assistants. It comes pre-loaded with Abraham Lincoln, Alan Turing, Jane Austen, etc., but you it's easy to add your own. I added myself as a custom assistant, which allows for ultimate rubber ducking :D

The app supports streaming responses and markdown (incl. multi-line code blocks).

Haha, I try to not be too serious about it all. Lots of stuff happening in this space. I went back and forth on the name quite a bit, and in the end I opted for this tongue-in-cheek but short and potentially memorable name.

This is my first ever SwiftUI app, and I had a lot of fun building it. I'm usually a web-person, but Electron just didn't feel right for this particular use case. Because I'm using the latest version of SwiftUI, I had to require MacOS 13.1, a fairly recent version of the OS.

I also considered ways to not require users to enter their own OpenAI API key. For friends and family I would be happy to just bake my own key into the app (or proxy calls through my own API), but I don't see how that would be feasible on a larger scale, while remaining free.

I'm here to answer comments, in case someone has questions!

This looks great! Congratulations. I particularly like the "shortcuts" to common actions like "Insert JS/CSS". That's very useful!

I want to also give a shoutout to https://proxyman.io/. Proxyman is a native Mac App that also works as a local proxy and is a pleasure to use. I've been using it for similar workflows and can highly recommend it over Charles (the SSL handling alone is 100x simpler).

Have you looked into Cypress (https://www.cypress.io/)? If I understand you correctly, it may actually do what you are describing here.

It's actually a nice feature that has been available on Airpods Pro as well. The feature makes it feel like the sound is actually coming out of the iPhone / iPad / etc. When you turn your head, the sound source stays the same.

Note that the Airpods don't actually know where your device is located. It simply sets a "base orientation" when the sound is started. This base orientation is updated when you keep your head in a new position for a longer time ("resetting" the approximated position of your device).

Could it be that you were using type-aware linting rules? If you have these rules enabled, ESLint basically has to compile all your TS files to check if the rules are followed. Note that most of the ESLint rules are _not_ type aware, but following the setup guides quickly has you turning them on “by accident”. For more details, see: https://github.com/typescript-eslint/typescript-eslint/blob/...

Interesting. Wouldn’t that allow someone to sign up for service Y with an email address associated with an account in your system using service X, in order to get access to the account in your system?

Maybe there’s something I’m not seeing, but it seems dangerous to rely on the identity provider’s email address to authenticate the user.

When the Courier concept was first shown, I almost couldn't contain my excitement.

Now, ten years later, it feels like most challenges the Courier (and now the Surface Neo) tried to solve have been solved by bigger screens, better multitasking and great pencil support.

New note taking and productivity apps benefit from the big screen and fluid resizing of apps that the iPad Pro and similar tablets provide.

The separation in the middle that made the courier look awesome ten years ago, now feels like an unnecessary hardware separation between the two sides of the display.

By "they" you refer to the oil companies? Sure, they will go wherever there's oil to be found.

It's the Norwegian politicians/people that I praise.

I can't help but being impressed by Norway and the decisions they have made in regards to their oil.

It would be very easy for the country to rely on their oil only, and forget about everything else. But instead, they realise the importance of renewable energy and try to build a sustainable future.

While the promise sounds great, it's important to note that no law has actually been passed.

Also, incentives to increase sales of electric vehicles are yet to be announced.

Denmark's Scandinavian neighbour Norway is on the other side of the spectrum. Heavy subsidisation has caused every 2nd (!) car sold to be electric (https://www.reuters.com/article/us-environment-norway-autos/...).

I agree that Live Share sounds like the perfect solution. You can even share ports, so your friend can access your development server.

You can do that, but the visitor's scroll position would be reset, when the modal is closed.

My understanding is that the EU PSD2 regulation indeed is supposed to make banks adhere to a standardised API. That being said, I wouldn't expect a super easy to use REST api with documentation powered by readme.io.

Great read that shows how web scarping can easily be utilised in a meaningful way.

However, doesn't this script either send out the same text very often, or potentially send it out too late (by e.g. only letting the cronjob run every 6 hours)?

I assume that time is of the essence in this situation. Some sort of log on sent texts would surely be helpful.