**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE **********************************************************************

Publication: FSP-10xx
Revision: 1
Title: BBSID Kludge Specification
Author: Rob Swindell (1:103/705)
Date: 2023-12-12 ----------------------------------------------------------------------

Status of this document
-----------------------

This document is a Fidonet Standard Proposal (FSP), issued by its
author for the benefit of the Fidonet community.

This document specifies an optional Fidonet standard protocol for
the Fidonet community, and requests discussion and suggestions for
improvements.

This document is released to the public domain, and may be used,
copied or modified for any purpose whatever.


Contents
--------
1. Background
2. Definition
3. Deployment
4. References

----------------------------------------------------------------------

1. Background
-------------
Synchronet BBS software supports the optional storage and display
of character/block-graphic "avatars" for users of a BBS as well
as the authors of messages imported from message networks.

Other BBS software packages have also adopted the Synchronet avatar
specifications and distribution model. The technical details of
Synchronet avatars, including their sharing and storage formats,
are not within the scope of this document, but more information
can be found by following the links in the References section.

1.1 The Problem
---------------
The Synchronet user avatar data is not sent/stored with every
posted message, but rather the avatar data is communicated
out-of-band from networked discussion areas and the stored avatars
include metadata to allow them to be correlated with the authors
of subsequently locally-posted and received networked messages.
This correlation is necessary in order to display the proper stored
avatar corresponding with each message's author.

Since avatars may be shared among BBSes using one of a number of
message networking technologies (e.g. QWK, NNTP, FidoNet), and a
BBS may have multiple FidoNet addresses (AKAs), a single
correlatable ID was saught to enable the identification of the
proper avatar to be displayed with the author of a networked
message, regardless of which FidoNet-technology-network address
from which the message was posted.

For example, a BBS may store an avatar for "Rob Swindell" at
1:103/705 (the FidoNet address of Vertrauen BBS) but would want
that same avatar to be displayed along with any messages received
from "Digital Man" at 21:1/183 (the fsxNet address of Vertrauen
BBS). Solving the correlation of user aliases and real names is
not within the scope of this document.

1.2 The Solution
----------------
Since BBSes that support QWK packet technology must already have a
globally unique ID (the so-called BBS-ID or "Board ID" from which
their QWK packet files are named), it made logical sense to reuse
this same ID as the method of correlating any message received via
FidoNet with the avatar data stored for the message author.

2. Definition
-------------
A control paragraph (AKA kludge line) that contains a FidoNet
node's BBS-ID has the format.

BBSID: <bbs-id>

Where <bbs-id> is a string of between 2 and 8 monocased ASCII
characters, begining with an alphabetic character (betweeen 'A'
and 'Z' inclusive). Only MS-DOS compatible filename characters
may be included in a BBS-ID.

The current common practice is for FidoNet message control
paragraphs to be introduced with an ASCII 1 (SOH) character and
terminated with an ASCII 13 (CR) character.

Although a BBS sysop would best serve their users by having a
globally unique BBS-ID, there's no existing known method to insure
that is the case. So some creativity and research on the part of
the sysop is recommended when determining what their BBS-ID should
be and it should not be changed once the system usership has been
established.

3. Deployment
-------------
Synchronet and its FidoNet echomail program, SBBSecho, added BBSID
kludge line support in December of 2020 (w/SBBSecho v3.12). So it's
likely that the nodes of various FidoNet technology networks around
the world started importing and storing echomail messages with BBS-IDs
around this same time. So this document (from late 2023) finally
formally defines the intention and use of this new metadata.

Its possible that other uses for shared correlatable BBS-IDs within
the metadata of FidoNet netmail and echomail messages may come to
light in the future.


4. References
-------------
[Synchronet Avatars] https://wiki.synchro.net/module:avatars
[QWK Packets] https://wiki.synchro.net/ref:qwk
[Kludge Line] https://wiki.synchro.net/ref:fidonet_glossary#kludge_line--
digital man (rob)

Sling Blade quote #11:
Doyle Hargraves (to Karl): What in the hell you doin' with that hammer?
Norco, CA WX: 64.1øF, 58.0% humidity, 0 mph E wind, 0.00 inches rain/24hrs
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Hello Rob,

On Tuesday December 26 2023 15:05, you wrote to All:

BBSID: <bbs-id>

Where <bbs-id> is a string of between 2 and 8 monocased ASCII
characters, begining with an alphabetic character (betweeen 'A'
and 'Z' inclusive). Only MS-DOS compatible filename characters
may be included in a BBS-ID.

1) In my logic "between 2 and 8" is the range that starts at 3 and ends at 7.

2) What exactly do you mean by "monocased"?
A) Upper case only.
B) Either case but the same case for all characters in the string.
C) Any case but case will be ignored when processing.
D) Something else.

3) Although I have done my fair share of MS-DOS programming even I do not know out of head any more exactly which characters are allowed in an MS-DOS file name. It has been too long ago. This will only get worse. It may be better not to refer to MS-DOS but to explicitly specify the characters.

4) But why all these restrictions? The time that memory, disk space or processing power were relevant limitations in issues like this is long gone. Considering that there is no central registration and that BBS sysops will not choose a random string of characters but choose something that relates to the BBS name, the chance of a conflict with only 8 characters is not neglegible. So why these limitations? why not 32 bytes instead of 8? And why ASCII only? The world of BBSing is bigger than the US and Canada and some may want to use non ASCII characters. Why not allow UTF-8?

5) But the most daring question is: why should this be a FIDONET standard? Technically Fidonet technology starts at the system outbound and ends at the system inbound. What happens beyond those borders is technically no concern of Fidonet. While BBSs can use Fidonet technology to exchange messages, there are many other ways for BBSs to achieve the same goal and these days Fidonet is probably no longer even be the main means to do so. I would say this should be a BBS standard rather than a Fidonet standard.

6) As a side note I would like to add that the idea is not entirely new. Henk Wevers introduced the GIF kludge in his BBS/mailer programme Dutchie. It allowed a portet of the author of the message to be diaplayed on the screen. The GIF kludge did not make it into a Fidonet standard.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: Nieuw Schnøørd (2:280/5555)

Good ${greeting_time}, Rob!

26 Dec 2023 15:05:26, you wrote to All:

Since BBSes that support QWK packet technology must

Must?

already have a globally unique ID (the so-called BBS-ID or "Board ID"

What happens if a BBS lacks such ID?

from which their QWK packet files are named),

What if BBS doesn't use QWK?

it made logical sense to reuse this same ID as the method of
correlating any message received via FidoNet with the avatar data
stored

Where?

for the message author.

Author or BBS?

BBSID: <bbs-id>
Where <bbs-id> is a string of between 2 and 8 monocased ASCII
characters, begining with an alphabetic character (betweeen 'A' and
'Z' inclusive).

The word "monocased" reduces the characters to letters.

Only MS-DOS compatible filename characters may be included in a
BBS-ID.

DOSes are dead for over 20 years. What is the reason for such limitation?

Filenames MAY (as in FTA-1006) contain any characters (bytes) except 0x2F ('/') and 0x00 (NUL). Software MUST be able to process these names correctly, but MAY use limited character subset when creating files.

Although a BBS sysop would best serve their users by having a globally unique BBS-ID, there's no existing known method to insure that is the case. So some creativity and research on the part of the sysop is recommended when determining what their BBS-ID should be and it should
not be changed once the system usership has been established.

If you want to introduce the globally unique user ID, you should look at some hash functions, especially ones designed for cryptography. Or simply use GPG public key fingerprints for this purpose.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

... GPG: 8832FE9FA791F7968AC96E4E909DAC45EF3B1FA8 @ hkp://keys.gnupg.net
--- /bin/vi
* Origin: ::1 (2:5020/545)

Re: FSP-10xx-1: BBSID Kludge Specification
By: Michiel van der Vlist to Rob Swindell on Wed Dec 27 2023 12:38 pm

Hello Rob,

On Tuesday December 26 2023 15:05, you wrote to All:

BBSID: <bbs-id>

Where <bbs-id> is a string of between 2 and 8 monocased ASCII
characters, begining with an alphabetic character (betweeen 'A'
and 'Z' inclusive). Only MS-DOS compatible filename characters
may be included in a BBS-ID.

1) In my logic "between 2 and 8" is the range that starts at 3 and ends at 7.

I'll add "inclusive".

2) What exactly do you mean by "monocased"?
A) Upper case only.
B) Either case but the same case for all characters in the string.
C) Any case but case will be ignored when processing.
D) Something else.

A.

3) Although I have done my fair share of MS-DOS programming even I do not know out of head any more exactly which characters are allowed in an MS-DOS file name. It has been too long ago. This will only get worse. It may be better not to refer to MS-DOS but to explicitly specify the characters.

Sure.

4) But why all these restrictions?

QWK software is largely MS-DOS software, sor for a BBS ID to be QWK-compatible, it generally needs a MS-DOS-compatible base filename.

5) But the most daring question is: why should this be a FIDONET standard?

I'm not saying it should be. I'm just documenting this new kludge that you and other FTN nodes will find on their networks now (and over the past few years).

6) As a side note I would like to add that the idea is not entirely new.

This is in actual use and has been for years now. It's not just an idea.
--
digital man (rob)

Breaking Bad quote #35:
You ever smoke anything else, Wendy? Sausages don't count - ha ha - Hank Norco, CA WX: 55.9øF, 90.0% humidity, 0 mph E wind, 0.00 inches rain/24hrs
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: FSP-10xx-1: BBSID Kludge Specification
By: Alexey Vissarionov to Rob Swindell on Wed Dec 27 2023 01:22 pm

Good ${greeting_time}, Rob!

26 Dec 2023 15:05:26, you wrote to All:

Since BBSes that support QWK packet technology must

Must?

already have a globally unique ID (the so-called BBS-ID or "Board ID"

What happens if a BBS lacks such ID?

The QWK packet standard requires a BBS ID. If a BBS supports QWK, it must have one.

from which their QWK packet files are named),

What if BBS doesn't use QWK?

Then the BBS may not have a need for a BBS ID.

it made logical sense to reuse this same ID as the method of correlating any message received via FidoNet with the avatar data stored

Where?

Out of scope of the document.

for the message author.

Author or BBS?

Avatars are associated with an author which is a user on a BBS.

BBSID: <bbs-id>
Where <bbs-id> is a string of between 2 and 8 monocased ASCII characters, begining with an alphabetic character (betweeen 'A' and
'Z' inclusive).

The word "monocased" reduces the characters to letters.

Only MS-DOS compatible filename characters may be included in a
BBS-ID.

DOSes are dead for over 20 years. What is the reason for such limitation?

The same answer I gave previous, for QWK packet compatibility.
--
digital man (rob)

Sling Blade quote #2:
Karl (re: killing Doyle): I hit him two good whacks in the head with it.
Norco, CA WX: 55.9øF, 90.0% humidity, 0 mph E wind, 0.00 inches rain/24hrs
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Hello Rob,

On Wednesday December 27 2023 18:50, you wrote to me:

2) What exactly do you mean by "monocased"?
A) Upper case only.
B) Either case but the same case for all characters in the string.
C) Any case but case will be ignored when processing.
D) Something else.

A.

Then I suggest you call it just that: "upper case". Using exotic synonims may benefit poets and novel writers but technical documentation should be as clear and unambigues as possible. Especially when part of the intended audience has a different native languange than the author. I have never come across "monocased" and even Google can not help me.

4) But why all these restrictions?

QWK software is largely MS-DOS software, sor for a BBS ID to be QWK-compatible, it generally needs a MS-DOS-compatible base filename.

Backward compatibility has pros and cons. In the beginning of a transition process it can be usefull but later in the transition process the pros erode and the cons get stronger. It gets in the way of the new. Your BBSID proposal is presented as a means to facilitate the use of Avatars in messages. For this use the maximum of 8 upper case ASCII characters is a serious and needless limitation. So why insist on backward compatibility with QWK. QWK is not even a Fidonet standard!

I'm not saying it should be. I'm just documenting this new kludge that
you and other FTN nodes will find on their networks now (and over the
past few years).

For things that are not strictly within Fidonet but that are usefull to be documented anyway, there is the reference library.

6) As a side note I would like to add that the idea is not entirely
new.

This is in actual use and has been for years now. It's not just an
idea.

Henk Wever's GIF kludge was not just an idea either. It has been in actual use for several years.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: Nieuw Schnøørd (2:280/5555)

Re: FSP-10xx-1: BBSID Kludge Specification
By: Michiel van der Vlist to Rob Swindell on Fri Dec 29 2023 02:31 pm

Hello Rob,

On Wednesday December 27 2023 18:50, you wrote to me:

2) What exactly do you mean by "monocased"?
A) Upper case only.
B) Either case but the same case for all characters in the string.
C) Any case but case will be ignored when processing.
D) Something else.

A.

Then I suggest you call it just that: "upper case". Using exotic synonims may benefit poets and novel writers but technical documentation should be as clear and unambigues as possible. Especially when part of the intended audience has a different native languange than the author. I have never come across "monocased" and even Google can not help me.

I didn't invent the term "monocase". e.g. pg 259 of K&R's C Programming Language.

4) But why all these restrictions?

QWK software is largely MS-DOS software, sor for a BBS ID to be QWK-compatible, it generally needs a MS-DOS-compatible base filename.

Backward compatibility has pros and cons. In the beginning of a transition process it can be usefull but later in the transition process the pros erode and the cons get stronger. It gets in the way of the new. Your BBSID proposal is presented as a means to facilitate the use of Avatars in messages. For this use the maximum of 8 upper case ASCII characters is a serious and needless limitation. So why insist on backward compatibility with QWK. QWK is not even a Fidonet standard!

I suppose no good reason. For this purpose, any string would actually do.

I'm not saying it should be. I'm just documenting this new kludge that you and other FTN nodes will find on their networks now (and over the past few years).

For things that are not strictly within Fidonet but that are usefull to be documented anyway, there is the reference library.

Sure, that'd work fine. Worst case, I'll just put this on my wiki.

6) As a side note I would like to add that the idea is not entirely
new.

This is in actual use and has been for years now. It's not just an idea.

Henk Wever's GIF kludge was not just an idea either. It has been in actual use for several years.

I've never seen the "GIF kludge" in actual use. <shrug>

But in any case (I can't seem to find the FTSC doc that describes that kludge), my recollection was that other Avatar/Gif thing provided a link to an image file to be used as an avatar. Not the same thing as a correlatable system ID (what I'm doing).
--
digital man (rob)

Sling Blade quote #17:
Charles Bushman: A shovel just makes too goddamned much racket.
Norco, CA WX: 62.2øF, 72.0% humidity, 1 mph ENE wind, 0.00 inches rain/24hrs --- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: FSP-10xx-1: BBSID Kludge Specification
By: Rob Swindell to All on Tue Dec 26 2023 03:05 pm

**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE **********************************************************************

Publication: FSP-10xx
Revision: 2
Title: BBSID Kludge Specification
Author: Rob Swindell (1:103/705)
Date: 2023-12-29 ----------------------------------------------------------------------

Status of this document
-----------------------

This document is a Fidonet Standard Proposal (FSP), issued by its
author for the benefit of the Fidonet community.

This document specifies an optional Fidonet standard protocol for
the Fidonet community, and requests discussion and suggestions for
improvements.

This document is released to the public domain, and may be used,
copied or modified for any purpose whatever.


Contents
--------
1. Background
2. Definition
3. Deployment
4. References

----------------------------------------------------------------------

1. Background
-------------
Synchronet BBS software supports the optional storage and display
of character/block-graphic "avatars" for users of a BBS as well
as the authors of messages imported from message networks.

Other BBS software packages have also adopted the Synchronet avatar
specifications and distribution model. The technical details of
Synchronet avatars, including their sharing and storage formats,
are not within the scope of this document, but more information
can be found by following the links in the References section.

1.1 The Problem
---------------
The Synchronet user avatar data is not sent/stored with every
posted message, but rather the avatar data is communicated
out-of-band from networked discussion areas and the stored avatars
include metadata to allow them to be correlated with the authors
of messages that are subsequently locally-posted and received via
message network. This correlation is necessary in order to display
the proper stored avatar corresponding with each message's author.

Since avatars may be shared among BBSes using one of a number of
message networking technologies (e.g. QWK, NNTP, FidoNet), and a
BBS may have multiple FidoNet addresses (AKAs), a single
correlatable ID was saught to enable the identification of the
proper avatar to be displayed with the author of a networked
message, regardless of which FidoNet-technology-network address
from which the message was posted.

For example, a BBS may store an avatar for "Rob Swindell" at
1:103/705 (the FidoNet address of Vertrauen BBS) but would want
that same avatar to be displayed along with any messages received
from "Digital Man" at 21:1/183 (the fsxNet address of Vertrauen
BBS). Solving the correlation of user aliases and real names is
not within the scope of this document.

1.2 The Solution
----------------
Since BBSes that support QWK packet technology should already have a
globally unique ID (the so-called BBS-ID or "Board ID" from which
their QWK packet files are named), it made logical sense to reuse
this same ID as the method of correlating any message received via
FidoNet with the avatar data stored for the message author.

So Synchronet/SBBSecho includes the sysop-configured BBS-ID of the
originating system in the metadata of all messages exported to FidoNet
technology networks, in the form of a new kludge line: BBSID.

2. Definition
-------------
A control paragraph (AKA kludge line) that contains a FidoNet
node's BBS-ID has the format:

BBSID: <bbs-id>

Where <bbs-id> is a string of between 1 and 100 printable characters.

The current common practice is for FidoNet message control
paragraphs to be introduced with an ASCII 1 (SOH) character and
terminated with an ASCII 13 (CR) character.

Although a BBS sysop would best serve their users by having a
globally unique BBS-ID, there's no existing known method to insure
that is the case. So some creativity and research on the part of
the sysop is recommended when determining what their BBS-ID should
be and it should not be changed once the system usership has been
established.

3. Deployment
-------------
Synchronet and its FidoNet echomail program, SBBSecho, added BBSID
kludge line support in December of 2020 (w/SBBSecho v3.12). So it's
likely that the nodes of various FidoNet technology networks around
the world started importing and storing echomail messages with BBS-IDs
around this same time. So this document (from late 2023) finally
formally defines the intention and use of this new metadata.

It is possible that other uses for shared correlatable BBS-IDs within
the metadata of FidoNet netmail and echomail messages may come to
light in the future.


4. References
-------------
[Synchronet Avatars] https://wiki.synchro.net/module:avatars
[QWK Packets] https://wiki.synchro.net/ref:qwk
[Kludge Line] https://wiki.synchro.net/ref:fidonet_glossary#kludge_line
--
digital man (rob)

This Is Spinal Tap quote #32:
Derek Smalls: [A jog?] We don't have time for that.
Norco, CA WX: 57.8øF, 83.0% humidity, 0 mph ESE wind, 0.00 inches rain/24hrs --- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: FSP-10xx-1: BBSID Kludge Specification
By: Michiel van der Vlist to Rob Swindell on Fri Dec 29 2023 02:31 pm

Henk Wever's GIF kludge was not just an idea either. It has been in actual use for several years.

Are you refering to this draft (by Sergey Sokoloff)? https://github.com/Mithgol/node-fidonet-jam/blob/master/avatar.txt

It defines a GIF kludge. And do find some (very few) uses of this kludge in my FidoNet archived messages, but none of the other kludges mentioned in that doc.
--
digital man (rob)

Breaking Bad quote #50:
I've got your restraining order right here. [grabs crotch] Restrain this! - WW Norco, CA WX: 57.0øF, 87.0% humidity, 0 mph E wind, 0.00 inches rain/24hrs
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Hello Rob,

On Friday December 29 2023 18:00, you wrote to me:

Henk Wever's GIF kludge was not just an idea either. It has been in
actual use for several years.

Are you refering to this draft (by Sergey Sokoloff)? https://github.com/Mithgol/node-fidonet-jam/blob/master/avatar.txt

I was not refering to any document, I was refering to my memory. As I mentioned, it never made it into an FTSC standard. Possible because there was no FTSC yet when it was used. It was used by Henk Wever's bbs/mailer Dutchie that was not used much outside The Netherlands. I am talking about the very early days of Fidonet. end 80ties, begin 90ties. Here is the picture that Henk used in his GIF kludge:

http://www.vlist.eu/fotos/henkweve.gif

I merely meant to point out that having a kludge to facilitate displaying an image representing the author along with the message is not new. Indeed it differs from what you propose in that the GIF kludge directly gives the name of the file that contains the image.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: Nieuw Schnøørd (2:280/5555)

Re: FSP-10xx-1: BBSID Kludge Specification
By: Michiel van der Vlist to Rob Swindell on Sat Dec 30 2023 05:18 pm

Hello Rob,

On Friday December 29 2023 18:00, you wrote to me:

Henk Wever's GIF kludge was not just an idea either. It has been in
actual use for several years.

Are you refering to this draft (by Sergey Sokoloff)? https://github.com/Mithgol/node-fidonet-jam/blob/master/avatar.txt

I was not refering to any document, I was refering to my memory. As I mentioned, it never made it into an FTSC standard. Possible because there was no FTSC yet when it was used. It was used by Henk Wever's bbs/mailer Dutchie that was not used much outside The Netherlands. I am talking about the very early days of Fidonet. end 80ties, begin 90ties. Here is the picture that Henk used in his GIF kludge:

http://www.vlist.eu/fotos/henkweve.gif

Interesting. Did this "GIF kludge" use the same format as defined by Sergey in 2017? The (few) GIF kludges I see in my message bases seem to match Sergey's definition.

I merely meant to point out that having a kludge to facilitate displaying an image representing the author along with the message is not new. Indeed it differs from what you propose in that the GIF kludge directly gives the name of the file that contains the image.

Yeah, I was aware. I think the BBS ID kludge could have other uses too.
--
digital man (rob)

This Is Spinal Tap quote #3:
How much more black could this be? and the answer is none. None more black. Norco, CA WX: 53.6øF, 87.0% humidity, 6 mph ENE wind, 0.08 inches rain/24hrs --- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Hello Michiel van der Vlist!

MvdV> http://www.vlist.eu/fotos/henkweve.gif

MvdV> I merely meant to point out that having a kludge to facilitate
MvdV> displaying an image representing the author along with the message is
MvdV> not new. Indeed it differs from what you propose in that the GIF kludge
MvdV> directly gives the name of the file that contains the image.

Even a kludge that is implemented in this in-the-clear system
as FTN is, is fraught with security issues. Anyone in the
chain of transfer can manipulate a message header kludge to
point something untowardly or inappropriate.




--
../|ug

--- OpenXP 5.0.58
* Origin: (2:221/1.58)

Hello Rob,

On Saturday December 30 2023 18:01, you wrote to me:

http://www.vlist.eu/fotos/henkweve.gif

Interesting. Did this "GIF kludge" use the same format as defined by Sergey in 2017? The (few) GIF kludges I see in my message bases seem
to match Sergey's definition.

Yes, Sergey's document matches what I recall of the format of the GIF kludge. I am not so sure about implication of the file being file requestable from the author's system. I do not recall how I got the file. File request would not work for point systems anyway and pointing was very popular at the time in The Netherlands.

The other kludges in the document do not trigger my memory.

I merely meant to point out that having a kludge to facilitate
displaying an image representing the author along with the message
is not new. Indeed it differs from what you propose in that the GIF
kludge directly gives the name of the file that contains the image.

Yeah, I was aware. I think the BBS ID kludge could have other uses
too.

Possibly. But in Fidonet we already have a way to identify a system: the node number. And that is guaranteed to be globally unique within Fidonet.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: Nieuw Schnøørd (2:280/5555)

Hello August,

On Saturday December 30 2023 18:47, you wrote to me:

Even a kludge that is implemented in this in-the-clear system
as FTN is, is fraught with security issues. Anyone in the
chain of transfer can manipulate a message header kludge to
point something untowardly or inappropriate.

I do not see the problem. The .GIF files are stored locally on the system of the receiver. In a directory that is under full control of the sysop of that system. Even if the kludge were altered on the way what clould possible happen other that that the picture of the wrong person is displayed om the reader's screen?


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: Nieuw Schnøørd (2:280/5555)

Hello Michiel!

MvdV> ..File request would not work for point systems anyway
MvdV> and pointing was very popular at the time in The
MvdV> Netherlands.

Why not? OpenXP doesn't seem to have a problem with it.


MvdV> Possibly. But in Fidonet we already have a way to
MvdV> identify a system: the node number. And that is
MvdV> guaranteed to be globally unique within Fidonet.

A few years ago, there were some duplicate net/nodes across
zones. Not sure of the situation now.

--
../|ug

--- OpenXP 5.0.58
* Origin: (2:221/1.58)

Hello August,

On Sunday December 31 2023 14:55, you wrote to me:

MvdV>> ..File request would not work for point systems anyway
MvdV>> and pointing was very popular at the time in The
MvdV>> Netherlands.

Why not? OpenXP doesn't seem to have a problem with it.

A point can request files from a node, not the other way around.

MvdV>> Possibly. But in Fidonet we already have a way to
MvdV>> identify a system: the node number. And that is
MvdV>> guaranteed to be globally unique within Fidonet.

A few years ago, there were some duplicate net/nodes across
zones. Not sure of the situation now.

The combination of zone:net/node.point is unique.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: Nieuw Schnøørd (2:280/5555)

Re: FSP-10xx-1: BBSID Kludge Specification
By: Michiel van der Vlist to Rob Swindell on Sun Dec 31 2023 03:22 pm

Yeah, I was aware. I think the BBS ID kludge could have other uses
too.

Possibly. But in Fidonet we already have a way to identify a system: the node number. And that is guaranteed to be globally unique within Fidonet.

What we don't have in FidoNet is a way to correlate systems with multiple FTN addresses (from multiple FTNs) as being the *same* system. That's the problem solved with the BBS ID Kludge.
--
digital man (rob)

Sling Blade quote #25:
Karl: they seen fit to put me in here and here I've been a great long while. Norco, CA WX: 51.8øF, 91.0% humidity, 0 mph ESE wind, 0.00 inches rain/24hrs --- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: FSP-10xx-1: BBSID Kludge Specification
By: Rob Swindell to Michiel van der Vlist on Sun Dec 31 2023 09:19 pm

Howdy,

What we don't have in FidoNet is a way to correlate systems with multiple FTN addresses (from multiple FTNs) as being the *same* system. That's the problem solved with the BBS ID Kludge.

This was something that I wanted to address in clrghouz.

So my mailer - I do correlate FTNs to a single system, across fidonet and othernets. It isnt easy (from my vantage point) - because folks are listed differently in different nodelists (the only tool I have that gives me that opportunity).

If they poll clrghouz for one of those FTNs, then I do have all the others they advertise (if they do) - but I represent a corner of the networks, and dont see all systems.

I might be able to leverage your BBSID kludge in echomail to help with this as well... Well, it will help with those systems (currently only SBBS?) that presents it...

As you may know, I can expose that via DNS (which could be that single tool to identify any particular system). I've thought about exposing them all via a suitable TLD but it hasnt got much further than exposing some of these nets via their ZC's domains.



...ëîåï
--- SBBSecho 3.20-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)

Hello Rob,

On Sunday December 31 2023 21:19, you wrote to me:

Possibly. But in Fidonet we already have a way to identify a
system: the node number. And that is guaranteed to be globally
unique within Fidonet.

What we don't have in FidoNet is a way to correlate systems with
multiple FTN addresses (from multiple FTNs) as being the *same*
system. That's the problem solved with the BBS ID Kludge.

1) When it comes to avatars, I'd say that the purpose is beter served with a USER ID rather than a BBS ID. Ever so often users do not always post from one and the same BBS. I posted as a user from several BBS's before I discovered posting as a point in Fidonet... over three decades ago. The BBS kludge does not address users posting from multiple BBS's. The GIF kludge did...

2) From my limited understanding of the reasons for users to participe in so called "othernets" I gather that ever so often they explicitley want to distance themselves from Fidonet. What I also see is people trying to obfuscate their identity by using nicknames and different spelling of their name. So what "problem" is solved by this proposed Fidonet standard for the users that most likely do not want to be identified across networks and that want no involvement with Fidonet?


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: Nieuw Schnøørd (2:280/5555)

Hello deon,

On Monday January 01 2024 20:02, you wrote to Rob Swindell:

This was something that I wanted to address in clrghouz.

So my mailer - I do correlate FTNs to a single system, across fidonet
and othernets. It isnt easy (from my vantage point) - because folks
are listed differently in different nodelists (the only tool I have
that gives me that opportunity).

Has it occured to you that listing in a different way in different networks is because they do /not want/ to be correlated across networks?


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: Nieuw Schnøørd (2:280/5555)

Re: FSP-10xx-1: BBSID Kludge Specification
By: Michiel van der Vlist to deon on Tue Jan 02 2024 11:31 am

Howdy,

Has it occured to you that listing in a different way in different networks is because they do /not want/ to be correlated across networks?

I have.

But the differences that I was referring to are what I would put in the category of spelling mistakes, locations specifics or format errors.

EG: In the case of one sysop, their BBS is listed as "United_States", "Bendigo_Vic", "Bendigo_AUS" and "Bendigo_VIC_AUS". I've seen some examples with Sysop names as well, normally those with Mac... Mc... or their name (or their BBS name) has an apostrophe that is listed in one nodelist and omitted in another.


...ëîåï
--- SBBSecho 3.20-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)

Hello deon,

On Wednesday January 03 2024 00:19, you wrote to me:

Has it occured to you that listing in a different way in different
networks is because they do /not want/ to be correlated across
networks?

I have.

OK, as long as you keep that in mind...

But the differences that I was referring to are what I would put in
the category of spelling mistakes, locations specifics or format
errors.

EG: In the case of one sysop, their BBS is listed as "United_States", "Bendigo_Vic", "Bendigo_AUS" and "Bendigo_VIC_AUS". I've seen some examples with Sysop names as well, normally those with Mac... Mc... or their name (or their BBS name) has an apostrophe that is listed in one nodelist and omitted in another.

The Mac vs Mc and the missing apostrophe might be a typo but it could just as well be an attempt to derail "correlation robots".

There are reasons for the existance of othernets and ever so often it has to do with a dislike for "Fidonet...


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: Nieuw Schnøørd (2:280/5555)