10 interesting stories served every morning and every evening.

Japan develops a method to recover up to 90% of lithium from used EV batteries and it could be a major breakthrough

tech.supercarblondie.com

In a ground-break­ing step for­ward, Scientists from Japan have de­vel­oped a new method to re­cover up to 90 per­cent of lithium from used EV bat­ter­ies — and it sud­denly feels like great news on Earth Day.

With elec­tric ve­hi­cles boom­ing world­wide, the pres­sure is mount­ing to find smarter ways to deal with old bat­tery waste.

This new tech­nique does­n’t just re­cy­cle ma­te­ri­als; it re­cov­ers most of them at an un­be­liev­able rate.

And if it de­liv­ers at scale, it could change how EV bat­ter­ies are made and reused for years to come.

A new method to re­cover up to 90% of lithium from used EV bat­ter­ies

This huge break­through in tech has come from a re­cy­cling fa­cil­ity in Japan, where en­gi­neers have man­aged to ex­tract around 90 per­cent of lithium from used bat­ter­ies.

That’s a huge leap com­pared to tra­di­tional meth­ods, which of­ten re­cover less than 50 per­cent of the ma­te­r­ial, es­pe­cially since it feels like a win to cel­e­brate this Earth Day.

At the heart of the process is a clever chem­i­cal tweak; in­stead of us­ing stan­dard sodium hy­drox­ide, the team swapped in re­cov­ered lithium hy­drox­ide dur­ing re­cy­cling, which is a white pow­der.

This helps con­vert bat­tery waste, known as black mass’, into high-pu­rity lithium that can be reused in new bat­ter­ies.

Even bet­ter, the process is­n’t just ef­fi­cient, it’s bet­ter for the en­vi­ron­ment too, be­cause re­searchers say it can cut car­bon emis­sions by around 40 per­cent com­pared to con­ven­tional re­cy­cling tech­niques.

It could be a ma­jor break­through for the fu­ture of EVs

This mat­ters be­cause lithium is one of the most crit­i­cal in­gre­di­ents in EV bat­ter­ies, and de­mand is sky­rock­et­ing, as well as min­ing be­ing ex­pen­sive, en­ergy-in­ten­sive, and of­ten geopo­lit­i­cally com­pli­cated.

By re­cov­er­ing lithium do­mes­ti­cally, Japan could re­duce its re­liance on im­ports and sta­bilise sup­ply chains.

In fact, the coun­try cur­rently im­ports al­most all of its bat­tery min­er­als, so re­cy­cling at this scale could be a game-changer.

Massive geopo­lit­i­cal shift. NHK World con­firms Japan has per­fected a rev­o­lu­tion­ary process to ex­tract high pu­rity lithium from dead bat­ter­ies with a stag­ger­ing 90 per­cent re­cov­ery rate. This bril­liant tech­no­log­i­cal leap guar­an­tees Japan’s ab­solute eco­nomic se­cu­rity. pic.twit­ter.com/​O7ENxL­HcNb— Furkan Gözükara (@FurkanGozukara) April 8, 2026

Massive geopo­lit­i­cal shift. NHK World con­firms Japan has per­fected a rev­o­lu­tion­ary process to ex­tract high pu­rity lithium from dead bat­ter­ies with a stag­ger­ing 90 per­cent re­cov­ery rate. This bril­liant tech­no­log­i­cal leap guar­an­tees Japan’s ab­solute eco­nomic se­cu­rity. pic.twit­ter.com/​O7ENxL­HcNb

There are still chal­lenges, though: only about 14 per­cent of used lithium-ion bat­ter­ies in Japan cur­rently make it into of­fi­cial re­cy­cling sys­tems, mean­ing col­lec­tion in­fra­struc­ture needs a se­ri­ous up­grade.

But with plans to make pro­duc­tion even more pow­er­ful by 2027 and ex­tract tens of thou­sands of tons of ma­te­ri­als an­nu­ally by 2035, this in­no­va­tion could be a big turn­ing point.

If adopted glob­ally, it might not just change lives in Japan; it could save the world.

Climate.gov was destroyed. Open data saved it.

werd.io

After los­ing their jobs at NOAA, Rebecca Lindsey, her sis­ter and an­other col­league teamed up to re­build a piv­otal re­source the Trump ad­min­is­tra­tion took of­fline.”

Link: Trump dis­man­tled a fed­eral cli­mate web­site. These women re­built it., by Jenae Barnes at The 19th

This should­n’t have been nec­es­sary, but is still won­der­ful to see. Climate.gov had been the go-to re­source for cli­mate data, but it went of­fline when the Trump Administration rad­i­cally cut NOAAs fund­ing. At that point:

[Rebecca] Lindsey joined forces with for­mer NOAA em­ploy­ees Anna Eshelman, and Mary Lindsey, her older sis­ter, to be­come the core team be­hind the de­ac­ti­vated site’s suc­ces­sor, Climate.us, pre­serv­ing over 15 years of key cli­mate data and re­sources. The trove fea­tures key maps, ed­u­ca­tional ma­te­ri­als and cli­mate in­di­ca­tor re­ports, in­clud­ing the now-deleted Fifth National Climate Assessment, the gov­ern­men­t’s most com­pre­hen­sive analy­sis of cli­mate change that was at risk of be­ing lost to the pub­lic.”

This is pos­si­ble be­cause US gov­ern­ment data is pub­lic do­main by law. Had it not been avail­able un­der a per­mis­sive li­cense, the ad­min­is­tra­tion’s act of van­dal­ism would have meant the data was gone for good. But be­cause it was, the datasets can find a new home.

It’s a joy to use. Check out the cli­mate dash­board, which tracks num­bers like the to­tal area of the Arctic Ocean that was at least 15% ice-cov­ered each September. It also hosts a set of re­sources for teach­ing cli­mate and en­ergy. The dataset gallery in­cludes cru­cial in­for­ma­tion like the NOAAs archive of oral his­to­ries from peo­ple whose lives were af­fected by cli­mate change.

But it’s also pre­car­i­ous. The whole thing re­lies on do­na­tions to keep it afloat, which is re­ally what tax dol­lars are for. Still, for the mo­ment it’s won­der­ful to see peo­ple pick up the slack when gov­ern­ment is no longer do­ing its job. In the ab­sence of gov­ern­ment sup­port, archives like this are works of jour­nal­ism in them­selves: ways to help us make stronger de­ci­sions. They de­serve stronger sup­port, and ul­ti­mately, we all de­serve the restora­tion of such im­por­tant gov­ern­ment in­fra­struc­ture.

Attention Required! | Cloudflare

19thnews.org

Why have I been blocked?

This web­site is us­ing a se­cu­rity ser­vice to pro­tect it­self from on­line at­tacks. The ac­tion you just per­formed trig­gered the se­cu­rity so­lu­tion. There are sev­eral ac­tions that could trig­ger this block in­clud­ing sub­mit­ting a cer­tain word or phrase, a SQL com­mand or mal­formed data.

What can I do to re­solve this?

You can email the site owner to let them know you were blocked. Please in­clude what you were do­ing when this page came up and the Cloudflare Ray ID found at the bot­tom of this page.

Your ‘App’ Could Have Been a Webpage (so I fixed it for you…)

danq.me

Why is this an app”?

This sum­mer, the kids’ per­form­ing arts school are singing and danc­ing in a show at Disneyland. We’re all very ex­cited, but my ex­cite­ment, at least, was muted a lit­tle when I was told to in­stall the Travelbound” app in or­der to get ac­cess to the itin­er­ary, travel arrange­ments, and ac­com­mo­da­tion de­tails.

Fuck that noise. This should have been a web­page. Why do you want me to in­stall a(nother) shitty app just to tell me some­thing that could have been a (smaller, faster, more uni­ver­sally-ac­ces­si­ble) doc­u­ment?

There only seem to be two things that this app” does, that a web­page might not have, and they’re both anti-fea­tures:

It re­ports track­ing data as­so­ci­ated with your Google Account back to the de­vel­op­ers.

It shows you ad­ver­tise­ments (which they call inspirations”) for other trips or­gan­ised by the same agency.

Fuck. Everything. About. That.

A web­page would have been so much bet­ter. Unlike this app, a web­page can be…1

Copy-pastable

Printable

Saveable

Bookmarkable

Searchable

Usable on vir­tu­ally any de­vice

(Potentially) more-ac­ces­si­ble

I’m an­noyed enough… that I’m go­ing to fix” this app. Hold my beer.

Intercepting app traf­fic

It’s been a while since the last time I re­verse-en­gi­neered an Android app from its net­work traf­fic, so I had to brush-up on the best way. Here’s what I ended up do­ing.

Created a new vir­tual de­vice in Android Studio’s Virtual Device Manager.

Tested adb shell was work­ing and used rootAVD to root it: ./rootAVD.sh sys­tem-im­ages/​an­droid-33/​google_apis_­play­store/​x86_64/​ramdisk.img.2

Performed a cold boot, ran Magisk, and tweaked its set­tings to au­to­mat­i­cally grant su ac­cess to any app that asked.3

Ran HTTP Toolkit and told it to in­ter­cept AVD traf­fic. It in­stalled a (fake) VPN provider, rout­ing the phone’s traf­fic through the proxy.4

Installed the Travelbound app from the Play Store.

Configured HTTP Toolkit to proxy only the Travelbound app (more sig­nal, less noise).

With only a cou­ple of min­utes ex­per­i­men­ta­tion I dis­cov­ered that the app works by con­cate­nat­ing the user­name and pass­word5 and us­ing it in a URL of the form:

https://​trav­el­bound.api.va­moos.com/​api/​itin­er­aries/{​user­name}-{pass­word}

https://​trav­el­bound.api.va­moos.com/​api/​itin­er­aries/{​user­name}-{pass­word}

This re­turns a pile of JSON which, with a lit­tle in­ter­pre­ta­tion, can be seen to rep­re­sent all of the con­tent the app shows”. E.g., there’s:

an ar­ray con­tain­ing each leg of the itin­er­ary,

an ar­ray con­tain­ing all of the inspirations” ad­ver­tise­ments to show you,

a cross-ref­er­enced ar­ray con­tain­ing all of the files (images etc.) that are ref­er­enced by the other sec­tions, etc.

A lit­tle ex­per­i­men­ta­tion showed me that the S3 im­age URLs were be­ing de­liv­ered with mod­er­ately-short ex­pi­ra­tion times, so the JSON needs re-fetch­ing pe­ri­od­i­cally even if the con­tent has­n’t been changed.6

Turning it into some­thing bet­ter

Now I had every­thing I needed to make some­thing… bet­ter. I wrote a Ruby script that runs on a Cron sched­ule to pull the lat­est JSON and use it to build a HTML page.

I chose to have it com­pletely skip over the inspirations” (“overlayRows” in the data schema) and just list:

the items from the itin­er­ary and

all of the files not ref­er­enced by the in­spi­ra­tions nor itin­er­ary, (a lazy way to col­late the PDF down­load links).

Then I hosted the page, pro­tected by a pass­word: the same one my tour group were given in the first place. I in­cluded the raw JSON it used in <details> el­e­ments so it can be checked if e.g. there are bits of the schema I did­n’t see but that might ap­pear later.

Some peo­ple like an app”, and that’s… fine, I guess. But some apps could have been a web­page. And es­pe­cially where, like this one, the con­tent they de­liver is al­ready writ­ten in HTML and de­liv­ered over HTTP… they should be a web­page, right?

I can’t un­der­stand how we got to this place with app cul­ture”! Software com­pa­nies are happy to make their lives harder (and more ex­pen­sive: de­ploy­ing to the big app stores is­n’t free!), in or­der to de­liver HTML con­tent to fewer peo­ple and with fewer fea­tures7 than if they just pub­lished di­rectly to the Web in the first place!

There are (some) tasks for which an app” is ab­solutely the right choice of medium. Travelbound is not one of them.

But at least I (and the rest of our group, whom I’ve shared it with) now get the choice about how we ac­cess this con­tent. Either a 43MB app (ballooning to 124MB when it’s fin­ished down­load­ing ex­tra con­tent) with track­ing and ad­ver­tise­ments… or a 0.05MB web page (with an op­tional ex­tra 35MB of im­ages) that pro­vides more fea­tures and works on more de­vices. I know which one I’ll be us­ing!

Footnotes

1 And these are just the fea­tures that every­body can get be­hind. The web­page I ul­ti­mately ended up mak­ing to re­place the app also has some user-friendly/​de­vel­oper-hos­tile fea­tures, like the fact that it re­moves the track­ing code and does­n’t show ad­ver­tise­ments.

2 You need to root the de­vice in or­der to force ap­pli­ca­tions that use Certificate Pinning to trust your man-in-the-mid­dle proxy server. Without this, some ap­pli­ca­tions — in­clud­ing the one I wanted to re­verse-en­gi­neer — will recog­nise your self-signed TLS cer­tifi­cate as in­valid and refuse to com­mu­ni­cate.

3 Without chang­ing this set­ting in Magisk, I found that HTTP Toolkit would re­quest su ac­cess but not wait for the re­sponse, and go on to run in un­priv­i­leged mode be­fore I had a chance to grant it!

4 Owing to Android se­cu­rity con­sid­er­a­tions I needed to man­u­ally in­stall the root CA cer­tifi­cate it in­stalled for me, but the in­struc­tions just worked”.

5 The user­name and pass­word is shared by an en­tire tour group. I’m guess­ing they don’t have a plan for if some cre­den­tials get leaked? Or pos­si­bly they con­sider all of the data they hold to be low-sen­si­tiv­ity enough that it does­n’t mat­ter if it does… in which case I re­turn to my orig­i­nal point: why the hell was­n’t it just a web­page in the first place?

6 Or else the im­ages need caching lo­cally, which seems to be what the app does, in the bloat­i­est pos­si­ble way.

7 And, of­ten, with worse ac­ces­si­bil­ity. I’ve not au­dited the ac­ces­si­bil­ity of this app, but there are things about it that sug­gest that it’d be harder to use us­ing ac­ces­si­bil­ity tech­nolo­gies than my plain, sim­ple Web ver­sion.

The git history command deserves more attention

lalitm.com

Working with lots of changes in par­al­lel on git can be painful. You end up jug­gling branches and com­mits, and run­ning scary re­base -i com­mands that can leave your tree in a half-bro­ken state if you so much as sneeze.

jj, an al­ter­na­tive to git, gets dis­cussed a lot these days (1, 2, 3, 4) and is of­ten pitched as a so­lu­tion. While I’m very sold on the prob­lems jj is try­ing to solve, the way it solves them has­n’t quite hit home with me. Every 3 months, for the last 1.5 years, I try it out for a few days, re­ally try­ing to make it part of my work­flow but even­tu­ally I give up and go back to git.1

That’s where git his­tory comes in. It’s an ex­per­i­men­tal com­mand that ar­rived across two re­leases, 2.54 (April, re­word and split sub­com­mands) and 2.55 (June, fixup sub­com­mand). It got a flurry of at­ten­tion on each re­lease day, and then, as far as I can tell, not much com­mu­nity dis­cus­sion since. Which is a shame, be­cause IMO it al­ready de­liv­ers sev­eral of the ben­e­fits peo­ple tout for jj with­out need­ing to switch your whole work­flow. And the cool thing is that it’s part of the core git dis­tri­b­u­tion, so you can try it with­out in­stalling any­thing.

There are three sub­com­mands: fixup, re­word and split.

fixup

git his­tory fixup fixes an old com­mit that has some­thing wrong in it, then au­tore­bases all your branches to match.

You stage the fix as usual with git add, then run git his­tory fixup <commit> to fold those staged changes into the tar­get com­mit. It’s like a git com­mit –fixup plus an au­tosquash re­base but with the ex­tra magic that it also up­dates any other branch which con­tained that com­mit.

That last part goes fur­ther than git re­base –update-refs, which only moves refs sit­ting in­side the range you’re ac­tively re­bas­ing. git his­tory in­stead finds and rewrites every lo­cal branch de­scended from the com­mit (while also hav­ing an op­tion to limit it to only the cur­rent branch). On the other hand it does not work in the pres­ence of merge com­mits which, for some us­ages of git, is go­ing to be a deal­breaker.

Here’s how it works in prac­tice:

Before, with a fix staged for B:

After git his­tory fixup B:

B* is B with the fix folded in. Rewriting a com­mit gives it a new hash, so C and D are au­to­mat­i­cally re-cre­ated on top as C* and D*, and the feat-1 and feat-2 branch tips move with them.

The most im­por­tant prop­erty, com­mon to all three com­mands, is that it’s atomic: it never leaves your tree in a half-bro­ken state. It man­ages this by re­fus­ing any op­er­a­tion that could pro­duce a con­flict.

To be clear, this is strictly less pow­er­ful than jj. jj treats con­flicts as first class so it can carry a con­flicted state through a re­base and let you sort it out later. git his­tory does­n’t do this yet but the docs leave the door open:

This lim­i­ta­tion is by de­sign as his­tory rewrites are not in­tended to be state­ful op­er­a­tions. The lim­i­ta­tion can be lifted once (if) Git learns about first-class con­flicts.”

This lim­i­ta­tion is by de­sign as his­tory rewrites are not in­tended to be state­ful op­er­a­tions. The lim­i­ta­tion can be lifted once (if) Git learns about first-class con­flicts.”

So ba­si­cally, this lim­i­ta­tion may change in the fu­ture; ex­cited to see if it does!

re­word

git his­tory re­word up­dates the com­mit mes­sage on an old com­mit and au­to­mat­i­cally re­bases every­thing on top. This is very use­ful for go­ing back and fix­ing com­mit mes­sages when the de­sign shifts as you it­er­ate.

git his­tory re­word <commit> opens your ed­i­tor with that com­mit’s ex­ist­ing mes­sage. You edit it, save, and the rest of the stack is re­built on top with the branches fol­low­ing along. It’s ex­actly like fixup but for com­mit mes­sages in­stead of the tree con­tents.

Because it only changes a mes­sage, re­word (like split later) never touches your in­dex or work­ing tree at all; it works purely on the com­mit graph. So both let you rewrite a com­mit on a branch you don’t have checked out with­out dis­turb­ing what­ever you’re in the mid­dle of.

Before:

After git his­tory re­word B:

Only B’s mes­sage changes, but that still gives it a new hash, so C is re­built on top as C* and feat-1 fol­lows along.

split

git his­tory split takes one com­mit and splits it into two, in­ter­ac­tively pick­ing what you care about from each. It’s the equiv­a­lent of git add -p, but with­out need­ing gym­nas­tics with git re­base. I’ve found this to be the most spe­cial­ized of the three, but in­valu­able when I need it.

Specifically, git his­tory split <commit> drops you into a hunk-by-hunk prompt over that com­mit’s diff. The hunks you keep make up the first com­mit, the rest fall into the sec­ond.

Before, with B bundling two un­re­lated changes:

After git his­tory split B:

B be­comes B1 and B2, and C is re­built on top of the pair as C*.

Conclusion

Judging by how many peo­ple are us­ing jj, I do think there’s still some key men­tal shift which I’m not yet mak­ing. And to be clear, git his­tory does­n’t close the full gap: jj still gives you an op­er­a­tion log with easy undo, mod­els your work­ing copy as a com­mit, and can carry con­flicts through a re­base, none of which this is try­ing to do.

But for now, git his­tory is a big step for­ward in adopt­ing many of the pieces that at­tract peo­ple to jj, and it’s al­ready in the tool I use every day. And the way the doc­u­men­ta­tion is writ­ten makes me hope­ful that more im­prove­ments will be com­ing in up­com­ing re­leases!

Regression: encrypted MultiAgentV2 messages remove readable task audit trail

github.com

What ver­sion of Codex CLI is run­ning?

Upstream main af­ter #26210 (Encrypt multi-agent v2 mes­sage pay­loads, merged 2026 – 06-05). This ap­pears to af­fect ver­sions that in­clude that change and en­able MultiAgentV2 (post-0.137.0).

What sub­scrip­tion do you have?

Not sub­scrip­tion-spe­cific.

Which model were you us­ing?

Not model-spe­cific. This con­cerns MultiAgentV2 spawn_a­gent, send_mes­sage, and fol­lowup_­task mes­sage han­dling.

What plat­form is your com­puter?

Not plat­form-spe­cific.

What ter­mi­nal em­u­la­tor and ver­sion are you us­ing (if ap­plic­a­ble)?

Not ter­mi­nal-spe­cific.

Codex doc­tor re­port

Not ap­plic­a­ble. The re­gres­sion is vis­i­ble from the merged code be­hav­ior in #26210 rather than from lo­cal en­vi­ron­ment state.

What is­sue are you see­ing?

#26210 makes MultiAgentV2 agent task/​mes­sage pay­loads opaque to Codex by mark­ing the model-fac­ing mes­sage pa­ra­me­ter as en­crypted, stor­ing only InterAgentCommunication.encrypted_content, and leav­ing InterAgentCommunication.content empty.

The en­crypted de­liv­ery path is un­der­stand­able as pri­vacy hard­en­ing, but it also re­moves the hu­man-read­able task/​mes­sage text from lo­cal roll­out his­tory, trace re­duc­tion, and par­ent-side au­dit/​de­bug sur­faces. That makes it dif­fi­cult to an­swer ba­sic ques­tions such as:

What task did this spawn_a­gent call give the child agent?

What mes­sage was sent to a sub­agent?

Why did a child thread ex­ist when re­view­ing a roll­out af­ter the fact?

This is dif­fer­ent from #26753, which re­ports re­quest val­i­da­tion fail­ures for en­crypted tool schemas. This is­sue is about au­ditabil­ity and de­bug­ga­bil­ity af­ter the en­crypted schema is ac­cepted.

What steps can re­pro­duce the bug?

Use a build con­tain­ing Encrypt multi-agent v2 mes­sage pay­loads #26210 with MultiAgentV2 en­abled. (aka post-0.137.0)

Have the model call spawn_a­gent, send_mes­sage, or fol­lowup_­task.

Inspect the par­ent roll­out/​his­tory/​trace for the sub­agent task.

The task/​mes­sage con­tent is hid­den be­hind ci­pher­text rather than be­ing avail­able as hu­man-read­able au­dit text.

What is the ex­pected be­hav­ior?

Codex should pre­serve a hu­man-read­able, struc­tured au­dit copy of the sub­agent task/​mes­sage while still al­low­ing en­crypted de­liv­ery to the re­cip­i­ent model.

A pos­si­ble shape is to keep the en­crypted mes­sage field for model de­liv­ery, but add a sep­a­rate non-en­crypted au­dit field for the read­able task text. The au­dit field should be per­sisted in roll­out/​his­tory/​trace meta­data so users and main­tain­ers can in­spect what was del­e­gated with­out need­ing to de­crypt model-de­liv­ery ci­pher­text.

Additional in­for­ma­tion

Related PR/issues:

Encryption change: Encrypt multi-agent v2 mes­sage pay­loads #26210

Related but dis­tinct schema-val­i­da­tion is­sue: MultiAgentV2 en­crypted spawn_a­gent schema re­turns 400: model not con­fig­ured for en­crypted tool use #26753

The goal is not nec­es­sar­ily to re­vert en­crypted de­liv­ery. The con­cern is that en­crypted de­liv­ery should not fully re­move lo­cal hu­man au­ditabil­ity for sub­agent del­e­ga­tion.

Source analy­sis

Upstream InterAgentCommunication::new_encrypted() de­lib­er­ately ini­tial­izes con­tent as an empty string and stores the pay­load only in en­crypt­ed_­con­tent:

The con­ver­sion used for re­cip­i­ent his­tory then emits only the en­crypted pay­load when­ever en­crypt­ed_­con­tent is pre­sent. Merely pop­u­lat­ing the run­time con­tent field would there­fore not cre­ate a read­able per­sisted ResponseItem; the fix also needs an ex­plicit lo­cal au­dit per­sis­tence path:

The cur­rent v2 mes­sage helper con­structs en­crypted com­mu­ni­ca­tion with empty plain­text con­tent:

send_mes­sage and fol­lowup_­task still de­se­ri­al­ize only tar­get plus the en­crypted mes­sage, then pass that ci­pher­text di­rectly through the shared helper. There is no plain­text com­pan­ion avail­able to per­sist:

The re­ceiver records the model-fac­ing ResponseItem pro­duced by to_­mod­el_in­put_item(). For en­crypted com­mu­ni­ca­tion that item con­tains the en­crypted de­liv­ery pay­load, not read­able au­dit text:

The struc­tured com­mu­ni­ca­tion log has the same fall­back: when con­tent is empty, it records en­crypt­ed_­con­tent as the event con­tent:

Implementation / fix spec

A con­crete im­ple­men­ta­tion can pre­serve en­crypted de­liv­ery and re­store a lo­cal au­dit trail:

Keep the ex­ist­ing en­crypted mes­sage field as the de­liv­ery pay­load.

Add a re­quired, non-en­crypted plain­text com­pan­ion to each v2 com­mu­ni­ca­tion tool:

spawn_a­gent: task_mes­sage send_mes­sage and fol­lowup_­task: a con­sis­tently named plain­text au­dit field, such as task_mes­sage or mes­sage_­text

spawn_a­gent: task_mes­sage

send_mes­sage and fol­lowup_­task: a con­sis­tently named plain­text au­dit field, such as task_mes­sage or mes­sage_­text

Reject empty plain­text au­dit val­ues at the han­dler bound­ary.

Construct InterAgentCommunication with both:

en­crypt­ed_­con­tent set to the en­crypted mes­sage con­tent set to the plain­text au­dit copy

en­crypt­ed_­con­tent set to the en­crypted mes­sage

con­tent set to the plain­text au­dit copy

Keep to_­mod­el_in­put_item() be­hav­ior un­changed so the re­cip­i­ent model still re­ceives ci­pher­text, not the lo­cal au­dit copy.

Persist the plain­text com­pan­ion in the par­ent tool in­vo­ca­tion/​roll­out and re­tain it in struc­tured trace edges and lo­cal com­mu­ni­ca­tion logs.

Match tool calls to de­liv­ered child items us­ing ci­pher­text/​IDs, not plain­text equal­ity. The plain­text field is au­dit meta­data and should not re­place the en­crypted de­liv­ery iden­tity.

Bound the plain­text au­dit field with the same hard size limit as the cor­re­spond­ing del­e­gated mes­sage so the new roll­out/​con­text item can­not grow with­out limit.

The spawn_a­gent half of this shape is im­ple­mented in the fol­low­ing snap­shot com­mit:

ig­na­trem­i­zov@df9a7c4

That pro­to­type makes task_mes­sage re­quired in the v2 spawn schema:

v2 spawn_a­gent schema and re­quired task_mes­sage field

It val­i­dates the field and places it in InterAgentCommunication.content while leav­ing the en­crypted de­liv­ery pay­load in en­crypt­ed_­con­tent:

plain­text au­dit val­i­da­tion

dual plain­text au­dit and en­crypted de­liv­ery con­struc­tion

It also teaches roll­out-trace re­duc­tion to keep read­able au­dit con­tent while us­ing the en­crypted value only to cor­re­late the tool in­vo­ca­tion with de­liv­ery:

sep­a­rate au­dit con­tent from de­liv­ery-match con­tent

cor­re­late de­liv­ery while ap­ply­ing read­able au­dit con­tent

The re­main­ing im­ple­men­ta­tion work is to ap­ply the same dual-con­tent con­tract to send_mes­sage and fol­lowup_­task, and to en­sure every user-fac­ing his­tory/​re­play/​de­bug sur­face reads the au­dit copy rather than falling back to provider ci­pher­text.

Acceptance cri­te­ria

Parent roll­out/​his­tory shows the read­able text for v2 spawn_a­gent, send_mes­sage, and fol­lowup_­task.

The child model still re­ceives only the en­crypted de­liv­ery pay­load when en­cryp­tion is en­abled.

Structured roll­out-trace in­ter­ac­tion edges carry bounded plain­text mes­sage_­con­tent.

Communication logs use plain­text au­dit con­tent when pre­sent and never sub­sti­tute ci­pher­text into a field pre­sented as read­able mes­sage text.

Resume/replay pre­serves the au­dit copy with­out in­ject­ing it into the child model con­text.

Existing plain­text v1 com­mu­ni­ca­tion be­hav­ior is un­changed.

Regression tests cover all three v2 tools and as­sert both sides of the con­tract: read­able lo­cal au­dit data and en­crypted re­cip­i­ent-model in­put.

Do not add Google Play Integrity integration · eu-digital-identity-wallet/av-doc-technical-specification · Discussion #19

github.com

Pinned

· 283 com­ments · 326 replies

In the README, the fol­low­ing is listed:

App and de­vice ver­i­fi­ca­tion based on Google Play Integrity API and Apple App Attestation

App and de­vice ver­i­fi­ca­tion based on Google Play Integrity API and Apple App Attestation

I would like to strongly urge to aban­don this plan. Requiring a de­pen­dency on American tech gi­ants for age ver­i­fi­ca­tion fur­ther deep­ens the EUs de­pen­dency on America and the USAs con­trol over the in­ter­net. Especially in the cur­rent po­lit­i­cal cli­mate I hope I do not have to ex­plain how un­de­sir­able and dan­ger­ous that is.

Furthermore I am sur­prised this is con­sid­ered an im­por­tant next step, given apps like the Dutch iden­tity app Yivi (who has no such de­pen­dency) al­ready ex­ist and can be used for age ver­i­fi­ca­tion by the gov­ern­ment just fine (on the few se­lect plat­forms that work with it). Yivi is even avail­able on Open Source app stores like F-Droid.

I think Yivi’s ex­is­tence should be suf­fi­cient proof that Google Play Integrity in­te­gra­tion is un­nec­es­sary.

Yivi (formerly IRMA) home­page: https://​yivi.app/​en/

0 replies

0 replies

In ad­di­tion, ty­ing age ver­i­fi­ca­tion to spe­cific op­er­at­ing sys­tems and their ven­dors (large American tech com­pa­nies) vi­o­lates two of the three prin­ci­ples listed else­where in this org:

made avail­able to any­one who wants to use it

con­trolled by users

0 replies

0 replies

Digital sov­er­eignty is a nec­es­sary step to re­duce the risks of data pro­cess­ing. There should be no de­pen­den­cies for ex­ter­nal ser­vices from third par­ties at all since each one adds a whole ecosys­tem of po­ten­tial se­cu­rity is­sues.

0 replies

This is in­sane, what’s the threat model? Someone re­motely ex­ploit­ing a de­vice to steal proof of age of ma­jor­ity just to watch p__n (most com­mon use case)? Is it even re­al­is­tic? Why does this ser­vice need an app at all? Just cre­ate a mod­ern web app, maybe even lever­ag­ing Digital Credentials API. I’m tired of app-for-every­thing.

0 replies

This hap­pens be­cause those who draft the tech­ni­cal spec­i­fi­ca­tions don’t know how the tech­nolo­gies they pro­pose work.

As I’ve ex­plained else­where, this is ridicu­lous. Here’s a brief ex­cerpt from one of my posts else­where:

It’s in­cred­i­ble that the European Commission sanc­tions Google for abuse of dom­i­nant po­si­tion and asks to open the op­er­at­ing sys­tem to other stores to al­low free” com­pe­ti­tion and you [the writer of tech­ni­cal spec­i­fi­ca­tions] im­pose the use of tools that ex­clude the free choice of the user and give to Google all the power of choice, that’s re­ally INCREDIBLE

It’s in­cred­i­ble that the European Commission sanc­tions Google for abuse of dom­i­nant po­si­tion and asks to open the op­er­at­ing sys­tem to other stores to al­low free” com­pe­ti­tion and you [the writer of tech­ni­cal spec­i­fi­ca­tions] im­pose the use of tools that ex­clude the free choice of the user and give to Google all the power of choice, that’s re­ally INCREDIBLE

There are dozens of ways to se­cure these apps’ cer­tifi­cates with­out us­ing pro­pri­etary sys­tems. Not to men­tion that Play Integrity sys­tems are 100% il­le­gal.

0 replies

There are dozens of ways to se­cure these apps’ cer­tifi­cates with­out us­ing pro­pri­etary sys­tems.

There are dozens of ways to se­cure these apps’ cer­tifi­cates with­out us­ing pro­pri­etary sys­tems.

Does it need to pro­tect those cer­tifi­cates at all? Maybe I’m too naive, but could­n’t this sim­ply be im­ple­mented by ver­i­fy­ing ran­dom chal­lenge signed by a na­tional iden­tity provider?

User goes to p__n web­site

Website de­tects user is vis­it­ing from Europe

Website down­loads them a file con­tain­ing a ran­dom string

Website tells them to visit ver­i­fyage.gov.ex­am­ple

User logs via iden­tity provider and up­loads the file

Challenge is signed and down­loaded through the browser

User goes back to the p__n web­site and up­loads the file

Website ver­i­fies the chal­lenge is signed by a trusted en­tity

Avoids hav­ing to pro­tect the signed chal­lenge at all since it’s sin­gle use, scheme is sim­i­lar to au­then­ti­cat­ing with SSH or WebAuthn. I haven’t checked the ar­chi­tec­ture thor­ough, per­haps does some­thing sim­i­lar in the end with more bloat in be­tween.

9 replies

Perhaps the log­i­cal con­clu­sion would be that strict age ver­i­fi­ca­tion just is­n’t a use­ful thing to try, and in­stead par­ents should be en­cour­aged to ac­tu­ally make use of the client-side fil­ters that pretty much all smart­phones have. I’ve made that ar­gu­ment here.

Perhaps the log­i­cal con­clu­sion would be that strict age ver­i­fi­ca­tion just is­n’t a use­ful thing to try, and in­stead par­ents should be en­cour­aged to ac­tu­ally make use of the client-side fil­ters that pretty much all smart­phones have. I’ve made that ar­gu­ment here.

I agree, how­ever given the peo­ple* cur­rently see the in­ter­net helped by cer­tain in­ci­dences (*cough* Roblox *cough*) I’m not very hope­ful that this view will change in the near fu­ture. Maybe it could change once the sys­tem is im­ple­mented and fails hor­ri­bly but that will take time.

* Note: With people” I don’t just mean politi­cians. I’ve heard this from clue­less par­ents as well as peo­ple from the I’ve noth­ing to hide”-crowd that truly be­lieve there is no way this could ever go wrong.

What the hell is a p__n web­site?

Porn, pornog­ra­phy. I see no rea­son fo the self-cen­sor­ship here.

I was just fol­low­ing the for­mat of the post I was orig­i­nally re­spond­ing to

0 replies

Fuck Google

0 replies

A manda­tory Google ac­count is un­ac­cept­able in a OSS Project

1 re­ply

*FOSS

Getting ac­cess to a web­site as a EU cit­i­zen by ac­cept­ing the TOS of EU-penalized American mega­corp is peak 1984.

0 replies

Besides the pri­vacy is­sues, this feels like South Korea’s IE6 prob­lem back in the days, every­thing was so tied and de­pen­dent on it, that they could­n’t get rid of it. But I guess we are just hu­mans re­peat­ing mis­takes, get­ting in­flu­enced by lob­by­ists, un­in­formed peo­ple, peo­ple who can’t imag­ine how things will look like in 10 or more years

0 replies

This would be mas­sive hin­der­ance to all South EU states, where adop­tion of non google phones is large.

This would be also mas­sive de­pen­dency on google.

Furthermore, why on earth are you build­ing dig­i­tal ids but then not do­ing IDPs, then forc­ing users to use some ex­tra app for agecheck… they and their OS main­tains…

It is bad UX, it causes is­sues, not sure if adds any se­cu­rity.

0 replies

I work in cy­ber­se­cu­rity and this is a pri­vacy and se­cu­rity night­mare. Just stop.

Using a EU-controlled web­site with na­tional cre­den­tials like it is pro­posed here #18 is the only rea­son­able so­lu­tion.

Or maybe just do not im­ple­ment this at all. People are go­ing to go to p*** web­sites a way or an­other any­way.

1 re­ply

This is one sane re­sponse.

I will word it dif­fer­ently: if this can­not be im­ple­mented with­out hurt­ing A LOT OF PEOPLE, then maybe it should not be im­ple­mented to solve just one prob­lem. Their so­lu­tion is sim­ply dan­ger­ous and will hurt a lot of peo­ple, ad­di­tion­ally will de­stroy com­put­ing by turn­ing it into a closed cage.

Did my com­ment about my 1984 com­ment get­ting re­moved re­ally get re­moved??

Damn.

Tells me all I need to know.

1 re­ply

see no evil, hear no evil, speak no evil 😂

This is a mea­sure to ban gen­eral com­put­ers. We will all be made to give up real com­put­ers and own a locked phone with tele­screen fea­tures and cen­sor­ship.

2 replies

Waiting for the EU to do an universal boot­loader un­lock” law….

That’s ex­actly it. Just in a frog boil­ing mode.

Do not let boil your­self. Age checks to­day, locked hard­ware to­mor­row. Australia ALREADY INCREASED FINES for by­pass­ing age checks, next step will be a manda­tory locked hard­ware” to stop by­pass­ing age checks. The UK ALREADY EXPANDED age checks from porn to harmful con­tent”.

THEY WILL NOT STOP.

Remember that EU ac­tions, for bet­ter or worse, are im­i­tated all over the world.

1 re­ply

It’s more like all the politi­cians are cor­rupts and tak­ing or­der from oli­garchs and pri­vate lob­bies

If the con­cern is Russian farms of­fer­ing au­to­mated ID ver­i­fi­ca­tion for a cost, do note that this security” can and will be spoofed, with a new method ap­pear­ing al­most a few days af­ter the cur­rent one is patched. It will only hurt le­git­i­mate users.

24 replies

Remember the goold old days where bio­met­rics and creepy sur­veil­lance were seen as dystopian? 😂

Talking about ef­fec­tive­ness: the only way to make sure some­one does not kill some­one else is to cut his arm and legs, re­move his teeth too, so this is prob­a­bly what nukeop wants too

That’s ac­tu­ally what you want, you keep say­ing it’s not ef­fec­tive enough.

My opin­ion is fuck this shit”

A rea­son for that is it will never work”

Another is they’re not do­ing it for the kids”″

No, the idea is that it only hurts le­git­i­mate users who sim­ply do not want Android or iOS, and it’s not even ef­fec­tive against the ones it at­tempts to block (and no sane sys­tem can be). So the best way is not to have it.

There will be more sale points of ver­i­fied ac­counts than you could ever imag­ine. With or with­out any at­tes­ta­tion. What is more, EU al­ready CREATED un­der­ground money for that. Congrats EU! If you want to build the biggest un­der­ground our world has seen, then you are on a right path.

WHy not use some­thing like this? Unified Attestation?? Single back­end · Offline ver­i­fi­ca­tion · No de­vice IDs Attestation that feels bor­ingly re­li­able.

Unified Attestation is a free, open-source al­ter­na­tive to Google Play Integrity. It de­liv­ers short-lived in­tegrity to­kens signed by a sin­gle back­end, ver­i­fied of­fline by app servers, and is­sued via a priv­i­leged Android sys­tem ser­vice. It can live along­side Play Integrity, and it’s sim­ple to in­te­grate for app de­vel­op­ers on both the app and server sides.

An ini­tia­tive by Volla Systeme GmbH. Volla Systeme GmbH is a Gemran based Company so European what means that this would make more sense as us­ing a American con­trolled ser­vices that locks peo­ple into the Stock roms that can and will har­vest data with no op­tion to dis­able data har­vest­ing, forced cloud ac­count to in­stall ap­pli­ca­tions over the in­tended way and other anti fea­tures the EU does­n’t stand for based on the Privacy reg­u­la­tion (i am just as­sum­ing and hop­ing here).

12 replies

Unified Attestation has the same prob­lems. It just puts a dif­fer­ent group of com­pa­nies in charge do­ing the same bull­shit that play in­tegrity does.

there should be a fork that re­moves all Antifeatures like Play in­te­girty and face scan­ning as that also re­quires api’s that are only found in google play ser­vices or only work on vanilla play ser­vices de­vice and don’t or func­tion worse on al­ter­na­tives like mi­croG.

there should be a fork that re­moves all Antifeatures like Play in­te­girty and face scan­ning as that also re­quires api’s that are only found in google play ser­vices or only work on vanilla play ser­vices de­vice and don’t or func­tion worse on al­ter­na­tives like mi­croG.

There can­not be a fork. Paradoxically, the source is li­bre, but you can’t mod­ify it in prac­tice, be­cause it re­lies on some at­tes­ta­tion to work and this is en­forced by all par­ties.

The truth is that these peo­ple don’t give a fuck about you and every­thing they do is for the sin­gle pur­pose of screw­ing you, and maybe make some profit along the way

Whois t.me

www.whois.com

Raw Whois Data

Domain Name: t.me Registry Domain ID: 67739971fd634dfca9b07d5e156f39c1-DONUTS Registrar WHOIS Server: whois.go­daddy.com Registrar URL: https://​www.go­daddy.com Updated Date: 2026 – 05-19T06:25:07Z Creation Date: 2010 – 05-20T18:50:32Z Registrar Registration Expiration Date: 2035 – 05-20T18:50:32Z Registrar: GoDaddy.com, LLC Registrar IANA ID: 146 Registrar Abuse Contact Email: @godaddy.com Registrar Abuse Contact Phone: +1.4806242505 Domain Status: client­Trans­fer­Pro­hib­ited https://​icann.org/​epp#client­Trans­fer­Pro­hib­ited Domain Status: clien­tUp­datePro­hib­ited https://​icann.org/​epp#clien­tUp­datePro­hib­ited Domain Status: clien­tRe­new­Pro­hib­ited https://​icann.org/​epp#clien­tRe­new­Pro­hib­ited Domain Status: client­DeletePro­hib­ited https://​icann.org/​epp#client­DeletePro­hib­ited Registry Registrant ID: CR775074207 Registrant Name: Registration Private Registrant Organization: Domains By Proxy, LLC Registrant Street: DomainsByProxy.com Registrant Street: 100 S. Mill Ave, Suite 1600 Registrant City: Tempe Registrant State/Province: Arizona Registrant Postal Code: 85281 Registrant Country: US Registrant Phone: +1.4806242599 Registrant Phone Ext: Registrant Fax: Registrant Fax Ext: Registrant Email: https://​www.go­daddy.com/​whois/​re­sults.aspx?do­main=t.me&ac­tion=con­tact­Do­main­Owner Registry Tech ID: CR775074206 Tech Name: Registration Private Tech Organization: Domains By Proxy, LLC Tech Street: DomainsByProxy.com Tech Street: 100 S. Mill Ave, Suite 1600 Tech City: Tempe Tech State/Province: Arizona Tech Postal Code: 85281 Tech Country: US Tech Phone: +1.4806242599 Tech Phone Ext: Tech Fax: Tech Fax Ext: Tech Email: https://​www.go­daddy.com/​whois/​re­sults.aspx?do­main=t.me&ac­tion=con­tact­Do­main­Owner Name Server: NS-CLOUD-B1.GOOGLEDOMAINS.COM Name Server: NS-CLOUD-B2.GOOGLEDOMAINS.COM Name Server: NS-CLOUD-B3.GOOGLEDOMAINS.COM Name Server: NS-CLOUD-B4.GOOGLEDOMAINS.COM DNSSEC: un­signed URL of the ICANN WHOIS Data Problem Reporting System: http://​wd­prs.in­ter­nic.net/ >>> Last up­date of WHOIS data­base: 2026 – 07-14T18:32:26Z <<< For more in­for­ma­tion on Whois sta­tus codes, please visit https://​icann.org/​epp

TERMS OF USE: The data con­tained in this reg­is­trar’s Whois data­base, while be­lieved by the reg­is­trar to be re­li­able, is pro­vided as is” with no guar­an­tee or war­ranties re­gard­ing its ac­cu­racy. This in­for­ma­tion is pro­vided for the sole pur­pose of as­sist­ing you in ob­tain­ing in­for­ma­tion about do­main name reg­is­tra­tion records. Any use of this data for any other pur­pose is ex­pressly for­bid­den with­out the prior writ­ten per­mis­sion of this reg­is­trar. By sub­mit­ting an in­quiry, you agree to these terms and lim­i­ta­tions of war­ranty. In par­tic­u­lar, you agree not to use this data to al­low, en­able, or oth­er­wise sup­port the dis­sem­i­na­tion or col­lec­tion of this data, in part or in its en­tirety, for any pur­pose, such as trans­mis­sion by e-mail, tele­phone, postal mail, fac­sim­ile or other means of mass un­so­licited, com­mer­cial ad­ver­tis­ing or so­lic­i­ta­tions of any kind, in­clud­ing spam. You fur­ther agree not to use this data to en­able high vol­ume, au­to­mated or ro­botic elec­tronic processes de­signed to col­lect or com­pile this data for any pur­pose, in­clud­ing min­ing this data for your own per­sonal or com­mer­cial pur­poses. Failure to com­ply with these terms may re­sult in ter­mi­na­tion of ac­cess to the Whois data­base. These terms may be sub­ject to mod­i­fi­ca­tion at any time with­out no­tice.

**NOTICE** This WHOIS server is be­ing re­tired. Please use our RDAP ser­vice in­stead.

Samsung will delete your health data if you don't let them use it to train AI

neow.in

Samsung Health in­tro­duces a con­tro­ver­sial AI data con­sent tog­gle that blocks back­ups and threat­ens dele­tion if users opt out.

David Uzondu

Neowin ·

Jul 13, 2026 11:06 EDT

· Hot!

Samsung has started no­ti­fy­ing users that they’d have to con­sent to the use of their pri­vate health data to train new AI mod­els or risk los­ing it for­ever.

Apparently, the com­pany has in­tro­duced a Consent to the Use of Health Data for AI train­ing and mod­el­ling” tog­gle deep in the set­tings of the Samsung Health app and is forc­ing peo­ple to agree to these terms if they want to back up their in­for­ma­tion. This tog­gle gives Samsung the right to use per­sonal met­rics for train­ing and al­go­rithm re­fine­ment. When you try to turn off this op­tion, the app stops you in your tracks with a warn­ing that reads:

Withdraw from this agree­ment?

You will not be able to sync health data with your Samsung ac­count and your health data will be deleted un­less re­tained pur­suant to ap­plic­a­ble law. If re­ten­tion is re­quired, we will erase it as soon as the re­quired re­ten­tion pe­riod ends.

Withdraw from this agree­ment?

You will not be able to sync health data with your Samsung ac­count and your health data will be deleted un­less re­tained pur­suant to ap­plic­a­ble law. If re­ten­tion is re­quired, we will erase it as soon as the re­quired re­ten­tion pe­riod ends.

Samsung said that the data it col­lects will improve Samsung Health” through re­fined ma­chine learn­ing al­go­rithms that an­a­lyze health con­di­tions. The com­pany plans to grab four cat­e­gories: your sleep, your med­ica­tions, your med­ical records, and your cy­cle track­ing de­tails. The com­pany also said that hu­mans (maybe Samsung em­ploy­ees and third-party con­trac­tors) will be able to re­view some of the data col­lected.

The Samsung Health app re­cently un­der­went a mas­sive Generative AI over­haul just in time for the up­com­ing launch of the Galaxy Watch 9 and One UI 9 Watch. Among the many Gen AI fea­tures Samsung added is Vitals, a tool that an­a­lyzes overnight bio­met­ric sig­nals against your base­line to warn you about po­ten­tial sick­ness or fa­tigue. It specif­i­cally mon­i­tors five sig­nals: heart rate, heart rate vari­abil­ity, res­pi­ra­tory rate, skin tem­per­a­ture, and blood oxy­gen lev­els, and it can send you a no­ti­fi­ca­tion if some­thing looks wrong.

Other fea­tures in­clude a Heart Health Score fea­ture that com­bines your body com­po­si­tion, daily phys­i­cal ac­tiv­ity, sleep met­rics, and daily stress into a sin­gle card on the home screen. Samsung has also pack­aged in a Cardio Load met­ric to pre­vent over­train­ing and a Fitness Index that grades how fit you are based on dif­fer­ent met­rics like your VO2 max and step count com­pared to peers.

How to stop Claude from saying load-bearing

jola.dev

Absolutely rip­ping your hair out read­ing Claude re­fer­ring to every­thing as honest takes” and load-bearing seams”? You’re not the only one. But what if I tell you there’s a way to take this mas­sive source of frus­tra­tion and make it so ridicu­lous you can’t but laugh at it? Or just sim­ply fix Claude’s vo­cab­u­lary. I pre­sent to you, the MessageDisplay hook.

First you need a lit­tle script with some re­place­ments set up:

#!/usr/bin/env python3 im­port json, re, sys re­place­ments = { seam”: whatchamacallit”, you’re ab­solutely right”: I’m a com­plete clown”, honest take”: spicy doo­dad”, load-bearing”: cooked” } data = json.load(sys.stdin) text = data.get(“delta”) or ” for phrase, re­place­ment in re­place­ments.items(): pat­tern = r”\b” + re.es­cape(phrase) + r”\b” text = re.sub(pat­tern, re­place­ment, text, flags=re.IG­NORE­CASE) print(json.dumps({ hookSpecificOutput”: { hookEventName”: MessageDisplay”, displayContent”: text, } }))

#!/usr/bin/env python3

im­port json, re, sys

re­place­ments = {

seam”: whatchamacallit”,

you’re ab­solutely right”: I’m a com­plete clown”,

honest take”: spicy doo­dad”,

load-bearing”: cooked”

}

data = json.load(sys.stdin)

text = data.get(“delta”) or

for phrase, re­place­ment in re­place­ments.items():

pat­tern = r”\b” + re.es­cape(phrase) + r”\b”

text = re.sub(pat­tern, re­place­ment, text, flags=re.IG­NORE­CASE)

print(json.dumps({

hookSpecificOutput”: {

hookEventName”: MessageDisplay”,

displayContent”: text,

}

}))

put that in ~/.claude/hooks/wordswap.sh and make it ex­e­cutable with chmod +x ~/.claude/hooks/wordswap.sh. Then to hook it up, add it to your ~/.claude/settings.json in the hooks block like:

{ hooks”: { MessageDisplay”: [ { hooks”: [ { type”: command”, command”: $HOME/.claude/hooks/wordswap.sh” } ] } ] } }

{

hooks”: {

MessageDisplay”: [

{ hooks”: [ { type”: command”, command”: $HOME/.claude/hooks/wordswap.sh” } ] }

]

}

}

Hooks load at startup, so you just need to start a new ses­sion to start your new life.

I’m sure you can come up with much bet­ter and more pro­duc­tive re­place­ments than me. Have fun!

To add this web app to your iOS home screen tap the share button and select "Add to the Home Screen".

10HN is also available as an iOS App

If you visit 10HN only rarely, check out the the best articles from the past week.

Visit pancik.com for more.