Lolly Work 1.1.2

Work 1.1.2 pairs the Work server and render worker with
Lolly 1.1.2, built from
Lolly source fe27a843813b0a653c648e6db078ae8f982b2654. It is published as
Work v1.1.2.
Installation and production acceptance are tracked separately.

Start with the tagged installation guide,
deployment options
and documentation index.

Matching components

Component	Version or source
Lolly product version	1.1.2
Work application	1.1.2
Work Helm chart	0.3.3; appVersion 1.1.2
Lolly source	fe27a843813b0a653c648e6db078ae8f982b2654
Engine	1.281.0
Tool-author core	1.5.0
Lolly web archive for YunoHost	No new archive. lolly-web-1.1.1-ynh1.tar.gz stays current, SHA-256 bc78012aa407983ecc818e63be98ae1b45ed7db1dcad3f4c8d4ffe0c371116c1

Engine and core versions describe their own contracts and are not reset to the
product version. engine-pin.json and content-resolver-pin.json record the
Lolly source above. The maintained producers generated both.

Work 1.1.1 carried engine 1.261.0 and core 1.4.0. Design 1.51.0 needs engine 1.263.0
or later and Strip Hidden Data 1.4.0 needs engine 1.264.0 or later wherever they
render, so a Work 1.1.1 server refuses to load either tool. Engine 1.281.0 is the
release commit's engine: its last change, from Lolly #431, carries wide colours, CMYK
builds and spot inks into the app's palette downloads, which no Work route calls.

What Lolly 1.1.2 needs from this release

Lolly 1.1.2 lists these features as needing Lolly Work. Against a Work 1.1.1 server
they stay hidden or fail as described in the Lolly notes.

• Shared library browsing. GET /api/v1/catalog/assets takes scope=shared,
  up to 16 types and a taxonomyKind with taxonomyId (section, collection or
  folder). Answers report each source's sync status (sources, complete) and
  capabilities.indexedFilters; Lolly shows its Shared library section only when
  that capability is present, and reads 100 records a page (the server allows 500).
  Search caps q at 300 characters and takes scope=shared and source. Paging,
  tag, type and source filters and the paged asset index existed in 1.1.1. The paged
  index now lists sources that have not synced yet under pendingProviders instead of
  waiting for them, and signed and hash-addressed index requests honour paged=1.
  The index is bounded only for sources with more than
  catalogServing.pagedProviderThreshold assets (2,000 by default).
• Reviewed search text. PUT /api/v1/catalog/text-index/<id> stores up to 8,192
  characters that a member reviewed on their own device, for an ext/* or inst/*
  asset the caller can see. It needs catalog.edit. Longer text is refused, not cut,
  and text: null clears the entry. The text is bound to the source revision and
  file it was read from; once either changes, it stops matching browse and search. A
  stale revision answers 409 SOURCE_CHANGED. Work never runs text recognition
  itself. Editing organisation metadata (catalog.edit) was already in 1.1.1.
• Shared project files into the library. POST /api/v1/catalog/submit with
  projectId, fileId and checksum submits a file from a shared project. It needs
  catalog.submit and current access to the project; service tokens are refused.
  groups sets the library audience: left out, every member of the workspace;
  otherwise only groups the submitter belongs to. Work checks the SHA-256 of every
  stored part and of the whole file, then runs the usual scan, quota and review
  steps. Listing projects and copying a file into a project use routes from 1.1.1.
• Source review. POST /api/v1/approvals accepts subjectType: "source-review"
  for 1 to 32 instance-owned originals, with a purpose and a target. Work reads the
  bytes again and checks them (64 MiB per file, 128 MiB in all), and an approval
  chain must exist. Version history advertises sourceReviewCapability
  (frozen-instance-originals-v1) only for instance-owned assets with no provider
  origin, so Request source review appears only there. Files copied in from a
  provider, and renditions, answer 409 SOURCE_UNAVAILABLE.
• Live shared sessions in the desktop and mobile apps. New
  POST /api/v1/collab/sessions/:id/socket-ticket issues a one-use ticket for one
  room, valid for 30 seconds, which the apps send as a WebSocket subprotocol. It needs
  a signed-in member with access to the session and the collab.join grant. Where no
  collaboration gateway runs, such as the Vercel function, it answers
  501 UNAVAILABLE. Tickets are held in memory, so the ticket request and the socket
  upgrade must reach the same process.
• App sign-in to a private Work server. The device sign-in routes are unchanged
  from 1.1.1. Lolly 1.1.2 fixes the lost session in the apps themselves. Work 1.1.2
  keeps the /activate?code= code through the browser sign-in round trip.
• Guest landing. A browser that opens a guest edit link (GET /l/:id?s=) now
  gets a page without scripts that shows the inviter, the tool and the end time in
  UTC, with a name field and, when the link has one, a password field. That request
  sets no cookie and writes no audit entry. The form posts to the same address,
  checks the password with the existing lockout, sets lw_guest, writes one
  guest.admit audit entry and redirects to the tool in the web app. The server still
  limits the guest to that link's tool. A link whose guest links are turned off, or
  whose maker can no longer create them, answers 403 GUEST_LINK_UNAVAILABLE.
  Clients that do not ask for HTML keep the JSON answers.
• Model downloads through Work. When Work serves the shell (instance.shellDir),
  GET and HEAD for /models/<family>[@<hash>]/<file> are answered from the shell
  directory first and otherwise streamed from instance.modelOrigin. The default is
  https://lolli.li; null turns the proxy off. Only an exact HTTPS origin is
  accepted, or a loopback http:// origin for testing. Ranges and validators pass
  through, hash-addressed paths are cached as immutable, and Work keeps no copy. The
  route has no size limit, type list or sign-in check, so by default Work makes
  outbound requests to lolli.li for any visitor. Set null, or a mirror you run, on
  installations that restrict outbound traffic. See configuration.
• Collaboration claims for Scale and keyframes. Work's collaboration gateway
  checks claims with the vendored core. Core 1.5.0 lets a move or scale claim cover
  an object's keyframe track and the content fields a Scale writes, and adds the
  'scale' preview kind. A Work 1.1.1 server, built with core 1.4.0, sees Scale
  previews as resizes.

Other changes since 1.1.1

• Cloudinary and Orange Logic sources. Two new catalog provider kinds,
  cloudinary and orange-logic, configured like the other sources. Orange Logic
  serves renditions only, so a cutover from it answers 422 ORIGINALS_UNAVAILABLE.
  Both drivers are tested against recorded fixtures, not a live tenant. See
  providers.
• Byte ranges on /catalog/ext. A single Range request gets 206 when the file
  is in the memory cache or the source supports ranges (Orange Logic today). Every
  part repeats the sign-in, exposure, source and lifecycle checks. Pinned local copies,
  HEAD and previews still return the whole file.
• History across documents. GET /api/v1/history lists versions across the
  documents a signed-in person can see, 50 at a time by default (at most 100), with
  project, tool, kind, kept, date and archive filters. Entries carry no content or
  email addresses.
• Named and pinned versions. PATCH /api/v1/sessions/:id/versions/:versionId
  sets a label or pin, guarded by annotationRev (409 VERSION_CHANGED). Each person
  can keep 20 versions and each document 100. Retention and space eviction never
  remove a named or pinned version.
• One commit per save. Saving a session writes its head, revision, version and
  audit event in one transaction, for single saves, bulk applies, room recovery and
  restores without a gateway. A bulk apply now also writes a save version for each
  session it changes. On gateway deployments, restores and room write-backs still use
  the room path.
• Resumable uploads. Uploads travel as checksummed 1 MiB parts. Project files
  report missing parts, and their hard ceiling rises from 256 MiB to 4 GiB (the
  default limit stays 25 MiB). New /api/v1/uploads routes feed catalog submissions,
  inspect and optimize. They are off by default: policy.uploads.enabled is false,
  with 64 MiB per file, 128 MiB per owner and 256 MiB per instance when turned on. The
  CLI gains lw upload. See resumable uploads.
• File references. /api/v1/files keeps account-scoped handles to uploaded
  files with a digest and an expiry (uploads.fileTtlHours, 168 hours by default, at
  most 720). Inspect and optimize take file:{id,checksum}, and optimize can keep its
  result as a file reference. The routes answer 404 while uploads are off.
• Automation discovery. GET /api/v1/discovery is public and lists no tool or
  person; /api/v1/discovery/me and /api/v1/discovery/tools are private to the
  caller. GET /api/v1/schema/:toolId now returns the caller's effective schema:
  hidden inputs removed, locked inputs read-on...

Lolly Work 1.1.1

Work 1.1.1 pairs the shared server and its optional Chromium render worker with Lolly 1.1.1, built from Lolly 26cf05324f46dc4cacd65d12d6f454ada181fb5e with engine 1.261 and tool-author core 1.4. The render worker now serves HTTPS, and the shell's content policy lets verified tool code load.

• Tool scripts and styles load from blob: URLs. The shell turns verified tool scripts and styles into blob: URLs. The server's shell policy and the YunoHost package's headers now allow them, so tools such as SUSECON Background and 3D render fully again.
• HTTPS render worker. The worker serves TLS from LW_RENDER_TLS_CERT_FILE and LW_RENDER_TLS_KEY_FILE, with optional CA and server-name settings. The chart takes renderWorker.tls.existingSecret, serverName and caSecret. The 1.1.0 worker image served plain HTTP and failed the chart's HTTPS probes.
• Optional worker user namespace. renderWorker.userNamespace.enabled runs the worker with hostUsers: false and adds CAP_SYS_ADMIN and CAP_SYS_CHROOT inside that namespace only, for clusters where no node seccomp profile can be installed. It needs Kubernetes 1.33+, containerd 2.0+ and kernel 6.3+, and is off by default.
• Connector origins. connectorOrigins in the instance configuration adds up to 32 exact HTTPS origins to the served shell's connect-src, for ingresses that cannot replace response headers.
• Enterprise sign-in. OIDC handling is stricter, and enterprise sessions gain scoped provider logout with back-channel logout.
• Frontend releases without a restart. An optional release-pointer mode serves immutable shell directories from one volume. It is off by default.
• Helm chart 0.3.1 with application version 1.1.1 for the server, optional worker and migration job.

Upgrading applies four new migrations (0067 to 0070). Take a fresh verified backup and complete an independent restore first. The release notes list the matched components, and the installation guide and deployment options cover setup.

Versioned server and render-worker images are public, signed and available for Linux amd64 and arm64. Anonymous manifest and configuration access and both keyless signatures were checked against these exact digests with cosign verify:

ghcr.io/lolly-tools/lolly-work-server@sha256:5fa8b86328bf453635791fc104f4cf6179fc3d3c02a1516da4dea07bd6ae1e55
ghcr.io/lolly-tools/lolly-work-render-worker@sha256:e15db945956db805a991e73e1c7f1d5ce59cdf0787bd93f2aee023d6fee25b6e

Both images build the tagged source 9fddbf2f1ce7736e2ec7948f54c750d49fce1a50, which passed all six main workflows, including native server and real Chromium worker checks on amd64. The render worker came from the tag's release run and is signed by release.yml@refs/tags/v1.1.1. In that run the server image's emulated arm64 build failed twice, inside Node 26's TypeScript stripper. The server release run then built the same tagged source on native amd64 and arm64 runners, and its signature identity is release.yml@refs/heads/main. The attached release-source-images.json records platform digests, layer counts and signing identities. Native arm64 runtime qualification remains open.

YunoHost 1.1.1~ynh1 is a beta test candidate. It pairs Work 1.1.1 with the signed, neutral Lolly 1.1.1 web shell, which loads models from lolli.li on first use. In the runtime run on amd64 Debian Bookworm, using mirror commit 399f670e571148498d217560b3f96acbf2e8f7fa, all seven official package checks passed:

• package lint;
• root installation;
• multiple instances;
• backup and restore;
• same-version upgrade;
• upgrade from the 1.1.0~ynh3 package;
• URL change.

The workflow still reports a failure, because the package linter counts "not in YunoHost's application catalog" as critical. That puts the overall package level at 0. Catalog registration is a separate step that hasn't been taken, and no catalog promotion is claimed. arm64 installation remains unqualified.

For a fresh beta installation, use the tagged package. The immutable Work archive and Lolly web archive have verified checksums. Keep a verified backup and complete a restore test before upgrading an existing instance.

Production rollout is tracked separately from release qualification.

Lolly Work 1.1.0

Work 1.1 brings the current Lolly editor and tool engine into the shared server, with signed catalogs, collaboration, governed providers and an optional Chromium render worker. It pairs Lolly 1.1 with engine 1.259 and tool-author core 1.2.

• Design and Present improvements, responsive controls and updated source navigation.
• Per-caller signed catalogs and verification of tool bytes and asset content before publication.
• Helm chart 0.3.0 with application version 1.1.0 for the server, optional worker and migration job.

Start with the installation guide, deployment options and documentation index.

Versioned server and render-worker images are public, signed and available for Linux amd64 and arm64. Anonymous manifest/configuration access and keyless signatures were independently verified against the exact published digests:

ghcr.io/lolly-tools/lolly-work-server@sha256:db96f0d0f84b81ec609a3816031bd7f78bbb2af87d36f49a6fef8a76c8a656ae
ghcr.io/lolly-tools/lolly-work-render-worker@sha256:8dbe45a9586f426c72cb87eb121da393e18c1074ff3ea5d886a39dceefdfbd5f

The tagged Work source passed all five ordinary CI jobs, including native server and real Chromium worker qualification on amd64 with the matched signed Lolly shell. Helm and deployment checks passed. Multiarch build and signing completed; native arm64 runtime qualification remains separate. The attached source/image metadata records the source, workflow, platform digests and signing identity.

YunoHost 1.1.0~ynh3 is a beta test candidate with host account sign-in, PostgreSQL and a neutral Lolly web shell. Models load from lolli.li on first use. Real root installation, reinstall, multiple-instance installation, backup/restore, same-version upgrade and URL change passed on amd64 Debian Bookworm with YunoHost 12.1.41.2.

The complete seven-test YunoHost workflow failed while setting up the historical 0.2.0~ynh1 baseline: its unsupported full_domain field prevented installation, so the app upgrade never began. The historical shell URL also advertises checksum metadata that differs from its old manifest; the original bytes were not requalified. Upgrade from 0.2 and arm64 installation remain unqualified. No stable YunoHost tag or catalog promotion is claimed.

For a fresh beta installation, use the reviewed YunoHost package and its tagged installation notes. The immutable Work archive and Lolly web archive have verified complete checksums. Preserve a verified backup and complete a restore test before upgrading an existing instance.

Production rollout is tracked separately from release qualification. Desktop and mobile packages are separate releases.