^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)