[mncharity]

Wow. And agreed. One question, re "being a great offline solution", in what sense offline? Able to work without net?

Thinking about dstillman's reply, I was thought-crawling towards a "local/remote vs online/offline" distinction. So Zotero would be local but always online (if net is available). Versus my expectation that when using only local resources, a local tool will be offline.

[jmiserez]

I think dstillman put it best, the features that make Zotero actually useful need to connect to the internet, like fetching metadata. You wouldn't want to enter everything by hand (but you can).

I think your expectation is reasonable (a local tool will be offline when using only local resources), and it's definitely possible with Zotero (disable the automatic translator/style updates) but just not the default setting.

On a technical level, I don't think there is a huge difference between polling and maintaining a persistent connection, if the polling interval is short or the keepalives are long. The real question that I'd find interesting is why the translator/style updates must be "instant". For my use, once a day or once every few hours would probably be more than sufficient.

[dstillman]

> The real question that I'd find interesting is why the translator/style updates must be "instant". For my use, once a day or once every few hours would probably be more than sufficient.

Before Zotero had push-based auto-sync, translator/style updates were indeed once a day, but that meant that, if a high-profile site changed and we pushed out an updated translator, we'd continue to get reports of the site being broken for 24 hours. We could say to update translators manually, but that would only help the people who made it to the forums.

When we added WebSocket support for syncing, we decided to send translator/style update notifications over the same connection. For anyone using auto-sync anyway (many/most users), there's no difference. If you don't use syncing/auto-sync, it's more debatable, but it's a choice between trying not to expose IP addresses that are likely already making at least some other anonymous requests (app updates, retraction checks, OA PDF checks) and decreasing the amount of breakage that users encounter after we've already fixed something.

[jmiserez]

Very interesting insights! Makes sense with the WebSocket reuse and the support requests.

[mncharity]

Nod. One way to address conflicting desires for both opt-in and defaults, is having an onboarding step "want to use net for features... can customize under Preferences/Privacy... [ok]". Informed and consent is somewhat spread in time, and between the step and preferences, but... it seems current best practice.