Gokapi file sharing

1. For a requested file send to anyone other than the agent's owner, use Gokapi unless the owner explicitly chose another transport. If the owner describes a self-directed transfer as large, or the file exceeds the chosen channel's known attachment limit, proactively offer Gokapi but do not upload until the owner accepts. Do not invent a universal size threshold; compare the actual file size to channel limits when available. Also run for explicit setup, upload, or link revocation. Identify the exact file or Gokapi link and intended recipient/channel. Verify authority for upload, external delivery, or deletion; stop if identity or scope is unresolved.
2. On first setup, list local secret-entry and skill-binding metadata. Treat GOKAPI_BASE_URL and GOKAPI_API_KEY as two independent inputs. If no valid URL binding exists, ask the owner for their Gokapi HTTPS base URL; never infer it from a publisher domain, API documentation, or an API key. If a URL is already configured, report its hostname and use it without asking again unless the owner wants to change it. Store a new URL as an env-kind GOKAPI_BASE_URL entry through the local CLI or Settings using stdin/value-file, then bind its store SecretRef to skills.entries.gokapi-file-sharing.apiKey using the local store-provider alias. OpenClaw's generic apiKey field is only the primaryEnv injection path for the URL; do not use an API-key-labeled prompt for the URL or store it as a secret-kind entry. Separately request GOKAPI_API_KEY through a masked secret prompt, restricted to the exact configured hostname. If the protected prompt is unavailable, follow references/setup.md for a local masked-CLI fallback; never request the key in chat. Confirm both entries and Gateway egress are usable without printing the key. Installation alone does not run this setup; do it when the skill is first invoked or setup is requested.
3. Before an upload, ask the owner how many whole days the file may remain online. In the same question, offer an optional maximum number of downloads. Use expiryDays as a positive integer, or 0 only if unlimited time was explicit. Use allowedDownloads as the requested positive integer, or 0 for unlimited downloads when the owner declines a cap. For hours or fractional days, explain the API's day granularity and get a compatible choice. Resolve retention before upload.
4. Use Gateway-host exec so the protected key sentinel can be substituted by the egress proxy. Accept only an HTTPS base URL without userinfo, query, or fragment; never follow redirects with the API key. POST multipart file, expiryDays, and allowedDownloads to /api/files/add. Follow references/api-upload.md for the exact request and chunked fallback. Require HTTP success, JSON Result=OK, a valid FileInfo.UrlDownload, and returned expiry/download metadata matching the choices.
5. For upload-only, return the download link and limits to the owner. For an authorized send, deliver only the link to the verified recipient on the requested channel; do not post a private link to a broader chat. Report upload and delivery as distinct outcomes.
6. For an explicit revocation, validate that the link belongs to the configured instance and identify its file ID. DELETE /api/files/delete with the ID in the id header using a key with DELETE permission; omit delay for immediate revocation. Require HTTP 200, then verify GET /api/files/list/{id} returns 404 with VIEW permission. A public download path may return HTTP 200 with an HTML error redirect after deletion; do not treat that status alone as proof the file remains available. Do not delete any other ID.

Simple and chunked API uploads do not provide Gokapi end-to-end encryption. If client-side E2EE is required, use Gokapi's encrypted client workflow instead; server-side storage encryption is not E2EE.