lossless-group_image-gin/release-notes/0.2.3.md
mpstaton d3d7a6a626 chore(release): 0.2.3 — workflow-driven releases + artifact attestations + log.json gitignored
Three things bundled:

1. Release workflow at .github/workflows/release.yml fires on every 3-digit-semver tag push. Builds main.js + styles.css in a clean Ubuntu runner, signs all three release assets via actions/attest-build-provenance@v1 (sigstore-backed via OIDC), creates the GitHub Release with notes pulled from release-notes/<tag>.md. Identical to the workflow landing across cite-wide, perplexed, metafetch as a family-wide pattern.

2. release-notes/0.2.3.md authored in marketing-shape per content-farm/context-v/skills/changelog-conventions/SKILL.md "These are marketing artifacts" section. Convention going forward: every release's body lives in the repo at this path before the tag is pushed.

3. log.json now in .gitignore — runtime plugin telemetry that captures at first-run per-vault, never source-of-truth. Was tracked accidentally in earlier commits; this stops the dirty-tree noise on every git status.

Version bumped 0.2.2 → 0.2.3 across manifest.json / package.json / versions.json. No source-code changes — Drop Gate, Recraft generation, Ideogram v3, Magnific search, ImageKit upload all behave identically to 0.2.2.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-18 03:09:02 -05:00

4.9 KiB

Image Gin generates and gates every image that touches your Obsidian vault — and starting with 0.2.3, every release asset is cryptographically attested back to the source code that built it.

Why care?

If you write in Obsidian about client-sensitive material — growth charts, dashboard screenshots, photos of a whiteboard at a strategy session — you don't want a default-on third-party uploader silently shipping bytes to a public CDN. Most note-taking-plus-uploader stacks ask "should we upload to Imgur?" The honest answer for anything proprietary is "neither, until you tell me where."

Image Gin asks first. Every dragged or pasted image gets a single confirmation modal: vault attachments (private, stays on your disk), your own private ImageKit CDN (for material that needs a URL but isn't strictly secret), or anonymous Imgur (for genuinely shareable). Pick once per drop; the modal closes; the markdown link lands at your cursor; you keep typing.

Plus: AI image generation via Recraft and Ideogram v3 from a image_prompt frontmatter field, stock-image search via Magnific, and CDN upload via ImageKit, all from inside Obsidian.

Open Obsidian → Settings → Community Plugins → Browse → "Image Gin" → Install → Enable.

What 0.2.3 brings

Cryptographic provenance on every release asset. Every main.js, manifest.json, and styles.css in this release is signed via GitHub's artifact attestation system (sigstore-backed, OIDC-verified) at build time. The bytes you install can be traced back to the exact commit and GitHub Actions workflow run that produced them.

Verify any release asset before you enable the plugin in your vault:

gh attestation verify main.js --repo lossless-group/image-gin

Exit code 0 means the file came out of a legitimate build of the source repo. Anything tampered with mid-flight — a compromised CDN, a maliciously-edited release attachment — fails the verification.

Particularly relevant for a plugin that handles your private imagery. The Drop Gate's whole value proposition is "you decide where your bytes go" — verifiable provenance on the plugin itself extends that same trust posture all the way down to "the plugin you installed is the plugin you think you installed."

What it changes for users

Installing from inside Obsidian: nothing visible. The Community Plugins directory pulls the latest release the same way it always has.

Auditing before manual install: verify before you drop files into <vault>/.obsidian/plugins/image-gin/. Same gh attestation verify command as above; same exit-code-0 contract.

How the build pipeline works now

A GitHub Actions workflow (.github/workflows/release.yml) fires on every 3-digit-semver tag push. In a clean Ubuntu runner it checks out the tagged commit, runs pnpm build, signs the three release assets via actions/attest-build-provenance@v1, and creates the GitHub Release with marketing-shape notes pulled from release-notes/<tag>.md in the repo.

Provenance is enforced by infrastructure, not maintainer discipline.

The Lossless Group plugin family

Image Gin sits alongside three sibling plugins, all by The Lossless Group:

Plugin What it does
Cite Wide Stable hex-identifier citations + URL-based dedupe + LLM-paste research conversion
Image Gin (this release) Recraft + Ideogram image generation, Magnific stock search, ImageKit CDN, drag-gate for every dropped or pasted image
Perplexed Source-cited research from Perplexity, Claude, Perplexica (self-hosted), or LM Studio (local) + per-directory templates
Metafetch Pull OpenGraph metadata into note frontmatter via OpenGraph.io or Microlink

If Image Gin saves you time, buy us a coffee. The plugins are free; the coffee keeps the next one coming.

Under the hood — what shipped in this commit

  • .github/workflows/release.yml — the build-attest-release workflow described above. Identical structure to the workflows landing across cite-wide, perplexed, and metafetch as a family-wide pattern
  • release-notes/0.2.3.md (this file) — convention going forward: each release's marketing-shape body lives in the repo at this path before the tag is pushed
  • log.json runtime telemetry now in .gitignore (it's plugin debug output that captures at first-run per-vault, never source-of-truth — was tracked by accident in earlier commits)
  • Version bumped 0.2.2 → 0.2.3 across manifest.json, package.json, versions.json
  • No source-code changes — Drop Gate, Recraft generation, Ideogram v3, Magnific search, ImageKit upload all behave identically to 0.2.2