https://github.com/SynchronetBBS/sbbs/blob/master/docs/dropfile_ini.md

Not implemented anywhere yet (not even in Synchronet), purposely, so as to give the community time (mainly door and host/BBS/server authors) time to give feedback. I do plan to implement support for this format (once it's finalized) in Synchronet BBS software and some of my new doors.

Thanks,
--
digital man (rob)

This Is Spinal Tap quote #11:
Nigel Tufnel: No. no. That's it, you've seen enough of that one.
Norco, CA WX: 66.4°F, 79.0% humidity, 1 mph ENE wind, 0.00 inches rain/24hrs --- SBBSecho 3.38-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)

--- Digital Man Said ---

https://github.com/SynchronetBBS/sbbs/blob/master/docs/dropfile_ini.md

Not implemented anywhere yet (not even in Synchronet), purposely, so as to give the community time (mainly door and host/BBS/server authors) time to give feedback. I do plan to implement support for this format (once it's finalized) in Synchronet BBS software and some of my new doors.

--- Digital Man Done ---

Hey DM. I'd like to support this new format in ViSiON/3. Is there a door that supports this dropfile format for testing?

.jA

<> Broken Bit Syndicate | BrokenBit.us:2323 <>
--- ViSiON/3 v0.9.4/Linux
* Origin: Broken Bit Syndicate - ViSiON/3 HQ (21:4/158.1)

Re: Re: New (proposed) door drop file format, for review and discussion
By: J0hnny A1pha to Digital Man on Wed Sep 30 2026 02:07 pm

--- Digital Man Said ---

https://github.com/SynchronetBBS/sbbs/blob/master/docs/dropfile_ini.md

Not implemented anywhere yet (not even in Synchronet), purposely, so as to give the community time (mainly door and host/BBS/server authors) time to give feedback. I do plan to implement support for this format (once it's finalized) in Synchronet BBS software and some of my new doors.

--- Digital Man Done ---

Hey DM. I'd like to support this new format in ViSiON/3. Is there a door that supports this dropfile format for testing?

Not yet: I wanted to put the proposed format up for review/discussion first. Add support to my existing doors won't be hard or take long at all, but I'll add support to Synchronet at the same time.
--
digital man (rob)

Breaking Bad quote #9:
"Cheesedick" - I know that one [word]. How about that? - Hank Schrader
Norco, CA WX: 85.2°F, 47.0% humidity, 5 mph WNW wind, 0.00 inches rain/24hrs --- SBBSecho 3.38-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)

https://github.com/SynchronetBBS/sbbs/blob/master/docs/dropfile_ini.md

Not implemented anywhere yet (not even in Synchronet), purposely, so as
to give the community time (mainly door and host/BBS/server authors)
time to give feedback. I do plan to implement support for this format (once it's finalized) in Synchronet BBS software and some of my new
doors.

In the mean time, may just need to put out a drop file converter with the first door. Like we had back the old times when just about every BBS used it's own drop file format.
---

-Dallas Vinson

... Help! I can't find the "ANY" key.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Legends of Yesteryear (Dothan, AL, USA) (21:3/235)

Digital Man around Wednesday, September 30th...

Not implemented anywhere yet (not even in Synchronet), purposely, so as to give the community time (mainly door and host/BBS/server authors) time to give feedback. I do plan to implement support for this format (once it's finalized) in Synchronet BBS software and some of my new doors.

Thanks for posting for discussion!

--
|08 ■ |12NuSkooler |06// |12Xibalba |08- |07"|06The place of fear|07"
|08 ■ |03xibalba|08.|03vip |08(|0344510|08/|03telnet|08, |0344511|08/|03ssh|08) |08 ■ |03ENiGMA 1/2 WHQ |08| |03Phenom |08| |0367 |08| |03iMPURE |08| |03ACiDic --- ENiGMA 1/2 v0.5.1-beta (linux; x64; 22.22.2)
* Origin: Xibalba -+- xibalba.vip:44510 (21:1/121)

On September 30 2026, Geri Atricks wrote:

https://github.com/SynchronetBBS/sbbs/blob/master/docs/dropfile_ini.m
d

Not implemented anywhere yet (not even in Synchronet), purposely, so
as
to give the community time (mainly door and host/BBS/server authors)
time to give feedback. I do plan to implement support for this format
(once it's finalized) in Synchronet BBS software and some of my new
doors.

In the mean time, may just need to put out a drop file converter with
the first door. Like we had back the old times when just about every
BBS used it's own drop file format.
---

-Dallas Vinson

... Help! I can't find the "ANY" key.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Legends of Yesteryear (Dothan, AL, USA) (21:3/235)

I do that already
On my door server … it generates like 5 different ones automatically so
i do not have to mess around

I think if the doors are awesome enough to justifying a new format
people Will do that …

... The Adventure BBS (HTTPS://BBS.OURBIRDHOUSE.CA)

--- BinktermPHP v1.10.7
* Origin: The Adventure BBS (21:3/254.0)

Digital Man around Wednesday, September 30th...

https://github.com/SynchronetBBS/sbbs/blob/master/docs/dropfile_ini.md
Not implemented anywhere yet (not even in Synchronet), purposely, so as to give the community time (mainly door and host/BBS/server authors) time to give feedback. I do plan to implement support for this format (once it's finalized) in Synchronet BBS software and some of my new doors.

I think this all could work quite well. Here is a long text of my review of draft 0.3:

SECURITY
--------

1. Key injection through Unicode line separators.
The control character list (C0, DEL, C1) leaves out U+2028 and
U+2029, so they can appear in UTF-8 text values. Python's
str.splitlines() and JavaScript multiline regex (/^KEY=(.*)$/m)
both treat them as line breaks; I tested both. With "first
occurrence wins", an alias of "A", U+2028, "USER_ROLE=sysop" is 19
bytes, so it fits a 25-byte alias. A door that reads the file that
way then thinks the user is a sysop. The same trick overrides
TIME_LEFT, PREF_* or vendor keys that come after [user]. The C,
Pascal and QBasic samples are safe; Python and JS doors are not.
Suggest: add U+2028 and U+2029 to the characters replaced with "?".
Consider the bidi overrides too (U+202A-U+202E, U+2066-U+2069),
which let a name pose as another on score lists.

2. USER_KEY isn't safe in file names.
The allowed characters let through ".", "..", and device names like
"NUL", "CON", "AUX", "PRN", "COM1" and "LPT1" ("CON.1" too, since
"." is allowed). A door that joins its data dir and USER_KEY gets a
path traversal or a write to a device.
Suggest: require a letter or digit first and ban DOS/Windows device
names with or without an extension, or tell doors to hash the key.

3. The file says who the user is.
"Grants no privileges" covers the OS. Inside a door, USER_KEY and
USER_ROLE decide whose saved game loads and who gets sysop
functions:
- A door that takes the path on its command line, and can also be
started directly (doors run over SSH, door servers), accepts a
forged file.
- The fallback to the current directory can pick up a stale file
from another session or node, so user B plays as user A.
FILE_TIME is only advisory.
- The spec says who may read the file, but not who may write it.
Suggest: say a door trusts the file only as far as it trusts
whoever could write it, and the host SHOULD make it writable only
by the host. Drop or discourage the current-directory fallback. A
SESSION_ID key, unique per launch, would help logs and let a door
spot a file it has already seen.

4. Windows handle inheritance (minor).
In a threaded multi-node host, an inheritable socket can leak into
another node's door started at the same moment. One line pointing
at PROC_THREAD_ATTRIBUTE_HANDLE_LIST would cover it; on POSIX,
close-on-exec everywhere and dup2 in the child.

5. Personal details by default.
The Synchronet notes write IP, birthdate, e-mail and caller ID
whenever the user record has them, so every door gets them,
including closed-source doors and inter-BBS doors that send data
off the system.
Suggest: recommend that personal keys are opt-in per door.

6. No COMM_TYPE for a door that connects to the host.
Every type is something the door is handed. A host where the door,
or an emulator's virtual COM port, connects back to a host TCP port
has no correct value to write. That setup has its own risk:
whatever connects first gets the caller's session.
Suggest: if a connect-back type is added, require a loopback-only
listener and a per-session token the door sends first.

7. Unknown token values.
Unknown keys are covered, unknown values are not. A door that sees
a USER_ROLE it doesn't know should treat it as "user", never as
cosysop or sysop.
Suggest: one general rule that an unknown token reads as the key's
default (TERM_TYPE, SYS_DATE_FORMAT, TERM_SIXEL_SCALE, ...), with
USER_ROLE called out.

COMPATIBILITY
-------------

8. FILE_UTF8 is yes/no, so any text that isn't UTF-8 must be CP437.
CP866 (Russian Fido), CP850/CP865 and Amiga Latin-1 doors can't be
served. Suggest a FILE_CHARSET key that uses the COMM_CHARSET names
and defaults to CP437.

9. TERM_TYPE has no "avatar" (AVT/0, still used by Fido-era doors) and
no "atascii" (the Atari 8-bit scene is active). COMM_CHARSET has no
ATASCII either.

10. No terminfo name. Native curses doors need the terminal type from
Telnet TTYPE or the SSH pty request (xterm-256color etc.).
TERM_NAME is "as the terminal reported it", but doesn't say which
report. Suggest TERM_TERMINFO, or naming TERM_NAME's source.

11. Screen size is a snapshot. A socket door never hears about a
Telnet NAWS or SSH window change during the session. Worth saying
so, and that a door can query the size again if it cares.

12. SYS_FTN_ADDR holds one "primary" address with no @domain.
Inter-BBS games on an othernet (fsxNet zone 21 and so on) need
that network's address. Suggest allowing @domain, and more than
one address (a comma list, or numbered keys).

13. File name case. Allowing lowercase dropfile.ini means every POSIX
door that searches a directory has to scan it case-insensitively.
Suggest: always DROPFILE.INI in caps, on every platform, and drop
the lowercase option.

14. Paths are "text". TEMP_DIR goes through CP437/UTF-8 conversion,
"?" replacement and the 222-byte cut. A cut or "?"-mangled path is
worse than none. Suggest a path type: file system bytes, never
converted, and left out (not cut) when it can't be written as is.
The same "leave out, don't cut" rule suits USER_EMAIL,
USER_NETMAIL and the host name keys.

15. CRLF on POSIX. It's the right call for DOS, but naive Linux
readers keep the trailing CR, and then COMM_TYPE == "socket" is
false. One sentence in the consumer rules would save some grief.

16. Test files. The Win32 profile API, Python's configparser and plain
line readers already disagree on some input. A key in the wrong
section is missed by a section lookup but found by a line reader.
A quoted value loses its quotes under Win32 and keeps them under
configparser. A few sample files with their expected values would
keep door kits in step.

Happy to discuss any of it, thanks again for posting up a spec for review!

--
|08 ■ |12NuSkooler |06// |12Xibalba |08- |07"|06The place of fear|07"
|08 ■ |03xibalba|08.|03vip |08(|0344510|08/|03telnet|08, |0344511|08/|03ssh|08) |08 ■ |03ENiGMA 1/2 WHQ |08| |03Phenom |08| |0367 |08| |03iMPURE |08| |03ACiDic --- ENiGMA 1/2 v0.5.1-beta (linux; x64; 22.22.2)
* Origin: Xibalba -+- xibalba.vip:44510 (21:1/121)

Re: RE: New (proposed) door drop file format, for review and discussion
By: NuSkooler to Digital Man on Wed Sep 30 2026 08:32 pm

8. FILE_UTF8 is yes/no, so any text that isn't UTF-8 must be CP437.
CP866 (Russian Fido), CP850/CP865 and Amiga Latin-1 doors can't be
served. Suggest a FILE_CHARSET key that uses the COMM_CHARSET names
and defaults to CP437.

Seems like feature creep: are there actual hosts (BBSes) and doors that use those charsets and couldn't be upgraded to UTF-8? Seems unlikely to me.

9. TERM_TYPE has no "avatar" (AVT/0, still used by Fido-era doors)

AVATAR seems like a blip and not supported by any modern terminals. I could add a definition, sure, but it just seems like more unused bloat.

and
no "atascii" (the Atari 8-bit scene is active). COMM_CHARSET has no
ATASCII either.

Due Atari-native boards/doors even use drop files? Have no problem defining it, but would really want to insure it has a consumer/tester first.

10. No terminfo name. Native curses doors need the terminal type from
Telnet TTYPE or the SSH pty request (xterm-256color etc.).
TERM_NAME is "as the terminal reported it", but doesn't say which
report. Suggest TERM_TERMINFO, or naming TERM_NAME's source.

Noted.

11. Screen size is a snapshot. A socket door never hears about a
Telnet NAWS or SSH window change during the session. Worth saying
so, and that a door can query the size again if it cares.

Yeah, I don't really consider dynamically sized terminals, but it is a thing, so good point. Thanks.

Thanks for *all* the feedback, I'll review and update accordingly.
--
digital man (rob)

Synchronet "Real Fact" #53:
Synchronet Blackjack was the first multi-node/multi-user game for Synchronet Norco, CA WX: 72.3°F, 70.0% humidity, 3 mph WNW wind, 0.00 inches rain/24hrs --- SBBSecho 3.38-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)

Re: RE: New (proposed) door drop file format, for review and discussion
By: Digital Man to NuSkooler on Wed Sep 30 2026 07:56 pm

Thanks for *all* the feedback, I'll review and update accordingly.

Addressed most of your comments, rest still up for discussion: https://gitlab.synchro.net/main/sbbs/-/commit/ab8af28788a4540a7bad0a68

Or (if prefer github): https://github.com/SynchronetBBS/sbbs/commit/ab8af28788a4540a7bad0a68
--
digital man (rob)

This Is Spinal Tap quote #34:
We'd love to stand around and chat, but we've gotta sit down in the lobby Norco, CA WX: 71.0°F, 73.0% humidity, 0 mph NNW wind, 0.00 inches rain/24hrs --- SBBSecho 3.38-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)

Twas Wednesday, September 30th when Digital Man said...

Seems like feature creep: are there actual hosts (BBSes) and doors that use those charsets and couldn't be upgraded to UTF-8? Seems unlikely to me.

I know there are quite a few Russian boards that still use other encodings, I don't know a ton about them though.


Digital Man around Wednesday, September 30th...

AVATAR seems like a blip and not supported by any modern terminals. I could add a definition, sure, but it just seems like more unused bloat.

Same as above, my understanding is there are some, but I haven't seen 'em :)


Twas Wednesday, September 30th when Digital Man said...

Due Atari-native boards/doors even use drop files? Have no problem defining it, but would really want to insure it has a consumer/tester first.

I don't think it's Atari *native* boards, boards are coming aroudn that support these types of things via their terminals/etc. (similar to the sixel swithcharoo)


On Wednesday, September 30th Digital Man said...

Thanks for *all* the feedback, I'll review and update accordingly. --

Hehe, I know there is a lot. Thanks again for putting this out there!

--
|08 ■ |12NuSkooler |06// |12Xibalba |08- |07"|06The place of fear|07"
|08 ■ |03xibalba|08.|03vip |08(|0344510|08/|03telnet|08, |0344511|08/|03ssh|08) |08 ■ |03ENiGMA 1/2 WHQ |08| |03Phenom |08| |0367 |08| |03iMPURE |08| |03ACiDic --- ENiGMA 1/2 v0.5.1-beta (linux; x64; 22.22.2)
* Origin: Xibalba -+- xibalba.vip:44510 (21:1/121)

I do that already
On my door server … it generates like 5 different ones automatically so i do not have to mess around

I think if the doors are awesome enough to justifying a new format
people Will do that …

Was thinking of something like the old SRDoor utility that read the BBS' drop file and converted it to a format the SR doors could use. Would elliminate the need for a new drop format.
---

-Dallas Vinson

... (A)bort, (R)etry, (I)nfluence with large hammer.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Legends of Yesteryear (Dothan, AL, USA) (21:3/235)

On October 1 2026, Geri Atricks wrote:

I do that already
On my door server … it generates like 5 different ones
automatically so
i do not have to mess around

I think if the doors are awesome enough to justifying a new format
people Will do that …

Was thinking of something like the old SRDoor utility that read the
BBS' drop file and converted it to a format the SR doors could use.
Would elliminate the need for a new drop format.
---

-Dallas Vinson

... (A)bort, (R)etry, (I)nfluence with large hammer.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Legends of Yesteryear (Dothan, AL, USA) (21:3/235)

I assume the new format is to allow more fields, it is easy to convert
from one to another. So really, having a new door format only is of
bennefit if there is a new DOOR that will use these extra fields,
otherwise it is just a make work project.

... The Adventure BBS (HTTPS://BBS.OURBIRDHOUSE.CA)

--- BinktermPHP v1.10.7
* Origin: The Adventure BBS (21:3/254.0)

Re: RE: New (proposed) door drop file format, for review and discussion
By: NuSkooler to Digital Man on Thu Oct 01 2026 08:21 am

Twas Wednesday, September 30th when Digital Man said...

Seems like feature creep: are there actual hosts (BBSes) and doors that use those charsets and couldn't be upgraded to UTF-8? Seems unlikely to me.

I know there are quite a few Russian boards that still use other encodings, I don't know a ton about them though.

Right, but I think the whole system (and the user's terminal is expected to) run in that "other encoding" and there's no translation going on (so all CP437 doors, like LORD, TW2002, etc. would look like crap). It seems UTF-8 is the ideal and CP437 is really the one legacy "other encoding" we'd realistically need to support. I'm fine adding more if there's an actual use case, but I'm making this a completionist's goal of defining everything imaginable up front. I originally had FILE_CHARSET=[CP437]/UTF-8 (something like that), and I guess I could revert back to that just for the potential of support other ASCII-compatible file-encodings in the future.

Digital Man around Wednesday, September 30th...

AVATAR seems like a blip and not supported by any modern terminals. I could add a definition, sure, but it just seems like more unused bloat.

Same as above, my understanding is there are some, but I haven't seen 'em :)

AVATAR was mainly a (very) minor optimization via a re-encoding of the same terminal control sequences as ANSI plus some Doorway-like physical key reporting, all done terribly. I've added it to the spec anyway.

Twas Wednesday, September 30th when Digital Man said...

Due Atari-native boards/doors even use drop files? Have no problem defining it, but would really want to insure it has a consumer/tester first.

I don't think it's Atari *native* boards, boards are coming aroudn that support these types of things via their terminals/etc. (similar to the sixel swithcharoo)

I've added ATASCII (apparently it's both a character set/encoding and a terminal emulation, like PETSCII) to rev 0.7 as well.

On Wednesday, September 30th Digital Man said...

Thanks for *all* the feedback, I'll review and update accordingly. --

Hehe, I know there is a lot. Thanks again for putting this out there!

Yeah, happy to. It's long been a stickler of mine that all the drop file formats are "lacking" and aren't extensible in a clearly backward compatible way.

One caveat: nobody should be implemeting this spec yet. I see that ViSiON/3 merged a DROPFILE.INI v0.3 support implementation yesterday. That's very
premature as the community review of the spec has just started. I did rename the default/target drop file (and env var) to DOORDROP.INI in rev 0.7 to avoid any confusion with DROPFILE.### (never heard of it before recently) and reserve the right to make other incompatible changes as the review proceeds. It's still just a proposal.
--
digital man (rob)

Synchronet "Real Fact" #37:
Synchronet's Windows Control Panel is built with Borland C++ Builder
Norco, CA WX: 90.1°F, 43.0% humidity, 3 mph W wind, 0.00 inches rain/24hrs
--- SBBSecho 3.38-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)

Re: New (proposed) door drop file format, for review and discussion
By: Digital Man to All on Wed Sep 30 2026 01:59 am

https://github.com/SynchronetBBS/sbbs/blob/master/docs/dropfile_ini.md

Not implemented anywhere yet (not even in Synchronet), purposely, so as to give the community time (mainly door and host/BBS/server authors) time to give feedback. I do plan to implement support for this format (once it's finalized) in Synchronet BBS software and some of my new doors.

The proposal, now at rev 0.7 (not a standard, nobody should be implementing this yet except for experimental purposes) is now at:
https://github.com/SynchronetBBS/sbbs/blob/master/docs/doordrop_ini.md and https://gitlab.synchro.net/main/sbbs/-/blob/master/docs/doordrop_ini.md
--
digital man (rob)

Rush quote #52:
His world is under observation, we monitor his station .. Digital Man
Norco, CA WX: 89.7°F, 47.0% humidity, 5 mph W wind, 0.00 inches rain/24hrs
--- SBBSecho 3.38-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)

--- NuSkooler Said ---

Same as above, my understanding is there are some, but I haven't seen 'em :)

--- NuSkooler Done ---

That's because the Sysops are now serving at the 'Front'


-------
Mickey at Large
centralontarioremote.net:2323 - Bad Poetry Board
--- ViSiON/3 v0.9.4/Linux
* Origin: The Bad Poetry Board Vision3 (21:1/159.20)

On 30 Sep 2026 at 07:56p, Digital Man pondered and said...

Thanks for *all* the feedback, I'll review and update accordingly.

I've been juggling some stuff on the home/house front but just pipping in here to say great to see you guys working on something new and in such a collaborative fashion :) Thanks for these collective efforts - we're all better off for it :)

Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Re: Re: New (proposed) door drop file format, for review and discussion
By: Avon to Digital Man on Mon Oct 05 2026 02:44 pm

On 30 Sep 2026 at 07:56p, Digital Man pondered and said...

Thanks for *all* the feedback, I'll review and update accordingly.

I've been juggling some stuff on the home/house front but just pipping in here to say great to see you guys working on something new and in such a collaborative fashion :) Thanks for these collective efforts - we're all better off for it :)

Sure thing! I think all the other BBS drop file formats (including my own) likely would have been better designed with more collaboration up front and I'm hoping not repeat that mistake. So to be clear, this is just a proposal, not something anyone should be implementing yet as the review period (however long that may be) is not complete.
--
digital man (rob)

Synchronet "Real Fact" #39:
Synchronet first supported Windows NT v6.x (a.k.a. Vista/Win7) w/v3.14a (2006) Norco, CA WX: 87.1°F, 33.0% humidity, 6 mph WNW wind, 0.00 inches rain/24hrs --- SBBSecho 3.38-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)