Future of Sync blog post about services-engineering HOT 11 CLOSED

Well, for what it's worth, we're running syncstorage-rs in production and have already begun migrating folks onto it. We've hit a few odd snags as we work out kinks and unexpected bugs and issues. We've now able to pay a bit more attention toward the self hosting side.

Not to make excuses, but we're a tiny team and have three services we're responsible for, so we can't dedicate time to this as much as we'd want to. Thus some of the slow progress. Still we've got issues out for work that we think needs to be done. Not to say that's all of the bugs that are blocking things, but those are the most evident.

from services-engineering.

For sure; completely understood - it was rhetorical, but I certainly didn't make that clear.

To be frank, I'm concerned about the future of the web, which is the source of my complaints. Firefox is the last line of defence nowadays, between Google having gone their standard route of "do a great job, capture a large market, then be evil; also let it fall apart once shipped and handed over to operations", HTTP/2.0 (and even more so, 3.0) and the web stack in general being far less approachable to new engineers than it was when I started out in 1997, Facebook (the company who claimed it was impossible to achieve 60fps in html5, demonstrating their lack of capability with the tools, then made a library which became prevalent 🙄 ) in general, and Apple doing everything they can to hold back the web and railroad developers into their Walled Dumpster Fire (which still doesn't support WebRTC in WKWebView the last time I checked, for example), and most recently the problems from Chrome which crept into Chromium are now filtering downstream into all the derivatives like Brave, etc... the web is at serious risk if Mozilla fails to honour guard it and makes large slip ups that kill off its userbase 😢

from services-engineering.

Not really, the blog post is more about why we rebuilt it and the benefits (data doesn't randomly disappear because a node dropped, etc.)

We're still working on the stand-alone side of syncstorage-rs. If you're willing to use a potentially not quite ready product, we'd love to get some help or at least a bit of debugging.

As for pointing the latest firefox for android at a different server, we got the details from the folks that wrote that part.

Go to the menu (the shishkebab menu in the lower right corner,

• Settings
• About Firefox Beta (it's at the very bottom)
• Tap the Firefox logo about 5 times, until a "Debug menu enabled" shows at the bottom
  

At that point, you need to be logged out of Sync.
You'll see two additional menu options:
"Custom Firefox Account server" and "Custom Sync server"

This should let you specify the auth and sync server, (or just the sync server). You won't be able to use the quick sign-in, so pick "Use email instead"

I have no idea if this is available on iOS (sorry, I just work on the back end stuff).

If you're willing to help out work on the stand-alone sync server and don't mind working in Rust, you can help us get things going over at https://github.com/mozilla-services/syncstorage-rs. Or you can try running the existing server inside of a Docker image because of the OpenSSL issues around 1.1.1g.

from services-engineering.

Unfortunately, I can't answer that one (no, really. I'm not part of the team that makes the decisions on mobile clients). I'm going to guess that the thought was that this is a specialty feature and that in order to keep things simple for most users, the option was moved to the debug menu. It's my hope that the team is working with Sumo (the mozilla support group) to make sure that the steps are clearly stated.

All that stated, I absolutely appreciate that the latest version of firefox for android is a complete re-write, from a small team. Their focus was getting a version out that worked and didn't have all the problems of the older version. They had to carefully pick and choose what to focus on first. Honestly, they performed miracles, so part of the decision to bury the self-hosting may be due to things not being 100% ready. In short: There may be dragons, and if you find any, PLEASE FILE BUGS!

from services-engineering.

Heh, on the oft unread Mozilla Services blog

from services-engineering.

Rough draft (sorry, internal only for now) https://docs.google.com/document/d/1DjwT-Atcm1qVJVL3_r8V9-BaWupCj2M2xItfFudZ4Qw/edit?usp=sharing

from services-engineering.

Hi there! Looking forward to reading the post.

As a refugee of the absolute nightmare that the chromium ecosystem has become, I've fallen in love with Firefox again (have definite nostalgia of moving from IE6->Firefox 1.0.3), and believe it to be the only reasonable choice in current times.

The quality of the support behind self hosting a syncserver for Firefox is unparalleled (brave/sync#58).

Glad to see Mozilla moving to rust for this component, but it would be great if there were an update on the progress as it's difficult to determine the production-readiness from the https://github.com/mozilla-services/syncstorage-rs repo currently.

from services-engineering.

Is there any new information available regarding the migration for custom sync server to syncstorage-rs?

I am asking, as with my "old" installation I run into this issue with Firefox 80. As I see it, the README for syncstorage-rs is somehow irritating, as in the "Connecting to Firefox" section it still points to documentation of the "old" syncserver. I would like to get rid of Python 2.7.

I personally would also be fine with a complete new installation, as the number of users / browsers using it is quite small.

from services-engineering.

@jrconlin thank you so much for the info on the custom sync server uri setting location; my experience on post version 68 was completely broken without this - why was this buried in a debug menu 😖

from services-engineering.

posted

from services-engineering.

@jrconlin where is it posted? Would love to read & share.

from services-engineering.