Questions, answered plainly.

Beauty of your collection first. Utility just below the surface. Muninn is a gallery before it is a tool. Every view defaults to a clean, uncluttered presentation focused on the photos. Filters, tags, metadata panels, and configuration are available but opt-in. Toggled on when needed, tucked away when not. The grid is the star, not the chrome around it.

Because the primary purpose of Muninn is viewing your finished, gallery-ready work. Not sorting it. If filter strips and toolbars are always visible, the experience becomes a utility view instead of a consume view. A single toggle surfaces all filters when you need them. When filters are active but hidden, a subtle indicator tells you the view is narrowed so nothing feels missing.

Albums are curated output. You build an album using the Library view, bulk editor, tags, and filters. The album detail view is where you enjoy the result. No filter strip, no editing chrome. What you put in the album is what you see.

A planned full-screen, zero-chrome mode for showing off your portfolio. The ultimate consume view. Just your photos, edge to edge. Designed to translate directly to web-published galleries as well.

Muninn is a native macOS photo portfolio and album management app for photographers who shoot with real cameras. It sits at the end of the photography workflow. After importing and culling, after editing in Luminar or Photoshop. Finished, edited photos live here: organized into albums, tagged for discovery, published to the web, and pushed to social.

Muninn is one of Odin's two ravens in Norse mythology. His name means "memory." Every day Odin sends Huginn (thought) and Muninn (memory) out across the nine worlds to observe everything and return with what they've seen. Odin himself has said he fears losing Muninn more than Huginn. Memory is more precious than thought.

Photographers who shoot with real cameras, edit in dedicated tools like Luminar or Photoshop, and have a pile of finished work with no good home. If you've ever scrolled through folders in Finder to find a specific shot, struggled to share work with clients, or wanted to post to Instagram without manually uploading. Muninn is for you.

Muninn does not edit photos. It is not a RAW processor, a culling tool, or a cloud sync service. It handles the portfolio organization, discovery, and publishing layer after editing is complete.

The Muninn app is a one-time $49.99 purchase, the full macOS app (library, albums, AI search, slideshows, MP4 export), all local. Web publishing and social are optional auto-renewing subscriptions: Muninn Web ($4.99/mo) publishes unlimited web galleries, with visitor ratings, comments and downloads you can switch on per gallery; Pro ($19/mo founder rate for launch subscribers, kept for as long as you stay subscribed; $24.99/mo standard) adds client projects (proofing, favorites and star ratings by private link, with review rounds) and scheduled and immediate social posting to Bluesky, Mastodon, Threads, Instagram, Facebook, Pinterest, LinkedIn, and X. A custom domain is a $10/yr add-on. Your first gallery is free for a year with the app.

Paid plans include 50 GB of published-media storage. If you reach it, publishing new content pauses and Muninn asks you to remove some published albums to free space, we never delete your content for hitting the cap, and unpublishing an album frees its storage immediately.

Two places, same app: the Mac App Store, or a direct download from muninnmemory.app (purchased with a card via Stripe). Features, pricing, and subscriptions are identical on both. The only practical difference is how updates arrive: the App Store handles updates for App Store copies, and the direct version updates itself with a built-in updater (check manually anytime via Settings, General, Check for Updates).

Yes. Muninn is free to download with a 14-day full trial. When the trial ends, the app enters a read-only grace mode: you can still view your library, run searches, play slideshows, and export, but imports, edits, and publishing pause until you purchase the one-time unlock. Nothing is ever deleted.

New publishing pauses immediately, but your live galleries stay up for a 30-day grace period. If the subscription isn't renewed by then, published galleries come down (they are preserved server-side, not destroyed). Re-subscribing within 90 days restores them automatically, same URLs, same customization. Your local library is never affected by subscription state.

In the app: Settings, Publishing, Subscription shows your plan, usage meters (connected accounts, X posts this month, storage), and a Manage plan button that opens your billing page in the browser, already signed in. From there you can switch between Muninn Web and Pro, add or remove add-ons, update your card, or cancel. Purchases of the app itself are managed by the store you bought it from (App Store or Stripe).

In the composer, expand “Tag people” and pick from your Directory, people Muninn already recognizes in the photo show up first. On Instagram and Facebook a tag is positioned on the photo (auto-placed on the detected face; drag to adjust); on Threads, Bluesky, and Mastodon it becomes an @mention. Each contact stores its own handle per platform, managed in the Directory tab.

Yes. In the composer, the character-count pills along the bottom are buttons: the Shared pill holds the caption every platform gets, and tapping a platform's pill lets you write custom copy for just that platform (an orange dot marks platforms with their own version). By default every platform shares one caption; overrides are per-post and opt-in. Useful when X needs a shorter cut or Instagram gets the hashtag-heavy version.

Yes. When an Instagram account is selected, the composer shows a “First comment” field. Whatever you put there is posted as the first comment on the photo right after it publishes, handy for keeping a wall of hashtags out of the caption.

The simplest way is to type the place name into your caption, which works on every platform. A tagged location pin (the kind that links to a place page on Instagram or Facebook) relies on Meta’s place-search API, which Meta keeps behind a special access review, so place search may show as unavailable. When that happens, just add the place to your caption.

Not for the core app. The local library, albums, and tagging all work fully offline. Web publishing and social publishing require an internet connection.

Only anonymous usage counts. The app sends small tallies (app opens, onboarding progress, which features get used, how many photos a library holds) so we can see how Muninn performs and improve it. These are bare numbers: never a photo, filename, album name, caption, or search. They are keyed to a random install identifier, never an advertising identifier, and are never sold or shared. There are no third-party analytics or tracking SDKs in the app. Public web galleries also keep a simple daily view count per gallery, with no information about the viewer. The full details are on the privacy page.

macOS 14.0 Sonoma or later.

No. Muninn is non-destructive. It reads and references your photos at their original locations on disk. Your files are never moved, renamed, or modified. You stay in control of your folder structure.

JPEG, PNG, TIFF, HEIC/HEIF, WebP, and RAW files from all major manufacturers: Canon (CR2, CR3), Nikon (NEF), Sony (ARW), Fujifilm (RAF), Adobe DNG, Olympus/OM (ORF), Panasonic (RW2), Leica (RWL), Pentax (PEF), Sigma (X3F), Hasselblad (3FR), Phase One (IIQ), and more.

Yes. Point Muninn at a local Midjourney download folder. All images are imported and tagged with a Midjourney source tag automatically.

Yes, two ways. Ad-hoc picker (File → Import from Apple Photos…, or Cmd+Shift+A) opens Apple's system photo picker in a window. Multi-select the photos you want and click Add. Muninn downloads them (even iCloud-backed originals), shows a confirmation sheet with Source / Project / Album pickers, and imports on confirm. Use this when you want a specific handful of photos in a specific destination.

Registered source (Settings → Library → Apple Photos Albums → Add Album) registers an entire Apple Photos album. Favorites or any user album. As a source that Muninn keeps in sync automatically. New photos added to the album appear in Muninn within seconds. Photos removed from Apple Photos stay in Muninn (the source tracks what's been imported, not what exists). Use this for "everything I favorite should live in Muninn too."

Yes. Drag one or more images from Finder, a browser tab (midjourney.com/organize, X, Reddit, anywhere), or any drag source onto the Library view or any album. A confirmation sheet appears with a count, thumbnails, and Source / Project / Album pickers (each supporting Create New…). The source tag is auto-detected from the origin URL of the drag (so photos dragged from Midjourney get tagged Midjourney, photos from X get X, etc.). Hit Import and they land in the library.

Yes. File → Import from URL… (Cmd+Shift+U) opens a small sheet. Muninn auto-pastes the clipboard if it contains an image URL, fetches a preview so you can confirm it's the image you meant, and imports on click. The source tag is auto-detected (Midjourney, X, Reddit, Flickr, Unsplash, etc. Falls back to "Web" for unknown hosts). The sheet stays open for rapid-fire imports: copy the next URL in your other app, the sheet auto-populates in ~300ms, and one keypress imports it. The last-used Project is remembered across sessions so batch imports land in the right bucket without re-picking.

Muninn uses PHAssetResourceManager.writeData with network access enabled, which downloads the original from iCloud on demand. For a first-sync of a large album (e.g. Favorites with hundreds of photos), this can take a while and consume bandwidth. A persistent banner shows Syncing "Favorites"… downloading N/M new during the fetch. 4 parallel downloads keep wall time reasonable. Subsequent syncs only fetch truly new photos (deduped by PHAsset identifier).

In Settings → Library → Apple Photos Albums, each source row has two controls:

• Pause (pause icon), stops syncing without losing anything. Paused sources ignore library change notifications and don't download new photos. Click again to resume and trigger an immediate sync.
• Delete (trash icon), opens a confirmation. Deleting the source unsubscribes AND removes every photo it previously imported (along with its managed-store subfolder). Your Apple Photos library is not touched.

When you remove an Apple Photos–sourced photo from Muninn, the photo's PHAsset identifier is added to every registered source's "excluded" list. This means the sync engine won't re-import it on the next pass. Even though it still exists in your Apple Photos library. Use this to cull specific shots without deleting them in Apple Photos.

Every import path runs through SourceDetector, which picks a source tag in priority order: (1) origin URL domain (Midjourney, X, Reddit, Discord, Imgur, Instagram, Flickr, Unsplash, Pinterest), (2) EXIF Software tag (Luminar, Photoshop, Lightroom, etc.), (3) filename sniff (Midjourney job-ID patterns), (4) EXIF camera model, (5) folder walk up to 3 levels for camera-named directories, (6) falls back to "Web" if origin URL was present but unmatched, otherwise "Unknown." You can always override in the import confirmation sheet.

Yes. Open any photo's detail view and the inspector (right panel) has an "Imported via" row in the File section. Values: Folder, Drag, URL, Apple Photos (ad-hoc picker), Apple Photos Sync (auto-syncing registered source). Only new imports from 2026-04-22 onward have this stamped. Older photos show a blank value until re-imported.

Yes. Muninn imports photos from any local folder, including network shares. Go to Settings → Library → Add Source and choose an import mode (see below).

Open Settings → Library. Click + Add Source and choose:

• Single Shoot, the folder you select IS the project. Every photo inside gets the folder name as its project tag. Use this for a single shoot or a stand-alone set of exports.
• Collection, the folder contains multiple shoot subfolders. Each subfolder becomes its own project, and photos inside get that subfolder's name as their project tag. Use this for a top-level folder like "Finished Photos" that organizes many individual shoots.

• Single Shoot: You select /Media/2026-04-01 Studio Session/. Every photo gets the project tag "2026-04-01 Studio Session."
• Collection: You select /Media/Finished Photos/. Muninn iterates every first-level subfolder. Photos in /Finished Photos/2026-04-01 Studio Session/ get the project tag "2026-04-01 Studio Session." Photos in /Finished Photos/2025-12-Colorado/ get the project tag "2025-12-Colorado." The collection root folder name is never used as a tag.

Yes. In Settings → Library, click the chevron (›) next to any Collection source to expand it. Each subfolder (shoot) is listed with its photo count and a remove button. Removing a shoot deletes those photos from Muninn. Files on disk are not touched. If you remove the last shoot, the collection source itself is removed. The removed shoot is added to the collection's exclusion list, so the live source watcher will not re-import it automatically. It appears below the active shoots under an "Excluded" label with a green "+" button to re-include it.

Yes. In Settings → Library, expand the collection. Excluded shoots appear below the active list with a green "+" button. Click it to re-include the shoot. Its photos are re-imported and it returns to the active list. The exclusion is cleared, so the live watcher will track it going forward.

In Settings → Library, click the red minus button next to the source. This removes all its photos from Muninn (files on disk are never touched) and stops the live watcher for that folder. To re-add it, use Add Source → Single Shoot and select the same folder again.

Yes. Muninn watches all registered import sources using macOS file system events (FSEvents). When a new photo is dropped into any watched folder. Or a new shoot subfolder appears inside a collection source. It is automatically imported within a few seconds. A brief notification banner appears at the top of the Library grid showing how many photos were imported and from which shoot. No user confirmation is required.

Yes. If a photo file is deleted or moved out of a watched folder, Muninn detects the change and removes the corresponding record from the library. The notification banner reports both additions and removals.

The live watcher itself only runs while Muninn is open. But Muninn also does a one-time catch-up scan of every registered source at launch, so any new photos, new shoot subfolders, or deletions that happened while the app was closed are reconciled the next time you open Muninn. In short: changes made while the app is running are picked up within seconds via file system events, and changes made while it was closed are caught on the next launch.

Muninn detects duplicates and skips files that already exist in the library. Importing the same folder twice does not create duplicates.

If your photos live on a network share (NAS, SMB volume, etc.), the file has to travel over the network before Muninn can decode it. First open is slower because of that transfer. However, Muninn writes a local display-resolution copy to your Mac's cache folder after the first load. Every subsequent view of that photo is instant, even after relaunching the app. While a photo is loading, the grid thumbnail appears immediately as a placeholder so you're never looking at a blank frame.

That's the whole point. Muninn treats all sources as first-class citizens in a single unified library. Source is auto-detected from EXIF at import time. No manual tagging required. You can filter by source at any time using the source filter strip at the top of the grid.

Automatically, from EXIF metadata. The detection follows a priority order: (1) If the EXIF Software tag indicates the file was processed by editing software (Luminar, Photoshop, Lightroom, Capture One, Darktable, RawTherapee, Affinity, ON1), the source is set to that software's name (e.g. "Luminar Export"). (2) If the EXIF camera model field is populated (e.g. "X-E5", "iPhone 15 Pro"), that model name is used. (3) If EXIF is missing or stripped. As often happens with compressed exports. Muninn walks up the folder path looking for a camera or device name (iPhone, iPad, Pixel, Samsung, X-E, X100, EOS, Nikon, Sony, Lumix, Leica, etc.). You never have to manually tag a source.

Yes. When your library contains photos from more than one source, a filter strip appears at the top of the grid with a chip for each source. Tap "Luminar Export" to see only edited exports; tap "X-E5" to see only raw-from-camera shots. Tap "All" to return to the full library. The filter strip is hidden when all photos share the same source.

The import progress banner shows shoot-level progress: "Importing shoot 3 of 12" for a collection with 12 shoot subfolders. It does not count individual photos during import. The shoot count is the correct granularity. Photo count in Settings → Library updates live as each shoot completes and reflects the final total once import finishes.

A compact bar at the top of the Library grid showing an icon and message like "3 new photos. Studio Session" or "1 removed. Portraits." It appears with a slide-down animation and auto-dismisses after 4 seconds. It uses the same visual style as the manual import progress banner.

No. Thumbnails are cached on disk in the app's Caches directory as compressed JPEG files. On relaunch, thumbnails load from disk instantly. No re-decoding required. A background prewarm pass quietly generates any missing thumbnails after launch without competing with visible cells.

Yes. When a source filter is active, the detail view navigates within the filtered set only. The counter ("2 of 6") reflects the filtered count. Previous/next arrows also stay within the filter.

An album is a named collection of photos. A photo can belong to multiple albums simultaneously. Removing a photo from an album never deletes it from the library. Muninn has two album types: regular (static) and dynamic (live).

Yes. Drag a photo from the grid (or the fullscreen image) onto an album in the sidebar to add it. It works for both album types: on a dynamic album, a dragged photo is added as a manual one-off include, the same as the right-click "Add to Album" action, so it stays in the album even if it does not match the rules.

Both are created through the same rule builder. You define filters (tags, source, camera model, date range, metadata) with full AND/OR logic to find exactly the photos you want. The only difference is what happens after creation:

• Regular album: The photos you select are locked in. The album is a frozen snapshot. You can still manually add or remove photos afterward, but it won't change on its own.
• Dynamic album: The rules stay live. Any new photo that matches your rules automatically appears in the album. Any photo that stops matching is removed. The album is always up to date.

Both types live in the same Albums section in the sidebar, distinguished by icon.

Yes. Dynamic albums use rules as a baseline, but you have full manual control on top:

• Force-include: Add any photo to a dynamic album manually, even if it doesn't match the rules. It stays in the album regardless.
• Exclude: Remove a photo from a dynamic album manually, even if it matches the rules. It stays excluded unless you add it back.

This means dynamic albums give you the best of both worlds: automatic population from rules, with manual precision when you need it.

Yes. You can right-click a photo in the Library, in a photo detail view, or anywhere else and add or remove it from any album. Regular or dynamic. This is how you force-include or exclude photos in dynamic albums.

Click "+" in the Albums sidebar section or the "New Album" button in the Albums grid view. The rule builder opens where you can define filters using tags, source, camera model, date range, file type, and more. With full AND/OR logic between rules. A live preview shows matching photos as you build your rules. You can then either select all matching photos or cherry-pick individual ones. Toggle "Keep this album live" to make it a dynamic album, or leave it off for a regular album.

Yes. Open the album and choose "Edit Rules" to re-open the rule builder. Changes to the rules immediately update which photos appear.

Full AND/OR logic. Rules are organized into groups: conditions within a group are OR'd (any match), and groups are AND'd together (all must match). Example: (XE-5 OR iPhone 15 Pro) AND (food OR beer) AND (after 2026-01-01). This finds all food or beer photos shot on either camera after January 2026.

Tags (any type, source, content, or project), photo source, camera model, camera make, lens model, film simulation, file type, date range (before/after), Keyword (literal text match), and Visual Search (CLIP image-content match).

A smart-album rule that uses MobileCLIP to find photos by image content. Example: add a rule Visual Search matches "food" and the album auto-populates with every photo that looks like food. No manual tagging required. Dynamic albums using this rule stay live: when a new import's embedding lands, the rule picks it up automatically.

Operators:

• matches, photos whose CLIP similarity to the query exceeds a fixed threshold.
• does not match, photos whose CLIP similarity is below the threshold. Returns the set complement.

Value syntax: a single concept like dog, or a comma-separated list like person, man, human which runs each as a separate query and unions (for matches) or complements the union (for does not match). Comma-OR is the clean way to write "exclude a cluster of related concepts" in one clause.

Keyword is a literal text match against filename + any attached tag names. Keyword contains "proj42" finds photos whose filename or tag names contain the substring "proj42".

Visual Search is a CLIP image-content match. Visual Search matches "food" finds photos that actually look like food, regardless of filename or tags.

They complement each other: Keyword for when you know a filename pattern or shoot codename, Visual Search for when you're describing what the photo depicts.

Available on any tag field (Any Tag, Source Tag, Content Tag, Project Tag), on the Keyword field, and on metadata fields (Source, Camera Model, etc.). Substring match against the relevant text: Content Tag contains "food" matches photos tagged with any content tag whose name contains "food" (food, street food, seafood, etc.). Camera Model does not contain "iPhone" matches anything shot on a real camera (or with missing camera metadata).

CLIP's similarity scores aren't calibrated across concepts. Photos where a person is clearly in frame but not dominant (small, turned away, partially occluded) can score below the match threshold for "person" and slip through. For the proper Boolean version of this use case, use the Face Detected is No smart-album rule (added in the People feature. See the People section below).

Every photo can carry multiple tags across three types. Tags of any type can be mixed on a single photo.

Source tags describe the technical provenance of a photo. The gear used, the software it passed through, the pipeline it came from. Source tags answer the question: how and with what was this made? Examples: camera model (X-E5, iPhone 15 Pro), editing software (Luminar Export, Photoshop). Source tags are auto-generated from EXIF metadata. Source tags cannot be manually deleted. They are a factual record of the photo's origin. To remove all photos associated with a source or project tag in one action, right-click the tag in the Tags panel and choose Remove from Library…

Content tags describe what is depicted in the photo. Subject matter, mood, genre, or any creative attribute a viewer would care about. Content tags answer the question: what is this a photo of? Examples: film simulation (Classic Chrome, Velvia/Vivid), food, portrait, landscape, architecture. Film simulations are auto-tagged from EXIF at import. All other content tags are user-defined and manually applied.

Project tags group photos by the organizational unit they belong to. A shoot, a client, a chapter, a series. Project tags answer the question: what is this photo part of? The project tag is automatically set to the name of the folder you select when importing.

The rule in one sentence: Source = the gear and pipeline. Content = the subject matter. Project = the organizational grouping.

Yes. The Library filter strip uses AND logic. All selected tags must match. This is intentional: the filter strip is for quick, temporary narrowing. "Show me the food shots from this shoot." It resets on launch.

For richer logic like OR combinations ("show me everything from XE-5 OR iPhone 15 Pro, tagged food"), use smart/dynamic albums. Smart albums are saved, persistent, and support complex tag rules. The Library filter strip drills down; smart albums define collections.

Click the filter toggle in the toolbar to reveal the filter strips. The tag strip has an "Add Tag" button that opens a searchable dropdown. Type to narrow, click to select. Selected tags appear as compact colored pills. Click the × on any pill to remove it, or click "Clear" to reset all tag filters.

Library filtering is quick and temporary. It drills down into what you're looking at right now and resets when you relaunch. Smart albums are saved, persistent rules with richer logic (including OR) that define a collection you come back to repeatedly. Filter to find; albums to keep.

Click the Aa button in the toolbar (the rightmost control in the toolbar pill). When active, section headers appear above each group of photos. Date headers when sorting by date, shoot name headers when sorting by name. When inactive, photos flow in a flat uninterrupted grid with no visual dividers. The preference persists between sessions.

The toolbar contains two dropdown menus plus an ascending/descending toggle.

Dropdown 1, Sort By: Date Captured, Date Added, or Shoot Name.

Dropdown 2, adapts based on sort:

• Date Captured or Date Added: grouping granularity, Day, Month, or Year.
• Shoot Name: secondary sort, A→Z (alphabetical) or By Date (shoots ordered by earliest photo date).

Ascending/Descending toggle: A bar icon that flips the sort direction. Applies to all sort modes, oldest/newest first for dates, A→Z vs Z→A for names, oldest/newest shoots for By Date.

Sort, grouping, and direction apply whether or not section labels are visible. Both Library and Album detail views share the same sort state.

Muninn automatically hides duplicate photos in date-sorted views. Same-folder duplicates are detected by matching capture date, file size, and film simulation. Cross-folder duplicates (same photo imported from multiple sources) are detected by matching filename, capture date, and file size. The earliest import wins. When sorted by Shoot Name, all copies are shown because each shoot context is intentional. Deduplication is applied consistently in the Library, album detail views, and the album builder preview.

Locked albums hide their photos from the Library view until you authenticate. Use this for content you don't want to accidentally scroll through when showing off your portfolio. Locking is not full security. Files still exist on disk. It's a visibility gate.

When creating or editing an album, toggle the "Locked" switch in the sheet header. The album's photos are immediately hidden from the Library view.

Several ways:

• Click the lock icon next to the album name in the sidebar (authenticates via Touch ID or password)
• Right-click a locked album → Unlock Album
• Click the Unlock button on the album's lock screen
• Click the lock icon in the Albums sidebar header to unlock all locked albums at once

• Click the open lock icon next to the album name in the sidebar
• Right-click an unlocked lockable album → Lock
• Click the lock icon in the Albums sidebar header to re-lock all
• Albums also re-lock automatically based on the re-lock policy in Settings → Albums

Settings → Albums → Re-lock albums: When Muninn quits (default), When screen locks, After 5/15/30 minutes, or After 1 hour.

For regular albums: if every photo in a locked album is already visible because another unlocked album contains all the same photos, that album automatically shows as unlocked. For dynamic albums: each must be explicitly unlocked.

No. Locked album photos are filtered from the Library view entirely. They don't appear in the grid, search results, or source/tag filters. Unlocking the album makes them visible again.

Yes. When you right-click a spot on the Map and choose an album or shoot, Muninn shows that album's photos so you can pick which ones get the location. If some already have a location, use the All / No location filter at the top of the picker to show only the photos that still need one, then Select All and Apply to tag just those. When the album is a mix of located and un-located photos, the picker opens to the No location view automatically. Leaving "Overwrite existing locations" off also skips any already-located photos, even if they are selected.

Type a natural-language query like "food", "mountains at sunset", or "a man in a suit" into the Library search bar (top-right). Muninn surfaces matching photos by actually understanding the image content. Not filenames, not tags. Powered by MobileCLIP-S0, a cross-modal vision-language model from Apple, running entirely on-device. No photos, embeddings, or queries leave your Mac.

No. All AI features run on-device. For semantic search, MobileCLIP-S0 is bundled into Muninn.app (~105MB) and every image embedding + every text query is computed locally. For Apple's built-in Vision features (face anchoring for Ken Burns, slideshow scene analysis), the same on-device rule applies. The Claude API is used elsewhere in Muninn (slideshow AI Director) but never for photo search or rule evaluation.

At import time (and once at first-launch backfill for existing photos), every photo is encoded into a 512-dimensional vector that captures what's in the image. When you search, your query text is encoded into the same vector space, and photos are ranked by cosine similarity. The top matches are shown in "Best matches" score order.

Around 90ms per photo on Apple Silicon. A 1,000-photo library takes about 1–2 minutes; 10k photos roughly 15 minutes. The backfill runs in the background on a low-priority queue, so it never blocks the UI or your imports. A banner above the Library grid shows live progress ("Indexing for search… N of M") and auto-dismisses when done. Quit mid-backfill. Next launch picks up right where it left off, because the database is the progress record.

Settings → Library, at the bottom of the tab. There's a live "Search index: N of M photos" line (or "Indexing for search: N of M" while backfill is still running).

Good: specific concepts (food, mountain, beach, dog, fireplace), compositional descriptions (a man in a suit, close-up portrait), stylistic queries (golden hour, moody lighting), scene descriptions (snowy mountains, city at night).

Limitations: CLIP scores aren't calibrated across concepts. Some queries are tight (cow only matches actual cows), others are loose (person/human can match anything with human-adjacent signal). Very specific identity queries (your specific dog, a named person) don't work. That requires face recognition, coming in the People phase. Negation queries don't work in the search bar itself ("dogs without people"). Use a smart-album Visual Search rule for that.

Yes. The Library grid narrows live on every keystroke: filename matches appear instantly, and visual (semantic) matches land a beat later as the on-device model scores your query. No need to press Enter, though Enter works too. Clearing the search restores the full library.

Yes. The Library search bar runs filename matching alongside semantic search. If your query is found as a literal substring of any photo's filename, those hits surface in a "Filename matches" section above "Best matches". Filename hits are ordered most-recently-imported first. Useful when you remember an export naming convention (RTF_, IMG_, a Midjourney UUID prefix) but the photo doesn't lend itself to a concept query. Concept and filename matching both fire from the same query. A search for "wedding" returns filenames containing "wedding" up top and visual matches below, with no photo appearing in both sections.

No. Photos in locked (and not currently unlocked) albums are hidden from Library search results. Whether the match came from filename matching or semantic search. When a search is active AND you have at least one locked album, a subtle "Images in locked albums will not be displayed" line appears above the grid. Muninn never reveals whether your specific query would have matched locked content. Unconditional disclosure keeps the privacy guarantee intact.

Muninn surfaces visually similar or near-identical photos. Burst shots, slight recompositions, same scene at different exposures. As a dismissable recommendation. You choose to hide or delete extras. Non-destructive by default: hide is the default action, delete is opt-in.

Muninn detects faces in every photo, groups faces of the same person into a cluster, and shows them in a People sidebar item between Map and Albums. Each cluster gets a representative face crop. Click an unnamed cluster, type a name, hit return. Every face in that cluster now has that person attached. Click into a person to see all photos they appear in.

Apple's Vision framework (VNDetectFaceRectanglesRequest) finds faces. AdaFace IR-18 (a Core ML model bundled with the app) generates a 512-dimensional face vector for each detected face. Faces with cosine similarity above 0.38 are auto-merged into the same cluster; below that, a new cluster opens. All work runs on-device. Face data never leaves your Mac.

Apple does not expose people metadata to third-party apps through any public API. There is no PHPerson symbol in PhotoKit; the names live only in Apple's private database. Reading that database directly would fail Mac App Store review and break with every macOS update. So Muninn detects and clusters faces independently. You'll name people once in Muninn, and after that every new photo of them is recognized automatically.

Click an unnamed cluster in the People grid (or click a face in any photo's inspector → People section). Type a name and hit return. The name persists. If two clusters turn out to be the same person, select both and choose Merge from the context menu. If one cluster is actually two people mixed together, select the wrong-person faces inside the person detail view and choose Split. They move to a new unnamed cluster you can then name.

Yes. Click the person in the People sidebar to see every photo. You can also combine it with other Library filters: "photos with Alice tagged 'food' shot on the X-E5" works.

Yes. Two new rule fields:

• Face Detected, is Yes finds photos with at least one face; is No finds photos with no faces (the proper version of "dog photos without me in them").
• Person, is Alice finds every photo Alice appears in; is not Alice excludes them.

Both update live as new photos are imported and clustered.

Open any photo, look at the right inspector panel. There's a People section showing each detected face as a chip with the person's avatar and name (or "Unnamed" if not yet identified). Click a chip to jump to that person's grid, or right-click for rename / reassign / find-similar / add a new person.

If Muninn missed a face (rare, but it happens with extreme angles or motion blur), toggle Add Person on and click directly on the face in the photo. Type a name and the face joins that person's cluster manually. Same as auto-detected faces from then on.

Face embeddings and bounding rects live in the local SQLite database alongside the rest of your library data. They are never written to any exported album, published gallery, social-media post, or cloud-synced artifact. Only the photo file itself travels, and face data is not embedded in it. To wipe everything: Settings → Privacy → Delete All Face Data. Photos, albums, tags, and album names are untouched. The next launch re-runs face detection from scratch.

No. Face detection runs on a low-priority background queue and completes asynchronously after the photo lands in your library. New imports show in the grid immediately; the People sidebar updates as faces are processed. The first-launch backfill on an existing library shows a progress banner and runs in the background. Quit and resume safely; it picks up where it left off.

Yes. Photos in locked (and not currently unlocked) albums don't contribute their faces to the People sidebar surfaces, the same way they're hidden from semantic search. Indexing still runs on locked photos so unlocking them doesn't introduce a delay.

Two paths:

• Let Muninn do it all (wand button): Click the wand.and.stars button in the album toolbar. The AI Director sheet opens. Pick a mood, music, and optional title/closing cards, then click "Let Muninn Direct." Muninn analyzes the music, places beat-aligned markers, arranges photos via narrative sequencing, assigns smart Ken Burns motion, and plays it fullscreen. When playback ends, you get Save & Exit / Modify / Discard.
• Manual (chevron button): Click the play chevron. The Slideshow Editor opens. If it's your first time, a guided setup wizard walks you through four steps: choose music, mark transitions, pick image count, and choose how to arrange your photos.

It is one of the length choices in the AI Director. Short caps the slideshow at about 60 seconds: it trims the music to roughly a minute with a short fade and uses the strongest frames, instead of stretching the photos across the full length of the song. "Match the music" follows the song length, and "Show every photo" includes every photo even past the music.

The editor opens with the full arrangement preloaded. Every slide position, duration, Ken Burns direction, fit/fill choice, and marker is exactly as Muninn built it. A "Directed by Muninn. Modify as you like" banner appears at the top of the editor. You can tweak anything, then Preview, Export, or Save & Close normally.

Yes. Save & Exit persists the full arrangement (slides, per-slide overrides, markers) to the database in addition to the basic config. The next time you open the editor for that album via the chevron button, the arrangement is reloaded exactly and the Muninn banner appears. To start over, delete the arrangement (coming soon) or just build a new one. New arrangements overwrite old ones per album.

A visual editor where you see your song's waveform and place transition markers by tapping spacebar while the song plays. You define WHEN transitions happen; Muninn handles WHAT photos go where and HOW they're displayed. Supports variable playback speed (0.25x-1x), drag to reposition markers, and zoom.

Markers are sacred time positions in the song that define when slide transitions occur. They never move when you reorder slides. Each gap between markers is a "slot" with a fixed duration. Photos can be swapped between slots, but the timing stays locked.

The AI Director analyzes your photos and arranges them intelligently based on mood, color, brightness, and composition. It handles photo ordering, transition types, Ken Burns motion/intensity/direction, and fit vs fill per slide. It does NOT change your transition markers or create title/closing cards.

Manual Sort lets you arrange photos yourself using presets (brightness, color, date) or natural language prompts ("darkest to lightest"). AI Directed lets Muninn analyze your photos and arrange them based on a mood you provide. Both are available as a toggle in the workflow controls strip. Only one is active at a time.

Fit to Song trims the slideshow to end when the music ends. The number of slides matches the number of marker slots. Show All Images keeps every photo; slides after the song ends play in silence.

Toggle between Slide view and Album view using the buttons above the main content area. Album view shows all photos in the album as a scrollable grid with green usage badges (checkmark + count). You can drag photos from the grid onto the timeline, right-click to replace or insert, or click to select.

Right-click a slide in the timeline and choose "Replace With..." This opens the Album grid with a replace indicator. Click any photo to swap it into that slot. All overrides (duration, transition, motion) are preserved. Alternatively, right-click a photo in the Album grid and choose "Replace Selected Slide."

The new photo takes the target slot. Everything after it shifts down by one. The last photo gets bumped off to keep the total slide count fixed (matching your markers). Slot durations never change.

Slides swap positions. Durations stay with their positions, not their photos. This means marker alignment is preserved after every reorder.

H.264, HEVC, ProRes 422, and ProRes 422 HQ. Resolutions: 720p, 1080p, 1440p, and 4K. Frame rates: 24, 30, or 60 fps. Audio is muxed into the exported video.

Yes. Export is WYSIWYG. Every per-slide transition (Crossfade, FadeToBlack, Cut, Push, Wipe, Slide), Ken Burns motion and direction, crop aspect, crossfade duration, title card, blank slide, artwork, and text overlay from the editor timeline is rendered into the file. Text effects (fade in / fade out / fade in-out / typewriter) animate in the export in lockstep with slide transitions.

Local audio files (including multi-track combinations merged by AI Director) are muxed into the final MOV. If the song is shorter than the slideshow, it loops. MP3, M4A, WAV, and AIFF are supported.

When a photo is chosen for Ken Burns motion in Smart mode, Muninn runs Vision face detection first. If faces are found, the motion is anchored to them. Zoom directions orbit around the face (not the image center), and pan directions are chosen so the pan ENDS on the subject. If no face is found, Muninn falls back to Vision's attention-based saliency model to pick the most "look-at-able" region of the photo. This kills the "zoomed in on the table instead of the people" problem common in naive slideshows.

When you open the slideshow editor for the first time on an album with no audio, a 4-step card-based wizard guides you through: (1) Choose music, (2) Mark transitions on the waveform, (3) Choose image count (fit to song or show all), (4) Choose arrangement (manual sort or AI directed). You can go back to any step or skip the entire setup.

Two paths, same underlying tool:

• Title / closing card: Click Insert → Title Card. A card slide appears on the timeline and its inspector holds the text controls.
• Caption on a photo: Select a photo slide, then Insert → Text Overlay on Selected Slide. A caption block appears in the photo's inspector.

In both cases the per-block editor gives you font, size, bold, italic, color, an optional rounded text background, and a text effect (fade in, fade out, fade in/out, typewriter, or none).

Click + next to the text-block picker at the top of the inspector. A new block appears, inheriting the previous block's font/color/effect and nudged downward so it doesn't land on top. Switch between blocks using the picker. Only the selected block accepts drag input on the preview, so you never move the wrong one. Click − to delete the selected block (the last block can't be removed. A card or overlay always has at least one).

Click-and-drag the text right on the preview. Same as dragging the crop rectangle. No sliders, no anchor picker. Drag is clamped so text stays inside the frame. A Reset Position button appears once you've nudged a block.

Press Shift+Return inside the text field. Plain Return commits focus (consistent with macOS messaging conventions). Multi-line text respects the block's alignment and background.

• Fade In, starts at 0 opacity and fades up over the effect duration at slide start.
• Fade Out, at full opacity and fades to 0 over the effect duration at slide end.
• Fade In/Out, combines both: in at start, out at end.
• Typewriter, characters are revealed one at a time over the effect duration.

Effects are crossfade-aware: during a slide transition, incoming text fades in WITH its photo and outgoing text fades out WITH its photo. Export matches live playback frame-for-frame.

The Crop control in the per-slide inspector has four options:

• Full, the whole photo is shown; any aspect mismatch with the canvas letterboxes against the blurred background.
• Landscape (16:9), a 16:9 region; on a landscape source photo this fills edge-to-edge.
• Portrait (9:16), a tall strip, typically with large side letterbox on a 16:9 canvas.
• Square (1:1), centered square crop.

Pick an aspect, then drag in the crop picker to pan and use the Size slider to zoom within that aspect. New slides default to Landscape so they cover the 16:9 canvas with zero setup. (The old Fit vs Fill toggle was removed. It was redundant with the crop aspect.)

Three sources, in priority order:

1. High-res online, Muninn queries the iTunes Search API by artist and title to pull artwork up to 3000×3000 px. Cached locally under Caches/Muninn/AlbumArt/ so the same song is looked up only once. Default on.
2. Embedded, if there's no online match (or the setting is off), Muninn uses whatever art is embedded in the audio file's ID3 metadata.
3. None, if neither source has art, the card renders with its background color.

The exporter re-runs the fetch on every export, so older arrangements automatically pick up high-res art when you re-export.

Yes. In the title-card inspector, the Artwork section has Choose Image… (pick any JPEG/PNG/HEIC/TIFF) and Pull from Music (runs the iTunes → embedded fallback against the slideshow's current audio file). Once the image is set you can:

• Size, slider from 20% to 250% of the card's short edge. Past ~170% it fills or overflows the frame for a dramatic close-up.
• Position, drag the image directly on the preview.
• Blurred background, toggle on for a Ken-Burns-style blurred backdrop of the art, off to show the card's background color instead.

Right-click an album in the sidebar → Publish… The publish sheet asks for one decision: public or password-protected. Hit Publish and Muninn uploads the photos to Cloudflare R2, creates the publication record on the Vercel backend, and. If you have a slideshow built for the album. Also renders the MP4 in parallel and uploads it. When the upload finishes, Muninn opens the gallery in your default browser, already signed-in via a one-time magic link.

gallery.muninnmemory.app/<your-publisher-slug>/<your-album-name>. The publisher slug is auto-derived from your Apple Sign-In email. Album slugs are auto-derived from the album name with numeric-suffix collision handling. URLs are stable across re-publishes. Family bookmarks don't move.

Yes. In the publish sheet, switch from Public to Password-Protected and enter a password. Visitors hit a password gate before seeing any photos. The cookie session lasts 30 days. Change or remove the password by re-publishing.

Yes. When you share a gallery link in iMessage, Mail, Slack, AirDrop, or any app that renders rich link previews, the cover photo and album name appear in the preview card. Even for password-protected galleries. The full album content stays gated behind the password; only the cover is exposed as a hint of what's behind it. This is intentional so the people you share with can see what they're being invited to. If you don't want the cover to leak in previews, leave the gallery public (no gate) or skip publishing it altogether.

Yes, two ways. If the album is a Live Web Gallery (published with the Live Album toggle turned on), changes you make in Muninn publish to the web automatically, usually within about a minute. No manual step needed. For a standard published album, use Re-publish: it replaces the published state with the album's current state. Same URL, same slug, same publication ID either way. Family bookmarks stay valid. Adding photos, removing photos, reordering, changing the cover, swapping the slideshow all flow through the same publish path.

Yes. Right-click the album → Unpublish… The gallery and its slideshow are removed from the web.

Next.js on Vercel for the rendering layer + API routes, Vercel Postgres (Neon under the hood) for relational data, Cloudflare R2 for all heavy media (photos, slideshow MP4s, posters). R2 was chosen over Vercel Blob because R2 has zero egress. A published gallery can be viewed by unlimited people for storage cost only.

Yes. Publish as many albums as you want; there's no hard cap on gallery count. Total storage across your account is fair-use limited to 50 GB, which fits the vast majority of working photographers (≈10 weddings at 5 GB each, or 50 client galleries at 1 GB each, or 5,000 lightly-edited JPEGs). The cap may be raised over time as the platform scales. It's an enforcement parameter, not a structural commitment.

Yes, X is the one metered platform. Pro includes 120 X posts per calendar month, pooled across the subscription. X charges for API posting per request, which is why the ceiling exists; every other platform is unmetered. A $5.99/mo add-on adds 60 X posts and stacks for heavier X users. Cancelling a queued X post refunds the meter automatically, and drafts do not count until they are scheduled.

Yes. Sign in with up to two Apple IDs simultaneously in Settings → Publishing → Identities. Each identity is a separate publishing persona with its own gallery URL (gallery.muninnmemory.app/<identity-slug>/...), its own profile (display name, title, location, bio, avatar, gear, website), and its own per-album publish settings + look-and-feel defaults. The library and album editor are shared. Same source photos, same albums. But the album editor's "Publish to" multi-select lets you pick which identities each album publishes under, and a tab bar lets you set per-identity settings independently (e.g. Alex's Oktoberfest is public with the map shown; Maxwell's Oktoberfest is password-protected with the map off). The sidebar marks each published album with a badge per identity that owns a publication of it.

Use cases this is built for: a wedding photographer with a separate fine-art portfolio under a pen name, a commercial shooter who wants studio work and personal projects on different domains, a documentarian publishing under both their working name and a project pseudonym. The unlimited gallery sub covers up to two identities sharing the 50 GB fair-use storage pool. Need more separation. A third identity, or each identity getting its own 50 GB pool? Pay for a second unlimited sub.

Yes. The album editor's Publishing section has a "Publish to" multi-select. Check both identities, and Save & Publish runs the upload for each in sequence. Each identity gets its own publication URL; per-identity settings (privacy, password, map, indexable, EXIF visibility) come from that identity's tab. Unchecking an identity that previously published the album triggers an unpublish from that identity on next Save. Album content (which photos in the album) stays shared across identities by design. If you want different photos under each identity, make two separate albums.

Save persists per-identity settings and album metadata (name, description, rules) without uploading anything. The settings stick on the AlbumPublication rows, ready for the next publish. Save & Publish does that, then runs the publish flow for every checked identity. Fresh first-publish for any identity that hasn't published this album, re-publish for ones that have. Save is greyed when nothing has changed since the editor opened.

Apple Sign In is tied to an Apple ID, so two publishing identities = two Apple IDs. Native Sign in with Apple on macOS uses your system's primary Apple ID with no account picker, so adding a second identity opens gallery.muninnmemory.app/sign-in in your default browser. Sign in there with whichever Apple ID you want, and Muninn jumps back to the Mac with the new identity wired up. The page recognizes the bridge handoff and redirects via a custom muninn:// URL scheme so the token never touches a server log.

Settings → Publishing → Identities. Each row shows the identity's display name, slug, and a radio button. Pick the one you want as the default for new publishes. The album editor's "Publish as" dropdown still lets you override per-album.

That identity's publications stay live on the web. We don't auto-delete server-side data when a Mac signs out. But you lose the ability to manage them from this Mac (re-publish, unpublish, edit) until you sign back in. Your other identity's publications are unaffected.

Yes. You sign in with Apple the first time you click Publish. The Apple sign-in sheet appears in the Mac app; once signed in, your Apple user ID and a session token are stored in Keychain and refreshed automatically. Publishing routes through Muninn's backend; you don't bring your own Vercel/R2/database account.

Yes. Sign in to the gallery URL in your browser (Muninn opens you signed-in automatically after a publish) and a Preferences panel appears in the corner. Tune theme (Dark/Light), background tone, display face (Sans/Serif/Condensed), grid layout (Justified/Masonry), columns 1-8, photo border, header variant (text-only / bleed cover / centered text / side-by-side), and slideshow controls when a slideshow is attached. Defaults are the Muninn brand baseline. A publisher who never opens the panel still gets a Muninn-canon gallery.

Yes. While signed in, hover any photo and a "Set as Cover" pill appears in the top-left of the cell; the current cover gets a star pill instead. Your web pick sticks: re-publishing from Muninn will not overwrite it. It stays the hero until you deliberately choose a different cover in the Mac app (right-click a photo, Set as Album Cover), which takes over on the next publish. In short, whichever side you changed most recently wins, so neither app can quietly undo a choice you made in the other. The gallery grid always follows your photo order; the cover drives the hero independently and is never moved to the front of the grid.

Yes. Automatically. If you've built a slideshow for the album in Muninn, it's rendered in parallel with the photo uploads and attached to the gallery. The slideshow surfaces on the gallery via your chosen indicator (Ribbon, Film Strip, or hidden) and plays in an in-page modal. No separate page navigation. On bleed-cover or side-by-side header variants you can also set Cover medium = Slideshow so the play button overlays the cover photo as the hero.

No, by default. Every gallery serves <meta name="robots" content="noindex"> and the gallery domain's robots.txt disallows everything. Galleries are "share with people I send the link to," not "I want this on the open web." An opt-in per-album indexing toggle is on the roadmap.

Yes. Subdomains only in v1. Settings → Publishing → Custom Domains, type the subdomain you want (e.g. photos.example.com), click Add. Muninn registers it with our hosting provider and shows you a CNAME record to add at your registrar. After DNS propagates (a few minutes for most registrars), click Re-check; status flips to Verified and your existing gallery URL is also reachable on the custom domain. HTTPS is automatic. Let's Encrypt cert provisions during verification. Apex domains (example.com with no subdomain) aren't supported in v1 because they require ALIAS/A records that not every DNS provider offers.

The most common gotcha: most registrars want just the subdomain label, not the full hostname. If you're attaching photos.example.com, the Name / Host field at Squarespace, Namecheap, GoDaddy, Cloudflare, or Google Domains takes photos. The registrar appends example.com automatically. If you type the full photos.example.com there, those registrars will store the record at photos.example.com.example.com (broken). A few registrars do expect the full hostname instead. Muninn's DNS instructions sheet shows both forms with a copy button for each, plus a one-line check ("if after saving you see the record listed as photos.example.com.example.com, you used the wrong form. Switch to the other one").

cname.vercel-dns.com. The exact value comes back from the Vercel Domains API at registration time and is shown in the DNS instructions sheet with a Copy button. Use whatever the sheet shows you in case it ever changes. The target is the same for every Muninn publisher; it's the entry point for our hosting CDN, which then routes the request to the right gallery based on the Host header.

Settings → Publishing → Custom Domains → trash icon on the row. The domain is unregistered from our hosting and removed from your publisher record. Visitors arriving on the unregistered domain after that get a generic 404. Your canonical gallery.muninnmemory.app/<your-slug>/... URL is unaffected. If you want to move the domain to a different identity, detach from the first identity, then re-add from the second.

It means the domain is registered with our hosting but the CNAME record at your registrar isn't resolving yet. Either because you haven't saved it, the change hasn't propagated, or the record points somewhere else. Squarespace, Namecheap, GoDaddy, and Cloudflare typically propagate within 2–5 minutes; some legacy DNS providers can take up to 48 hours. Click Re-check periodically. If a domain stays Pending for two weeks, the daily cleanup sweep flips it to Failed. You can then detach and re-add to start over.

Because that’s the URL where you’re signed in. View on Web does a magic-link handoff so you land in the gallery already authenticated, with the Preferences panel available to tune theme, layout, header variant, slideshow visibility, and so on. The auth cookie is set on *.muninnmemory.app and won’t carry across to a third-party domain like photos.example.com. Web cookies are scoped to the issuing eTLD+1 by design, no way around it. So the author flow uses the canonical URL.

If you visit your custom domain directly (typing it in the browser, opening a shared link), you’ll see the gallery rendered exactly the same way visitors see it. Just without the Preferences panel. Both URLs serve the same gallery; only the auth state differs.

Yes. Once your custom domain is verified, every audience-facing share surface auto-rewrites to it: Share Public Link in the album toolbar (system share sheet with rich-link preview), Copy Public Link in the sidebar context menu (single-target and per-identity multi-target sub-menus), and the post-publish “here’s your link” row all hand off the photos.example.com/<album> form instead of the canonical gallery.muninnmemory.app/<slug>/<album>. If you have multiple identities signed in, each identity uses its own configured custom domain (or falls back to canonical when that identity has none).

If you detach a custom domain later, future shares revert to canonical automatically. No stale stored URLs, the rewrite happens client-side at copy/share time. Already-shared links to the old custom domain stop resolving once detached, so plan accordingly before pulling a domain that recipients have bookmarked.

Nothing. Custom domains resolve by hostname (the CNAME points at cname.vercel-dns.com); the publisher slug only matters for the canonical gallery.muninnmemory.app/<slug>/<album> URL. Renaming your slug from alex-reed to ar-photos doesn’t touch the DNS record, the Vercel domain registration, or the database row tying your domain to your publisher. photos.example.com/<album> keeps working without re-verification.

The slug-history 301 redirect kicks in for the canonical URL the same way it does for non-custom-domain visitors: visiting gallery.muninnmemory.app/alex-reed/oktoberfest after the rename redirects to gallery.muninnmemory.app/ar-photos/oktoberfest. Your custom domain skips the redirect dance entirely. No slug appears in the URL bar at all when visitors come in via your domain.

Yes. Right-click the album in the sidebar and the context menu expands per-identity sub-menus when more than one identity owns a publication of it. View on Web → Maxwell opens Maxwell’s gallery URL signed in as Maxwell (Album Preferences panel works); → Alex opens Alex’s URL signed in as Alex. Re-publish Now → Maxwell pushes the current album state to Maxwell’s publication only, leaving Alex’s untouched. Copy Public Link and Unpublish from <name> work the same way. Share Public Link in the album toolbar at the top of the gallery also expands per-identity when there are multiple publications.

The magic-link auth cookie is per-identity too. Clicking View on Web → Alex routes the magic-link through Alex’s session token, so the cookie that gets set in the browser matches the URL you land on. (Earlier in development we had a bug where the bearer was always the active identity regardless of which sub-menu entry you clicked; the cookie ended up for one identity and the URL for another, so the Album Preferences panel didn’t render. Fixed.)

The Preferences pill at the bottom-right of your gallery (when signed in as the owner). Click × on the panel to close it; click the pill to bring it back. The pill only renders for signed-in owners. Visitors don’t see it.

If you signed out by accident, follow the How do I edit my gallery from a different browser? path below to sign back in. Clicking Sign in in the gallery footer, authenticating, and landing back on the gallery with the panel open.

Two paths, both audience-discoverable from the gallery itself:

Path 1 (easiest): from the Mac sidebar, right-click your album → View on Web (per-identity sub-menu when multi-target). Muninn fires a one-time magic-link → Vercel sets the auth cookie → the browser lands on the gallery with the Album Preferences panel already open. No password to remember; the magic-link is single-use and expires fast.

Path 2 (no Mac handy): visit the gallery URL directly in any browser. Phone, friend’s laptop, incognito, anywhere. Scroll to the footer and click Sign in next to “Powered by Muninn · FORGE-MADE.” That hits gallery.muninnmemory.app/sign-in, runs Apple’s JS popup auth, sets the cookie on *.muninnmemory.app, and bounces back to the gallery with the Album Preferences panel ready.

The Sign in link in the footer is only visible when nobody is currently signed in. If you’re already authenticated as the owner, you see the panel itself (or the Preferences pill if you closed it). Anonymous viewers also see the Sign in link, but clicking through and signing in only grants editor access if your Apple ID matches the publisher who owns that gallery.

Two different scopes:

Mac Settings → Publishing → Web look-and-feel defaults are publisher-level. They stamp every new album at first publish. Tune theme, columns, header variant, slideshow indicator, etc. once, and every album you publish from that point inherits those values as its starting customization. Existing already-published albums aren’t touched.

Album Preferences (the on-gallery panel) overrides the publisher-level defaults for one specific album. Tweaking the theme to Light here changes only this album; sibling albums keep whatever they were already at. Re-publishing this album from Mac doesn’t clobber your Album Preferences edits. The Mac sends customization only on first publish, so re-publishes preserve the per-album overrides.

Rule of thumb: set publisher-level defaults once for your house style; use Album Preferences for the one-off “this wedding wants a lighter feel” tweaks.

Yes, by design. Unpublish soft-deletes the publication record server-side. The photos and slideshow MP4 are removed from R2 (the gallery is gone for visitors), but the row carrying your customization JSONB and password state survives in a hidden state for up to 30 days. Re-publishing the same album within that window resurrects the row, and your Album Preferences edits (theme, header variant, columns, etc.) come back exactly as you left them. Same shareable URL, same slug.

After 30 days the soft-deleted row is hard-deleted by the daily cleanup sweep, and a re-publish creates a fresh publication with default customization. The grace period is configurable on the backend (currently 30 days). Slug-collision behavior: if a soft-deleted “mountains” album exists and you re-publish under the same name, you get back the original row with original customization. Not a mountains-2 duplicate.

It means Mac tried to re-publish using a publication ID that the server no longer recognizes. The cause is almost always one of: (a) the publication was deleted off-device, perhaps by the daily cleanup sweep after a long unpublish, (b) the publication is owned by a different identity than the one Mac thinks owns it, or (c) the local record drifted out of sync after a database restore.

Click Publish as new. Mac drops the stale publication ID, retries the publish via the create-new path, and ends up with a fresh publication. If a soft-deleted record is still resurrectable for the same album name, the server quietly resurrects it (preserving customization). Otherwise you get a brand-new publication-id, and the previous shared URL stops resolving forever.

Cancel just dismisses the alert. Nothing changes locally or on the server.

Network glitch or transient server error. The alert appears when the server returns anything other than success or 404 (gone-already) on the unpublish request. Important: when this fires, your local publish state is preserved. The album’s sidebar globe icon stays visible, the Unpublish action is still available, and your audience can still see the gallery. Nothing is lost.

What to do: confirm your network is up, then right-click the album → Unpublish again. If the failure repeats, check the gallery URL in a browser. If it’s still loading, the server is reachable and something else is off (paste the alert text and we’ll dig). If it’s 502/504, the backend is rebooting; wait a minute and retry.

This is intentional: earlier in development the unpublish path cleared local state regardless of server response, so a network drop mid-unpublish made Mac think the album was unpublished even though the gallery was still serving. Now the local state only clears on confirmed success or a 404 (which means the publication was already gone, perhaps via a different device).

The globe shows an album's web publication state at a glance.

Green globe: a Live Web Gallery that is in sync. Changes you make publish to the web automatically.

Orange globe: a Live Web Gallery that is updating right now, or has an update pending.

Grey globe with a green dot: a published album that is in sync with the web.

Grey globe with an orange dot: a published album with local changes the web does not have yet. Re-publish to push them.

No globe means the album is not published.

An album published with the Live Album toggle turned on in the album editor. Once live, changes you make in Muninn (adding or removing photos, reordering, renaming, changing the cover) publish to your public gallery automatically, usually within about a minute. Muninn waits about 30 seconds after your last change so a batch of edits publishes as one update. If changes happen while Muninn is closed, they publish shortly after the next launch.

That album is a Live Web Gallery, so the photo will publish to its public gallery automatically. The warning appears when adding photos from the library, from a person, or by dragging onto the sidebar. Tick "Don't warn me about Live Web Galleries" in the dialog to stop the warnings, and re-enable them any time in Settings, Albums, Live Web Galleries.

Yes. Click the "Albums" header in the sidebar to open the album grid: one card per album with its cover photo and photo count. Sort by sidebar order, name, date created, last edited, or photo count; adjust card size with the slider in the footer; right-click a card for Open, Edit Album, View on Web, Copy Public Link, Lock, and Delete. Inside any album, the back chevron in the toolbar returns you to the grid.

Open the album, choose Custom from the sort menu, then click Edit. Drag photos where you want them: an insertion bar shows exactly where the photo will land. Click Done when finished. Your custom order is also the order the published web gallery uses, photo for photo.

The cover photo you set in Muninn (right-click a photo, Set as Album Cover) drives the web gallery's hero image. The gallery grid itself always follows your photo order; the cover is not moved to the front. If you pick a different cover on the web gallery's edit panel, that pick sticks: re-publishing from Muninn will not overwrite it. It holds until you deliberately set a different cover in the Mac app, which then takes over on the next publish. Whichever side you changed most recently wins, so a routine re-publish never undoes a web pick, and a new Mac cover is never ignored.

The Mac drives the order. Each album remembers its own sort (Date Captured, Date Added, or Shoot Name, ascending or descending), set with the sort controls at the top of the album view. That order is what gets published, and it is remembered per album, so sorting one album does not disturb any other. For a hand-picked order, switch the sort to Custom and drag photos into place. If the album is a Live Web Gallery, changing its sort re-publishes the new order automatically. On the web gallery you can override the order for that one gallery from the Album Preferences panel (Sort: Published Order, Date, or Random); Published Order is the default and simply mirrors the Mac.

Yes. Settings, Slideshow, "Fetch album artwork from iTunes". When on, Muninn looks up high-resolution cover art for your chosen slideshow song by its artist and title using Apple's anonymous iTunes Search API. When off, Muninn only uses artwork embedded in the audio file itself. This is not an Apple Music integration; it is a one-off artwork lookup for songs you provide.

Yes. Settings, Social, "Notify me when a scheduled post fails". This is the only notification Muninn sends; it appears when a queued social post cannot publish.

It was removed. The toggles it held never controlled anything: project tags (from shoot folder names) and source tags (from EXIF and folder data) are always applied automatically at import, and you can add or remove tags manually at any time.

Open any photo in detail view and click the share button (square-and-arrow-up) in the toolbar. The menu has Share… (the system share sheet. Mail, Messages, AirDrop, Notes, Reminders, Save to Files, etc.) and Export to Apple Photos (lands in your "Muninn" album in Apple Photos and syncs to your phone via iCloud).

Yes. Right-click (or two-finger click, or ctrl-click) a thumbnail in the grid, or the image in the fullscreen view, and choose Copy. Muninn puts both the picture and the file on the clipboard, so you can paste the image into Messages, Mail, or an editor, or paste the original file straight into a folder in Finder.

Yes. Drag any thumbnail (or the fullscreen image) onto a Finder window, the Desktop, or another app to copy the original file out. Muninn is non-destructive, so the original stays exactly where it lives. Dragging a photo out and back into Muninn just cancels, it does not re-import.

In the detail view's inspector, right-click the path in the Path section and choose Reveal in Finder (jumps to that location and selects the file) or Copy Path. If the file's drive is offline, Reveal in Finder falls back to opening the containing folder.

Top-right of the album view has a share menu (square-and-arrow-up) with three options: Share Public Link… (opens the system share sheet with the gallery URL. Only available when the album has been published to the web), Export to Apple Photos… (creates an Apple Photos album with the same name and adds all the photos plus optionally the slideshow), and Share as Bundle… (builds a zip of the photos plus optionally the slideshow ready to AirDrop, email, or save).

Creates an Apple Photos album named after the Muninn album and adds every photo in it. Originals are exported (RAW files included). Once iCloud Photos syncs, the album shows up on your iPhone in the Albums tab. The export sheet has a per-export toggle to also include the rendered slideshow video; the default tracks Settings → Publishing → "Also export the slideshow video."

No. Muninn stamps every successfully-exported photo with its Apple Photos identifier, and on re-export it looks up the existing asset and re-attaches it to the destination album rather than creating a new copy. Photos you've deleted from Apple Photos since the last export get a fresh copy. The done sheet shows separate counts for "new" (just exported) and "already exported" (re-attached).

It's a per-export choice. The export sheet has an Include Slideshow toggle (default on, if you have one rendered). When on AND the album has a fresh slideshow MP4 cached, the slideshow video lands in the same Apple Photos album as the stills. The done sheet says either "Slideshow video added," "Slideshow not added. No rendered MP4 in cache" (run the slideshow once to cache it), or "Slideshow failed: <reason>" so you know exactly what happened.

Builds a single zip file of an album so you can AirDrop it, email it, message it, or save it to Files. Two quality modes: Compress for iMessage / Mail resizes photos to 2048 px JPEG and re-encodes the slideshow at 720p so the bundle fits inside messaging-app attachment limits (typically under 100 MB). Originals ships full-resolution photos and the original-quality slideshow MP4. Best for AirDrop or large file sharing. The build sheet shows a live size estimate so you can pick the right mode before building.

While building, the zip lives in a temporary directory. The done sheet has Download (saves the zip wherever you choose, defaults to ~/Downloads. Atomic move so no copy is left behind) and Share (opens the system share sheet. The temp file is cleaned up after the share completes). Cancel also cleans up. Either way, no zips pile up in your temp directory between sessions.

Per-photo: Share… (system share. For sending one image) and Export to Apple Photos (for adding one image to your phone). Per-album: Share Public Link… (sends the gallery URL. Most efficient for "send 95 photos to a family member"), Export to Apple Photos… (whole album syncs to phone), and Share as Bundle… (offline-friendly zip when the recipient doesn't have a way to view the gallery URL). The shapes match the typical workflow. Single photo gets shared one-off; whole albums get shared via published gallery, synced to phone, or bundled for offline transport.

Yes. The Download button on the bundle done sheet opens a save dialog where you pick the destination. The temp copy is moved (not copied) to your chosen location, so no duplicate gets left behind.

Visit gallery.muninnmemory.app/sign-in and tap Sign in with Apple. Once your Apple ID is recognized as a publisher, the gallery's Preferences panel works from any browser. Phone, friend's laptop, anywhere.

When you've marked one of your People clusters as "Me" (right-click → Mark as Me in the People view), the avatar picker grows a button that surfaces a grid of every photo containing your face. Pick one, reframe with pinch + drag inside the circular crop sheet, Save.

A small panel inside the lightbox showing camera, lens, ISO/aperture/shutter, focal length, capture time, and (for Fujifilm) film simulation. Three modes in Settings → Publishing: Visible by default, Off but viewer can reveal (default), or Hidden entirely. Per-album override on the gallery's Preferences panel.

Granular toggles in Settings → Publishing → Photo info on web galleries: Camera body, Lens, ISO/aperture/shutter, Focal length, Capture date/time, Film simulation. Default all on. Photo-nerd-friendly. GPS is governed separately by the per-album "Include map" toggle.

GPS is the privacy-critical group (home, school, work locations). Camera/lens/exposure/timestamp is the photo-nerd payload most photographers happily ship. Default: strip GPS, keep the rest. Applies to Share menu, downloaded photos, and album bundles.

No. Re-publishing from Mac preserves the customization (theme, columns, header variant, photo info HUD, etc.) you tweaked on the gallery's Preferences panel. Mac sends customization only on first publish; re-publishes leave it out and the server preserves what's there.

Yes. Settings → Publishing → Web look & feel defaults: Theme, Background tone, Display face, Grid layout, Columns, Photo border, Header variant, Gallery sort, Slideshow indicator, Cover medium, Map entry, Map style, Photo info HUD. These stamp every new album at first publish.

When on (default), a password-protected album shows its cover, title, and description above the password input on the gate page. And rich link previews (iMessage, Mail) include the cover. A teaser to build anticipation. When off, the gate page is bare and the OG meta drops the cover. Per-album override in the editor.

They're forced to re-enter the new one. Each unlock cookie carries the publication's password version; the server re-checks it on every gallery view. Rotating the password bumps the version, every old cookie stops validating immediately.

If the photo upload pass hasn't completed within 15 minutes, the landing page hides the empty publication as an orphan. Re-publish from the album's right-click menu. That bumps the updated timestamp, restarts the upload, and the album reappears within the grace window.

The slideshow publication exists server-side but the MP4 didn't land on R2. Re-publish the album from Muninn. The existing-publication-id flow retries cleanly. Once the MP4 lands, the notice disappears and the slideshow indicator + cover render.

Yes. Settings → Publishing → Profile. Website renders as a small monospaced link under the bio; gear renders as a labeled bullet list (one item per line). Both hide cleanly when empty.

Muninn supports eight platforms: Bluesky, Mastodon, Threads, Instagram, Facebook, X, LinkedIn, and Pinterest. All eight are open to everyone: connect each account with its own sign-in from the Connect dialog and start posting.

Pinterest pins live on boards. Every pin must specify one. Muninn picks the first board on your account as the default at connect time; change it any time via Settings → Social → the Pinterest row → Change board…. Pinterest only supports single-image pins via API v5; ComposeSheet's photo-count clamp warns when you have a multi-photo post with Pinterest selected. Title is auto-derived from the first ~100 chars of your caption; the full caption rides as the pin description.

Yes. ComposeSheet (the full composer, not the right-click SharePanel) has a tertiary "Save as draft" button to the left of the Schedule… / Post buttons. Drafts land under the Drafts pill on the Scheduled view. Open one from there to edit the caption, accounts, or scheduled time. The Edit panel adds a primary "Schedule…" button that promotes the draft to queued in one action. SharePanel (right-click) and the drip editor do not have a Save-as-draft button by design. SharePanel optimizes for fewer decisions on the casual fast path, and a drip is N rows where "draft" doesn't map cleanly.

Right-click any photo → Share to social… → a quick Share panel opens with your connected accounts pre-checked. Type an optional caption → Post to N or Schedule… for later. Three clicks if you have one account, no decisions if you don't want any. The Share panel is the casual fast path; click "Open full composer →" if you need carousels, per-platform character counters, or to fan out across multiple Muninn identities.

The Share panel is the right-click quick-post surface: one photo, your already-connected accounts pre-checked, optional short caption, Post Now or Schedule. The full Composer (reached via "Open full composer →" or via the Social workspace's Compose tab) is the power surface: carousels (drag-to-reorder), per-platform character counters, a two-level account picker grouped by Muninn identity, scheduling controls, and the ability to add more photos from your library. Both routes use the same backend. They're just two presentations of the same compose action.

No. Scheduled posts fire from Muninn's server (a Vercel cron tick every five minutes), so the Mac can be closed, asleep, or offline at the scheduled time. Posts land within ~5 minutes of their scheduled time.

Settings → Social → Add account → Bluesky. Muninn opens a browser page that asks for your handle and a Bluesky App Password (not your account password). Mint an App Password at bsky.app/settings/app-passwords, paste it in the form, and you'll jump back to Muninn with the account connected. Tokens are stored encrypted at rest.

Settings → Social → Add account → Mastodon. The browser page asks for your instance host (e.g. photog.social). You'll be sent to your instance to authorize Muninn, then bounced back. Muninn registers a per-instance OAuth app on first connect and remembers it.

Yes. There's no per-platform sub-cap. You get 30 connected accounts pooled across your subscription (up to two identities), so you can split them across Bluesky, Mastodon, Instagram, Threads and the rest however you like. Generic schedulers cap at five profiles total; Muninn gives you 30, with a $5/mo add-on for 10 more.

Social scheduling is part of Muninn Pro ($19/mo founder rate for launch subscribers, kept for as long as you stay subscribed; $24.99/mo standard). Muninn Web ($4.99/mo) publishes unlimited web galleries without social; Pro adds scheduled and immediate posting to all eight platforms, with 30 connected accounts and no per-profile fees.

No. Photos upload on the fly when you Post Now or Schedule. If a photo is already in a published album, the upload is a no-op (Muninn reuses the existing storage); otherwise the bytes go up the first time you post that photo.

By default it appears only when you have at least one queued post, at least one drip campaign, or three or more connected accounts. The casual user with one account doesn't need a sidebar item taking up space. Once it appears, it stays visible (sticky) so it doesn't flicker out when the queue empties. Settings → Social → Show in sidebar lets you flip to Always or Never.

The Social workspace has three tabs:

• Scheduled, the queue. Filter pills (All / Queued / Posted / Failed / Canceled / Drafts) + search. Three presentations: List (typographic ledger grouped by day), Calendar (month grid, drag a chip to a different day to reschedule), and Stream (typographic spine with larger photo previews under each caption). Click any row to open the Edit panel.
• Compose, the full Composer embedded inline. Same as the right-click "Open full composer →" handoff, just always there as a tab.
• Drip, list of your drip campaigns + "+ New campaign" launcher (picks an album, then opens the drip editor).

Yes. In the Social workspace's Scheduled tab, switch the view-mode segment from List to Calendar. Each day shows up to three queued/posted/failed post chips (platform mark + time + first-sentence caption). Click a chip to open the Edit panel. Drag a chip from one day to another to reschedule. It preserves the time-of-day on the new date. Drag is gated to queued and draft posts; already-fired posts can't be moved.

Yes. While it's still queued or a draft. Click any row in the Scheduled view to open the Edit panel. You can change the caption, swap or reorder photos, add new photos from your library, reschedule to a different date/time, retry a failed post, or discard it. Drag a thumbnail to reorder (the first slot is the cover); click the X to remove; click "Add" to pick more from your library. Once a post is in firing or posted status it's history and immutable; you can re-post (creates a new post from the same photos), but you can't edit the original.

Yes. In the Scheduled view, click the stacked-chevron toggle next to the List/Calendar/Stream picker to flip between oldest first and newest first. Direction applies to the List and Stream presentations (the Calendar is a month grid and ignores it). Your preference persists across launches.

Two ways. Open any individual failed or canceled row in the Edit panel and click Discard to permanently remove just that one. Or filter the Scheduled view to Failed or Canceled and click the red Clear all pill at the end of the filter row to remove every matching row at once after a confirmation. Both actions hard-delete the rows from the server. Posted rows can never be deleted (they're history).

Yes. Click any photo thumbnail anywhere in the Social workspace, in the Compose sheet, the right-click Share panel, the Edit panel for a scheduled post, the Re-post sheet, or the Drip builder's slot list, and the photo opens in a fullscreen preview. Click anywhere or press Escape to dismiss. Remote photos (already-queued or posted) resolve via signed thumbnail URLs; local photos load instantly.

Yes. Open the Edit panel on any posted row. There's a primary "Re-post…" button. The Re-post sheet opens with the original photos pre-loaded (click any thumbnail for a fullscreen preview), the original caption pre-filled and editable, and the original accounts pre-checked. Any accounts you've added since the original post show up with a small NEW badge so you can see what's new in the list. Hit Re-post to N or Schedule for N to send. Each re-post is a brand new post in your queue. The original posted row stays as history.

A drip campaign turns an album (or a folder) into a multi-day posting plan. Pick a cadence (specific weekdays, or a simple Daily / Every other day / Weekly interval), photos-per-post (1–4), order (by shoot time / album order / shuffle), a schedule mode, target accounts, and a caption template. Muninn schedules the posts and queues them server-side so they fire whether or not your Mac is running. You can pause, edit, or delete a campaign at any time, and delete individual posts within it.

Three paths to the drip editor:

• Right-click any album in the sidebar → "Schedule as drip campaign…"
• Open the album, then use the toolbar share menu (↑ icon) → "Schedule as drip campaign…"
• Social workspace → Drip tab → "+ New campaign" → pick an album from the picker

All three open the same editor pre-loaded with that album's photos. (The Drip tab's "Import from folder…" opens the same editor pointed at a folder + optional manifest instead of an album.)

Put a calendar.md (or queue.md, calendar.csv, queue.csv) next to your images in the campaign folder, then use Social > Drip > "Import from folder…". Each ## Platform heading is a stream that posts to the accounts you check for it in the editor. Name the account right in the heading (for example ## Facebook — Your Page Name) and Muninn pre-checks it for you; platforms where you only have one connected account pre-check automatically. A stream with no accounts checked shows a SKIPPED tag and imports nothing, so an unrouted stream can never accidentally post everywhere. Repeating an entry under two sections creates two separate posts; they are never merged. A minimal example:

## Instagram

- **Mon, Aug 4 · Launch**
  - Image: photo-01.jpg
  - Caption: Day one. No hashtags up here.
  - Time: 18:00 PT
  - First comment: #your #hashtag #block

## Facebook

- **Mon, Aug 4 · **
  - Image: photo-01.jpg
  - Caption: The longer Facebook telling of the same shot.
  - Time: 08:00 PT
  - Link: https://your-site.example

Fields per entry (only Image is required): Image (pipe-separate for a carousel: a.jpg | b.jpg), Caption, Time (24-hour, optional timezone like 09:00 PT; AM/PM is not supported), Tags (comma-separated @handles), Location, Link, First comment (Instagram), Accounts (per-post routing override), Recycle (yes/no). Dates use a month name plus day ("Aug 4" or "Mon, Aug 4"); the year comes from the campaign year you pick in the editor. Three gotchas: head an X section "X (Twitter)" or it will not route; never use a bare # line as a divider inside a section (any line starting with # reads as a new heading); and a date the parser cannot read sends that post to the undated pool.

Before you save, three quick checks: every stream in the Sections panel shows the account you expect checked (no surprise SKIPPED tags); the routing line on a few review cards reads like "→ @youraccount · Facebook" rather than listing several accounts with "default"; and the post count in the header matches what your file contains. Thirty seconds of checking beats un-queuing a misrouted campaign.

Muninn clamps automatically (over-long captions and extra photos are trimmed at dispatch), but the limits are why a slightly different version of the same post per platform is usually worth it: Pinterest keeps only the first photo of a carousel, X clips a long shared caption mid-sentence at 280 characters, only Instagram has a First comment for the hashtag block, and only Facebook and Pinterest attach a real destination link. The full rundown:

• Bluesky — 300 characters, up to 4 photos. @mentions become real tappable mentions when the handle resolves (handles are domains, like name.bsky.social; underscores are not valid).
• Mastodon — 500 characters, up to 4 photos. Handles can be user or user@instance.
• Threads — 500 characters, up to 10 photos as a swipeable carousel.
• Instagram — 2,200 characters, up to 10 photos as a carousel. The First comment field posts your hashtag block as the first comment so the caption stays clean. Links in captions are not tappable, so put the URL in your bio or caption text knowingly.
• Facebook — effectively unlimited text, up to 10 photos, and the one platform (besides Pinterest) where the Link field attaches a real destination link. Posts go to a Page, never a personal profile.
• X — 280 characters, up to 4 photos. The one metered platform: Pro includes 120 X posts per month, pooled across the subscription.
• LinkedIn — 3,000 characters, up to 9 photos. Posts to the personal feed; there are no @-handles.
• Pinterest — 500 characters, exactly 1 photo per pin. The pin title is drawn from the start of the caption, and the Link field is the whole point of a pin, so give every pin one. Pins land on the board picked at connect time.

Practical upshot for a manifest: write the short X and Bluesky captions as their own sections rather than letting a long caption get cut mid-sentence, park Instagram hashtags in First comment, and give Facebook and Pinterest entries a Link.

Yes, and it is the recommended shape for a launch: dated posts for the days that matter, an undated pool for everything else. Whether an entry is dated or pool is decided only by its bold slot line. - **Aug 4 · ** fires once on that day and never recycles. A slot line with no readable date, like - **Backlog · **, joins the pool, and the campaign cadence schedules pool posts onto the open days around your dated ones.

Evergreen means a pool post repeats. Turn it on per post with Recycle: yes, or flip the whole campaign to Evergreen in the import editor and opt individual posts out with Recycle: no. Fresh pool posts always go out before any repeat, so a new backlog drains once before it starts looping. To convert a dated post into an evergreen one, remove its date so it becomes a pool post and mark it Recycle: yes; a post keeps its date or recycles, never both.

- **Backlog · **
  - Image: photo-05.jpg
  - Caption: An evergreen shot. The cadence schedules it.
  - Recycle: yes

One-shot (the default) posts each photo once on its scheduled date, then the campaign is done. Evergreen turns the album into a pool that keeps posting on your cadence and recycles when it runs out, so the campaign never ends on its own. Pick the mode with the "Post schedule" toggle in the editor; evergreen also exposes a recycle order (loop or shuffle) and a horizon (how far ahead posts are prepared).

Yes. In the Social workspace's Drip tab, click "Edit" on any active or paused campaign. It reopens with your saved settings and the exact posting order preserved (including a shuffle). Change the caption template, per-post captions, accounts, cadence, order, photos-per-post, or the schedule, then Save. Changing only the caption re-uses the same queued posts; changing dates or order reschedules them.

Yes. A paused campaign stops firing until you resume it. On resume, Muninn asks whether to continue where it left off (the remaining posts re-space one per cadence starting the next day) or skip the posts that would have gone out during the pause and pick up from today. The Drip tab shows Pause / Resume / Edit / Delete on each campaign.

Yes. In the editor's schedule list, right-click a post → "Delete post". The post greys out with a Restore option instead of disappearing, and the remaining posts close the gap. The removal is saved with the campaign, so re-editing keeps it out; click Restore any time to bring it back.

In the Drip tab, click "Delete" on any campaign (a confirmation names the campaign first). This stops it and permanently removes it along with its unsent posts. Anything that already posted stays as history on the accounts it went to.

Yes. In the drip editor's schedule preview, every slot has a small pencil icon next to its date. Click it to type a custom caption for just that one post. The slot gets a CUSTOM badge so you can see at a glance which posts differ from the template. A "Reset to template" link drops the override and the slot goes back to the template-resolved caption. Use overrides for the captions that need to be unique. "Checking in to our new home for the week". While keeping the template baseline for everything else.

Yes. Click any photo thumbnail in the slot list to view it fullscreen. Click anywhere or press Escape to dismiss. Thumbnails load asynchronously and downsampled so even a 200-photo drip opens instantly. The same click-to-preview affordance works everywhere photos appear in the Social workspace (Compose, Share, Edit, Re-post).

Reusable caption shapes with tokens that auto-fill from each photo's metadata. Create them at Settings → Social → Caption templates → "+ New template". For example, a template body of {cameraModel} · {location} would resolve to "X-E5 · Posthotel" for one photo and "X-T5 · Leavenworth" for the next. Click any token chip in the editor to insert it at the cursor. One template can be marked as default; that is the one Muninn offers first.

Every token works in every caption template: the ones in Settings, Social and the one on a drip campaign. Click "Tokens" in either editor to see this list with a live preview against one of your photos.

The full reference, with examples, date formats and the rules, is at muninnmemory.app/tokens.html.

Numbering. {number} is the photo's number in the album, assigned once and never reused, so a shuffled campaign and a re-save keep every photo's number ("From the Vault #12"). {number:03} pads it. {index} is the photo's position in the album's order when the campaign was saved, {count} the album's size, {slot} and {total} the post's place in the campaign.

The photo. {caption} (a folder manifest's caption), {comment} (the inspector's Comment), {fileName}, {shoot} (the Shoot tag), {people} (the named people in the frame), {tags}, {hashtags}, {location}, {city}, {country}.

The camera. {cameraModel}, {cameraMake}, {lens}, {focalLength}, {aperture} (as f/8), {shutter} (as 1/250), {iso} (as ISO 400), {filmSimulation}, {recipe} (the film simulation today, the Huginn recipe name once frames carry it), {whiteBalance}, {exposureComp}.

Time. {date} (March 12, 2026; {date:MMM d} for a format of your own), {year}, {monthName}, {day}, {weekday}, {time}, {season}, {ago} ("3 years ago", or "3 years ago today" when the post lands on the anniversary), {postDate} (the day the post goes out).

The album and you. {albumName}, {albumDescription}, {albumUrl} (the published gallery link, on your own domain when you have one), {displayName}, {signature} (your signature line from Settings, Social, one per identity), {handle} (your handle on the platform the post goes to), {platform}.

The shoot and the look. For frames that went through Huginn and Valkyrie: {shot}, {set}, {lightWindow}, {place}, {mood}, {creator}, {creatorHandle}, {recipeCode}, {palette}, {cameraSlot}, {creatorUrl}, {recipeUrl}. A token is always plain text, so {creator} writes the name and {creatorUrl} writes the address; the photo inspector and your published gallery render the credit as a real link. {recipe} reads the recipe name from the same record and falls back to the film simulation. Frames that never went through them have none of these.

Social. {mention:Name} writes a Directory contact's handle for the platform the post goes to. {random:one|two|three} picks one option per photo and keeps it on re-save, so a long campaign does not open every caption the same way.

Three rules. A token with nothing to say vanishes, and a line left with nothing else goes with it, so a template can carry {comment} or {people} on its own line without leaving blanks. A token Muninn does not know stays as typed, so a typo shows. {handle}, {platform} and {mention:} give each platform its own copy of the caption automatically.

The Comment field in the photo inspector (top-right when you open a photo in detail view) is a per-photo annotation. It surfaces in three places: as an overlay at the bottom of the photo in detail view, in slideshows as a caption layer, and as the {comment} token inside caption templates. Use it on a few signature shots in an album. "Such a cozy place for a night cap". And let drip campaigns surface those custom blurbs while the rest of the campaign uses the template baseline.

A comment can carry caption tokens too. "Shot on {cameraModel}, {ago}" renders on the web album, in the slideshow and on the detail overlay; the inspector shows the rendered line with the template beneath it. In a comment, {handle} is your suite handle (the @name on your gallery address), {number} counts within the album the photo is published in, and the post-only tokens ({slot}, {platform}, {mention:}) come out empty. Full reference: Caption tokens.

Yes. Export any album to Apple Photos so it's visible on your iPhone for in-person showing. This is a bridge until the iOS companion app ships.

Facebook requires a Page-level publishing authorization on some Pages, and it has to be completed in the Facebook mobile app. Open the Facebook app on your phone, switch to the profile that admins the Page, and follow the identity prompt for that Page. Once it's confirmed, retry the post and it will publish.

Two things that commonly confuse this one. First, it is separate from the Identity Confirmation on your personal profile. You can show a green "Your identity is confirmed" check and still hit this, because that confirmation may only cover other features such as political ads. Second, it is per Page. If you manage several Pages, one can be blocked while the others publish normally, which is also the fastest way to confirm the problem is the Page and not your account: post to a different Page you manage. If that works, the issue is scoped to the one Page.

Meta applies this to Pages that cross certain audience or reach thresholds, so a Page that published fine for months can start requiring it with no warning and no change on your side. Your Page settings may still show "no issues" while the API refuses to publish.

The access token for that account is no longer valid, so Muninn can't post on its behalf. Disconnect the account in Settings, Social, then connect it again. That issues a fresh token and the account starts working immediately.

This usually follows a password change or a security checkpoint on the Instagram account. It can happen even when the token has not expired and even when Instagram's own "Apps and websites" screen shows nothing under Removed or Expired, so there is often no visible reason. Reconnecting is the fix in every case.

No. Disconnecting marks the account inactive rather than deleting it, and reconnecting restores the same account record. Every scheduled post stays attached and picks up the new token automatically. You can reconnect as often as you need without touching your queue.

Reconnecting also works when you are at your connected-account limit, because reconnecting an existing account does not consume another slot.

No. Muninn records which accounts published successfully, and a retry only attempts the ones that have not gone out yet. You can retry a mixed post as many times as you need without duplicating anything on the platforms that already succeeded.

When several posts failed for the same reason, filter to Failed and use Retry all to requeue them in one go. Fix whatever caused the failure first, because retried posts send right away.

The Forge skull-and-hammers logo and FORGE-MADE. text appear at the bottom of the General settings tab. It's the hallmark of The Forge. The software studio behind Muninn. Every app shipped by The Forge carries this stamp.

Cmd+Comma, or Muninn menu → Settings. The settings window is managed via AppKit (not SwiftUI's Settings scene) to ensure the keyboard shortcut works reliably.

SQLite via GRDB 7.x. The database lives at ~/Library/Application Support/Muninn/muninn.sqlite. The v1 schema includes tables for photos, albums, album-photo junctions, tags, and photo-tag junctions. Supporting multi-album and multi-tag from day one.

A secret easter egg activated by a konami-style key combo. Find it.