Add Typlog Publisher v0.3.8

[haohailong]

Typlog Publisher

Supersedes #53 with version 0.3.8, which adds user-confirmed recovery when an associated draft is no longer present.

Adds extensions/markedit-typlog.json for Typlog Publisher, an MIT-licensed MarkEdit extension for creating and updating Typlog drafts from the current document.

Features

• Reads local images directly through MarkEdit's file APIs and folder permissions, without Textpack or another extension. Uploads supported images, preserves dimensions, and produces figures and captions.
• Reads opening ::: metadata for titles and tags, falls back to the first H1, and accepts English and Chinese comma separators for tags.
• Discovers the account username and accessible sites from a Token with profile and site permissions, caches site metadata, and supports author selection or no author assignment.
• Associates a saved document with a draft per site so subsequent sends update the same draft. Checks draft status, resumes interrupted operations, and offers explicit recovery instead of silently creating duplicate posts.
• If a linked post returns HTTP 404 and access to the configured site is verified, offers an explicit choice to create a replacement draft and associate the document with its new Post ID. Cancellation preserves the original association; permission/network errors and uncertain creation outcomes never silently create duplicate posts.
• Can open the selected site's dashboard editor after sending. Dashboard URLs are derived from each user's own site configuration.
• Provides English, Simplified Chinese, and Traditional Chinese interfaces following system language preferences, with settings for Token replacement and deletion.

Provenance and validation

• Version: 0.3.8; minimum MarkEdit version: 1.36.0.
• The versioned JavaScript Release asset is publicly downloadable without authentication and is pinned with SHA-256 in the entry. Anonymous API download bytes match the committed build exactly.
• The submitted entry passes the official registry schema and integrity validator using those downloaded bytes; the registry's 14 tests also pass.
• Only the new source entry is included; generated index.json and gallery files are left to the registry workflow. Registry timestamps are also left to the publish workflow.
• The extension's 80 automated tests pass using simulated Typlog responses; a fresh build matches the committed JavaScript bytes.
• Tokens, passwords, account settings, document contents, and draft journals are not embedded in the distributed script. There is no analytics or background publishing. Publishing requests and image uploads require explicit confirmation.

Optional follow-up: a native Keychain API

The current public MarkEdit API does not expose Keychain operations. This extension therefore offers plain-text Token storage with a first-use notice, or optional AES-256-GCM encryption with a separate local password. The encrypted mode needs unlocking after restarting the app or opening a new document window; passwords and encryption keys are never stored in configuration files.

Would a future MarkEdit API provide native, permission-mediated secret storage, such as getSecret, setSecret, and deleteSecret, backed by macOS Keychain? An extension-scoped namespace, user approval for secret access, and clear handling of denial/deletion would help publishing extensions store API Tokens securely without a recurring extension-specific password prompt. Ideally other extensions could not read the same namespace.

This is a follow-up API suggestion, not a dependency of this registry entry. I would be happy to move it to a separate issue in the main MarkEdit repository if preferred.

[cyanzhong]

Thanks for the contribution. As a follow-up: I will consider a keychain API.

[cyanzhong]

I’ve added MarkEdit.secretStorage with async has, get, set, and delete methods backed by macOS Keychain. It will be part of the next release.

Credentials are namespaced by extension ID. Every read requires user approval, see Extension Credentials.

Please check if (MarkEdit.secretStorage) before using it so your extension remains compatible with older versions. This should remove the need for your own token encryption/password flow.

Type definitions are available in: https://github.com/MarkEdit-app/MarkEdit-api/releases/tag/v0.36.0

[haohailong]

Every read requires approval. The dialog shows the extension, script location, and credential key. Allow Once approves only that read; Cancel denies it. Only approve trusted extensions: they can use or transmit retrieved credentials.

Is that possible to choose Always Allow? Then we won't need to input the password every time.

[cyanzhong]

The approval doesn't require a password, it's MarkEdit's confirmation before running the native code to read keychain.

By adding "Always Allow", user scripts can read keychain secretly without user consent. Even currently the service name is prefixed by Extension ID, it is possible for malicious scripts to bypass the boundary.

[haohailong]

Thank you. I will try it out as soon as the new version releases.

[cyanzhong]

Feel free to test the API using this preview build:

MarkEdit.zip

I am still working on a few things before I can finalize the next release.

[haohailong]

Thanks again for adding MarkEdit.secretStorage and providing the preview build. The Typlog extension is now using Keychain in its local beta.

After testing the permission dialog, I have a few suggestions to make the experience clearer for ordinary users while keeping the explicit approval requirement.

1. Make the dialog look like a permission request

The large warning icon makes the dialog look like an error, even though requesting access is a normal part of the workflow. Could it use an informational style with the MarkEdit icon, or a key/lock icon, instead?

A heading such as “Extension requests access to a saved credential” would also help distinguish authorization from an operation failure.

2. Clarify the primary button

Would “Allow This Read” be clearer than “Allow Once”? It would explain exactly what is being approved, especially when an extension reuses the retrieved credential in memory afterward.

3. Put technical details behind a disclosure control

The script path and long credential key currently dominate the message. Users unfamiliar with these identifiers may interpret them as an error.

Could the default view show the extension identity and a readable credential name, with the full script path and internal key under “Show Details”? For example:

“markedit-typlog” requests access to your saved Typlog API Token.

The identifying details would remain available for inspection, but the initial presentation would be much easier to understand. An optional human-readable credential label in the API might help, while retaining the actual key in the details.

4. Reduce interruptions during publishing

Currently, users encounter the credential approval near the beginning, then edit the article metadata, and finally confirm publication. This feels like several consecutive confirmations.

On the extension side, I plan to combine metadata editing and publication confirmation into one dialog, then defer credential retrieval until the user clicks “Create Draft” or “Update Draft.” The native approval would appear immediately before remote validation and sending, with no further routine confirmation afterward.

The beta also caches an approved Token in the current document window’s memory and clears that cache when the window closes or the credential changes. This reduces repeated reads without changing MarkEdit’s approval behavior.

I understand that the native permission dialog cannot currently be styled or merged with an extension’s own dialog. Would the presentation improvements above be feasible in MarkEdit? I think they would make the security prompt feel much more understandable without weakening its purpose.

[cyanzhong]

1 & 2 look reasonable to me, I will make the change.

For 3 I won't introduce more complicated interactions for a simple alert, but will consider better presentation style.