Update now if you sync with Zotero Desktop. In every earlier beta, changing an item's type in Zotero Desktop so that the item lost fields — a book turned into a journal article, say — stopped that whole library syncing. The desktop uploads the change as a patch that clears the fields the new type lacks; altero refused it, and from then on every sync of that library failed with Zotero's "Made no progress during upload". beta.5 accepts the change and moves fields and creators the way zotero.org does.
A library that is already stuck recovers by itself, with nothing to reset: Zotero keeps the refused change queued and sends it again on every sync, and the first sync after upgrading uploads it. Tried with Zotero 10.0.6 — a library stuck on beta.4 synced cleanly on its first sync against beta.5, and the item arrived as its new type with its fields moved.
Beyond that fix, this version edits items in the browser — fields, type, creators, tags, related items and new items — and shows changes made elsewhere as they happen. Pull the new image: it runs Python 3.14.10, which distrusts the leaked eMudhra certificate keys. Upgrading needs no database changes.
- Changing an item's type in Zotero Desktop no longer stops sync when the item loses fields; fields and creators move as on zotero.org.
- Building from source needs uv 0.13.4, Python 3.14.10 and Node 24.22.1, which distrust the leaked eMudhra keys (source).
- altero makes its outbound requests with httpx2 in place of httpx, verifying TLS against the system's trust store instead of certifi's.
- The browser interface can be installed as an app on phones and computers, and opens offline; no library data is kept on the device (install).
- Desktop acceptance covers items edited in the browser reaching both desktops, and a desktop edit winning a race: 31 scenarios.
- An open browser page shows changes made elsewhere — a desktop syncing, a group member — without a reload (editing).
- The browser's item list offers Show more until every item is shown; it stopped after the second page, hiding the rest.
- The browser's item list is worked with the arrow keys, Home, End, Enter and F2, as on the desktop;
?lists the shortcuts (items). - An edit in the browser over a change made elsewhere is saved when they differ, and asks which version to keep when they clash (editing).
- The browser interface makes new items: + over the item list, recently used types first, filed into the open collection (editing).
- The browser interface edits an item's tags, offering the library's tags as you type, and shows colours set in Zotero Desktop (editing).
- The browser interface relates items under Related: search the library to add one, remove one, or open it (editing).
- The browser interface edits an item's creators: role, one or two name fields, add, remove, and reorder by drag or menu (editing).
- Icons in the browser interface are larger: 22px in toolbars and the sidebar instead of 16–18px, in slightly larger buttons.
- The browser interface edits an item's fields and changes its type, saving each field as you leave it (editing).
- Desktop acceptance covers a lost parent, a child moved out to the library and a type change: 30 scenarios.
- Uploads are held to zotero.org's rules for what may be a child of what; annotations on EPUBs and HTML snapshots are accepted (parents).
- A note or attachment moved out to the library in Zotero Desktop is top-level here too; it used to stay under its old parent.
- An upload naming a missing parent or collection fails with 409 and names it, so Zotero Desktop uploads it and retries (dependencies).
- An item created from the
/items/newtemplate no longer keeps its empty creator; other nameless creators are refused, as on zotero.org. - A v3 item write without
dateModifiedthat changes nothing keeps its version, as on zotero.org.