I actually think the legacy completion API is superior to the newer chat creation API. The completion API takes all the input as a single string, whereas the chat API expects input as a list of messages. Given today's common use of agentic workflows, the model often has to process a large amount of input—RAG data, function calls, and other metadata—in addition to the user and assistant messages. The conversation itself might be just a small part of the overall prompt.

I’ve found it more intuitive to format the conversation as <conversation>...</conversation> within one unified text prompt, alongside all the other input data.

OpenAI’s new completion API supports both a single large string or a list of messages, which is great. I briefly experimented with the prompting tool in Claude—it essentially builds a big prompt that includes instructions and examples in XML format.

oh i never thought about y = append(x, ...) in which scenario would make sense to have different x and y?

Great idea! The demo looks impressive. What are your thoughts on real-time translated captioning compared to AI voice? I guess it's still difficult to mimic nonverbal elements like laughter and pauses.

Fantastic question. Our opinion on this is that the higher-bandwidth we can make the communication, the more useful it will be. The reason we've moved from IRC->VoIP->Video is because of the efficiency of information transfer and additionally the empathic element of face-to-face conversation.

From the technical side, speech to speech models have more potential for accuracy (no explicit ASR, no audio->text information loss). We have a few options on mimic'ing nonverbal elements - we could decide when to naturally mix in the original audio, or train our end to end model to handle those nonverbal audio chunks. We'll be trying both but likely the first option on the sooner side!

"synthesize large amounts of online information" does it heavily depend on the search engine performance and relevance of the search results? I don't see any mention of Google or Bing. Is this using their internal search engine then?

I actually like how NULLs behave in SQL. They mean "I don't know" In the modern programming language we all care about Null safety. But no matter how you model your data, you will always run into the situations when you don't know everything. So I believe NOT NULL is not very practical. NULLs in SQL handle these case very well - when the input is unknown your output is unknown

Except they don't consistently behave that way. If NULL means "unknown", why do they show up in outer joins, or when you SUM an empty table?

The most annoying is having to order by DESC NULLS LAST to get the largest value from an aggregation.

Agreed. If SQL didn't have NULL, we'd have other special values meaning "I don't know" or "no data" all over the place.

Too many newbies hear that NULL is bad, so they declare all columns as NOT NULL and end up inserting ad hoc values like 0, -1, '', or {} when they inevitably come across cases where they don't have data. Which is even worse than NULL.

Those mini apps are built on the same web stack. I believe the main advantages of creating mini apps are that the platform provides identity (allowing you to know who the users are upon permission approval) and payment APIs.

They use a mixture of web rendering stack and native rendering stack. See my other comment.

There are also more architectural diagrams thst illustrate the layers in the links I posted in my original comment.

I believe Telegram has something similar too.

I'm a heavy use of tmux integration in iterm2. this allows seamless mouse scroll in a tmux window. I haven't seen any other terminals that provide the same tmux support.

Wezterm doesn’t have tmux integration but instead implements multiplexing natively, meaning if you install it on a remote, it will host a mux server you can attach to over ssh. Pretty cool, and much faster/lower latency than tmux.

this looks like the workflows in gumloop.com

Give it a dark theme and I'd say the modern Westworld TV series.

the only reason i use wget over curl is that when i'm downloading a file, i don't have to specify the output file name with wget lol

-O (for name based on end of the URL) or -J (for name based on the returned HTTP header)

and wget is -o ; when i have a head full of tasks and code i only remember that they are different and tend to wget things, unless of course i am on a bsd and reach for fetch