I much prefer cursor paginated API requests vs. webhooks. The obvious downside being that in order to not get 429'd you need a respectable poll frequency - meaning you lose reactivity to new events.
Thus I think webhooks still have a place - but as a simple "poke" that can be sent to the client to tell them something has changed - supplementing a default low frequency polling interval.
This gives us the best of both worlds:
1. No need to bother de-duping/retrying pokes - if you miss a webhook you will shortly recover anyway when you next poll.
2. No need for any local-specific tunnelling/tooling - the local app will work just fine with the default poll interval.
3. No need to keep a connection live for each client.
4. All the good stuff OP mentioned in his blog post.
The Gmail API works nicely like this. There's a history.list endpoint where you can see the recent history of message additions and removals, you can query for just the history that's taken place since a specific event's historyId, and you can subscribe to push notifications (that can be delivered by webhook) which just tell you when there are new history events, and you're expected to hit the history.list endpoint to see what's new. Some dropped push notifications aren't a big deal.
Yep, the poke pattern is additionally nice because it means my state reconciliation function is the same when running on cron interval vs event driven.
On the flip side, it helps to have endpoints which have a query param linking to some sort of resource update time stamp. That way you can query to only get those items changed since last poll.
Absolutely. I have been so livid at so many applications for not providing a decent CDC API (and dont forget deletes). Salesforce perhaps is the best out there. Imagine if every application exposed a standard CDC API, the world of integrations would be so much better.
Webhooks are fine, but a pollable API is a must have. The amount of hacks I had to do at work to workaround shitty APIs gives me nightmares.
As I understand it, anything publicly viewable is free to be scraped without issue.
If you scrape stuff behind a sign-up, you potentially open yourself up to being sued for breach of ToS.
Now I'm sure the Chinese labs don't give a rats arse about that threat, but I imagine it stops the likes of Google, OAI, Anthropic from scraping and instead forces them to purchase the data.
Not how it works ... Anything public viewable is still subject to a TOS. And the whole copyright or whatever still applies.
If your argument was valid, we can scrape news websites and show their content freely. No ... You get sued and lose the case.
See Google News that got their behinds in court and lost. Short summaries are allowed / transformative, but you can not just take content (even without a login). Not without getting into civil court if somebody wants to press the matter.
Now, if you scrap and never make that data public or transform it (LLMs). Then it becomes a harder matter to deal with.
With simple prompting it works sometimes but less reliably. I implemented a healing and strengthening algorithm which can improve codes that don't scan quickly.
Trying to polish a bunch of my projects I've worked on over the years but never had the cojones to release to the wider world:
Hallways (https://hallways.lonnycorp.com) - a web browser for 3D spaces, where instead of hyperlinks you have portals that you can seamlessly walk through
LonnyMQ (https://lonnymq.lonnycorp.com) - a performant, production-ready TS PostgreSQL message queue library and accompanying blog post that walks through its design (of which I'm quite proud of)
I think _some_ but not _too much_ typechecking is the sweet spot for LLMs.
Without any typechecking, LLMs obviously find it harder to work agentically and validate their work.
With too much typechecking (I'm looking at you, rust), I've found agents get themselves stuck in local "architectural minima" and end up doing insane shit to mitigate ownership/borrow-checker issues inherent in the design they ended up with.
That said, if you're hands-on I think rust is a fantastic language for pairing with an LLM.
Presumably because API keys are n bytes of random data vs. a shitty user-generated password we don’t have to bother using a salt + can use something cheap to compute like SHA256 vs. a multi-round bcrypt-like?
I think they are saying passwords are salted and we use multiple rounds of hashing to prevent rainbow tables and slow down brute-forcing the password (in case of db leak). We don't need to do that for randomized long strings (like api keys), no one is guessing 32 character random string, so no salt is needed and we don't need multiple rounds of hashing.
Bugginess in the Claude Code CLI is the reason I switched from Claude Max to Codex Pro.
I experienced:
- rendering glitches
- replaying of old messages
- mixing up message origin (as seen here)
- generally very sluggish performance
Given how revolutionary Opus is, its crazy to me that they could trip up on something as trivial as a CLI chat app - yet here we are...
I assume Claude Code is the result of aggressively dog-fooding the idea that everything can be built top-down with vibe-coding - but I'm not sure the models/approach is quite there yet...
Bots get so good that they become indistinguishable from humans. If that’s true then it doesn’t actually matter if your community is all bots. But it does matter because authenticity matters to humans. They will seek authenticity where they can successfully sense it, which will be in-person.
Human simulacrums will one day cause a repeat of this issue. Then we’ll have a whole Blade Runner 2049 issue about what exactly is authenticity?
>transactional emails from various services that you’ve signed up for
These are one of the main culprits of unwanted emails... and a toll system would make them all the more valuable for the even worse actors to take advantage of.
Thus I think webhooks still have a place - but as a simple "poke" that can be sent to the client to tell them something has changed - supplementing a default low frequency polling interval.
This gives us the best of both worlds:
1. No need to bother de-duping/retrying pokes - if you miss a webhook you will shortly recover anyway when you next poll. 2. No need for any local-specific tunnelling/tooling - the local app will work just fine with the default poll interval. 3. No need to keep a connection live for each client. 4. All the good stuff OP mentioned in his blog post.