tags are how the marketplace is browsed rather than scrolled: a list of them on the left, the plugins that carry one on the right. a closed vocabulary (PLUGIN_TAGS in the platform) because free text becomes homelab, home-lab, Home Lab and selfhosted inside a month, and a filter list of synonyms is worse than no filter at all. declared here rather than curated in the catalogue, so a plugin can say what it is and nobody edits a table when one ships. the marketplace caches it on sync, exactly as it already does for label and summary.
50 lines
1.9 KiB
TypeScript
50 lines
1.9 KiB
TypeScript
import type { PluginManifest } from '@@/plugins/manifest';
|
|
|
|
/**
|
|
* Photos — your Immich library, reached through Officer.
|
|
*
|
|
* ── What this plugin is, and what it is not ──
|
|
*
|
|
* It does NOT store photographs, and it does not install Immich. You point it at an instance you already
|
|
* run and it forwards to it, holding the API key server-side so no device ever carries one. The library,
|
|
* the originals and every thumbnail stay where they are.
|
|
*
|
|
* The account registry is per-user and already server-side (`photos_config`): a label, a URL and an
|
|
* encrypted API key, with one marked active. Adding and switching instances happens in the app rather
|
|
* than in a shell, which is why nothing here reads `process.env` — an `IMMICH_API_KEY` in `.env` would
|
|
* also sit in the environment of every other pm2 process, including the one with the largest attack
|
|
* surface and no code to use it.
|
|
*
|
|
* ── No `osDependencies` ──
|
|
*
|
|
* Nothing shells out. The sidecar is a Bun HTTP proxy and reaches Immich with `fetch`.
|
|
*/
|
|
export const manifest: PluginManifest = {
|
|
publisher: 'officerdev',
|
|
version: '1.0.0',
|
|
platform: '>=1.0.0',
|
|
|
|
label: 'Photos',
|
|
summary: 'Your Immich library — browse, search, upload from the phone',
|
|
/** Google Photos is the thing it replaces. */
|
|
tags: ['Personal', 'Degoogling'],
|
|
icon: 'Images',
|
|
color: '#10b981',
|
|
|
|
// Immich accounts are created one per Officer account. Declared here so the owner sees it on the install
|
|
// screen beside the permissions — "this plugin will be told who your users are" belongs where a person
|
|
// decides, not in a log afterwards.
|
|
//
|
|
// What it turns on: the sidecar receives `users:list` when it registers and whenever an account is
|
|
// created or removed. See src/servers/plugins/user-provisioning.ts and plugins/USER_PROVISIONING.md.
|
|
userProvisioning: true,
|
|
|
|
permissions: [
|
|
{
|
|
key: 'photos',
|
|
label: 'Photos',
|
|
description: 'Browse the photo library',
|
|
},
|
|
],
|
|
};
|