Create Sharing Publishing

Create: Sharing & Publishing

Once your wallpaper works, you can share it two ways: export it to a portable .zip file you hand to anyone, or publish it to the Sucrose Store so other users can browse and install it in-app. Both paths run through the Portal's ThemeShare dialog. This page documents the .zip package contract (what a valid export must contain), the publish-to-Store flow and its hard limits (a 90 MB cap, field-length rules, validity checks), the reporting mechanism, and why the GitHub Store backend cannot accept uploads while the Soferity backend can.

Contents

• Two ways to share
• Export to a .zip
• The .zip package contract
• SucroseInfo field limits
• Publish to the Store
• The publish pipeline
• Why GitHub cannot publish
• Reporting a wallpaper
• Tips and gotchas
• See also

Two ways to share

Action	Where	Result	Backend
Export	ThemeShare → Export	A portable .zip saved to disk (default to Desktop)	Local; no network
Publish	ThemeShare → Publish	Uploaded to the Store for everyone	Soferity only

Open both from a Library card's Share action (see Managing Library). A wallpaper that came from the Store is marked with a SucroseStore.json file and cannot be re-published.

Export to a .zip

The Export action compresses your whole wallpaper folder into a single .zip:

1. From the Library card, choose Share → Export.
2. A Save dialog opens with a default file name derived from your wallpaper title, initially pointing at the Desktop.
3. Sucrose compresses the folder using the smallest-size compression level, writing all files at the root of the archive (no extra nesting folder).

The resulting .zip is the shareable package format: anyone can import it back into their Library by dropping it on the Portal (see Managing Library). The same archive is what the publish flow uploads.

The .zip package contract

A valid Sucrose wallpaper .zip must satisfy the package contract — the same validation runs on import and on publish. In order, the archive is checked for:

1. File exists, is accessible, and is not locked.
2. Extension is exactly .zip and the file begins with the ZIP magic header 50 4B 03 04. (The 7-Zip variant of the validator checks the 7z magic header 37 7A BC AF 27 1C 00.)
3. No root nesting — the wallpaper's files must be at the top of the archive, not inside a single wrapper folder.
4. Contains SucroseInfo.json — present, non-empty, and valid JSON.
5. SucroseInfo field limits are within range (see the next section).
6. Localization entries each have Title ≤ 50 and Description ≤ 500.
7. Thumbnail and Preview files are present in the archive (the files named by the manifest).
8. AppVersion ≤ the current app version — a wallpaper made with a newer Sucrose cannot be installed on an older one.
9. Type is a valid WallpaperType and the per-type Source is valid: Gif / Web / Video / Application require the source file present with the correct extension; Url / YouTube require valid URLs.
10. Optional SucroseProperties.json and SucroseCompatible.json are validated if present (the {0} / {1} placeholder tokens must be correct).

If any check fails, the package is rejected. See Create Package Format for the manifest itself and Create Customization Controls / Create JS Bridge for the optional files.

SucroseInfo field limits

The publish and import validators enforce these limits on the manifest fields:

Field	Limit
Title	≤ 50 characters
Description	≤ 500 characters
Author	≤ 50 characters
Contact	≤ 250 characters; must be a valid URL or email
Tags	1–5 entries, each 1–20 characters
Arguments	≤ 250 characters
Localization.<lang>.Title	≤ 50 characters
Localization.<lang>.Description	≤ 500 characters

Stay within these when authoring (see Create Step By Step) so your wallpaper passes validation on the first try.

Publish to the Store

Publishing uploads your .zip to the Soferity Store backend so other users can find and install it. From the Library card choose Share → Publish. Before anything uploads, Sucrose:

• Blocks Store-sourced wallpapers. If the wallpaper has a SucroseStore.json marker (it came from the Store), publishing is refused with an "Already" warning.
• Requires connectivity and downloads the catalog to populate a Category combo box (categories sorted by their localized names) so you can pick where your wallpaper goes.

The publish pipeline

When you confirm the publish, Sucrose runs five steps in order — Limit → Compress → Size → Check → Upload:

Step	What happens	Constraint
1. Limit	Checks your per-user upload quota against the Soferity backend.	Quota must allow another upload
2. Compress	Compresses the wallpaper to a temporary .zip.	Must pass compatibility validation
3. Size	Measures the .zip.	Hard cap 90 MB; over-limit aborts
4. Check	Runs the full .zip package contract (see above).	Must pass all checks
5. Upload	Streams the archive to Soferity as multipart/form-data (field file, content type application/zip), with live progress.	—

The upload is keyed to your anonymous user GUID and includes the chosen category and the current Sucrose app version. Progress is reported as the bytes stream up.

The 90 MB cap and the .zip package contract are the two practical constraints to design around. Keep assets lean (compress media, drop unused files) so you stay well under the limit.

Why GitHub cannot publish

Sucrose's Store has two interchangeable backends, chosen by the StoreServerType setting (default Soferity):

• Soferity — a custom backend that supports byte-accurate downloads, search patterns, uploading, and reporting.
• GitHub — the public Taiizor/Store repository, browsed read-only through the GitHub Contents API. It has no upload endpoint.

Because GitHub is read-only, publishing always targets Soferity, regardless of which backend you have selected for browsing. You can still browse and install from the GitHub backend; you just cannot publish to it. See Using Store for the backend setting and browse flow.

Reporting a wallpaper

If you find a Store wallpaper that violates the rules, the ThemeReport dialog lets you flag it. The available reasons are:

Reason
Spam
Other (default)
Nudity
Harmful
Violence
Malicious
CopyrightViolation
MisleadingInformation

• On the Soferity backend, the report checks your reporting quota and then submits the app version, the wallpaper's title/version/location, your contact email, the reason category, and a description. A valid contact email and a non-empty description are required.
• On the GitHub backend, reporting instead opens a pre-filled GitHub issue on the Store repository (using the wallpaper_report.yaml template, labeled wallpaper).

Tips and gotchas

• You cannot re-publish a Store wallpaper — the SucroseStore.json marker blocks it.
• Mind the 90 MB cap — measured on the compressed .zip; large videos are the usual culprit.
• Validation runs on both import and publish — a .zip that imports cleanly will generally publish cleanly, and vice versa.
• Keep the archive un-nested — files must sit at the root of the .zip, not inside a wrapper folder.
• Set a sane AppVersion — it must be ≤ the current app version, or users on older builds cannot install your wallpaper.
• Provide a real Contact (URL or email) within 250 characters — it is required and, for reporting, must be a valid email if you want Soferity reports to reach you.
• Publishing always goes to Soferity, even if you browse the GitHub backend.
• Telemetry note: download/report/publish actions touch the Soferity backend; some are gated by your telemetry consent. See Privacy Telemetry.

See also

• Create Package Format — the SucroseInfo.json manifest and folder layout
• Create Step By Step — authoring and the field validation rules
• Using Store — browsing, installing, and the backend setting
• Managing Library — the Share action and importing .zip files
• Create Customization Controls and Create JS Bridge — the optional files validated on publish
• Privacy Telemetry — what the Store actions send