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)

27 Feb 2026 09:39, you wrote to All:

Wanted to run this by you for feedback. I've recently added markdown support for LovlyNet - a dedicated FTN for BinktermPHP nodes.

[...]

Would appreciate feedback on this idea.

My 2c: in case of something like that being implemented, could it be better to use a more general kludge, such as MARKUP?

^aMARKUP: Markdown 1.0

That would allow for specifying other formats, like BBCode, Gemtext, etc.

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)

My 2c: in case of something like that being implemented, could it be better to use a more general kludge, such as MARKUP?
^aMARKUP: Markdown 1.0
That would allow for specifying other formats, like BBCode, Gemtext, etc.

This makes more sense to me.


I've done up a second draft based on this this feedback.


1. INTRODUCTION
---------------

This document defines the MARKUP 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 a named markup 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.

Unlike a Markdown-specific kludge, MARKUP provides a general mechanism
for identifying the body format of a message. This allows the same
extension point to be used for Markdown, BBCode, Gemtext, and other
formats without requiring a new kludge definition for each syntax.


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.

"Markup syntax": A textual formatting language used within the visible
message body to express structure or presentation, such as Markdown,
BBCode, or Gemtext.


3. THE MARKUP KLUDGE
--------------------

3.1 Syntax

The MARKUP kludge line has the following syntax:

^AMARKUP: <format> <version>

where ^A represents the ASCII SOH character (0x01), <format> is a
registered or otherwise well-known markup format identifier, and
<version> is a format version string meaningful within that format.

Examples:

^AMARKUP: Markdown 1.0
^AMARKUP: BBCode 1.0
^AMARKUP: Gemtext 1.0

3.2 Placement

The MARKUP 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 Format Identifier

The format identifier MUST be a single token and SHOULD use a stable,
widely recognized name for the markup syntax. Implementations SHOULD
treat format identifiers case-insensitively for matching purposes,
though they MAY preserve the original casing for display or logging.

3.4 Version String

The version string MUST follow the format identifier and SHOULD be
included whenever the syntax has meaningful version distinctions. Implementations MAY treat the version as an opaque string. Software
that recognizes a format but not its declared version SHOULD fall back
to best-effort rendering or plain text display.


4. BEHAVIOR OF CONFORMING SOFTWARE
----------------------------------

4.1 Message Authors and Editors

A message editor that supports composition in a named markup syntax
MAY insert the MARKUP kludge line when the user composes a message in
that format. It SHOULD NOT insert the kludge unless the message body
actually contains content intended for that markup syntax.

4.2 Message Readers

A message reader that encounters the MARKUP kludge:

- SHOULD inspect the declared format identifier before attempting
rendering.
- MAY render the body according to the declared format if that
format is supported.
- SHOULD provide plain text display when the declared format is not
supported, not recognized, or cannot be safely rendered.
- SHOULD provide a way for the user to view the raw source if
desired.

4.3 Unknown or Unsupported Formats

Software that does not recognize the declared markup format MUST
ignore the semantic meaning of the kludge and display the message body
as plain text. The original body content MUST be preserved unchanged.

4.4 Tosser and Packer Behavior

Tossers, packers, and other mail-handling software MUST NOT alter,
strip, or otherwise modify the MARKUP kludge line during normal
message handling. The kludge MUST be preserved through the normal
FidoNet message routing process.


5. FORMAT-SPECIFIC GUIDANCE
---------------------------

This document defines only the transport-level declaration mechanism.
It does not standardize the parsing rules of any specific markup
syntax.

Implementors supporting a given format SHOULD document which variant
they support. For example:

- Markdown implementations SHOULD identify which dialect or baseline
they follow, such as CommonMark.
- BBCode implementations SHOULD document which tags are supported.
- Gemtext implementations SHOULD follow Gemtext line-oriented rules.

When possible, authors SHOULD choose markup syntaxes that degrade
gracefully in plain-text environments, since many FidoNet-compatible
systems may display the raw message body without rendering.


6. SECURITY CONSIDERATIONS
--------------------------

Rendering software MUST treat the declared markup format as untrusted
input. Implementations SHOULD sanitize or restrict active content,
embedded HTML, unsafe URLs, and any construct that could execute code,
load remote resources, or mislead the user interface.

Software rendering marked-up messages MUST NOT automatically fetch
remote resources without explicit user consent, in order to protect
user privacy and avoid unexpected network activity.


7. IMPLEMENTATION NOTES
-----------------------

The MARKUP kludge is intended as a general extension mechanism for FidoNet-compatible software. A given implementation MAY support only
a subset of markup syntaxes and still conform to this specification,
provided unsupported formats are safely treated as plain text.

An implementation that currently supports only Markdown may still emit:

^AMARKUP: Markdown 1.0

This preserves forward compatibility with other markup syntaxes while
allowing immediate use for Markdown-aware readers.


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
https://spec.commonmark.org/


9. REVISION HISTORY
-------------------

2026-02-27 Initial proposal for a Markdown-specific kludge.
2026-03-01 Revised proposal to use the general MARKUP kludge.

... Back Up My Hard Drive? I Can't Find The Reverse Switch!

--- BinktermPHP v1.8.5
* Origin: Claude's BBS - https://claudes.lovelybits.org (1:153/150)

Re: Re: MARKDOWN kludge
By: Matthew Asham to Carlos Navarro on Sun Mar 01 2026 01:40 pm

My 2c: in case of something like that being implemented, could it be better to use a more general kludge, such as MARKUP?
^aMARKUP: Markdown 1.0
That would allow for specifying other formats, like BBCode, Gemtext, etc.

This makes more sense to me.

I've done up a second draft based on this this feedback.

1. INTRODUCTION
---------------

This document defines the MARKUP 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 a named markup 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.

Unlike a Markdown-specific kludge, MARKUP provides a general mechanism
for identifying the body format of a message. This allows the same
extension point to be used for Markdown, BBCode, Gemtext, and other
formats without requiring a new kludge definition for each syntax.

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.

"Markup syntax": A textual formatting language used within the visible message body to express structure or presentation, such as Markdown,
BBCode, or Gemtext.

3. THE MARKUP KLUDGE
--------------------

3.1 Syntax

The MARKUP kludge line has the following syntax:

^AMARKUP: <format> <version>

where ^A represents the ASCII SOH character (0x01), <format> is a
registered or otherwise well-known markup format identifier, and
<version> is a format version string meaningful within that format.

Examples:

^AMARKUP: Markdown 1.0
^AMARKUP: BBCode 1.0
^AMARKUP: Gemtext 1.0

There's the Synchronet-supported message markup format too: https://wiki.synchro.net/ref:markup
--
Rob Swindell
FTSC Standing Member
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

3. THE MARKUP KLUDGE
--------------------

3.1 Syntax

The MARKUP kludge line has the following syntax:

^AMARKUP: <format> <version>

where ^A represents the ASCII SOH character (0x01), <format> is a
registered or otherwise well-known markup format identifier, and
<version> is a format version string meaningful within that format.

Examples:

^AMARKUP: Markdown 1.0
^AMARKUP: BBCode 1.0
^AMARKUP: Gemtext 1.0

There's the Synchronet-supported message markup format too: https://wiki.synchro.net/ref:markup

Thanks for that!

I've added "StyleCodes" as the format name to Section 5. I figure this is the most appropriate because it appears to have come from GoldEd initially.

Examples:

^AMARKUP: Markdown 1.0
^AMARKUP: BBCode 1.0
^AMARKUP: Gemtext 1.0
^AMARKUP: StyleCodes 1.0

Matthew

... OS/2 VirusScan - "Windows found: Remove it? [Y/y]"

--- BinktermPHP v1.8.5
* Origin: Claude's BBS - https://claudes.lovelybits.org (1:153/150)

^AMARKUP: Markdown 1.0
^AMARKUP: StyleCodes 1.0

BinktermPHP 1.8.5 (to be released) now uses the MARKUP kludge and adds support for StyleCodes/Synchronet Message Markup. It continues to be enabled/disabled on a per network/uplink basis.

I've also posted a copy of the draft proposal to https://github.com/awehttam/binkterm-php/issues/161

---
~ awehttam @1:153/150 @gmail.com | www.lovelybits.org

... Your E-mail has been returned due to insufficient voltage

--- BinktermPHP v1.8.5
* Origin: Claude's BBS - https://claudes.lovelybits.org (1:153/150)

Re: Re: MARKUP kludge
By: Matthew Asham to All on Tue Mar 03 2026 10:41 am

^AMARKUP: Markdown 1.0
^AMARKUP: StyleCodes 1.0

BinktermPHP 1.8.5 (to be released) now uses the MARKUP kludge and adds support for StyleCodes/Synchronet Message Markup. It continues to be enabled/disabled on a per network/uplink basis.

I've also posted a copy of the draft proposal to https://github.com/awehttam/binkterm-php/issues/161

I think it's a good idea and thinking about how best to implement support (both adding and consuming the kludges in Synchronet).

Maybe I missed it, but does your spec say if/how multiple MARKUP styles/kludges could be used in a single message?
--
Rob Swindell
FTSC Standing Member
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On March 9 2026, Rob Swindell wrote:

Re: Re: MARKUP kludge
By: Matthew Asham to All on Tue Mar 03 2026 10:41 am

^AMARKUP: Markdown 1.0
^AMARKUP: StyleCodes 1.0

BinktermPHP 1.8.5 (to be released) now uses the MARKUP kludge and adds
support for StyleCodes/Synchronet Message Markup. It continues to be
enabled/disabled on a per network/uplink basis.

I've also posted a copy of the draft proposal to
https://github.com/awehttam/binkterm-php/issues/161

I think it's a good idea and thinking about how best to implement
support (both adding and consuming the kludges in Synchronet).

Maybe I missed it, but does your spec say if/how multiple MARKUP styles/kludges could be used in a single message?

It does not. I think the assumption is the message is soley the listed MARKUP.

I'm not sure how we would support multiple markups other than perhaps listing the MARKUP kludges in order of precedence, eg: MARKUP: Markdown 1.0,StyleCodes 1.0,BBText 1.0 and then the parser would apply rendering for each in order.

Personally I feel it would be simplest to leave it as a single markup only.

Matthew

~ awehttam @1:153/150 @gmail.com | www.lovelybits.org

... Never underestimate the bandwidth of a station wagon full of tapes

--- BinktermPHP v1.8.6
* Origin: Claude's BBS - https://claudes.lovelybits.org (1:153/150)

Re: Re: MARKUP kludge
By: Matthew Asham to Rob Swindell on Mon Mar 09 2026 07:06 am

On March 9 2026, Rob Swindell wrote:

Re: Re: MARKUP kludge
By: Matthew Asham to All on Tue Mar 03 2026 10:41 am

^AMARKUP: Markdown 1.0
^AMARKUP: StyleCodes 1.0

BinktermPHP 1.8.5 (to be released) now uses the MARKUP kludge and adds
support for StyleCodes/Synchronet Message Markup. It continues to be
enabled/disabled on a per network/uplink basis.

I've also posted a copy of the draft proposal to
https://github.com/awehttam/binkterm-php/issues/161

I think it's a good idea and thinking about how best to implement support (both adding and consuming the kludges in Synchronet).

Maybe I missed it, but does your spec say if/how multiple MARKUP styles/kludges could be used in a single message?

It does not. I think the assumption is the message is soley the listed MARKUP.

I'm not sure how we would support multiple markups other than perhaps listing the MARKUP kludges in order of precedence, eg: MARKUP: Markdown 1.0,StyleCodes 1.0,BBText 1.0 and then the parser would apply rendering for each in order.

Personally I feel it would be simplest to leave it as a single markup only.

I agree, definitely simplier. Maybe add some text to your spec clarifying that a maximum of one MARKUP kludge should be included in a message body and the entire message body is expected to be displayed with the specified MARKUP applied regardless of where the MARKUP kludge line appears in the message body.
--
Rob Swindell
FTSC Standing Member
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On March 9 2026, Rob Swindell wrote:

I'm not sure how we would support multiple markups other than perhaps
listing the MARKUP kludges in order of precedence, eg: MARKUP: Markdown
1.0,StyleCodes 1.0,BBText 1.0 and then the parser would apply rendering
for
each in order.

Personally I feel it would be simplest to leave it as a single markup
only.

I agree, definitely simplier. Maybe add some text to your spec
clarifying that a maximum of one MARKUP kludge should be included in a message body and the entire message body is expected to be displayed
with the specified MARKUP applied regardless of where the MARKUP
kludge line appears in the message body.

Updated section 3.2 and 4.2 which now read:

3.2 Placement

The MARKUP 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.

A message body MUST NOT contain more than one MARKUP kludge line.
If multiple MARKUP kludge lines are present, implementations SHOULD
use the first one encountered and ignore the remainder.

The MARKUP kludge applies to the entire visible message body
regardless of where in the message the kludge line appears. The
declared format is not limited to the text following the kludge;
the complete body content MUST be interpreted and rendered as a
single unit using the declared markup syntax.


4.2 Message Readers

A message reader that encounters the MARKUP kludge:

* SHOULD inspect the declared format identifier before attempting
rendering.
* MAY render the body according to the declared format if that
format is supported.
* MUST apply the declared format to the entire visible message body,
not only the portion of the body following the kludge line.
* SHOULD provide plain text display when the declared format is not
supported, not recognized, or cannot be safely rendered.
* SHOULD provide a way for the user to view the raw source if
desired.


~ awehttam @1:153/150 @gmail.com | www.lovelybits.org

... OS/2 VirusScan - "Windows found: Remove it? [Y/y]"

--- BinktermPHP v1.8.6
* Origin: Claude's BBS - https://claudes.lovelybits.org (1:153/150)

Re: Re: MARKUP kludge
By: Matthew Asham to Rob Swindell on Mon Mar 09 2026 05:18 pm

Updated section 3.2 and 4.2 which now read:

I'd up-vote your message, but alas, FTN doesn't support such thing. It's on my todo list to get message-up/down voting into an FTSC spec and supported (at least) by my software.
--
Rob Swindell
FTSC Standing Member
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On March 10 2026, Rob Swindell wrote:

I'd up-vote your message, but alas, FTN doesn't support such thing.
It's on my todo list to get message-up/down voting into an FTSC spec
and supported (at least) by my software.

I've had thoughts about such a feature (the thoughts being we should do that). It would be interesting.

~ awehttam @1:153/150 @gmail.com | www.lovelybits.org

... Uncontained entropy experiment gone crazy.......maybe.

--- BinktermPHP v1.8.6
* Origin: Claude's BBS - https://claudes.lovelybits.org (1:153/150)

On March 2 2026, Matthew Asham wrote:

3. THE MARKUP KLUDGE
--------------------

3.1 Syntax

The MARKUP kludge line has the following syntax:

^AMARKUP: <format> <version>

where ^A represents the ASCII SOH character (0x01), <format> is a
registered or otherwise well-known markup format identifier, and
<version> is a format version string meaningful within that format.

Examples:

^AMARKUP: Markdown 1.0
^AMARKUP: BBCode 1.0
^AMARKUP: Gemtext 1.0

It occured to me that a REGISTRY is not defined for the markup codes. There is an
examples section but examples are not really a registry.

I have added a new section "MARKUP FORMAT REGISTRY" as section 8.


8. MARKUP FORMAT REGISTRY
-------------------------

This section defines the initial set of registered format identifiers
for use with the MARKUP kludge. Additional identifiers MAY be used by
mutual agreement between implementations; authors of new identifiers
are ENCOURAGED to document them and submit them for inclusion here.

Format identifiers are matched case-insensitively per section 3.3.
The canonical capitalisation shown below SHOULD be used when emitting
the kludge.

8.1 Registered Identifiers

Identifier Version Description
---------- ------- -----------
Markdown 1.0 CommonMark-compatible Markdown. Implementations
SHOULD follow the CommonMark specification [5].
See section 5 for guidance on dialect disclosure.

BBCode 1.0 Tag-based markup originating in bulletin board
systems, using [tag] and [/tag] delimiters.
Implementations SHOULD document which tag set
is supported, as no single normative BBCode
specification exists.

Gemtext 1.0 Line-oriented markup used by the Gemini protocol.
Each line begins with an optional prefix character
that determines its type (link, heading, list
item, preformatted block, quote, or plain text).
Implementations SHOULD follow the Gemini
specification for line-type parsing.

StyleCodes 1.0 Character-sequence-based inline formatting
originating in GoldEd and compatible FidoNet
editors. Also known as "Rich Text" (SemPoint),
"Structured Text" (Mozilla/Thunderbird), and
"markup" (Synchronet). The identifier StyleCodes
is RECOMMENDED over these alternatives; see
section 5.

8.2 Reserved Identifiers

The following identifiers are reserved and MUST NOT be used as
format identifiers in the MARKUP kludge, to avoid collision with
existing terminology:

RTF (conflicts with Microsoft Rich Text Format)
RST (conflicts with reStructuredText)
HTML (conflicts with HyperText Markup Language; active content
rendering is explicitly discouraged by section 6)

8.3 Registration Process

At this time no formal registration authority exists. Authors wishing
to use a new identifier SHOULD:

1. Choose a stable, unambiguous token not already in use.
2. Publish a definition of the format and the meaning of any
version strings used.
3. Submit the identifier and definition to the FidoNet community
for inclusion in this registry.



Rather than re-post the entire proposal I've updated the "live" version here: https://github.com/awehttam/binkterm-php/issues/161

Matthew

~ awehttam @1:153/150 @gmail.com | www.lovelybits.org

... Press any key to continue or any other key to quit

--- BinktermPHP v1.8.6
* Origin: Claude's BBS - https://claudes.lovelybits.org (1:153/150)

I sent the draft to the FTSC coordinator this morning.

And then realized quoting needed to be addressed. I've now added section 4.5 to the draft to document how reply quoting can work (otherwise it looks funky).

Now on Draft 5. Updated https://github.com/awehttam/binkterm-php/issues/161


4.5 Reply Quoting

When replying to a message declared with the MARKUP kludge, software
SHOULD preserve the original source structure as much as practical.

Software SHOULD NOT mechanically convert the entire original body into
legacy inline quote prefixes if doing so would damage the structure or readability of the declared markup syntax.

For line-oriented or block-oriented formats such as Markdown and
Gemtext, software SHOULD prefer quoting mechanisms native to that
format.

For Markdown specifically, implementations SHOULD prefer enclosing the
original body in a Markdown blockquote while keeping any reply
attribution line outside the quoted block.

Example:

On 13 Mar 2026, Jane Doe wrote:

> # Heading
>
> - item one
> - item two
>
> ```text
> code block
> ```

This approach improves round-trip fidelity for marked-up replies while remaining readable in plain-text environments.

... The boxes are talking to each other again

--- BinktermPHP v1.8.6
* Origin: Claude's BBS - https://claudes.lovelybits.org (1:153/150)