topic Re: Help shape the future of Firefox Sync: 5-minute survey in Discussions

Help shape the future of Firefox Sync: 5-minute survey

adc — Mon, 24 Aug 2026 20:38:55 GMT

Hello Connect community,

The Firefox Sync team is working on improvements, and we'd love your input on what you expect Sync to do and where it might confuse you.

Take the survey

What to know before you start:

It takes about 5 minutes.
There are a few screener questions to make sure we get relevant information.
There’s no right or wrong answers.
Responses are anonymous.

Thanks for helping us make Firefox better!

Re: Help shape the future of Firefox Sync: 5-minute survey

smda — Tue, 25 Aug 2026 09:51:22 GMT

Seems to be closed already

Re: Help shape the future of Firefox Sync: 5-minute survey

adc — Tue, 25 Aug 2026 13:49:21 GMT

Update: we hit our maximum for the survey at this time.

If you did not get to respond, please let us know in this thread what is working and what is confusing about current Firefox sync. Thanks!

Re: Help shape the future of Firefox Sync: 5-minute survey

Jon — Wed, 26 Aug 2026 09:58:28 GMT

Correct, we reached our maximum pretty quickly - but we're gonna keep this thread open for Sync related feedback.

Feel free to let us know how it's working for you, how it can be improved, link to any ideas already posted here on Connect, questions, etc.

Re: Help shape the future of Firefox Sync: 5-minute survey

Charli — Wed, 26 Aug 2026 10:00:10 GMT

Thanks for sharing the survey. Firefox Sync is a useful feature, and getting clearer information about how syncing works across devices would definitely make the experience easier for users. I’ll take the survey and share my feedback.

Re: Help shape the future of Firefox Sync: 5-minute survey

wutongtaiwan — Thu, 27 Aug 2026 12:19:58 GMT

I have no idea what questions this survey even asks. Even if you’re already full, at least you should still show the questions, otherwise we won’t know what to say. I have a suggestion: for Firefox’s sync feature, use post-quantum encryption and post-quantum signature techniques for the synced data. Of course, I don’t know if you’re already using this technology. If not, I hope you can use it; if you are, just forget I said anything.

Re: Help shape the future of Firefox Sync: 5-minute survey

rudihartinger — Mon, 31 Aug 2026 12:52:16 GMT

Since the survey has already ended, I’ll share a few thoughts here.
In my opinion, Sync is an indispensable feature that every modern browser must support, and I think Firefox’s Sync feature is among the best, but there are still a few features I’d like to see added.
For example:
- Syncing tab groups! That would be a very welcome addition.
- The ability to sync New Tab page settings, such as the background and other customizations like shortcuts.
- The ability to sync the toolbar and its settings

Re: Help shape the future of Firefox Sync: 5-minute survey

akayanni — Wed, 02 Sep 2026 01:34:58 GMT

Begs the question... what has been built for Sync that could have other applications. Nice to Sync with Mozilla but what within this code would be usable for me to sync with my web sites? Does anything even need to change for that to happen?

We are having a chat about that here...

Thing is, what did they build into sync that is tough and performant that we could use?

● Good question — most of Sync is boring plumbing, but a few pieces are genuinely hard, battle-tested at
tens-of-millions-of-users scale, and packaged as reusable Rust. Here's what's actually worth taking, ranked
by how liftable it is for our stack (vault/folios/notes/hed):

1. dogear — the tree merger (the crown jewel).
A standalone Rust crate that does a three-way merge of two trees sharing a common ancestor — moves,
deletions, duplicates, structural divergence, all resolved deterministically. This is the PhD-hard part of
sync that everyone underestimates and gets wrong. Mozilla wrote it for bookmarks, but it's generic
tree-merge. Our folios/notes-with-wikilinks are trees/graphs — if two devices reorganize a vault offline,
dogear is the thing that reconciles them without losing a note. Directly reusable, and the highest-value
single piece.

2. The sync15 reconciliation engine.
The delta machinery: track local-vs-remote change sets, timestamp fencing (X-If-Unmodified-Since), interrupt
+ resume a half-finished sync, recover from partial failure, per-record conflict resolution. "Sync that
stays correct when the network dies mid-push" is brutal to get right; this is that, already correct.
Reusable as a crate or as the design.

3. The mirror-table three-way-merge pattern (architecture, not code).
Their local stores keep three copies: local / mirror (last-synced server state) / remote. That triple is
what lets you merge mutable records without clobbering — you diff against the mirror, not the current
server. This maps straight onto our hed model: our undo journals already have the timestamped-record shape;
add a mirror tier and we get lossless sync. Adopt the pattern even if we write our own store.

4. The batch / atomic-commit protocol (the performance win).
Syncstorage's batch API commits many records as one atomic unit, and the client batches to stay under POST
limits — so a 500-note sync is a handful of round-trips, not 500. Plus server backoff respect
(X-Weave-Backoff) and retry-with-jitter. This is the "performant" you're pointing at: it's engineered to
minimize round-trips and behave under load.

5. viaduct + the networking discipline.
Their platform-abstracted HTTP client with built-in backoff/rate-limit handling. Less exciting, but it's the
robust-client behavior you'd otherwise reinvent badly.

6. syncstorage-rs / tokenserver-rs (server side, if we ever self-host at scale).
The actual server — actix-web, Spanner/MySQL backend, quota + TTL enforcement, node assignment — proven at
Mozilla scale. We wouldn't run this now (hed-gate is our edge), but it's the reference for "what a real sync
server has to handle."

The honest split:
- Lift as code: dogear (tree merge), sync15 (reconciliation), viaduct.
- Lift as pattern: the mirror three-way-merge, the batch/atomic-commit protocol, backoff discipline.
- Reference only: syncstorage-rs, tokenserver.

The through-line: the value isn't the transport, it's the merge correctness + interruption safety +
round-trip batching. That's the tough, performant IP — and it's exactly the part we'd get wrong writing sync
from scratch.

Something to note there... Firefox is testing of millions of users, I'm luck to have 5. Wouldn't be a bad idea to consider that across the code base. What is battle tested that Firefox does which as developers we redo and skip on the battle testing.

There's clearly a different way to think about things we you move beyond a php, css, js world.

We haven't found anything we can't do. But to do it we drop out of Firefox. And it won't be tested by an army of 100,000.

"Firefox, the longest living, battle tested, internet code in the world."

You need to expose more of the precious interface to code and be less "browser" in what you consider the assets to be.

We will do a full assessment on this and how it could benefit us.

This isn't me pulling it out of the air, this is what I see after 1+ of writing a set of apps using WASM. We get so far then get pulled into something Chromium where we never wanted to go. We don't have a Tauri with FF in it. We get pushed into a different system. Yet all over the code runs perfectly in Firefox. The PITA is that you guys at Mozilla still think you are making a better browser while sitting on top of the internet platform.

It's not a browser you need to be fussing with to out match Chromium. It's better exposing the code base in a useful manner to developers. And understand that what was once too complicated for us humble mortals we are not grabbing for with AI.

We have 2 views of our code, the web view stuck in a browser where we can remove unwanted chrome and have to fight to save and out plugin get sandboxed in way that doesn't assist.

With spending a billion dollars, I think opening up some of the pathways for developers, particularly those that have been battle tested and are maintained, there might be some joy in this.

Re: Help shape the future of Firefox Sync: 5-minute survey

hi_bye — Thu, 03 Sep 2026 11:02:58 GMT

+1 to syncing tab groups