Hi All,
Wanted to run this by you for feedback. I've recently added markdown support for LovlyNet - a dedicated FTN for BinktermPHP nodes.
It basically works like this:
- When posting to a network that has markdown enabled a new MARKDOWN kludge is added.
- When the MARKDOWN kludge is seen, the message reader renders the markdown.
It's pretty basic and is an attempt to provide richer text formatting in echo and netmail.
Below is a specification proposal.
Would appreciate feedback on this idea.
Thanks
Matthew
**********************************************************************
LOVLYNET STANDARDS COMMITTEE DOCUMENT LSC-001
Document: LSC-001
Title: MARKDOWN Kludge for FidoNet-Compatible Echomail and Netmail
Author: LovlyNet Standards Committee
Date: 2026-02-27
Status: Proposed Standard **********************************************************************
1. INTRODUCTION
---------------
This document defines the MARKDOWN kludge line for use in FidoNet-
compatible echomail and netmail messages. Its purpose is to indicate
that the body of a message is formatted using Markdown syntax, allowing
capable reader software to render the message with appropriate
formatting while remaining fully readable by legacy software that does
not support this kludge.
Markdown was chosen specifically because it degrades gracefully in
plain-text environments. Markup conventions such as **bold**, # headings,
and - list items are intuitive and legible even when rendered as
literal characters, making this kludge safe for use in mixed
environments where not all nodes or readers support it.
2. DEFINITIONS
--------------
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in FTA-1006.
"Kludge line": A line in a FidoNet message body beginning with the
ASCII SOH character (0x01), used to carry machine-readable metadata
not intended for direct display to the end user.
"Markdown": The lightweight markup language as described in CommonMark Specification 0.31.2 (
https://spec.commonmark.org/), which serves as
the reference standard for this proposal.
3. THE MARKDOWN KLUDGE
-----------------------
3.1 Syntax
The MARKDOWN kludge line has the following syntax:
^AMARKDOWN: <version>
where ^A represents the ASCII SOH character (0x01), and <version> is
a positive integer indicating the version of this specification the
message author intended to conform to.
Example:
^AMARKDOWN: 1
3.2 Placement
The MARKDOWN kludge line SHOULD be placed with other kludge lines at
the beginning of the message body, before any visible text content,
in accordance with common FidoNet kludge conventions.
3.3 Version Number
This document defines version 1. The version number is provided to
allow for future revisions to this specification. Software encountering
a version number higher than it supports SHOULD still attempt to render
the message body as Markdown, falling back to plain text display if
rendering fails or is not supported.
4. BEHAVIOR OF CONFORMING SOFTWARE
------------------------------------
4.1 Message Authors and Editors
A message editor that supports Markdown composition MAY insert the
MARKDOWN kludge line when the user composes a message in Markdown
format. It SHOULD NOT insert the kludge unless the message body
actually contains Markdown-formatted content.
4.2 Message Readers
A message reader that encounters the MARKDOWN kludge:
- SHOULD render the message body as Markdown rather than plain text.
- SHOULD support at minimum the CommonMark core feature set including
headings, bold, italic, inline code, code blocks, blockquotes,
unordered lists, ordered lists, and hyperlinks.
- MAY support extended Markdown features such as tables (GFM-style)
and strikethrough at the implementor's discretion.
- SHOULD provide a way for the user to view the raw Markdown source
if desired.
4.3 Legacy Software
Software that does not recognize the MARKDOWN kludge MUST ignore it,
as per standard FidoNet kludge handling rules. The message body will
be displayed as plain text. Because Markdown is designed to be human-
readable in its raw form, this is an acceptable fallback and authors
SHOULD write their Markdown content with this in mind.
4.4 Tosser and Packer Behavior
Tossers, packers, and other mail-handling software MUST NOT alter,
strip, or otherwise modify the MARKDOWN kludge line during normal
message handling. The kludge MUST be preserved through the normal
FidoNet message routing process.
5. RECOMMENDATIONS FOR AUTHORS
--------------------------------
Authors composing Markdown messages for FidoNet distribution SHOULD
be mindful that many recipients may be reading in plain text. The
following guidelines are recommended:
- Prefer Markdown constructs that degrade naturally (e.g., **bold**
reads clearly as emphasis even unrendered).
- Avoid complex nested structures that may appear cluttered in plain
text.
- Use code blocks for technical content, as the indentation remains
meaningful in plain text.
- Avoid inline HTML, which does not degrade gracefully and may
be stripped or mangled by some software.
- Keep line lengths reasonable (72-80 characters) in accordance
with traditional FidoNet message formatting conventions. Note that
Markdown treats single newlines within a paragraph as spaces, so
hard-wrapped paragraphs will render correctly.
6. SECURITY CONSIDERATIONS
----------------------------
Markdown rendering software MUST NOT render inline HTML contained
within Markdown messages, or MUST sanitize it thoroughly before
display. FidoNet messages originate from a wide variety of sources
and inline HTML could be used to inject malicious content into
web-based or GUI readers.
Software rendering Markdown SHOULD sanitize hyperlink URLs and MUST
NOT automatically fetch remote resources (images, stylesheets, etc.)
without explicit user consent, in order to protect user privacy and
avoid unexpected network activity.
7. IMPLEMENTATION NOTES
------------------------
The MARKDOWN kludge is currently implemented in BinktermPHP, a web-
based FidoNet-compatible BBS system, and is used within the LovlyNet
amateur FidoNet-compatible network. Implementors wishing to add support
are encouraged to contact the LovlyNet administrators for coordination.
The CommonMark reference implementation and specification are available
at
https://spec.commonmark.org/ and provide a solid basis for
conformant rendering.
8. REFERENCES
--------------
[1] FTS-0001 - A Basic FidoNet(r) Technical Standard
[2] FTS-0009 - The MSGID and REPLY kludges
[3] FTS-5003 - Character set kludge (CHRS/CHARSET)
[4] FTA-1006 - Key words to indicate requirement levels
[5] CommonMark Specification 0.31.2
https://spec.commonmark.org/
9. REVISION HISTORY
--------------------
2026-02-27 Initial proposal, LSC-001 version 1.
**********************************************************************
END OF DOCUMENT LSC-001 **********************************************************************
... On a clear disk you can seek forever
--- BinktermPHP v1.8.3
* Origin: Claude's BBS -
https://claudes.lovelybits.org (1:153/150)