Try being a 90-year old with minimal social contact and nobody to talk to, wasting away in front of a TV blasting NewsMax or Fox News ... does that sound like Heaven or Hell?
Substituting one form of media for another does not improve the hypothetical situation at all, giving a senior nothing to do all day except talk to a spreadsheet is not a solution to that senior being lonely, it is a false dichotomy. Far lower tech solutions can be (and are) used. In my locale we have volunteer schoolchildren active in the community, as far as I know that's quite common, and even half an hour biweekly with a fake grandkid is many orders of magnitude healthier and more meaningful than swapping out their TV for this generation's take on Fox News.
It goes without saying all these tools are still largely in their pre-advertising state, it won't last.
I speak from experience. The last few weekends I've been taking a friend to see her grandma at a Senior Facility in Sonoma County, and it is really depressing to watch them either lying in bed, listlessly, or in a wheelchair, gazing away in the distance.
They need interaction. And a suitably prompted LLM _can_ provide such interaction. I'm not saying hook them up with ChatGPT and let them loose, but that with the right harnesses and guardrails, they could have a more interactive life.
Is it responsive to personality settings? I actively don't want fake AI girlfriend, but I do get a ton of value out of voice mode. Looking forward to trying this but hoping it's not a creepy overdone mess (like Sesame). Expectations are they'll keep doubling down on fake AI girlfriend approach because the thing I want probably wouldn't drive engagement anywhere nearly as well
I have my Chat personality settings stripped right down to no-fluff. I'd want voice to be more akin to the Star Trek computer, and less akin to as you said an AI friend, but previously it was tuned too personable/friend-like.
Star Trek computer voice model is something I have yet to encounter, and I've looked repeatedly :) It's not about a specific voice, it's the fact they managed to capture "I am a utility" perfectly in the voice. Our modern friends do not want to be thought of as a utility, but to engender trust and agency all of their own and that's a huge problem for me.
Prompt text: There are 14 varieties of tomato soup available from this replicator. With rice, with vegetables, Bolian style, with pasta specify hot or chilled.
I think the request here is not about sounding like Majel Barrett but in keeping the output extremely terse and unobtrusive.
There's been a few studys showing that novices love LLM output that's long, but experts hate it. As an example, I've been tasked with using some agentic PM tool to write specs, and it keeps generating these huge page long outputs with "HBR voice" bolded summaries of paragraph long bulletpoints. I.e.:
> Right-size hard, and watch the one open-ended edge. Endorse the DRI's simplifications wholesale: drop the runbook-per-alert mandate (keep 1–2 diagnostic-only runbooks for the high-priority set), and ride durability on the existing weekly incident + monthly operational reviews — no new governance. The single scope-creep risk is the coverage strand (gaps are defined by absence); bound it to gaps evidenced by real, already-missed customer-facing outages, not a proactive gap hunt. Curing ownership gaps (e.g. foo-bar, no clear owner) is finite in-scope work.
There's dozens of these every iteration. I can't imagine trying to deal with that via voice, I would just zone out after the second sentence.
I'm just going to say, Wow. That's a pretty incredible result. I had no idea you could clone a voice with such a short snippet of audio these days.
I've had this dream of talking to the Enterprise-D computer since I was 8 years old. Midlife-crisis me still has that dream, but hooked up to Home Assistant so it can actually do useful things too. A couple months back, I went looking around for "clean" samples of Majel's voice as the computer but didn't have a lot of luck. Even though there are three television series and several movies, pretty much all of them have some amount of background noise, bleeps, bloops, or warp core thrum. (As this one does.) There may be modern ways to clean those up without affecting her voice much, but I haven't dug into that yet.
There are a few audiobooks narrated by Majel Barrett but obviously her role as the computer was proper voice acting and so the books would not be good source material.
There were also a few games/CD-ROM (Omnipedia) with some samples, but they did not bother to post-process them for that lofi Enterprise-D computer feel. Can _probably_ be replicated fairly faithfully after the fact, but I only know a _little_ about audio post-processing.
According to her son (Rod Roddenberry), Majel sat down in a studio and recorded audio samples specifically for the purpose of having her voice cloned someday for future Star Trek stories. However, those haven't been released publicly. (And likely never will, but I can dream, can't I?)
Edit: I played with your samples and the time it takes to generate the output audio is pretty brutal. Too slow for interactive use. Maybe that's a limitation of the HF-hosted app, though.
If you read their GitHub README and the code, it's possible to separate and cache the voice cloning step, and they have some streaming variant with low first chunk latency. I only played with it via Hugging Face. It is astonishingly good with certain rare accents, and it responds well to longer input clips
I noticed that too, I guess the content in the training data suggests that when some text self-identifies as "cold, hard logic" it additionally assumes a mean tone. Additionally it makes responses more likely to disagree even when given inputs that are more or less valid. A while ago I tested out giving some idea to a model with the "hard logic" prompt, then taking its own output, reverting the conversation and giving it its own statement again, making it disagree with the very same statement it just made itself. This was mostly just humorous, and doesn't indicate too much, after all both statements might've been wrong in some way, but the statement itself was moreso an opinion with no fully right answer, showing this tendency to disagree.
I guess when we tell models to use "cold logic" they don't interpret that purely definitionally, but moreso with what this statement usually implies, which is often a disagreement between two people, one trying to leverage supposed logic to disagree and denigrate the other party, oftentimes actually arguing out of emotion and not the logic they claim to use. This probably occurs enough to give model responses a mean tint. That's my theory on why this could occur at least.
One popular speech synth from back in the day, I believe it was WillowTalk, had a voice called Colossus, which sounded like the voice module of the computer from Colossus: The Forbin Project. This voice was used for that of CATS in the famous "All your base are belong to us" Flash video.
Another WillowTalk voice was a clone of DECtalk's Perfect Paul good enough to be used as the voice in the MC Hawking rap recordings.
It came from a company called Willow Pond Software. That seems to narrow searches down.
WillowTalk is apparently still of interest to Half-Life modders because another WillowTalk voice, possibly a clone of DECtalk's Huge Harry, was used as the Black Mesa VOX facility-wide announcement system in the original Half-Life.
I think that's mostly just a frequency shift :) You could probably recreate it with another model and some effects on top. Also, why the hell not for voice mode haha.
I explicitly prompt my small local models to channel that kind of energy. It's one of few ways to get them to just spit it out without yapping on about temperature- and humidity-appropriate activities when I just asked if it'll rain this week.
You do have to do it carefully and not literally say "Star Trek" or else it'll start yapping about main shields being at full strength.
It’s 2026 what the customer wants is probably an indication of what not to do if you’re a hyperscaler.
Whoever ends up actually winning after the crash will be the ones who figure out the needs of users, not the needs of the financial machinations of the companies trying to grab land.
> Lloyds has not explained why it has taken this action… despite multiple communications from us
Because you've tripped an AML flag you unbearable dweebs, this happens a thousand times every week and the story is always the same, tipping off rules actively prevent notification. But of course the reason must be political, because that's the only story that will drive traffic to an otherwise unknown outlet
So now that I randomly tripped some "flag" of some obscure algorithm, my innocence doesn't matter anymore and actions taken against me (without compensation) are automatically justified?
We should be ok with that just because this is how it works?
What’s new is banks coordinating to prevent someone who has been de-banked from being re-banked, as discussed in TFA. Oh, and that this was a journalistic outlet that was de-banked; possibly not an AML case based on the UK’s recent targeting of activists.
> that's the only story that will drive traffic to an otherwise unknown outlet
Naked Capitalism (the blog where this is published) has been around since before the GFC and is actually quite well-known among those who read, especially for its coverage of financial shenanigans. The economist Michael Hudson often comments there, and they sometimes republish his work. They are highly critical of the hyperfinancialization that’s taken over the economy, but despite this bias they often have a clearer view of what’s happening than the subservient and often manipulative financial press.
If banks view and treat their customers like spammers and random callers, banking regulations are fundamentally broken. It's even worse to see people who don't see the problem with such policies.
Triggered by both of these comments.. interaction mode dictates a style of thinking. I have to use a mouse, I'm forced to use my eyes, which also means I probably have to use a massive screen. I have to pay attention to some hyperactive Intellisense-like feature, I'm forced to remove my attention from the problem.
It's like saying you're convinced people reporting they feel more productive in a mauve-coloured room are liars, or those that drive automatic vs manual. Maybe they just find muave a restful colour?
I think most people who strongly identify with tools like vim do so out of a sense of identity-building to "be the kind of developer who is good at vim" / embody some kind of aesthetic or in-group signal moreso than an actual desire to be more effective at getting work done.
As long as you don't have some kind of stochastic or >5s impediment taking you out of a state of flow, most developers' productivity is going be vastly more influenced by their knowledge, understanding, and ability to focus on the problem they are working on than the marginal difference in time it requires to perform some navigation or editing task. Which is not to say that vim is bad or that you shouldn't use it, but that it's just a text editor and if you get triggered by someone not liking it or thinking it's more trouble than it's worth, it might be worth taking a step back and thinking about why it's something that triggers an emotional/defensive response, rather than the kind of reaction you'd have to someone liking strawberry more than vanilla.
> I think most people who strongly identify with tools like vim do so out of a sense of identity-building to "be the kind of developer who is good at vim" / embody some kind of aesthetic or in-group signal moreso than an actual desire to be more effective at getting work done.
This is the exact same sweeping inferential leap as the original comment. I happen to think people who drive red cars do so only because they want to incite a sense of danger and potency in their road opponents, people who wear boots obviously want to identify with Ukranians on the front lines and any claims it helps with their flat feet are obvious rubbish.
Tooling and language obsession is boring and borderline offensive to anyone who has been around for a few years. Imagine walking into someone's workplace and demanding they replace their well worn chair, would you do it? Imagine insisting someone use vim because their IDE didn't have a natural pipe-through-shell-command function.
>> I'm forced to use my eyes, which also means I probably have to use a massive screen. I have to pay attention to some hyperactive Intellisense-like feature
I can quite easily (and often do) use a basic editor while staring at the wall. I've yet to use an IDE where there wasn't some idiotic race between keystrokes and whatever random latency language server just told it to insert parens or a newline after you already typed them, assuming the text is even visible on a 13" screen buried in sidebars and "essential" extensions. They're full attention tools which is a completely different mode of work than is otherwise possible.
It's not to say an IDE isn't a useful thing, they just have their place like anything else. I personally find autocompletion useful for a couple of weeks going into a new language or project after which it's very often more a distraction than a productivity enhancer. Same goes with e.g. Git integration. I wouldn't presume to say a Git integration user simply needs to learn Git in much the same way I wouldn't expect someone to tell me that I can't use Git just because I don't use the IDE Git integration. They're just tools
Probably throwing quite the grenade here, but around 29% of pregnancies end in termination globally. Absent cultural considerations, it's questionable whether life expectancy has improved in absolute terms in modern times
I don't think it's a grenade unless you are implicitly trying to mean it that life begins before birth, which ultimately is a definition game since it's actually quite hard to define life, hard enough that calling it "life" is a matter of personal worldview. I personally think it's quite reasonable to exclude pre-birth "deaths" from life expectancy, or event infant deaths sometimes, depending on what you are trying to measure.
In any case I didn't know this number and it's quite relevant to the discussion of how much we got rid of natural selection.
What's the point of even trying to obfuscate this with such a simple method? Could at least have hidden the targeted features by storing their hashes or embedding a bloom filter or similar
In this case, this is probably not the only stereographic tattletale.
Had a competitor pull something like this with a previous employer. They were supposed to be interoperating with a standard, but they had a secret steganographic handshake, which they used to pretend that competitors products were unreliable (they had a first mover position in a smaller national market with specific requirements, so this wasn't shooting themselves in the foot). Our guys figured out the handshake and just silently implemented it. In this case, the competitor wasn't big enough to waste engineering time on multiple such hacks, but Anthropic have time (or Claude does).
> The failure was caused by a timing-dependent race condition in hyper’s HTTP/1 connection handling. When the reader was slower and the socket buffer filled, poll_flush returned Poll::Pending, but the dispatch loop discarded that result. Hyper then treated the response as complete and shut down the socket while data remained buffered internally, causing the client to receive an EOF before the full body arrived.
This is relevant if the client sends multiple requests but the server decides to close the connection after one of them. The server should discard the additional requests until the client signals no more requests are coming.
connection reset - TCP says "this connection is too messed up, abort, abort!"
The relevant condition here is where one side closed its socket but the other side didn't and keeps sending data to the closed socket. That's obviously an improper way to end a connection. A graceful shutdown does not send RST and ensures all data is received on both sides.
You are far better off reading the sockmap docs than this post, it adds almost nothing, entirely fails to explain the point of the interface and more or less amounts to marketing slop
Idempotency is an important attribute for correctness. Yep, you can document that POSTing to $ENDPOINT is idempotent, but you can't communicate that to caching layers throughout the network. QUERY, by definition, is idempotent and cacheable.
Including a strong motivating example might have helped sell this, using an example that could trivially be expressed as a GET is extremely distracting.
Even imagining a QUERY with a large JSON filtering structure, or say an image input as request body, it feels extremely odd to include the request body as part of the cache key. It also implies an unbounded and user-controlled cache key, with the only really meaningful general caching strategy being bitwise compare of the request body (or a hash), which in a hostile scenario implies cache busting would be trivial.
This invokes multiple semantic oddities in one go with obvious difficulties for a very niche use case. If I'm writing a service that needs complex filtering or complex input like an image, any form of caching (e.g. individual data columns of a join, or embeddings keyed by perceptual hashes of a decoded image input) is going to be far away from the HTTP layer and certainly unrelated to the exact bit representation of the request on the wire.
Why even bother trying to capture this in a generic way?
I would be far more inclined to try and capture this caching semantic as a new header for POST. Something like "Vary: request-body" or similar. Perfectly backwards compatible and perfectly ignorable for all but the 0.1% of CDN use cases where the behaviour might turn out useful
> It also implies an unbounded and user-controlled cache key,
The query part of GET's URI is also barely bounded in practice and user-controlled, and is indeed used as part of the cache key (because it's a part of URI), so I am not sure why you raise this objection at all.
I've found some sites that tack on a session ID and if you try to tamper with the URL in any way, it sends you back to "Page 1" really annoys me lol at that point let me skip to any page with your web UI.
There is: your browser or other type of client does not know it can repeat a POST request if it fails, whereas a QUERY request can be freely repeated in case of errors.
Yes. That is what the spec says. However, if the search query is expensive you need some form of caching. Either on the endpoint itself caching the data, or the mechanism with location to redirect to the location of the result.
Putting something in a spec does not automatically make it true. In the real world if you repeat expensive queries more than an undefined amount you get blocked or at least bot-checked.
Why the snark? The existing methods have been around for ages. Many engineers I’ve encountered were not even aware that there was a distinction between “idempotent” and “safe” as attributes of a method and generally conflated them, using “safe” in the sense of the dictionary definition instead of the spec’s.
Elsewhere it was suggested that we can now replace POST with this query. I was trying to be cautionary because just changing the method alone will bring different behaviour. I did so in brevity because I was in a rush. IMHO, that does not call for snark.
Technically a put or a patch is also idempotent. The benefits are idempotent and safe (and semantically appropriate). Post (generally) communicates something is changing whereas a query doesn't
PUT is idempotent, PATCH is not always. The semantics of a PATCH payload are up to the server and standards like JSON Patch (RFC 6902, https://datatracker.ietf.org/doc/html/rfc6902) allow non-idempotent operations like adding an item to a list.
> Why even bother trying to capture this in a generic way?
I guess it's about resolving the odd semantics of using POST which is not idempotent and thus allowing easier control flow of caches and retrys.
Your perspective is 100% correct if you think at the application-layer, but with a dedicated method, you can have that behaviour out-of-the-box out of your HTTP infrastructure (whether it's at your hyperscaler's router or your apache/nginx/browser whatever) and stop implementing yourself the post-as-a-query edge case.
The browser can simply store a collision resistant hash (e.g. SHA-256) of the body, if it wants a smaller cache key. I can't really think of any caching related attacks that don't equally apply to a query parameter. Generating a unique 30 character query parameter is just as easy as generating a 30 MB request body, if you want to flood the cache.
Not necessarily that simple, as you'd have sort all the input parameters to maintain a useable cache key. Not especially difficult, but if the data is large and so re-allocation and sorting is required, then you're starting to open up the attack surface where bugs might have been introduced.
Do you have to? Is it common to treat ?a=1&b=2 the same as ?b=2&a=1 in browser/CDNs/etc?
Seems the spec puts this as a MAY. I think I doubt it will be implemented in generic ways, except perhaps for urlencoded payloads. After all you cannot normalize in general without knowing the query language. At the backend it does not matter, may as well cache one level deeper based on the parsed input irrespective of QUERY or not.
No, that was my point. In a GET request, a caching proxy cannot assume the URL is URL encoded parameters, because the URL can contain data encoded in any form. So, you could only cache a GET on an exact URL.
But for a QUERY that explicitly marked the data as multipart or url-encoded, then semantically the order of parameters no longer matters.
That said, it's hypothetical because the only thing that uses those at the moment is POST and that explicitly should never be cached.
But there's another reply above to my comment that points out that a caching implementation is free to do what it likes, and if it fails to cache when parameters are in a different order, then it would still be correct, which is a fair point. That comment was https://news.ycombinator.com/item?id=48578024
I think the only sane approach for caching comparing if the body is identical and not apply any content type specific transformations. It's the safest choice, and the cache not being effective in some edge cases isn't a big deal. The client can always canonicalize the data itself, if it matters for its use-case.
Even if the spec says that different representations are equivalent, it's quite common for applications to treat them differently. For example field ordering in json objects is supposed to not matter, but some serializers care if a type discriminator is the first field.
I like the proposal, but I agree they could have sold it better.
This is basically a GET request that can have a body. I've found myself in need of that more than once when I did not want huge URLs with encoded data showing up in logs. Using POST request there is not appropriate because it signals data could be modified (i.e. cannot be sent to read-only instances). I guess modifying the spec to allow GET to have a body would pose too many problems.
Not all usage scenarios are the public internet, and something doesn't have to be useful on the public internet to be standardized.
Realistically, systems for the public internet will use a secure hash as the cache key so it'll always be the same size. The cache key already includes a URL that can be very long, and an arbitrary set of header values.
Except that by definition, in a URL the data has no implicit meaning so for a cache hit you need an exact match, including order and case, but for a list of POST parameters, they could legitimately be in any order and so you can't just hash it all as a blob, you need to sort the keys, possibly copy data around (unless using keys plus hash), probably allocating more memory, etc. I'm pretty certain we'll see at least one CVE out of the first few implementations of this!
POST/QUERY data can be in any format. Who are you to say order doesn't matter? Are you sure you can even parse it? Mine is in DES-encrypted (with key "password") base85 DER, you really gonna implement that in your proxy?
Maybe my knowledge is out of date in terms of how people generally use POST nowadays, but AFAIK multipart/form-data is still the most common encoding for data and occasionally application/x-www-form-urlencoded.
Both of these, the key values can be in any order with the same interpretation. That's kind of a moot point for POST method, because they should never be cached anyway, but for the new QUERY method it'd be reasonable to expect a cache hit whenever the parameters are the same regardless of order.
My point is that for a GET, you can't assume that the order isn't important, because the URL is an opaque string by the time it hits the cache. However, POST (and now QUERY) explicitly says what the coding is, so for instance with application/x-www-form-urlencoded we can be sure that the parameters can be in any order without changing the meaning. You cannot infer that from a URL itself.
As to your point, yes you can use any other encoding you like to. But most systems don't do that, they use multipart/form-data.
This RFC does not require caching to be implemented at all, so it wouldn’t be reasonable to expect a cache hit, no. But if your implementation does that, cool :)
An RFC would never mandate caching. But the table in the article says "cacheable: yes" for GET and QUERY. There is no "my implementation" because this is a proposal that has only just been proposed and there is currently "no implementations". I'm simply saying that QUERY will be harder to get caching correct compared to GET, and I'm almost certain there will be end up being CVEs resulting from its implementation.
It’s been an IETF Internet-Draft for a few years at this point, so there are some implementations already in the wild.
What I mean is that implementations are free to choose do something as complex as what you suggest, but also something as simple as hashing the body as a blob, and they can even bail on caching completely (for example if the payload is too large).
All of those options would be correct behavior per the RFC.
Of course we may still see CVEs from this, but they will be self-inflicted, not caused by a complex standard.
One example - I'm building an MCP server at the moment for a database I'm working on. In ChatGPT I want to do dry-run posts first that roll back before committing - both are POST requests with a property - and it loves to trigger the safety layer in the tools (for various reasons, it's hard to debug exact causes)
But I think this would make it better - QUERY before POST means different request types, not just the same with a safety flag.
Sure you can provide an image as request body, but you could already do it with b64 query parameter. If you try hard enough, you can poorly use any proposed standard.
GET with query parameters already is opaque and makes cache busting trivial.
I'm guessing you never hit this issue then, but it's a real issue. Whether or not it's in the RFC as a hard limit it doesn't matter, no HTTP server will allow unlimited sized URIs.
You simply can't base64 large payloads and you're stuck with workarounds.
You are guessing wrong. Thanks, I know specific implementation will come with their limits. This will equally apply to QUERY body size and caching strategy.
Are we seriously ok with linking the RFC as source while providing a statement that doesn't match? RFC does matter.
The RFC does say "It is RECOMMENDED that all senders and recipients support, at a minimum, URIs with lengths of 8000 octets in protocol elements."
One can infer from the RFC that you can reasonably expect many implementations to fail beyond 8000 characters, and that there are no guarantees up to that either.
True, the RFC doesn't specify a limit, but it does clearly indicate that it's not unbounded, nor should you expect it to be.
This RFC (10008) does not require caching to be implemented at all, so it would make no sense to make a recommendation here for what is a reasonable limit to expect caching to work.
Of course I don't advocate oversize URLs. That's a point of RFC10008.
Let's say we build a service for image transformation or image information extraction. Get isn't practical. QUERY with image as body could be a valid usage, regardless of caching. It conveys information that request is idempotent and can be retried with no impact on data, contrary to POST. If your http client is configured to support this, it can potentially improve reliability.
This is controlled by the (Last-Modified, If-Modified-Since) and (ETag, If-None-Match) header pairs. HTTP is stateless; it does not require any persistence. The only thing that defines kind of an optional persistence is the caching layer, for obvious reasons.
If you control the full stack then the functionality described here can be implemented with POST. The only way this comes into play is if some second party client of your service is trying to impose rules on how your backend works. My answer to that is no. I will be defining the contract by which my services operate.
Actually this is a use-case supported by this RFC [1]. You accept an arbitrary QUERY /search/ and you cache it on your side (or in a middle box somewhere such as a CDN edge) you can return in your response:
Location: /search/?queryHash=SOMECDNHASH
The browser can then cache that Location and the next time convert that same QUERY /search/ into GET /search/?queryHash=SOMECDNHASH.
Sure, it is more work for your webserver to compute that and potentially the browser to cache it's knowledge of that QUERY, but it potentially gives you an advantage in keeping things like CDN edge caches generally aware of client/browser caches in a way that can be performance optimized.
