fidzu : thunderbird

The team has been working hard behind the scenes laying a strong foundation for the Thunderbird iOS app. Rather than leveraging existing code, we are building natively from scratch. This fresh start allows us to take everything we've learned from Thunderbird Desktop and Android to ensure a fast, reliable, and modern experience on your iPhone right from the start.

Our ultimate goal is seamless cross-device experience. Whether you're sitting at your desktop computer, checking messages on the go, your workflow should feel effortless and unified.

Right now, we are focused heavily on getting the core foundations right. We are excited about the momentum because having clean architecture today means we can layer on exciting new features much faster in the future.

Below we've captured some of our work in progress. Nothing is final, but we wanted to share what we are cooking up so far. If you have feedback, keep reading on. At the bottom of the post we have a link to a user research study where we want to hear from you and what you want to see from Thunderbird for iOS.

Hassle-free setup

We know people are really busy, often doing more than one thing at a time. We're making login fast, secure, and fully automatic, so whether you're signing in with a single click or setting up multiple accounts, you can get to your inbox quickly.

Solid reliable connections

An email app is only as good as its connection. Behind the scenes, we're building a background sync that maintains a steady connection with your provider that keeps your inbox up to date while respecting your battery life.

Core daily tools

Your daily email routine should feel effortless. We're polishing the essentials: a clutter-free, easy-to-read inbox layout paired with a clean, modern editor that lets you format messages smoothly without getting in your way.

Designed for growth

Thunderbird has always belonged to its community. We're structuring the app with clean code and an experimental feature flag system so it's easy for community developers to contribute. This means power users will be able to test out new experimental features early, and external contributors can easily help us extend what the app can do.

When can you try it?

Our goal is to have a first version ready for community testing in the next few months.

Building with our community, not just for people, is core to what we are trying to do. To help us decide what to build next after our first release, we'd love your input. If you had to pick the top three things that matter most to your daily email routine, what would they be?

Survey link

A note to the community

Lastly, we know how long many of you have been asking for and waiting for Thunderbird on iOS. Whether you've dropped a comment on our forums, tagged us on social media, or simply kept an eye on our progress, thank you for your patience!

Bringing Thunderbird to iPhone and iPad isn't just about building an app; it's about doing it right so it serves you reliably for years to come. Today, we want to pop open the hood, share where we are, and work with everyone to design the best possible experience.

The post Thunderbird for iOS: A First Look at the Native iPhone Email App in Development appeared first on The Thunderbird Blog.

01 Oct 2026 10:14pm GMT

Following the rollout of Firefox's Shake to Summarize feature to Android devices this May, we wanted to take a closer look at the modeling work behind the feature. In a previous blog post, we discussed our model selection process. Now that Shake to Summarize has been available on both iOS and Android for a few months, we wanted to take it a step further and outline our approach to prompt development.

This is the story of a Shake to Summarize use case that required a little extra prompt tuning: online recipes.

Framing the Problem

The first step in developing a useful prompt is clearly describing what you want the LLM to do. LLMs thrive on specificity, so the more sharply you can define your task, the better your results are likely to be.

This is especially important when using smaller LLMs (like we are here), since these little models are not as good at reading between the lines and intuiting unstated intentions as their more powerful cousins are.

For this application, we were looking to create summaries. On the face of it, this seems pretty straightforward. However, as we iterated on prompts, we quickly discovered that what constitutes a "good" summary depends largely on what one is summarizing.

For example, a useful summary of a novel should provide us with a quick overview of the plot without getting into too many specific details; we wouldn't expect the summary to contain anything from the text verbatim.

In contrast, a summary of a recipe website should include the recipe essentially as written. If the recipe says "cook lovingly" we might be OK with shortening it to "cook," but if it calls for 4 cups of vegetable broth, a Tbsp of oregano and a tsp of thyme, we want these details relayed to us exactly. Merely stating, "this recipe calls for some broth and some spices" would not be adequate.

Forming the Prompt

From here, it became clear that we wanted not just one "summarize" instruction, but a whole set of instructions - one for each category of webpage that we wished to summarize. We worked with the product team to compile a list of article types that we were targeting for this feature. For each article type, we then gave a brief description of what a good summary would look like:

Recipe - Ingredients as written, along with the key steps, time required, and any tips given by the author or commenters

News - Only the important details: what happened, when, and what would be the likely consequences to the reader

How-to - Start with the required materials, skills, tools, etc., along with the main steps and any specific warnings called out by the author

Review - Highlight the bottom line rating. If it is a product review, include the pros and cons, the price, and who the target audience is.

Research - Key finding and level of confidence the researchers have in their results as well as the projected real-world impact.

Opinion - The main argument, along with any key evidence cited in support

We then wrapped this list in some general instructions to ground the model in the task and came up with our initial prompt (formatted for readability) [source]:

You are a Content Summarizer. You create mobile-optimized summaries by first understanding what users actually need from each type of content.

Process:

Step 1: Identify and Adapt.

Step 2: Based on content type, prioritize:

Recipe - Servings, Total time, Ingredients list, Key steps, Tips.

News - What happened, when, where.

How-to - Total time, Materials, Key steps, Warnings.

Review - Bottom line rating, price.

Opinion - Main arguments, Key evidence.

Personal Blog - Author, main points.

Fiction - Author, summary of plot.

All other content types - Provide a brief summary of no more than 6 sentences.

Step 3: Format for mobile using concise language and paragraphs with 3 sentences maximum.

Bold critical details (numbers, warnings, key terms).

We Foxfooded the above prompt and found that it mostly worked pretty well. The summaries the model produced were concise, accurate, and informative.

The only exception was recipes.

We found that, when the prompt above was used for recipes, the model tended to summarize too much - often leaving out key ingredients, or in some cases, leaving out the recipe entirely.

For example, when asked to summarize a lentil soup recipe the model returned:

The webpage provides a detailed recipe for a vegan lentil soup, which the author claims is the best they've ever made. The soup is made with pantry staples like lentils, diced tomatoes, vegetable broth, and spices (cumin, curry powder, thyme), along with fresh vegetables (onion, carrots, garlic) and greens (kale or collard greens). A key step is blending a portion of the soup to create a creamy texture without dairy.

The summary is accurate, so far as it goes, but it isn't exactly useful. If our goal is to have the summary be a quick way to access the recipe itself, without having to read through the narrative preamble, this wouldn't cut it.

Focusing the Prompt

To address this problem, we needed to be more explicit with the instructions we gave the model when summarizing recipes: we needed to tell it which information we were interested in and which it could safely discard.

Although we could have added this extra guidance directly to the prompt above, doing so risked causing the model to over-index on the recipe formatting and ignore the other article types. Instead, we developed a separate prompt which contained only the recipe instructions and directed recipe summarization requests to use it, rather than the general one [source].

To perform this routing, we used the structured data embedded in each webpage. While this categorization could have been handled by another model pass, metadata from the webpage itself allowed us to quickly and deterministically identify the page categories without additional inference overhead. To capture cases where this data is either missing or inaccurate, we also maintain some lightweight recipe guidance in the general prompt.

After this change, the summary returned by the model for the above recipe became much more usable (shortened for brevity):

Servings: 6

Total Time: 50 minutes

Prep Time: 10 minutes

Cook Time: 40 minutes

Ingredients

• ¼ cup extra virgin olive oil
• 1 medium yellow or white onion, chopped
• 2 carrots, peeled and chopped
• …

Instructions

1. Warm the olive oil in a large Dutch oven or pot over medium heat.
2. Add the chopped onion and carrot, cooking until the onion softens and turns translucent, about 5 minutes.
3. …

Tips

• Use an immersion blender for easier blending without transferring soup.
• …

Nutrition

• Calories: 320
• …

With this change in place, we ran a quick test over a curated set of recipe sites and found that the new system was more than twice as likely to return a complete and accurate summary than our previous one. Success!

The system was now working as expected: summaries were useful and recipes were complete.

Reflections

From this experience we learned that the model produced the best results when it was told explicitly what we wanted it to do. When the instructions were vague or left too much up to the model, performance suffered.

To this end, we found that framing this problem as a routing problem - where the specific kinds of articles are routed to specific prompts - worked well. Since the task of summarization is not monolithic, our summarization pipeline should not be either.

Even though our current approach has only a single category-specific prompt, we hypothesize that the system would see further gains by using dedicated prompts for other page types as well.

More broadly, this experience reinforced an important lesson for us: improving AI systems is not solely about building larger or more capable models. Some of the biggest gains come from reducing ambiguity, narrowing the task, and designing systems that help the model succeed. Within the right harness, smaller, open source models can deliver great value.

While building more capable models continues to advance the field, our experience shows that thoughtful system design and solid engineering still matter.

The post Under the Hood: Prompt tuning Shake to Summarize for recipes appeared first on The Mozilla Blog.

01 Oct 2026 4:00pm GMT

The Rust team is happy to announce a new version of Rust, 1.99.0. Rust is a programming language empowering everyone to build reliable and efficient software.

If you have a previous version of Rust installed via rustup, you can get 1.99.0 with:

$ rustup update stable

If you don't have it already, you can get rustup from the appropriate page on our website, and check out the detailed release notes for 1.99.0.

If you'd like to help us out by testing future releases, you might consider updating locally to use the beta channel (rustup default beta) or the nightly channel (rustup default nightly). Please report any bugs you might come across!

What's in 1.99.0 stable

extern "C" variadics

Rust 1.99.0 stabilizes defining C-ABI variadic functions with "C" and "C-unwind" ABIs. Variadic functions defined this way use a variable argument list (...) and accept an arbitrary number of arguments. Rust could already call externally-defined variadic functions (e.g., libc::printf). With Rust 1.99, these functions can now be written in Rust itself:

/// SAFETY: must be called with (at least) 2 i32 arguments.
unsafe extern "C" fn sum(mut args: ...) -> i32 {
    // SAFETY: guaranteed by the caller.
    let a = unsafe { args.next_arg::<i32>() };
    let b = unsafe { args.next_arg::<i32>() };
    a + b
}

fn foo() -> i32 {
    unsafe { sum(0i32, 2i32) }
}

The type of ... is VaList, which is ABI-compatible with the C va_list type across targets. What types can be read from a VaList is guarded by the VaArgSafe trait.

For more details on c-variadic functions, see the Reference. This release also stabilizes support for defining naked variadic functions with non-"C" ABIs, which must be written via inline assembly.

Layout information from raw pointers

This release settles the safety requirements for retrieving the size and alignment on raw pointers to both Sized (trivially safe, already possible on stable) and non-Sized types.

This is done by stabilizing three functions:

• Layout::for_value_raw
• mem::size_of_val_raw
• mem::align_of_val_raw

Recommend against round-trip unleaking after Box::leak

While there are no changes to the language semantics in Rust 1.99, we have updated the documentation on Box::leak to recommend against patterns that later deallocate that memory. This was done because such code was found to have problematic interactions with current and future potential compiler optimizations, and is especially problematic with the upcoming stabilization of custom allocators. Instead, Box::into_non_null or Box::into_raw should be preferred.

This guidance also applies to other leak functions in the standard library.

Stabilized APIs

• IntoIterator for Box<[T; N]>
• IntoIterator for &Box<[T; N]>
• IntoIterator for &mut Box<[T; N]>
• VecDeque::retain_back
• core::ffi::VaList
• Box::into_non_null
• Box::from_non_null
• Vec::into_parts
• Vec::from_parts
• core::mem::size_of_val_raw
• core::mem::align_of_val_raw
• core::alloc::Layout::for_value_raw
• String::from_utf8_lossy_owned
• string::FromUtf8Error::into_utf8_lossy
• FusedIterator for StepBy<I>
• std::fs::set_times
• std::fs::set_times_nofollow

Other changes

Check out everything that changed in Rust, Cargo, and Clippy.

Contributors to 1.99.0

Many people came together to create Rust 1.99.0. We couldn't have done it without all of you. Thanks!

01 Oct 2026 12:00am GMT