Pre-flight checks
Problem
Markra can render and export a document as a complete styled HTML file, but sharing a work-in-progress still requires the author to send that file or configure separate hosting. Sending the file adds download/open friction for reviewers, while setting up permanent hosting is excessive for a draft that only needs a browser link for a few days.
This is especially relevant for review workflows: the author may revise the Markdown repeatedly and would ideally keep one URL rather than export and resend a new file after every change.
Because Markra is local-first, any remote sharing workflow also needs to be unmistakably opt-in. Nothing should leave the device until the user explicitly requests it and understands who can view it and how long it remains available.
Proposed solution
Add an optional Publish temporary preview action in the existing Export workflow.
Suggested behavior:
- Reuse Markra's existing HTML export renderer so the shared page matches the exported document.
- Before the first upload, show a confirmation explaining that the rendered document and referenced assets will be uploaded to a third-party service, that anyone with the link can view it, and that the link remains active for seven days after the latest publish.
- After publishing, show the URL with Copy link and Open preview actions.
- Keep the returned update credential locally, associated with the document, so later publishes update the same URL instead of creating a new one.
- Offer Remove preview, which revokes the public page and clears the locally stored credential.
- Never upload in the background. Closing or cancelling the dialog must make no network request, and a failed publish must not alter the document.
Temp.md is one possible implementation provider. It accepts a generated index.html plus assets through a multipart HTTP API, requires no account for a temporary link, supports updating the same URL with a private capability token, and supports explicit revocation. The integration could use fetch directly without adding an SDK dependency.
For local images, the publish path could include the referenced files in the multipart bundle and rewrite their document-relative paths as needed. If that is too large for an initial version, the UI should detect unsupported local references and explain the limitation before uploading rather than publish a broken page.
Product area
Export
Alternatives considered
- Export HTML and send the file directly. This works, but reviewers must download and reopen every revision.
- Export HTML and deploy it manually to GitHub Pages, Vercel, or another host. This is appropriate for a finished document but too much setup for short-lived review.
- Add a generic permanent publishing system. That would be substantially larger in scope and less aligned with Markra's local-first focus.
Additional context
The existing MarkdownExportDocument and buildMarkdownHtmlDocument flow already appears to produce the main HTML payload needed for this feature, so the editor rendering path would not need to be duplicated.
The public URL must never contain or expose the private update/revocation token. That token should stay in local app storage and only be sent as authorization when updating or removing the preview.
I would be happy to prepare a focused implementation with tests if this workflow and third-party integration are acceptable to the maintainers.
Pre-flight checks
Problem
Markra can render and export a document as a complete styled HTML file, but sharing a work-in-progress still requires the author to send that file or configure separate hosting. Sending the file adds download/open friction for reviewers, while setting up permanent hosting is excessive for a draft that only needs a browser link for a few days.
This is especially relevant for review workflows: the author may revise the Markdown repeatedly and would ideally keep one URL rather than export and resend a new file after every change.
Because Markra is local-first, any remote sharing workflow also needs to be unmistakably opt-in. Nothing should leave the device until the user explicitly requests it and understands who can view it and how long it remains available.
Proposed solution
Add an optional Publish temporary preview action in the existing Export workflow.
Suggested behavior:
Temp.md is one possible implementation provider. It accepts a generated
index.htmlplus assets through a multipart HTTP API, requires no account for a temporary link, supports updating the same URL with a private capability token, and supports explicit revocation. The integration could usefetchdirectly without adding an SDK dependency.For local images, the publish path could include the referenced files in the multipart bundle and rewrite their document-relative paths as needed. If that is too large for an initial version, the UI should detect unsupported local references and explain the limitation before uploading rather than publish a broken page.
Product area
Export
Alternatives considered
Additional context
The existing
MarkdownExportDocumentandbuildMarkdownHtmlDocumentflow already appears to produce the main HTML payload needed for this feature, so the editor rendering path would not need to be duplicated.The public URL must never contain or expose the private update/revocation token. That token should stay in local app storage and only be sent as authorization when updating or removing the preview.
I would be happy to prepare a focused implementation with tests if this workflow and third-party integration are acceptable to the maintainers.