Hey everyone, During the town hall I asked about implementing a way to sync settings between different instances of TB. I just read through the old bug report, and I'm not sure that's the best place to continue the discussion. That bug report (https://bugzilla.mozilla.org/show_bug.cgi?id=446444) seems very focused on using the Firefox Sync method. A couple other methods came up in the town hall discussion. Would it be better to have a discussion about the pros and cons of the different sync methods here (maildev)? Or maybe a new bug report? Or on discourse.mozilla.org? Specifically, the pros and cons of using: Firefox Sync (or some kind of server based system), an integrated peer-to-peer daemon, or just a solid manual export/import tool. Thanks again for talking the idea over. - David Reagan (Oh, and I said FF Sync's docs were bad in the town hall chat, that is no longer the case. :D https://github.com/mozilla-services/syncserver)

Hey David, If I'm not mistaken, this is something  that the new JMAP protocol could implement quite easily. I know it is designed to be able to save Contacts and Calendars to the JMAP server, so if not immediately, could likely easily be extended to do so. On 3/15/2021 4:03 PM, David Reagan wrote > Hey everyone, > > During the town hall I asked about implementing a way to sync settings > between different instances of TB. > > I just read through the old bug report, and I'm not sure that's the best > place to continue the discussion. That bug report > (https://bugzilla.mozilla.org/show_bug.cgi?id=446444) seems very focused > on using the Firefox Sync method. A couple other methods came up in the > town hall discussion. > > Would it be better to have a discussion about the pros and cons of the > different sync methods here (maildev)? Or maybe a new bug report? Or on > discourse.mozilla.org? > > Specifically, the pros and cons of using: Firefox Sync (or some kind of > server based system), an integrated peer-to-peer daemon, or just a solid > manual export/import tool. > > Thanks again for talking the idea over. > > - David Reagan > > (Oh, and I said FF Sync's docs were bad in the town hall chat, that is > no longer the case. :D https://github.com/mozilla-services/syncserver) > _______________________________________________ > Maildev mailing list -- maildev@lists.thunderbird.net > To unsubscribe send an email to maildev-leave@lists.thunderbird.net >

Firefox put many many, many, man years of work into Firefox sync. If we want a sync solution, certainly it would make sense to use that same code. That's why it's been the focus of the discussion: if you want something else, you'd have to put up a good plan, and have a *really* good argument why spending resources on that alternative approach would make sense.  -Magnus On 2021-03-15 22:03, David Reagan wrote: > Hey everyone, > > During the town hall I asked about implementing a way to sync settings > between different instances of TB. > > I just read through the old bug report, and I'm not sure that's the > best place to continue the discussion. That bug report > (https://bugzilla.mozilla.org/show_bug.cgi?id=446444) seems very > focused on using the Firefox Sync method. A couple other methods came > up in the town hall discussion. > > Would it be better to have a discussion about the pros and cons of the > different sync methods here (maildev)? Or maybe a new bug report? Or > on discourse.mozilla.org? > > Specifically, the pros and cons of using: Firefox Sync (or some kind > of server based system), an integrated peer-to-peer daemon, or just a > solid manual export/import tool. > > Thanks again for talking the idea over. > > - David Reagan > > (Oh, and I said FF Sync's docs were bad in the town hall chat, that is > no longer the case. :D https://github.com/mozilla-services/syncserver) > _______________________________________________ > Maildev mailing list -- maildev@lists.thunderbird.net > To unsubscribe send an email to maildev-leave@lists.thunderbird.net

I strongly disagree. Why intentionally do anything that ties TB even further to the Mozilla code base? We have resources now. We should be doing everything possible to gain independence from Mozilla, this would do exactly the opposite. Implement JMAP, then implement a sync protocol/system on top of it for syncing settings, that is not reliant on Mozilla, or any other protocol or service, one that 'just works' with any JMAP server (build it and they will come). Timo has already plainly stated that a) he is interested in adding JMAP support to dovecot, but b) it is not a high priority for him because there are no clients out there that could use it. If TB supported it, that would eliminate that 'excuse' - not that he is using it as an excuse, it is just the reality - but a reality that you, the TB Council/Devs, can change. TB could do something really amazing here... take a leap of faith... be the first... Hell, what I would do if I were on the Board is start talks with Fastmail to build some kind of partnership where TB makes it easy for people to create Fastmail accounts, free at first (maybe these could be either @fastmail or @thunderbird.net addresses), but with some paid tiers, the revenues of which are shared between Fastmail and TB. Paid tiers could provide any number of extras/goodies, from more storage, to unlimited storage, multiple email addresses, and even bring your own domain, all of which are able to take full advantage of the goodness of JMAP. I do not want to store my stuff on anything of Mozilla's. Charles On 3/16/2021 3:56 PM, Magnus Melin wrote > Firefox put many many, many, man years of work into Firefox sync. If we > want a sync solution, certainly it would make sense to use that same > code. That's why it's been the focus of the discussion: if you want > something else, you'd have to put up a good plan, and have a *really* > good argument why spending resources on that alternative approach would > make sense. > >  -Magnus > > On 2021-03-15 22:03, David Reagan wrote: >> Hey everyone, >> >> During the town hall I asked about implementing a way to sync settings >> between different instances of TB. >> >> I just read through the old bug report, and I'm not sure that's the >> best place to continue the discussion. That bug report >> (https://bugzilla.mozilla.org/show_bug.cgi?id=446444) seems very >> focused on using the Firefox Sync method. A couple other methods came >> up in the town hall discussion. >> >> Would it be better to have a discussion about the pros and cons of the >> different sync methods here (maildev)? Or maybe a new bug report? Or >> on discourse.mozilla.org? >> >> Specifically, the pros and cons of using: Firefox Sync (or some kind >> of server based system), an integrated peer-to-peer daemon, or just a >> solid manual export/import tool. >> >> Thanks again for talking the idea over. >> >> - David Reagan >> >> (Oh, and I said FF Sync's docs were bad in the town hall chat, that is >> no longer the case. :D https://github.com/mozilla-services/syncserver) >> _______________________________________________ >> Maildev mailing list -- maildev@lists.thunderbird.net >> To unsubscribe send an email to maildev-leave@lists.thunderbird.net > _______________________________________________ > Maildev mailing list -- maildev@lists.thunderbird.net > To unsubscribe send an email to maildev-leave@lists.thunderbird.net

Using what's most suitable is a per-requisite for success. The Firefox Sync code is open source, and can even be run independently, not that it probably would make any sense. You're free to run a sync server and store your stuff there. Our resources are not at all abundant. To recreate sync properly you'd have to put *all* the resources onto only that. Seems rather pointless if you ask me. JMAP is a completely different discussion. All mails, calendars and address books can already be stored on the servers with the solutions we have.  This discussion was about sync of account prefs and such.  -Magnus On 2021-03-16 22:09, Tanstaafl wrote: > I strongly disagree. > > Why intentionally do anything that ties TB even further to the Mozilla > code base? > > We have resources now. We should be doing everything possible to gain > independence from Mozilla, this would do exactly the opposite. > > Implement JMAP, then implement a sync protocol/system on top of it for > syncing settings, that is not reliant on Mozilla, or any other > protocol or service, one that 'just works' with any JMAP server (build > it and they will come). Timo has already plainly stated that a) he is > interested in adding JMAP support to dovecot, but b) it is not a high > priority for him because there are no clients out there that could use > it. If TB supported it, that would eliminate that 'excuse' - not that > he is using it as an excuse, it is just the reality - but a reality > that you, the TB Council/Devs, can change. > > TB could do something really amazing here... take a leap of faith... > be the first... > > Hell, what I would do if I were on the Board is start talks with > Fastmail to build some kind of partnership where TB makes it easy for > people to create Fastmail accounts, free at first (maybe these could > be either @fastmail or @thunderbird.net addresses), but with some paid > tiers, the revenues of which are shared between Fastmail and TB. Paid > tiers could provide any number of extras/goodies, from more storage, > to unlimited storage, multiple email addresses, and even bring your > own domain, all of which are able to take full advantage of the > goodness of JMAP. > > I do not want to store my stuff on anything of Mozilla's. > > Charles > > > On 3/16/2021 3:56 PM, Magnus Melin wrote >> Firefox put many many, many, man years of work into Firefox sync. If we >> want a sync solution, certainly it would make sense to use that same >> code. That's why it's been the focus of the discussion: if you want >> something else, you'd have to put up a good plan, and have a *really* >> good argument why spending resources on that alternative approach would >> make sense. >> >>  -Magnus >> >> On 2021-03-15 22:03, David Reagan wrote: >>> Hey everyone, >>> >>> During the town hall I asked about implementing a way to sync settings >>> between different instances of TB. >>> >>> I just read through the old bug report, and I'm not sure that's the >>> best place to continue the discussion. That bug report >>> (https://bugzilla.mozilla.org/show_bug.cgi?id=446444) seems very >>> focused on using the Firefox Sync method. A couple other methods came >>> up in the town hall discussion. >>> >>> Would it be better to have a discussion about the pros and cons of the >>> different sync methods here (maildev)? Or maybe a new bug report? Or >>> on discourse.mozilla.org? >>> >>> Specifically, the pros and cons of using: Firefox Sync (or some kind >>> of server based system), an integrated peer-to-peer daemon, or just a >>> solid manual export/import tool. >>> >>> Thanks again for talking the idea over. >>> >>> - David Reagan >>> >>> (Oh, and I said FF Sync's docs were bad in the town hall chat, that is >>> no longer the case. :Dhttps://github.com/mozilla-services/syncserver) >>> _______________________________________________ >>> Maildev mailing list --maildev@lists.thunderbird.net >>> To unsubscribe send an email tomaildev-leave@lists.thunderbird.net >> _______________________________________________ >> Maildev mailing list --maildev@lists.thunderbird.net >> To unsubscribe send an email tomaildev-leave@lists.thunderbird.net >

Looks like the discussion is happening here. Ok. :) *Option number one* is something based on Firefox sync. It's not my favorite method. I actually avoided Firefox sync for years. I only started using it when Xmarks bit the dust. I strongly believe that I should be able to control my own data, and I don't like trusting anyone else with it unless I have to. As in I run my own email server and avoid third-party services as much as I can. When I first heard you could host your own Firefox sync server, I looked into it, and promptly ran into a wall of no docs, and not enough time to figure it out from the code. It looks like that issue may be fixed. So that's definitely on my todo list to look into again. So the cons (imo): * Adding another third party having access to my data, or having to host yet another tool for myself. o This would be especially worrisome since I'd really have to evaluate the security of FF sync. I've avoided that by not syncing passwords in FF... * Needing to send my data out of my LAN in order for it to sync. o Related, not being able to sync without general internet access. Yes, for me it is rare, but for someone out on the seas, or somewhere with slow internet? Having to sync via the Internet could be frustrating. * TB would need to use Mozilla's servers, or host their own, for those users who aren't willing to put the effort into being secure I am. The pros: * Code for syncing already exists. * TB already has work done to make it work. * We'd get working sync faster. Ultimately, I'll be fine with syncing via a self hosted FF sync server. If I couldn't host it myself easily, then I wouldn't use it. *Option number two* would be some kind of peer-to-peer sync tool built into TB. This is my preferred method. I avoid Dropbox by using Syncthing, and it is really nice not having to worry about some third party putting limits on what I can do. And while people can figure out that I use Syncthing, they don't know what I actually use it for. The cons: * There likely isn't any code for syncing peer-to-peer that TB could use right away. * Additional attack surface for compromises. * Ongoing maintenance. The pros: * TB won't need to host any new infrastructure, depending on how the service works. * No third parties involved in handling my data. * TB won't have to worry about what people are using their servers for. o This point would be enough to convince me. Having to worry that someone is using my servers for criminal acts and run my stuff with that in mind would not be easy. Or cheap. * Only need a LAN to get your data synced. So people with bad internet won't be left out. * Can be built into TB, and only TB, so less work ensuring things work with a third party tool. * * *Option number three* would be a settings export and import tool. Something simple that just outputs all the settings as a text file, then you can copy that file where ever you need it, and import the settings there. The cons: * No automatic syncs. * Would overwrite all your local settings, or else TB would have to make a much more difficult to code export/import wizard with granular controls. The pros: * Might be much much simpler to implement. * It would be possible to sync via syncthing/dropbox/etc. * Depending on the format, might be able to template the config via config management tools like Ansible. So, here's a question, would the extension api allow an addon to perform the peer-to-peer sync method? Last time I looked into writing extensions was back when TB was just moving away from the XUL stuff to the new way. And I haven't had time to dig back into that since. Hope this helps further the discussion in a positive way. I've been using TB since it was Netscape Mail. Only took a few years break before coming back when I got tired of gmail being bad, and there not being any other mature cross platform mail client. So I definitely want to see TB keep growing. - David On 3/16/21 1:22 PM, Magnus Melin wrote: > Using what's most suitable is a per-requisite for success. > > The Firefox Sync code is open source, and can even be run > independently, not that it probably would make any sense. You're free > to run a sync server and store your stuff there. > > Our resources are not at all abundant. To recreate sync properly you'd > have to put *all* the resources onto only that. Seems rather pointless > if you ask me. > > JMAP is a completely different discussion. All mails, calendars and > address books can already be stored on the servers with the solutions > we have.  This discussion was about sync of account prefs and such. > >  -Magnus > > On 2021-03-16 22:09, Tanstaafl wrote: >> I strongly disagree. >> >> Why intentionally do anything that ties TB even further to the >> Mozilla code base? >> >> We have resources now. We should be doing everything possible to gain >> independence from Mozilla, this would do exactly the opposite. >> >> Implement JMAP, then implement a sync protocol/system on top of it >> for syncing settings, that is not reliant on Mozilla, or any other >> protocol or service, one that 'just works' with any JMAP server >> (build it and they will come). Timo has already plainly stated that >> a) he is interested in adding JMAP support to dovecot, but b) it is >> not a high priority for him because there are no clients out there >> that could use it. If TB supported it, that would eliminate that >> 'excuse' - not that he is using it as an excuse, it is just the >> reality - but a reality that you, the TB Council/Devs, can change. >> >> TB could do something really amazing here... take a leap of faith... >> be the first... >> >> Hell, what I would do if I were on the Board is start talks with >> Fastmail to build some kind of partnership where TB makes it easy for >> people to create Fastmail accounts, free at first (maybe these could >> be either @fastmail or @thunderbird.net addresses), but with some >> paid tiers, the revenues of which are shared between Fastmail and TB. >> Paid tiers could provide any number of extras/goodies, from more >> storage, to unlimited storage, multiple email addresses, and even >> bring your own domain, all of which are able to take full advantage >> of the goodness of JMAP. >> >> I do not want to store my stuff on anything of Mozilla's. >> >> Charles >> >> >> On 3/16/2021 3:56 PM, Magnus Melin wrote >>> Firefox put many many, many, man years of work into Firefox sync. If we >>> want a sync solution, certainly it would make sense to use that same >>> code. That's why it's been the focus of the discussion: if you want >>> something else, you'd have to put up a good plan, and have a *really* >>> good argument why spending resources on that alternative approach would >>> make sense. >>> >>>  -Magnus >>> >>> On 2021-03-15 22:03, David Reagan wrote: >>>> Hey everyone, >>>> >>>> During the town hall I asked about implementing a way to sync settings >>>> between different instances of TB. >>>> >>>> I just read through the old bug report, and I'm not sure that's the >>>> best place to continue the discussion. That bug report >>>> (https://bugzilla.mozilla.org/show_bug.cgi?id=446444) seems very >>>> focused on using the Firefox Sync method. A couple other methods came >>>> up in the town hall discussion. >>>> >>>> Would it be better to have a discussion about the pros and cons of the >>>> different sync methods here (maildev)? Or maybe a new bug report? Or >>>> on discourse.mozilla.org? >>>> >>>> Specifically, the pros and cons of using: Firefox Sync (or some kind >>>> of server based system), an integrated peer-to-peer daemon, or just a >>>> solid manual export/import tool. >>>> >>>> Thanks again for talking the idea over. >>>> >>>> - David Reagan >>>> >>>> (Oh, and I said FF Sync's docs were bad in the town hall chat, that is >>>> no longer the case. :Dhttps://github.com/mozilla-services/syncserver) >>>> _______________________________________________ >>>> Maildev mailing list --maildev@lists.thunderbird.net >>>> To unsubscribe send an email tomaildev-leave@lists.thunderbird.net >>> _______________________________________________ >>> Maildev mailing list --maildev@lists.thunderbird.net >>> To unsubscribe send an email tomaildev-leave@lists.thunderbird.net >> > _______________________________________________ > Maildev mailing list -- maildev@lists.thunderbird.net > To unsubscribe send an email to maildev-leave@lists.thunderbird.net