• FSP-10xx-1: BBSID Kludge Specification

    From Michiel van der Vlist@2:280/5555 to Rob Swindell on Fri Dec 29 14:31:04 2023
    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)
  • From Rob Swindell@1:103/705 to Michiel van der Vlist on Fri Dec 29 16:15:15 2023
    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)
  • From Rob Swindell@1:103/705 to All on Fri Dec 29 17:34:36 2023
    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)
  • From Rob Swindell@1:103/705 to Michiel van der Vlist on Fri Dec 29 18:00:59 2023
    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)
  • From Michiel van der Vlist@2:280/5555 to Rob Swindell on Sat Dec 30 17:18:45 2023
    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)
  • From Rob Swindell@1:103/705 to Michiel van der Vlist on Sat Dec 30 18:01:42 2023
    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)
  • From August Abolins@2:221/1.58 to Michiel van der Vlist on Sat Dec 30 18:47:00 2023
    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)
  • From Michiel van der Vlist@2:280/5555 to Rob Swindell on Sun Dec 31 15:22:24 2023
    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)
  • From Michiel van der Vlist@2:280/5555 to August Abolins on Sun Dec 31 15:37:14 2023
    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)
  • From August Abolins@2:221/1.58 to Michiel van der Vlist on Sun Dec 31 14:55:00 2023
    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)
  • From Michiel van der Vlist@2:280/5555 to August Abolins on Sun Dec 31 21:16:35 2023
    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)
  • From Rob Swindell@1:103/705 to Michiel van der Vlist on Sun Dec 31 21:19:49 2023
    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)
  • From deon@3:633/509 to Rob Swindell on Mon Jan 1 20:02:30 2024
    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)
  • From Michiel van der Vlist@2:280/5555 to Rob Swindell on Tue Jan 2 11:12:09 2024
    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)
  • From Michiel van der Vlist@2:280/5555 to deon on Tue Jan 2 11:31:39 2024
    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)
  • From deon@3:633/509 to Michiel van der Vlist on Wed Jan 3 00:19:09 2024
    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)
  • From Michiel van der Vlist@2:280/5555 to deon on Tue Jan 2 16:58:33 2024
    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)