At Netflix, we are al­ways ex­plor­ing ways to make our con­tent look and sound even bet­ter. To pro­vide a com­mon ref­er­ence for pro­to­typ­ing bleed­ing-edge tech­nolo­gies within en­ter­tain­ment, tech­nol­ogy and aca­d­e­mic cir­cles with­out com­pro­mis­ing the se­cu­rity of our orig­i­nal and li­censed pro­gram­ming, we’ve de­vel­oped test ti­tles ori­ented around doc­u­men­tary, live ac­tion, and an­i­ma­tion.

Many open source as­sets are avail­able from each pro­ject listed be­low. Our hope is this will en­cour­age more ex­per­i­men­ta­tion, learn­ing, and dis­cov­ery that will ben­e­fit the whole in­dus­try. Many of these ti­tles are also stream­ing on Netflix and are best en­joyed with any HDR con­fig­ured de­vice with your Premium sub­scrip­tion.

You can down­load sin­gle files di­rectly through your web browser, but for large files and long frame se­quences, you may wish to use com­mand line tools. Guidance is in­cluded be­low. Ad Blockers may cause er­rors in your down­load­ing process, so try turn­ing it off if you have is­sues.

Our open source con­tent is avail­able un­der the Creative Commons Attribution 4.0 International Public License.

Nicolas Guillou, a French judge at the International Criminal Court (ICC), was sanc­tioned by the United States un­der a de­ci­sion made by Donald Trump on August 20. The US Treasury Department jus­ti­fied the ac­tion, stat­ing that “Guillou is be­ing des­ig­nated for rul­ing to au­tho­rize the ICC’s is­suance of ar­rest war­rants for Israeli Prime Minister Benjamin Netanyahu and for­mer Minister of Defense Yoav Gallant.” Both men are in­dicted for war crimes and crimes against hu­man­ity for their roles in the de­struc­tion of the Gaza Strip.

In to­tal, six judges and three pros­e­cu­tors from the ICC, in­clud­ing Chief Prosecutor Karim Khan, have been sanc­tioned by the US. In an in­ter­view with Le Monde, the judge ex­plained the im­pact of these mea­sures on his work and daily life. Without com­ment­ing on on­go­ing cases, he called on European au­thor­i­ties to ac­ti­vate a mech­a­nism that could limit the im­pact of US re­stric­tions.

Initially, it was cre­ated to ad­dress hu­man rights vi­o­la­tions, counter ter­ror­ism and com­bat drug traf­fick­ing. Today, nearly 15,000 in­di­vid­u­als are on the US sanc­tions list, mostly mem­bers of Al-Qaeda, the Islamic State group (IS), mafia or­ga­ni­za­tions and the lead­ers of au­thor­i­tar­ian regimes. Among this long list are nine ICC judges.

You have 81.05% of this ar­ti­cle left to read. The rest is for sub­scribers only.

Donations are a key part of what keeps F-Droid in­de­pen­dent and re­li­able and our lat­est hard­ware up­date is a di­rect re­sult of your sup­port. Thanks to do­na­tions from our in­cred­i­ble com­mu­nity, F-Droid has re­placed one of its most crit­i­cal pieces of in­fra­struc­ture, our core server hard­ware. It was over­due for a re­fresh, and now we are happy to give you an up­date on the new server and how it im­pacts the pro­ject.

This up­grade touches a core part of the in­fra­struc­ture that builds and pub­lishes apps for the main F-Droid repos­i­tory. If the server is slow, every­thing down­stream gets slower too. If it is healthy, the en­tire ecosys­tem ben­e­fits.

This server re­place­ment took a bit longer than we would have liked. The biggest rea­son is that sourc­ing re­li­able parts right now is gen­uinely hard. Ongoing global trade ten­sions have made sup­ply chains un­pre­dictable, and that hit the spe­cific com­po­nents we needed. We had to wait for quotes, re­view, re­plan, and wait again when quotes turned out to have un­ex­pected long waits, be­fore we fi­nally man­aged to re­ceive hard­ware that met our re­quire­ments.

Even with the de­lays, the pri­or­ity never changed. We were look­ing for the right server set up for F-Droid, built to last for the long haul.

Another im­por­tant part of this story is where the server lives and how it is man­aged. F-Droid is not hosted in just any data cen­ter where com­mod­ity hard­ware is man­aged by some un­known staff. We worked out a spe­cial arrange­ment so that this server is phys­i­cally held by a long time con­trib­u­tor with a proven track record of se­curely host­ing ser­vices. We can con­trol it re­motely, we know ex­actly where it is, and we know who has ac­cess. That level of trans­parency and trust is not com­mon in in­fra­struc­ture, but it is cen­tral to how we think about re­silience and stew­ard­ship.

This was not the eas­i­est path, and it re­quired care­ful co­or­di­na­tion and ne­go­ti­a­tion. But we are glad we did it this way. It fits our val­ues and our threat model, and it keeps the pro­ject grounded in real peo­ple rather than anony­mous sys­tems.

The pre­vi­ous server was 12 year old hard­ware and had been run­ning for about five years. In in­fra­struc­ture terms, that is a life­time. It served F-Droid well, but it was reach­ing the point where speed and main­te­nance over­head were be­com­ing a daily bur­den.

The new sys­tem is al­ready show­ing a huge im­prove­ment. Stats of the run­ning cy­cles from the last two months sug­gest it can han­dle the full build and pub­lish ac­tions much faster than be­fore. E.g. this year, be­tween January and September, we pub­lished up­dates once every 3 or 4 days, that got down to once every 2 days in October, to every day in November and it’s reach­ing twice a day in December. (You can see this in the fre­quency of in­dex pub­lish­ing af­ter October 18, 2025 in our f-droid.org trans­parency

log). That ex­tra ca­pac­ity gives us more breath­ing room and helps shorten the gap be­tween when apps are up­dated and when those up­dates reach users. We can now build all the auto-up­dated

apps in the

(UTC) morn­ing in one cy­cle, and all the newly in­cluded apps, fixed apps and man­u­ally up­dated apps, through the day, in the evening cy­cle.

We are be­ing care­ful here, be­cause real world in­fra­struc­ture al­ways comes with sur­prises. But the per­for­mance gains are real, and they are ex­cit­ing.

This up­grade ex­ists be­cause of com­mu­nity sup­port, pooled over time, turned into real in­fra­struc­ture, ben­e­fit­ing every­one who re­lies on F-Droid.

A faster server does not just make our lives eas­ier. It helps de­vel­op­ers get timely builds. It re­duces main­te­nance risk. It strength­ens the health of the en­tire repos­i­tory.

So thank you. Every do­na­tion, whether large or small, is part of how this pro­ject stays re­li­able, in­de­pen­dent, and aligned with free soft­ware val­ues.

Hi, I’m Non-Zero-Sum James, your com­pan­ion on this ex­plo­ration of win-win games and how they are es­sen­tial for a bet­ter fu­ture. Each week we’ll ex­plore a new as­pect of game the­ory, moral phi­los­o­phy, eth­i­cal eco­nom­ics and ar­ti­fi­cial in­tel­li­gence—look­ing to solve the com­plex prob­lems we face in our world to­gether.

… or my lead­er­ship style as op­posed to Stuart’s

All the posts are con­nected through the lens of non-zero-sum games, but they fall into a few broad cat­e­gories. You can start your jour­ney with what­ever ap­peals to you:

a new sec­tion es­pe­cially for new­com­ers

the only thing I’m ac­tu­ally qual­i­fied to write about

Your thoughts and con­tri­bu­tions are wel­come. Share, de­bate, and co-cre­ate in the com­ments.

Weather has al­ways sig­nif­i­cantly in­flu­enced my life. When I was a young ath­lete, know­ing the fore­cast in ad­vance would have al­lowed me to bet­ter plan my train­ing ses­sions. As I grew older, I could choose whether to go to school on my mo­tor­cy­cle or, for safety rea­sons, have my grand­fa­ther drive me. And it was him, my grand­fa­ther, who was my go-to me­te­o­rol­o­gist. He fol­lowed all weather pat­terns and fore­casts, a rem­nant of his child­hood in the coun­try­side and his life on the move. It’s to him that I ded­i­cate FediMeteo.

The idea for FediMeteo started al­most by chance while I was check­ing the hol­i­day weather fore­cast to plan an out­ing. Suddenly, I thought how nice it would be to re­ceive reg­u­lar weather up­dates for my city di­rectly in my time­line. After re­flect­ing for a few min­utes, I reg­is­tered a do­main and started plan­ning.

The choice of op­er­at­ing sys­tem was al­most au­to­matic. The idea was to sep­a­rate in­stances by coun­try, and FreeBSD jails are one of the most use­ful tools for this pur­pose.

I ini­tially thought the pro­ject would gen­er­ate lit­tle in­ter­est. I was wrong. After all, weather af­fects many of our lives, di­rectly or in­di­rectly. So I de­cided to struc­ture every­thing in this way:

* I would use a test VPS to see how things would go. The VPS was a small VM on a German provider with 4 shared cores, 4GB of RAM, 120GB of SSD disk space, and a 1Gbit/sec in­ter­net con­nec­tion and now is a 4 euro per month VPS in Milano, Italy - 4 shared cores, 8 GB RAM and 75GB disk space.

* I would sep­a­rate var­i­ous coun­tries into dif­fer­ent in­stances, for both man­age­ment and se­cu­rity rea­sons, as well as to have the pos­si­bil­ity of re­lo­cat­ing just some of them if needed.

* Weather data would come from a re­li­able and open-source friendly source. I nar­rowed it down to two op­tions: wttr.in and Open-Meteo, two so­lu­tions I know and that have al­ways given me re­li­able re­sults.

* I would pay close at­ten­tion to ac­ces­si­bil­ity: fore­casts would be in lo­cal lan­guages, con­sultable via text browsers, with emo­jis to give an idea even to those who don’t speak lo­cal lan­guages, and every­thing would be ac­ces­si­ble with­out JavaScript or other re­quire­ments. One’s mother tongue is al­ways more “familiar” than a sec­ond lan­guage, even if you’re flu­ent.

* I would man­age every­thing ac­cord­ing to Unix phi­los­o­phy: small pieces work­ing to­gether. The more years pass, the more I un­der­stand how valu­able this ap­proach is.

* The soft­ware cho­sen to man­age the in­stances is snac. Snac em­bod­ies my phi­los­o­phy of min­i­mal and ef­fec­tive soft­ware, per­fect for this pur­pose. It pro­vides clear web pages for those who want to con­sult via the web, “speaks” the ActivityPub pro­to­col per­fectly, pro­duces RSS feeds for each user (i.e., city), has ex­tremely low RAM and CPU con­sump­tion, com­piles in sec­onds, and is sta­ble. The de­vel­oper is an ex­tremely help­ful and pos­i­tive per­son, and in my opin­ion, this car­ries equal weight as every­thing else.

* I would do it for my­self. If there was no in­ter­est, I would have kept it run­ning any­way, with­out ex­pand­ing it. So no anx­i­ety or fear of fail­ure.

I started set­ting up the first “pieces” dur­ing the days around Christmas 2024. The scheme was clear: each jail would han­dle every­thing in­ter­nally. A Python script would down­load data, city by city, and pro­duce mark­down. The city co­or­di­nates would be cal­cu­lated via the geopy li­brary and passed to wttr.in and Open-Meteo. No data would be stored lo­cally. This ap­proach gives the abil­ity to process all cities to­gether. Just pass the city and coun­try to the script, and the mark­down would be served. At that point, snac comes into play: with­out the need to use ex­ter­nal util­i­ties, the “snac note” com­mand al­lows post­ing from stdin by spec­i­fy­ing the in­stance di­rec­tory and the user to post from. No need to make API calls with ex­ter­nal util­i­ties, hav­ing to man­age API keys, per­mis­sions, etc.

To sim­plify things, I first struc­tured the jail for Italy. I made a list of the main cities, nor­mal­iz­ing them. For ex­am­ple, La Spezia be­came la_spezia. Forlì, with an ac­cent, be­came forli - this for max­i­mum com­pat­i­bil­ity since each city would be a snac user. I then cre­ated a script that takes this list and cre­ates snac users via “snac ad­duser.” At that point, af­ter cre­at­ing all the users, the script would mod­ify the JSON of each user to con­vert the city name to up­per­case, in­sert the bio (a stan­dard text), ac­ti­vate the “bot” flag, and set the avatar, which was the same for all users at the time. This script is also able to add a new city: just run the script with the (normalized) name of the city, and it will add it - also adding it to the “cities.txt” file, so it will be up­dated in the next weather up­date cy­cle.

I then cre­ated the heart of the ser­vice. A Python ap­pli­ca­tion (initially only in Italian, then mul­ti­lin­gual, sep­a­rat­ing the op­er­a­tional part from the text) able to re­ceive (via com­mand line) the name of a city and a coun­try code (corresponding to the file with texts in the lo­cal lan­guage). The script de­ter­mines the co­or­di­nates and then, us­ing API calls, re­quests the cur­rent weather con­di­tions, those for the next 12 hours, and the next 7 days. I con­ducted ex­per­i­ments with both wttr.in and Open-Meteo, and both gave good re­sults. However, I set­tled on Open-Meteo be­cause, for my uses, it has al­ways pro­vided very re­li­able re­sults. This ap­pli­ca­tion di­rectly pro­vides an out­put in Markdown since snac sup­ports it, at least par­tially.

The cities.txt file is also cru­cial for up­dates. I cre­ated a script - post.sh, in pure sh, that scrolls through all cities, and for each one, launches the FediMeteo ap­pli­ca­tion and pub­lishes its out­put us­ing snac di­rectly via com­mand line. Once the job is fin­ished, it makes a call to my in­stance of Uptime-Kuma, which keeps an eye on the sit­u­a­tion. In case of fail­ure, the mon­i­tor­ing will alert me that there have been no re­cent up­dates, and I can check.

At this point, the sys­tem cron takes care of launch­ing post.sh every 6 hours. The re­quests are se­ri­al­ized, so the cities will up­date one at a time, and the posts will be sent to fol­low­ers.

After list­ing all Italian provin­cial cap­i­tals, I started test­ing every­thing. It worked per­fectly. Of course, I had to make some ad­just­ments at all lev­els. For ex­am­ple, one of the prob­lems en­coun­tered was that snac did not set the lan­guage of the posts, and some users could have missed them. The de­vel­oper was very quick and, as soon as I ex­posed the prob­lem, im­me­di­ately mod­i­fied the pro­gram so that the post could keep the sys­tem lan­guage, set as an en­vi­ron­ment vari­able in the sh script.

After two days, I de­cided to start adding other coun­tries and an­nounce the pro­ject. And the an­nounce­ment was un­ex­pect­edly well re­ceived: there were many boosts, and peo­ple started ask­ing me to add their cities or coun­tries. I tried to do what I could, within the lim­its of my phys­i­cal con­di­tion, as in those days, I had the flu that kept me at home with a fever and ill­ness for sev­eral days. I started adding many coun­tries in the heart of Europe, trans­lat­ing the main in­di­ca­tions into lo­cal lan­guages but main­tain­ing emo­jis so that every­thing would be un­der­stand­able even to those who don’t speak the lo­cal lan­guage. There were some small prob­lems re­ported by some users. One of them: not all weather con­di­tions had been trans­lated, so some­times they ap­peared in Italian - as well as er­rors. In bilin­gual coun­tries, I tried to in­clude all lo­cal lan­guages. Sometimes, un­for­tu­nately, mak­ing mis­takes as I en­coun­tered dy­nam­ics un­known to me or dif­fi­cult to in­ter­pret. For ex­am­ple, in Ireland, fore­casts were pub­lished in Irish, but it was pointed out to me that not every­one speaks it, so I mod­i­fied and pub­lished in English.

The turn­ing point was when FediFollows (@FediFollows@social.growyourown.ser­vices - who also man­ages the site Fedi Directory) started pub­lish­ing the list of coun­tries and cities, high­light­ing the pro­ject. Many peo­ple be­came aware of FediMeteo and started fol­low­ing the var­i­ous ac­counts, the var­i­ous cities. And from here came re­quests to add new coun­tries and some new in­for­ma­tion, such as wind speed. Moreover, I was asked (rightly, to avoid flood­ing time­lines) to pub­lish posts as un­listed - this way, fol­low­ers would see the posts, but they would­n’t fill lo­cal time­lines. Snac did­n’t sup­port this, but again, the snac dev came to my res­cue in a few hours.

But with new coun­tries came new chal­lenges. For ex­am­ple, in my orig­i­nal im­ple­men­ta­tion, all units of mea­sure­ment were in met­ric/​dec­i­mal/​Cel­sius - and this does­n’t adapt well to re­al­i­ties like the USA. Moreover, fo­cus­ing on Europe, al­most all coun­tries were lo­cated in a sin­gle time­zone, while for larger coun­tries (such as Australia, USA, Canada, etc.), this is to­tally dif­fer­ent. So I started de­vel­op­ing a more com­plete and global ver­sion and, in the mean­time, added al­most all of Europe. The new ver­sion would have to be back­ward com­pat­i­ble, would have to take into ac­count time­zone dif­fer­ences for each city, dif­fer­ent mea­sure­ments (e.g., de­grees C and F), as well as, ini­tially more dif­fi­cult part, be­ing able to sep­a­rate cities with the same name based on states or provinces. I had al­ready seen a sim­i­lar prob­lem with the im­ple­men­ta­tion of sup­port for Germany, so it had to be ad­dressed prop­erly.

The orig­i­nal goal was to have a VPS for each con­ti­nent, but I soon re­al­ized that thanks to the qual­ity of snac’s code and FreeBSD’s ef­fi­cient man­age­ment, even keep­ing coun­tries in sep­a­rate jails, the load did­n’t in­crease much. So I de­cided to chal­lenge my­self and the lim­its of the eco­nom­i­cal 4 eu­ros per month VPS. That is, to in­sert as much as pos­si­ble un­til see­ing what the lim­its were. Limits that, to date, I have not yet reached. I would also soon ex­haust the avail­able API calls for Open-Meteo’s free ac­counts, so I tried to con­tact the team and ex­plain every­thing. I was pos­i­tively sur­prised to read that they ap­pre­ci­ated the pro­ject and pro­vided me with a ded­i­cated API key.

Compatible with my free time, I man­aged to com­plete the richer and more com­plete ver­sion of my Python pro­gram. I’m not a pro­fes­sional dev, I’m more ori­ented to­wards sys­tems, so the code is prob­a­bly quite poor in the eyes of an ex­pert dev. But, in the end, it just needs to take an in­put and give me an out­put. It’s not a dae­mon, it’s not a ser­vice that re­sponds on the net­work. For that, snac takes care of it.

So I de­cided to start with a very im­por­tant launch: the USA and Canada. A non-triv­ial part was iden­ti­fy­ing the main cities in or­der to cover, state by state, all the ter­ri­tory. In the end, I iden­ti­fied more than 1200 cities. A num­ber that, by it­self, ex­ceeded the sum of all other coun­tries (at that time). And the pro­gram, now, is able to take an in­put with a sep­a­ra­tor (two un­der­scores: __) be­tween city and state. In this way, it’s pos­si­ble to per­fectly un­der­stand the dif­fer­ences be­tween city and state: new_y­ork__new_y­ork is an ex­am­ple I like to make, but there are many.

The launch of the USA was in­ter­est­ing: de­spite hav­ing had many pre­vi­ous re­quests, the re­cep­tion was ini­tially quite luke­warm, to my ex­treme sur­prise. The num­ber of fol­low­ers in Canada, in a few hours, far ex­ceeded that of the USA. On the con­trary, the coun­try with the most fol­low­ers (in a few days, more than 1000) was Germany. Followed by the UK - which I ex­pected would have been the first.

The VPS held up well. Except for the mo­ments when FediFollows launched (after fix­ing some FreeBSD tun­ing, the ser­vice slowed slightly but did­n’t crash), the load re­mained ex­tremely low. So I con­tin­ued to ex­pand: Japan, Australia, New Zealand, etc.

At the time of the last up­date of this ar­ti­cle (30 December 2025), the sup­ported coun­tries are 38: Argentina, Australia, Austria, Belgium, Brazil, Bulgaria, Canada, Croatia, Czechia, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, India, Ireland, Italy, Japan, Latvia, Lithuania, Malta, Mexico, Netherlands, New Zealand, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Taiwan, the United Kingdom, and the United States of America (with more re­gions com­ing soon!).

Direct fol­low­ers in the Fediverse are around 7,707 and grow­ing daily, ex­clud­ing those who fol­low hash­tags or cities via RSS, whose num­ber I can’t es­ti­mate. However, a quick look at the logs sug­gests there are many more.

The cities cur­rently cov­ered are 2937 - grow­ing based on new coun­tries and re­quests.

There have been some prob­lems. The most se­ri­ous, by my fault, was the API key leak: I had left a de­bug code ac­tive and, the first time Open-Meteo had prob­lems, the er­ror mes­sage also in­cluded the API call - in­clud­ing the API key. Some users re­ported it to me (others just mocked) and I fixed the code and im­me­di­ately re­ported every­thing to the Open-Meteo team, who kindly gave me a new API Key and de­ac­ti­vated the old one.

A fur­ther prob­lem was re­lated to geopy. It makes a call to Nominatim to de­ter­mine co­or­di­nates. One of the times Nominatim did­n’t re­spond, my pro­gram was­n’t able to de­ter­mine the po­si­tion and went into er­ror. I solved this by in­tro­duc­ing co­or­di­nate caching: now the pro­gram, the first time it en­coun­ters a city, re­quests and saves the co­or­di­nates. If pre­sent, they will be used in the fu­ture with­out mak­ing a new re­quest via geopy. This is both lighter on their servers and faster and safer for us.

And the VPS? It has no prob­lems and is sur­pris­ingly fast and ef­fec­tive. FreeBSD 14.3-RELEASE, BastilleBSD to man­age the jails. Currently, there are 39 jails - one for haproxy, the FediMeteo web­site, so ng­inx, and the snac in­stance for FediMeteo an­nounce­ments and sup­port - the other 38 for the in­di­vid­ual in­stances. Each of them, there­fore, has its au­tonomous ZFS dataset. Every 15 min­utes, there is a lo­cal snap­shot of all datasets. Every hour, the home­page is re­gen­er­ated: a small script cal­cu­lates the num­ber of fol­low­ers (counting, in­stance by in­stance, the fol­low­ers of in­di­vid­ual cities, since I don’t pub­lish ex­cept in ag­gre­gate to avoid pos­si­ble tri­an­gu­la­tions and pri­vacy leaks of users). Every hour, more­over, an ex­ter­nal backup is made via zfs-au­to­backup (on en­crypted at rest dataset), and once a day, a fur­ther backup is made in my dat­a­cen­ter, on disks en­crypted with geli. The oc­cu­pied RAM is 501 MB (yes, ex­actly: 501 MB), which rises slightly when up­dates are in progress. Updates nor­mally oc­cur every 6 hours. I have tried, as much as pos­si­ble, to space them out to avoid over­loads in time­lines (or on the server it­self). Only for the USA, I added a sleep of 5 sec­onds be­tween one city and an­other, to give snac the op­por­tu­nity to bet­ter or­ga­nize the send­ing of mes­sages. It prob­a­bly would­n’t be nec­es­sary, with the cur­rent num­bers, but bet­ter safe than sorry. In this way, the USA is processed in about 2 and a half hours, but the other jails (thus coun­tries) can work au­tonomously and send their up­dates.

The av­er­age load of the VPS (taking as ref­er­ence both the last 24 hours and the last two weeks) is about 25%, as it rises to 70/75% when up­dates oc­cur for larger in­stances (such as the USA), or when it is an­nounced by FediFollows. Otherwise, it is on av­er­age less than 10%. So, the VPS still has huge mar­gin, and new in­stances, with new na­tions, will still be in­side it.

This ar­ti­cle, al­though in some parts very con­ver­sa­tional, aims to demon­strate how it’s pos­si­ble to build solid, valid, and ef­fi­cient so­lu­tions with­out the need to use ex­pen­sive and com­plex ser­vices. Moreover, this is the demon­stra­tion of how it’s pos­si­ble to have your on­line pres­ence with­out the need to put your data in the hands of third par­ties or with­out nec­es­sar­ily hav­ing to re­sort to com­plex stacks. Sometimes, less is more.

The suc­cess of this pro­ject demon­strates, once again, that my grand­fa­ther was right: weather fore­casts in­ter­est every­one. He wor­ried about my health and, thanks to his con­cerns, we spent time to­gether. In the same way, I see many fol­low­ers and friends talk­ing to me or among them­selves about the weather, their ex­pe­ri­ences, what hap­pens. Again, in my life, weather fore­casts have helped so­cial­ity and so­cial­iza­tion.

Libsodium is now 13 years old!

I started that pro­ject to pur­sue Dan Bernstein’s de­sire to make cryp­tog­ra­phy sim­ple to use. That meant ex­pos­ing a lim­ited set of high-level func­tions and pa­ra­me­ters, pro­vid­ing a sim­ple API, and writ­ing doc­u­men­ta­tion for users, not cryp­tog­ra­phers. Libsodium’s goal was to ex­pose APIs to per­form op­er­a­tions, not low-level func­tions. Users should­n’t even have to know or care about what al­go­rithms are used in­ter­nally. This is how I’ve al­ways viewed lib­sodium.

Never break­ing the APIs is also some­thing I’m ob­sessed with. APIs may not be great, and if I could start over from scratch, I would have made them very dif­fer­ent, but as a de­vel­oper, the best APIs are not the most beau­ti­fully de­signed ones, but the ones that you don’t have to worry about be­cause they don’t change and up­grades don’t re­quire any changes in your ap­pli­ca­tion ei­ther. Libsodium started from the NaCl API, and still ad­heres to it.

These APIs ex­posed high-level func­tions, but also some lower-level func­tions that high-level func­tions wrap or de­pend on. Over the years, peo­ple started us­ing these low-level func­tions di­rectly. Libsodium started to be used as a toolkit of al­go­rithms and low-level prim­i­tives.

That made me sad, es­pe­cially since it is clearly doc­u­mented that only APIs from builds with –enable-minimal are guar­an­teed to be tested and sta­ble. But af­ter all, it makes sense. When build­ing cus­tom pro­to­cols, hav­ing a sin­gle portable li­brary with a con­sis­tent in­ter­face for dif­fer­ent func­tions is far bet­ter than im­port­ing mul­ti­ple de­pen­den­cies, each with their own APIs and some­times in­com­pat­i­bil­i­ties be­tween them.

That’s a lot of code to main­tain. It in­cludes fea­tures and tar­get plat­forms I don’t use but try to sup­port for the com­mu­nity. I also main­tain a large num­ber of other open source pro­jects.

Still, the se­cu­rity track record of lib­sodium is pretty good, with zero CVEs in 13 years even though it has got­ten a lot of scrutiny.

However, while re­cently ex­per­i­ment­ing with adding sup­port for batch sig­na­tures, I no­ticed in­con­sis­tent re­sults with code orig­i­nally writ­ten in Zig. The cul­prit was a check that was pre­sent in a func­tion in Zig, but that I for­got to add in lib­sodium.

The func­tion cryp­to_­core_ed25519_is_­valid_­point(), a low-level func­tion used to check if a given el­lip­tic curve point is valid, was sup­posed to re­ject points that aren’t in the main cryp­to­graphic group, but some points were slip­ping through.

Edwards25519 is like a spe­cial math­e­mat­i­cal play­ground where cryp­to­graphic op­er­a­tions hap­pen.

It is used in­ter­nally for Ed25519 sig­na­tures, and in­cludes mul­ti­ple sub­groups of dif­fer­ent sizes (order):

* Order L: the “main sub­group” (L = ~2^252 points) where all op­er­a­tions are ex­pected to hap­pen

* Order 2L, 4L, 8L: very large, but not prime or­der sub­groups

The val­i­da­tion func­tion was de­signed to re­ject points not in the main sub­group. It prop­erly re­jected points in the small-or­der sub­groups, but not points in the mixed-or­der sub­groups.

To check if a point is in the main sub­group (the one of or­der L), the func­tion mul­ti­plies it by L. If the or­der is L, mul­ti­ply­ing any point by L gives the iden­tity point (the math­e­mat­i­cal equiv­a­lent of zero). So, the code does the mul­ti­pli­ca­tion and checks that we ended up with the iden­tity point.

Points are rep­re­sented by co­or­di­nates. In the in­ter­nal rep­re­sen­ta­tion used here, there are three co­or­di­nates: X, Y, and Z. The iden­tity point is rep­re­sented in­ter­nally with co­or­di­nates where X = 0 and Y = Z. Z can be any­thing de­pend­ing on pre­vi­ous op­er­a­tions; it does­n’t have to be 1.

The old code only checked X = 0. It for­got to ver­ify Y = Z. This meant some in­valid points (where X = 0 but Y ≠ Z af­ter the mul­ti­pli­ca­tion) were in­cor­rectly ac­cepted as valid.

Concretely: take any main-sub­group point Q (for ex­am­ple, the out­put of cryp­to_­core_ed25519_ran­dom) and add the or­der-2 point (0, -1), or equiv­a­lently negate both co­or­di­nates. Every such Q + (0, -1) would have passed val­i­da­tion be­fore the fix, even though it’s not in the main sub­group.

The fix is triv­ial and adds the miss­ing check:

Now it prop­erly ver­i­fies both con­di­tions: X must be zero and Y must equal Z.

You may be af­fected if you:

* Use a point re­lease <= 1.0.20 or a ver­sion of lib­sodium re­leased be­fore December 30, 2025.

* Use cryp­to_­core_ed25519_is_­valid_­point() to val­i­date points from un­trusted sources

* Implement cus­tom cryp­tog­ra­phy us­ing arith­metic over the Edwards25519 curve

But don’t panic. Most users are not af­fected.

None of the high-level APIs (crypto_sign_*) are af­fected; they don’t even use or need that func­tion. Scalar mul­ti­pli­ca­tion us­ing cryp­to_s­calar­mult_ed25519 won’t leak any­thing even if the pub­lic key is not on the main sub­group. And pub­lic keys cre­ated with the reg­u­lar cryp­to_sign_key­pair and cryp­to_sign_seed_key­pair func­tions are guar­an­teed to be on the cor­rect sub­group.

Support for the Ristretto255 group was added to lib­sodium in 2019 specif­i­cally to solve co­fac­tor-re­lated is­sues. With Ristretto255, if a point de­codes, it’s safe. No fur­ther val­i­da­tion is re­quired.

If you im­ple­ment cus­tom cryp­to­graphic schemes do­ing arith­metic over a fi­nite field group, us­ing Ristretto255 is rec­om­mended. It’s eas­ier to use, and as a bonus, low-level op­er­a­tions will run faster than over Edwards25519.

If you can’t up­date lib­sodium and need an ap­pli­ca­tion-level workaround, use the fol­low­ing func­tion:

This is­sue was fixed im­me­di­ately af­ter dis­cov­ery. All sta­ble pack­ages re­leased af­ter December 30, 2025 in­clude the fix:

A new point re­lease is also go­ing to be tagged.

If lib­sodium is use­ful to you, please keep in mind that it is main­tained by one per­son, for free, in time I could spend with my fam­ily or on other pro­jects. The best way to help the pro­ject would be to con­sider spon­sor­ing it, which helps me ded­i­cate more time to im­prov­ing it and mak­ing it great for every­one, for many more years to come.

A less ro­man­tic truth is that aes­thetic stan­dards rarely travel alone; power tends to fol­low in their wake. An episode at the U. S. State Department this month makes ex­actly this point.

On December 9, Secretary of State Marco Rubio is­sued a memo ti­tled “Return to Tradition” that re­quired all State Department doc­u­ments to switch back to 14-point Times New Roman, over­turn­ing a Biden-era di­rec­tive from 2023 that had turned to 15-point Calibri.

Frankly, most peo­ple likely view both of these sim­ply as “standard type­faces” with­out dis­tin­guish­ing much dif­fer­ence be­tween them. So why would an in­sti­tu­tion of the State Department’s scale bother, twice in three years, to take a stance on some­thing as seem­ingly triv­ial as a de­fault type­face?

John Gruber, an Apple-sphere blog­ger with a well-known ap­petite for po­lit­i­cal com­men­tary, ob­tained the full text of Rubio’s memo and pub­lished it. (It is worth read­ing first.) Rubio’s ra­tio­nale, in sim­pli­fied form, has three parts. First, serif type­faces are said to bet­ter com­mu­ni­cate pro­fes­sion­al­ism, for­mal­ity, and au­thor­ity in of­fi­cial doc­u­ments (¶¶ 6–8). Second, us­ing a serif type­face is align­ing with the White House, the courts, and the State Department’s own his­tor­i­cal prac­tice (¶ 9). Third, the 2023 de­ci­sion was a “cosmetic” ges­ture as­so­ci­ated with di­ver­sity, eq­uity, in­clu­sion, and ac­ces­si­bil­ity (DEIA) pol­i­tics, and the re­ver­sion a cor­rec­tion to that (¶ 10).

Commentary on American par­ti­san pol­i­tics is be­yond the scope of this ar­ti­cle. Still, in neu­tral terms, Trump’s sec­ond term has been marked by an un­usu­ally rapid and sweep­ing ef­fort to re­peal or re­verse the prior ad­min­is­tra­tion’s poli­cies, with DEIA among the ear­li­est tar­gets. The memo it­self cites Executive Order 14151, signed on the first day of the term, that in­structed fed­eral agen­cies to ter­mi­nate all DEIA-related ac­tiv­i­ties, of­fices, po­si­tions, poli­cies, pro­grams, and con­tracts.

That makes the po­lit­i­cal el­e­ment of this ty­pog­ra­phy de­ci­sion fairly plain: it co­heres with, and sig­nals loy­alty to, a broader anti-DEIA agenda. The re­main­ing ques­tion is whether it is only pol­i­tics. Put dif­fer­ently, how per­sua­sive are Rubio’s first two, os­ten­si­bly non­po­lit­i­cal claims about de­sign and con­ven­tions? Or are they merely pre­texts?

To re­cap, a serif type­face is one with ex­tra dec­o­ra­tive strokes, or “serifs,” at the ends of main strokes. A pop­u­lar nar­ra­tive links ser­ifs to stone in­scrip­tions: Roman crafts­men would sketch let­ter out­lines on stone and carve along them; at stroke end­ings and cor­ners, the chisel work flared out­ward, leav­ing the small pro­tru­sions we now call ser­ifs. That lin­eage likely un­der­writes the mem­o’s as­so­ci­a­tion of ser­ifs with “tradition,” “formality,” and “ceremony.”

However, most peo­ple don’t ac­tu­ally know this his­tory, and many can­not re­li­ably dis­tin­guish serif from sans-serif in the first place. The gen­eral pub­lic does­n’t per­ceive serif type­faces as pro­fes­sional and au­thor­i­ta­tive, a pri­ori, be­fore pri­or­i­tiz­ing their use in for­mal set­tings. Instead, peo­ple first ob­serve that gov­ern­ment, acad­e­mia, and cor­po­rate work­places dis­pro­por­tion­ately use serif faces — or are trained to use them — and only then in­fer that ser­ifs must mean pro­fes­sion­al­ism and au­thor­ity.

Even if we limit our­selves to de­sign and his­tor­i­cal con­sid­er­a­tions, Times New Roman, de­spite be­ing a serif type­face, pos­sesses lit­tle of the “professional, solemn, and au­thor­i­ta­tive” aura. The type­face was de­signed in 1931 for The Times of London, and news­pa­per type­faces are typ­i­cally en­gi­neered to print cleanly on cheap pa­per, con­serve space, and sup­port rapid scan­ning.

Those goals are vis­i­ble in the de­tails. The strokes of Times New Roman are rel­a­tively thin (leaving tol­er­ance for ink spread on newsprint), the let­ter­forms are nar­row, and the x-height (the height of the low­er­case “x”) is com­par­a­tively large. There is noth­ing in­her­ently wrong with such func­tional de­sign; it sim­ply does­n’t map neatly onto the “traditional” look of older ser­ifs. On a mod­ern, high-res­o­lu­tion dis­play, the type­face can ap­pear spindly, more util­i­tar­ian than cer­e­mo­nial.

Indeed, the stronger ex­pla­na­tion for Times New Roman’s long reign is­n’t aes­thetic ex­cel­lence, but prac­ti­cal­ity and in­er­tia. Times New Roman was among the small set of type­faces bun­dled with early ver­sions of Windows. It was also pro­moted as “web-safe,” mean­ing web­mas­ters could rea­son­ably as­sume it would ren­der prop­erly across plat­forms. In the early era of dig­i­tal­iza­tion, choos­ing Times New Roman was of­ten less a de­lib­er­ate en­dorse­ment than a de­fault im­posed by lim­ited op­tions. Over time, the habit hard­ened into a stan­dard, and in­sti­tu­tions be­gan to re­quire it with­out much re­flec­tion, ef­fec­tively bor­row­ing their own au­thor­ity to con­fer au­thor­ity upon the type­face.

Professionals who gen­uinely fo­cus on ty­pog­ra­phy have ad­vised against Times New Roman. For ex­am­ple, type de­signer Matthew Butterick elo­quently com­ments:

When Times New Roman ap­pears in a book, doc­u­ment, or ad­ver­tise­ment, it con­notes ap­a­thy. It says, “I sub­mit­ted to the type­face of least re­sis­tance.” Times New Roman is­n’t a type­face choice so much as the ab­sence of a type­face choice, like the black­ness of deep space is­n’t a color. To look at Times New Roman is to gaze into the void.

Similarly, the U. S. Court of Appeals for the Eighth Circuit, in its for­mat­ting ad­vice for lawyers, specif­i­cally cau­tions:

Typographic de­ci­sions should be made for a pur­pose. The Times of London chose the type­face Times New Roman to serve an au­di­ence look­ing for a quick read. Lawyers don’t want their au­di­ence to read fast and throw the doc­u­ment away; they want to max­i­mize re­ten­tion. Achieving that goal re­quires a dif­fer­ent ap­proach — dif­fer­ent type­faces, dif­fer­ent col­umn widths, dif­fer­ent writ­ing con­ven­tions. Briefs are like books rather than news­pa­pers. The most im­por­tant piece of ad­vice we can of­fer is this: read some good books and try to make your briefs more like them.

As for the other U. S. of­fi­cial bod­ies Rubio cites in the memo, many don’t ac­tu­ally use Times New Roman ei­ther. The Supreme Court’s rules re­quire book­let-for­mat fil­ings to be set in the Century fam­ily, and its own opin­ions are type­set in Century Schoolbook from that fam­ily. Originating in the 19th cen­tury, the type­face fea­tures more ex­pan­sive pro­por­tions, bal­anced stroke con­trast, and an el­e­gant form, ex­ud­ing a far more as­sertive pres­ence than Times New Roman. As the name sug­gests, it also be­gan life as a text­book face, op­ti­mized for leg­i­bil­ity. With proper type­set­ting, it reads far bet­ter than a hap­haz­ardly pro­duced Word doc­u­ment set in Times New Roman.

Looking at the leg­is­la­ture, the of­fi­cial PDFs of U. S. Congressional bills use Cheltenham for ti­tles and De Vinne for body text. De Vinne, first re­leased in 1902, shares sim­i­lar­i­ties in style with Century Schoolbook but fea­tures stronger stroke con­trast and more dec­o­ra­tive ser­ifs, giv­ing it an “engraved” qual­ity. Objectively speak­ing, this de­sign bor­ders on be­ing a dis­play type­face — imag­ine the lo­go­type of Harper’s Bazaar, Didot — and is some­what tir­ing to read in body text. But when it comes to con­vey­ing cer­e­mony and solem­nity, it’s far more qual­i­fied than Times New Roman. (After a bill is en­acted into law, it will be type­set in New Century Schoolbook.)

Even the Trump ad­min­is­tra­tion, to which Rubio pledges al­le­giance, con­tra­dicts the “serif tra­di­tion” by us­ing a fash­ion­able tall, high-con­trast serif (Instrument Serif) on the White House web­site. It may look a bit man­nered by gov­ern­ment stan­dards — an im­pres­sion no less bol­stered by its bom­bas­tic rhetoric — but it does man­age to ap­pear as­sertive and em­phatic. Swap in Times New Roman and “AMERICA IS BACK” would read more like a mut­ter.

Thus, the de­sign and his­tor­i­cal rea­sons cited in Rubio’s memo don’t hold up. The for­mal­ity and au­thor­ity of serif type­faces are largely so­cially con­structed, and Times New Roman’s ori­gin story and de­sign con­straints don’t ex­press these qual­i­ties. If Times New Roman car­ries au­thor­ity at all, it’s pri­mar­ily bor­rowed from the au­thor­ity of in­sti­tu­tions that have ad­hered to it. If the sin­cere goal were to “return to tra­di­tion” by re­turn­ing to a serif, there are many choices with deeper pedi­gree and more fit­ting grav­i­tas.

At this point, it might sound as though the ar­gu­ment is trend­ing to­ward a de­fense of the Department’s ear­lier choice: Calibri. Unfortunately, Calibri is also a poor fit for for­mal con­texts. While se­ri­ous­ness and au­thor­ity aren’t the ex­clu­sive province of ser­ifs, Calibri does lit­tle to con­vey those traits.

Typographically, Calibri is a hu­man­ist sans-serif. Such type­faces tend to have open, rounded forms and gen­er­ous aper­tures (look at the wide open­ings in let­ters like a, c, e, and s). Calibri takes that soft­ness es­pe­cially far: ter­mi­nals are vis­i­bly rounded, and many let­ters ap­pear al­most hand­writ­ten, to the ex­tent that its de­signer de­scribed its qual­ity as “warm and soft.”

There’s noth­ing in­her­ently wrong with this style, but one would hardly want an of­fi­cial doc­u­ment or le­gal con­tract to ap­pear “warm and soft.” That is why I have long dis­liked Microsoft’s de­ci­sion to make Calibri the de­fault Office type­face start­ing with Office 2007. A de­fault body type­face should be neu­tral and ver­sa­tile, not ex­ude a tem­per­a­ture. (Microsoft re­placed Calibri with Aptos as the de­fault in 2023, but in­er­tia be­ing what it is, Aptos still ap­pears rel­a­tively rarely in the wild.)

To be fair, the State Department’s 2023 change was jus­ti­fied less as a mat­ter of taste than as an ac­ces­si­bil­ity and in­clu­sion ini­tia­tive. That is, to make doc­u­ments eas­ier to read for in­di­vid­u­als with var­i­ous phys­i­cal and cog­ni­tive con­di­tions. This goal is com­mend­able in it­self, but the means were, at best, loosely con­nected to the end, much like many in­clu­sive mea­sures that were once fash­ion­able in U. S. pol­i­tics and busi­ness in re­cent years.

First, Calibri was not de­signed with ac­ces­si­bil­ity in mind. It was com­mis­sioned by Microsoft to pro­mote its ClearType tech­nol­ogy, with the de­sign ob­jec­tive of ap­pear­ing clear on the low-res­o­lu­tion dis­plays of its time. This means it pri­or­i­tizes smooth­ness un­der spe­cific sub-pixel ren­der­ing tech­niques, rather than en­sur­ing the glyphs are easy to tell apart. If ac­ces­si­bil­ity were truly the goal, one might se­lect a type­face cre­ated for that pur­pose. For ex­am­ple, Atkinson Hyperlegible ad­dresses char­ac­ter dif­fer­en­ti­a­tion by adding ser­ifs, ex­ag­ger­at­ing shapes, and slant­ing strokes, mak­ing it leg­i­ble even un­der low-vi­sion con­di­tions. In con­trast, Calibri has no anti-am­bi­gu­ity de­sign: the up­per­case I and low­er­case l are nearly iden­ti­cal. So much for “accessibility.”

Furthermore, ac­ces­si­bil­ity does­n’t de­pend solely on a doc­u­men­t’s ap­pear­ance but more on its in­ter­nal struc­ture and pre­sen­ta­tion mech­a­nisms. For in­stance, the W3C’s Web Content Accessibility Guidelines (WCAG) state that ac­ces­si­ble con­tent should be per­ceiv­able, op­er­a­ble, un­der­stand­able, and ro­bust. This means that doc­u­ments should have proper se­man­tic struc­ture (so tools like screen read­ers can in­ter­pret con­tent cor­rectly), sup­port cus­tomiz­able lay­outs and fonts, and be com­pat­i­ble with var­i­ous ap­pli­ca­tions and de­vices. If these prin­ci­ples were met, the spe­cific font used would mat­ter lit­tle, as users can ac­cess the con­tent with their pre­ferred tools in their pre­ferred man­ner. Conversely, if a doc­u­ment is tech­ni­cally crude, like a scanned PDF — as many of­fi­cial doc­u­ments are — the use of an “inclusive” font is merely self-con­grat­u­la­tory.

If one in­sisted on a sans-serif for of­fi­cial writ­ing, there are many bet­ter can­di­dates than Calibri: Frutiger (common in air­port wayfind­ing), Myriad (used by Apple for years), the cool and se­ri­ous Univers (or a well-set Helvetica Neue), or con­tem­po­rary neu­tral work­horses like Inter. If a “made in America” sig­nal mat­tered, Public Sans (funded un­der the 21st Century Integrated Digital Experience Act passed dur­ing Trump’s first term) and used by many U. S. gov­ern­ment web­sites is also a good op­tion.

Therefore, Rubio’s crit­i­cism that the pre­vi­ous move was “cosmetic,” while be­ing po­lit­i­cally charged, is­n’t en­tirely un­founded.

Taken to­gether, the Department had pre­vi­ously pur­sued a de­fen­si­ble goal with a poorly matched de­sign in­ter­ven­tion and landed on an ill-fit­ting type­face. Now, for po­lit­i­cal mo­tives, it has re­versed that de­ci­sion and re­turned to a bland, un­re­mark­able de­fault. Between the two, Times New Roman may be the lesser evil: it is more widely rec­og­nized, and it does­n’t clash with the of­fi­cial con­text as overtly as Calibri does. Still, Rubio, or who­ever drafted the memo for him, could have been more can­did. There was no need to dress up a po­lit­i­cal ges­ture with faux-eru­dite claims or to lav­ish praise on a mediocre type­face.

Because Times New Roman just will not make America great again.