Muninn · Reference
Every feature, setting, and behavior in Muninn. Looking for the short version? See the FAQ.
No matching questions.
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 in Sentinel, 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. Muninn pairs with Sentinel in the photography suite: Sentinel culls, Muninn remembers.
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. For culling, use Sentinel.
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: Basic ($4.99/mo) publishes unlimited web galleries; Pro ($14.99/mo) adds scheduled and immediate social posting to Bluesky, Mastodon, Threads, Instagram, Facebook, Pinterest, and LinkedIn. 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.
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. 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.
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. Muninn reads Sentinel's output folder structure directly. It detects your shoot folders, camera subfolders, and Sentinel session files, then imports your keeper photos automatically. Camera model and shoot name are applied as tags automatically.
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:
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:
/Media/2026-04-01 Studio Session/. Every photo gets the project tag "2026-04-01 Studio Session."/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).
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:
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:
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:
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:
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.
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 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:
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. Apple Music is not a supported source. DRM prevents track export and we removed it pre-ship in favor of a single clean path: upload your own music file. 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:
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.
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:
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:
Caches/Muninn/AlbumArt/ so the same song is looked up only once. Default on.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:
Apple Music tracks are DRM-protected. The stream can play live in an app, but it can't be written into an exported video file. The split UX ("plays in preview, silent in the export") was confusing, so we pulled Apple Music from the music picker for v1 and shipped a single clean path: upload your own music file.
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. Re-publishing replaces the published state with the album's current state. Same URL, same slug, same publication ID. Family bookmarks stay valid. Adding photos, removing photos, changing the cover, swapping the slideshow all flow through the same Publish action.
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. 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. Matt'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. The choice persists with the publication.
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 matt-grimes to mg-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/matt-grimes/oktoberfest after the rename redirects to gallery.muninnmemory.app/mg-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); → Matt opens Matt’s URL signed in as Matt. Re-publish Now → Maxwell pushes the current album state to Maxwell’s publication only, leaving Matt’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 → Matt routes the magic-link through Matt’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).
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).
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.
Bluesky and Mastodon are live today. Pinterest and Threads adapters are also shipped. Pinterest is gated on Pinterest's trial-access approval before its app secret is released; Threads is gated on Meta's app review for the threads_content_publish permission. Instagram, Facebook, X, and LinkedIn are still on the roadmap. All eight platforms appear in the Connect dialog with their availability status.
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 DripBuilder 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 cap. Connect as many Bluesky, Mastodon, or future Instagram/Threads accounts as you want under each Muninn identity. Generic schedulers cap at five profiles total; Muninn doesn't.
Social scheduling is part of Muninn Pro ($14.99/mo). The Basic plan ($4.99/mo) publishes unlimited web galleries without social; Pro adds scheduled and immediate posting to all seven platforms with no per-profile fees or metering.
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:
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 into a multi-day posting plan. Pick a cadence (Daily / Every other day / 2× per week / Weekly), photos-per-post (1–4), order (by shoot time / album order / shuffle), start date+time, target accounts, and a caption template. Muninn schedules N posts spread across the cadence and queues them all server-side. Cancel the campaign at any time to soft-cancel every still-queued post in it. Already-fired posts stay as history.
Three paths to DripBuilder:
All three open the same DripBuilder pre-loaded with that album's photos.
Yes. In the DripBuilder'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; the default is used as the starting point in the full Composer's caption field.
{location}, the photo's reverse-geocoded place name from EXIF GPS or your LocationPicker assignment{cameraModel}, EXIF camera make + model (e.g. "Fujifilm X-E5"){lens}, EXIF lens model{aperture}, formatted as f/8 or f/2.8{shutter}, EXIF exposure time (e.g. 1/250s or 30s){iso}, formatted as ISO 400{date}, photo capture date (e.g. March 12, 2026){albumName}, album name (when the post was launched from an album view){comment}, the photo's user-authored Comment from the inspectorMissing/empty values collapse to , (so you can see what failed to expand), with one exception: missing {comment} disappears cleanly, including any whitespace or newlines around it. Most photos won't have a comment, and an empty , reads as broken inside a social post.
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.
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.
| Tab | Contents |
|---|---|
| Library | Import sources, duplicate handling, file reference behavior |
| Albums | Default album sort, cover photo behavior |
| Tags | Tag type management, AI suggestion toggle, auto-tagging behavior |
| Publishing | Identities (per-identity sign-in/sign-out + active picker + "Sign in with another Apple ID" browser bridge), Profile (display name, title, location, description, avatar, website, gear, URL slug), Account (sign-in info), Publish defaults (gallery privacy, map, indexable, locked-page teaser, slideshow + bundle export inclusion), Web look-and-feel defaults (theme, background, face, grid, columns, photo border, header variant, gallery sort, slideshow indicator/cover, map entry, map style, EXIF visibility), Photo info on web galleries (granular keep-flags). Per-album controls live in the publish sheet + on-gallery Preferences panel. |
| Social | Per-identity connected social accounts (Bluesky, Mastodon. Threads, Instagram, Facebook, X, LinkedIn, Pinterest on the way), Caption templates (create/edit/delete with token reference + default selection), Show-in-sidebar mode (Auto / Always / Never) |
| General | Launch at login, notifications, app version, Forge-made stamp |
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 and Sentinel. 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. Details TBD at launch time.