• anyway the wind blows

    From August Abolins@2:221/1.58 to Maurice Kinal on Mon Apr 12 18:05:00 2021
    Hello Maurice Kinal!

    ** On Monday 12.04.21 - 20:52, you wrote to me:

    Here is an official test of duplicate MSGID serial numbers from two different addresses to see if it shows up as a false dupe..


    My system has both of these:

    [1]

    EMP: /FIDO/ASIAN_LINK
    ABS: Maurice Kinal@1:153/7001
    BET: MSGID
    ROT: 2:221/1!153/7001 757 221/6 1
    MID: 1:153/7001 8QIOgQad
    EDA: 20210412014100W+0
    LEN: 2042
    BEZ: 2:221/1.58@fidonet ef514dc6
    MAILER: GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    X_C:
    X-XP-NTP: 30
    F-TO: August Abolins
    X-XP-Charset: UTF-8

    [2]

    EMP: /FIDO/ASIAN_LINK
    ABS: Maurice Kinal@1:153/7001.2989
    BET: anyway the wind blows
    ROT: 2:221/1!153/7001 757 221/6 1
    MID: 1:153/7001.2989 8QIOgQad
    EDA: 20210412205200W+0
    LEN: 811
    MAILER: GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    X_C:
    X-XP-NTP: 30
    F-TO: August Abolins
    X-XP-Charset: UTF-8


    But the subtle difference in these two lines:

    [1] == MID: 1:153/7001 8QIOgQad
    [2] == MID: 1:153/7001.2989 8QIOgQad

    Perhaps you need to keep the "address" part the same for a valid
    test.

    --
    ../|ug

    --- OpenXP 5.0.49
    * Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)
  • From Maurice Kinal@1:153/7001.2989 to August Abolins on Mon Apr 12 20:52:02 2021
    Hey August!

    Here is an official test of duplicate MSGID serial numbers from two different addresses to see if it shows up as a false dupe. Note that I am using the 8 character serial number which is restricted to [a-z][A-Z][0-9] aka [:alnum:] regex. So far it appears to be working as I've already seen it converted to a REPLY kludge in MSGs from a number of different sources so now all that needs to be confirmed is the dupe checking.

    For the record I still believe the 32-bit hex unixtime to be the better option given that it actually represents something useful beyond just dupe checking.

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Satellite - Ladysmith BC, Canada (1:153/7001.2989)
  • From Maurice Kinal@1:153/7001 to August Abolins on Mon Apr 12 22:17:06 2021
    -={ 2021-04-12 22:17:06.607549879+00:00 }=-

    Hey August!

    My system has both of these

    Perfect! That confirms that the address is indeed part of the dupe checking routine.

    [1] == MID: 1:153/7001 8QIOgQad
    [2] == MID: 1:153/7001.2989 8QIOgQad

    That is what I see here. Also there is no doubt they are completely different MSGs, from two different systems. Right? Also it appears from this angle that your idea for the random serial number is indeed compliant with fts-0009.001 despite objections anyone might have about the methodolgy.

    Perhaps you need to keep the "address" part the same for a valid
    test.

    This was a perfectly valid test. If you actually need to see if it will pick up on a duped MSGID we could try that as well. I'll follow up this reply of a totally new MSG with the "1:153/7001 8QIOgQad" address serial number. Don't touch that dial!

    Life is good,
    Maurice

    ... Wa þære þeode þe hæfð ælðeodigne cyng.
    Woe will come to the nation which has a foreign king.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From August Abolins@2:221/1.58 to Maurice Kinal on Mon Apr 12 19:11:00 2021
    Hello Maurice!

    Perfect! That confirms that the address is indeed part of
    the dupe checking routine.

    As it should be, according to some aged sysops in-the-know of
    wisdom and programming experience.

    [1] == MID: 1:153/7001 8QIOgQad
    [2] == MID: 1:153/7001.2989 8QIOgQad

    That is what I see here. Also there is no doubt they are
    completely different MSGs, from two different systems.
    Right? Also it appears from this angle that your idea for
    the random serial number is indeed compliant with fts-
    0009.001 despite objections anyone might have about the
    methodolgy.

    That little word "may" in the salient paragraph of the spec
    opens up the possibilities.

    ..I'll follow up this reply of a totally new MSG with the
    "1:153/7001 8QIOgQad" address serial number. Don't touch
    that dial!

    And.. if I don't see it, it probably means it was detected as a
    dupe along the way!

    --
    ../|ug

    --- OpenXP 5.0.49
    * Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)
  • From Maurice Kinal@1:153/7001 to August Abolins on Tue Apr 13 00:05:42 2021
    -={ 2021-04-13 00:05:42.194992579+00:00 }=-

    Hey August!

    And.. if I don't see it, it probably means it was detected as a
    dupe along the way!

    Yes. My money is on 1:153/757 since that system is the first that MSGs from 1:153/7001 will encounter. For sure the Europoint didn't see it so somewhere along the line it got caught as a dupe ... which of course it wasn't. It was a perfectly valid and original packed MSG with a duped MSGID which could happen although like you pointed out is highly unlikely to happen in a three year period.

    Life is good,
    Maurice

    ... Druncen beorg þe ond dollic word.
    Guard against drunkenness and foolish words.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Wilfred van Velzen@2:280/464 to August Abolins on Tue Apr 13 09:36:08 2021
    Hi August,

    On 2021-04-12 19:11:00, you wrote to Maurice Kinal:

    That is what I see here. Also there is no doubt they are
    completely different MSGs, from two different systems.
    Right? Also it appears from this angle that your idea for
    the random serial number is indeed compliant with fts-
    0009.001 despite objections anyone might have about the
    methodolgy.

    That little word "may" in the salient paragraph of the spec
    opens up the possibilities.

    You probably reading that wrong! ;)

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to Maurice Kinal on Tue Apr 13 09:40:20 2021
    Hi Maurice,

    On 2021-04-13 00:05:42, you wrote to August Abolins:

    And.. if I don't see it, it probably means it was detected as a
    dupe along the way!

    Yes. My money is on 1:153/757 since that system is the first that MSGs from 1:153/7001 will encounter. For sure the Europoint didn't see it so somewhere along the line it got caught as a dupe ... which of course it wasn't. It was a perfectly valid and original packed MSG with a duped MSGID which could happen although like you pointed out is highly unlikely to happen in a three year period.

    I think I have both in my messagebase:

    From : Maurice Kinal 1:153/7001 2021-04-12 01:41:38
    To : August Abolins 2021-04-12 03:55:31
    Subj : MSGID

    @MSGID: 1:153/7001 8QIOgQad
    @REPLY: 2:221/1.58@fidonet ef514dc6
    @CHRS: UTF-8 4
    -={ 2021-04-12 01:41:38.694142067+00:00 }=-

    From : Maurice Kinal 1:153/7001.2989 2021-04-12 20:52:02
    To : August Abolins 2021-04-12 23:57:29
    Subj : anyway the wind blows

    @MSGID: 1:153/7001.2989 8QIOgQad
    @CHRS: UTF-8 4

    If those are the ones you are refering to. So please check again...

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Maurice Kinal@2:280/464.113 to Wilfred van Velzen on Tue Apr 13 13:52:13 2021
    -={ 2021-04-13 13:52:13.576038337+00:00 }=-

    Hey Wilfred!

    @MSGID: 1:153/7001 8QIOgQad
    @MSGID: 1:153/7001.2989 8QIOgQad

    Those were the original tests to ensure that the addresses are indeed part of dupe checking which obviously they are since they show up here on the Europoint. However the third test was an original, fully compliant MSG with a duped MSGID matching "@MSGID: 1:153/7001 8QIOgQad" that doesn't show up here or anywhere beyond 1:153/757 which is 1:153/7001's uplink.

    For the record we repeated the test on a local echoarea that all concerned have access to and it 'failed' again which is exactly what was suspected. Therefore we all concluded that dupe checking is ONLY based on MSGIDs given all were original and compliant MSGs.

    If you want I could repeat the third test here just to see how far your dupe checking goes when encountering a duped MSGID. I think it was worthwhile. Also the EuroPoint uses the 32-bit hex unixtime for it's serial numbers instead of the random 8 character [:alnum:] regex one but that shouldn't matter. What will matter is your dupe checker's abilities to differentiate between a real dupe and one where only the MSGID is duped.

    Let me know and I'll make it so.

    Life is good,
    Maurice

    ... Yldo beoð on eorðan æghwæs cræftig.
    Old age has power over everything on earth.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)
  • From Wilfred van Velzen@2:280/464 to Maurice Kinal on Tue Apr 13 21:52:52 2021
    Hi Maurice,

    On 2021-04-13 13:52:13, you wrote to me:

    For the record we repeated the test on a local echoarea that all
    concerned have access to and it 'failed' again which is exactly what
    was suspected. Therefore we all concluded that dupe checking is ONLY
    based on MSGIDs given all were original and compliant MSGs.

    If you want I could repeat the third test here just to see how far your dupe checking goes when encountering a duped MSGID. I think it was worthwhile. Also the EuroPoint uses the 32-bit hex unixtime for it's serial numbers instead of the random 8 character [:alnum:] regex one but that shouldn't matter. What will matter is your dupe checker's abilities to differentiate between a real dupe and one where only the MSGID is duped.

    Well FMail's dupe checking works a little bit different. When there is a valid MSGID, it also uses the first letters of the From, To and Subject, for it's dupe checking. So if they differ, while the MSGID is the same it's not considered a dupe.

    Let me know and I'll make it so.

    You are welcome to test it, but I already know how it works. ;)

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Maurice Kinal@1:153/7001 to Wilfred van Velzen on Tue Apr 13 20:51:27 2021
    -={ 2021-04-13 20:51:27.779252352+00:00 }=-

    Hey Wilfred!

    So if they differ, while the MSGID is the same it's not
    considered a dupe.

    Until it reaches one of your downstream links that isn't using FMail.

    You are welcome to test it, but I already know how it works.

    No need at this end ... or on the EuroPoint for that matter. I have a copy of the original nondupe dupe if you ever get curious about it. I thought it was fun. Too bad nobody got to see it.

    Life is good,
    Maurice

    ... Sterk als een stier, slim als een tractor.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From August Abolins@2:221/1.58 to Wilfred van Velzen on Tue Apr 13 17:02:00 2021
    Hello Wilfred!

    ** On Tuesday 13.04.21 - 21:52, you wrote to Maurice Kinal:

    Well FMail's dupe checking works a little bit different.
    When there is a valid MSGID, it also uses the first
    letters of the From, To and Subject, for it's dupe
    checking. So if they differ, while the MSGID is the same
    it's not considered a dupe.

    Clever, that is!

    Is that a way to reduce the probability of collisions within a
    certain span of allotted time?

    --
    ../|ug

    --- OpenXP 5.0.49
    * Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)
  • From Maurice Kinal@1:153/7001 to August Abolins on Tue Apr 13 21:15:41 2021
    -={ 2021-04-13 21:15:41.032014984+00:00 }=-

    Hey August!

    Is that a way to reduce the probability of collisions within a
    certain span of allotted time?

    Good question. I've heard of a few different methods for doing this none of which I am currently deploying. Mind you I take care of MSGIDs in the creation of the MSG so the possiblity of collisions is near zero. There is a way but if that happens then it is a signal that something is seriously wrong on my system. It has yet to happen.

    Just for fun here is the output of 10 potential MSGID serailno's, the first column being unixtime 32-bit hex based, the second being the random 8 character [:alnum:] regex dealies;

    60760e0b kUBdI5RO
    60760e0b G5T1LBae
    60760e0b mFSS1Gxc
    60760e0b Daxpq9EE
    60760e0b XVCgstYj
    60760e0b uWuB7Jqj
    60760e0b J0qZbQIo
    60760e0b kGrnLcEZ
    60760e0b NQGnXOVM
    60760e0b kK7htVJO

    Note that only one method produced zero collisions while the other produced nothing but collisions. Based on this very simple test the random 8 character [:alnum:] regex thingies are obviously superior.


    Life is good,
    Maurice

    ... Lofdædum sceal in mægþa gehwære man geþeon.
    By praiseworthy deeds shall one prosper among peoples everywhere.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Wilfred van Velzen@2:280/464 to Maurice Kinal on Wed Apr 14 10:31:12 2021
    Hi Maurice,

    On 2021-04-13 20:51:27, you wrote to me:

    So if they differ, while the MSGID is the same it's not
    considered a dupe.

    Until it reaches one of your downstream links that isn't using FMail.

    ... and only uses the MSGID for dupe checking...


    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to August Abolins on Wed Apr 14 10:32:53 2021
    Hi August,

    On 2021-04-13 17:02:00, you wrote to me:

    Well FMail's dupe checking works a little bit different.
    When there is a valid MSGID, it also uses the first
    letters of the From, To and Subject, for it's dupe
    checking. So if they differ, while the MSGID is the same
    it's not considered a dupe.

    Clever, that is!

    Is that a way to reduce the probability of collisions within a
    certain span of allotted time?

    I don't know, it's how the original author of FMail implemented it. If that was because of a detected collision event, or because he found it a good idea before hand, when he developed the algorithm, I don't know...

    But I think you are confusing the MSGID genererating side and the dupe detecting on the other side of the fence. ;)

    The MSGID generating side must try to prevent collisions. The dupe detecting side can only respond to it by making the detecting algorithm as robust as possible.

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to Maurice Kinal on Wed Apr 14 10:43:48 2021
    Hi Maurice,

    On 2021-04-13 21:15:41, you wrote to August Abolins:

    Is that a way to reduce the probability of collisions within a
    certain span of allotted time?

    Good question. I've heard of a few different methods for doing this none of which I am currently deploying. Mind you I take care of MSGIDs in the creation of the MSG so the possiblity of collisions is near zero. There is
    a way but if that happens then it is a signal that something is seriously wrong on my system. It has yet to happen.

    Just for fun here is the output of 10 potential MSGID serailno's, the first
    column being unixtime 32-bit hex based, the second being the random 8 character [:alnum:] regex dealies;

    60760e0b kUBdI5RO
    60760e0b G5T1LBae
    60760e0b mFSS1Gxc
    60760e0b Daxpq9EE
    60760e0b XVCgstYj
    60760e0b uWuB7Jqj
    60760e0b J0qZbQIo
    60760e0b kGrnLcEZ
    60760e0b NQGnXOVM
    60760e0b kK7htVJO

    Note that only one method produced zero collisions while the other produced
    nothing but collisions. Based on this very simple test the random 8 character [:alnum:] regex thingies are obviously superior.

    So your algorithm based on unixtime has a bug! It should take into account it can be called multiple times within the same second. If you do that correctly, it's superior to the random one...

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Maurice Kinal@1:153/7001 to Wilfred van Velzen on Wed Apr 14 12:07:59 2021
    -={ 2021-04-14 12:07:59.425302400+00:00 }=-

    Hey Wilfred!

    ... and only uses the MSGID for dupe checking...

    Yes. It only takes one in a strategic position to spoil it for everyone and you will never be aware of it until someone like me comes along to point out the obvious ... which of course everyone will ignore and do nothing about it. It happens all the time and not just in fidonet.

    Life is good,
    Maurice

    ... Ne byð þæt fele freond, se þe oþrum facn heleð.
    He who harbours treachery against another is not a faithful friend.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Maurice Kinal@1:153/7001 to Wilfred van Velzen on Wed Apr 14 12:17:02 2021
    -={ 2021-04-14 12:17:02.619723556+00:00 }=-

    Hey Wilfred!

    So your algorithm based on unixtime has a bug!

    That was just a demo which probably is accurate for time based serialno's generated by abandonware which will likely never get fixed.

    It should take into account it can be called multiple times
    within the same second.

    Sure. How about this?

    6076da69-1689a348
    6076da69-16bf0244
    6076da69-16f7701c
    6076da69-172abd44
    6076da69-175c7788
    6076da69-179027b0
    6076da69-17c263b4
    6076da69-17f51008
    6076da69-18287584
    6076da69-185be1cc

    Note that all of the above were created in the same second and there are zero collisions. Also note that the following 8 hex characters are in sequence and are indeed unique. The above routine has a shelf life of just over 2 billion years since the leading seconds hex field is not a fixed field and will expand by one hex character when it is required. The second part after the ascii dash is from strftime()'s %N (nanoseconds) which only requires 8 hex characters for all time BUT in my future proposal, if it gets that far, will allow for picoseconds when they become available by adding 2 hex digits which will make it a fixed 10 hex digit field.

    If you do that correctly, it's superior to the random one...

    See above but just for fun I will do it side by side just like before.

    6076e0bd-22d50e70 n3yM8uFm
    6076e0bd-246302d4 sL4Irxdg
    6076e0bd-25d0d1f0 8fq4vU7e
    6076e0bd-276236a4 Aez4QZog
    6076e0bd-28f6291c jbQiqKYc
    6076e0bd-2a842704 gElrH3UT
    6076e0bd-2bf24d98 8qmyLLQR
    6076e0bd-2d8103dc Pbeaul1Z
    6076e0bd-2f0436d0 IHsKacHr
    6076e0bd-30a01b60 0An6jRkx

    My best guesstimation is that the random one is superior given that it doesn't require a rewrite of current FTN standards. However I do plan to change that and then for sure the unixtime based one will be superior and unique for all time, nevermind 3 lousy years.

    I doubt there is anything better currently in use to either of the above routines and most definetly nothing even comes close to the unixtime based one. It is a work of pure genius. :-)

    Hm. Interesting tagline got tossed into the works considering the content of this reply. It looks to me the Anglo-Saxons might have had working knowledge of the Laws of Thermodynamics long before it's time.

    Life is good,
    Maurice

    ... Eal þæt þu her sceawast hit is sceaduwa gelic, æll hit gewitað.
    All that you see here is like a shadow; it will all vanish.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From August Abolins@2:221/1.58 to Maurice Kinal on Wed Apr 14 09:02:00 2021
    Hello Maurice!

    ** On Tuesday 13.04.21 - 21:15, you wrote:

    Just for fun here is the output of 10 potential MSGID serailno's, the first column being unixtime 32-bit hex based, the second being the random 8 character [:alnum:] regex dealies;

    60760e0b kUBdI5RO
    60760e0b G5T1LBae
    60760e0b mFSS1Gxc
    60760e0b Daxpq9EE
    60760e0b XVCgstYj
    60760e0b uWuB7Jqj
    60760e0b J0qZbQIo
    60760e0b kGrnLcEZ
    60760e0b NQGnXOVM
    60760e0b kK7htVJO

    I thought you said that your 32bit algorithm for the time-
    version took into account fractions of a second down to the microsecond/nanosecond.


    --- OpenXP 5.0.49
    * Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)
  • From Maurice Kinal@1:153/7001 to August Abolins on Wed Apr 14 15:57:11 2021
    -={ 2021-04-14 15:57:11.900772548+00:00 }=-

    Hey August!

    I thought you said that your 32bit algorithm for the time-
    version took into account fractions of a second down to the microsecond/nanosecond.

    That is impossible and if I did say that it would have been in conjunction with the nanosecond part in order to facillitate that degree of resolution. The later example I gave Wilfred would be of two 32-bit hex fields which would resolve it to nanosecond output up to 2106 and then the seconds output would output to 9 hex characters while the nanosecond part remains a 32-bit hex field (fixed 8 hex character field). I recall saying that your idea is superior since it doesn't require any changes to existing documentation regarding MSGIDs.

    If I gave you the wrong impression I will now apologize for my lousy communication skills. I am obviously a lousy technical writer but in my defence I never claimed to be good at it.

    Please note the MSGID of this reply. I think it illustrates that I now have and can facillitate both your idea as well as the usual 32-bit unixtime 8 character hex field which is in seconds not nanoseconds. Once 2106 rears it's ugly head there is nothing in my routine that will prevent it from adding an extra hex character but then it won't be compliant to the current documented MSGID/REPLY format. However the routine based on random 8 character [:alnum:] regex should still be good to go if indeed my attempt at forwards compatibilty fails, which according to everyone is the most likely result. I am on record saying that I am prepared to soldier on if indeed that happens. That won't stop me from trying again in the future but I cannot guarentee how long I can keep soldiering on. I am getting old.

    Life is good,
    Maurice

    ... Ich habe Eichhörnchen in meiner Hose!
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Wilfred van Velzen@2:280/464 to Maurice Kinal on Wed Apr 14 21:28:35 2021
    Hi Maurice,

    On 2021-04-14 12:07:59, you wrote to me:

    ... and only uses the MSGID for dupe checking...

    Yes. It only takes one in a strategic position to spoil it for everyone and you will never be aware of it until someone like me comes along to point out the obvious ... which of course everyone will ignore and do nothing about it. It happens all the time and not just in fidonet.

    It's not really a problem. Because collisions in the MSGID seldom happen...

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to Maurice Kinal on Wed Apr 14 21:29:57 2021
    Hi Maurice,

    On 2021-04-14 12:17:02, you wrote to me:

    It should take into account it can be called multiple times
    within the same second.

    Sure. How about this?

    6076da69-1689a348
    6076da69-16bf0244
    ...

    It doesn't conform to the standard.

    If you do that correctly, it's superior to the random one...

    See above but just for fun I will do it side by side just like before.

    6076e0bd-22d50e70 n3yM8uFm
    6076e0bd-246302d4 sL4Irxdg
    6076e0bd-25d0d1f0 8fq4vU7e
    6076e0bd-276236a4 Aez4QZog
    6076e0bd-28f6291c jbQiqKYc
    6076e0bd-2a842704 gElrH3UT
    6076e0bd-2bf24d98 8qmyLLQR
    6076e0bd-2d8103dc Pbeaul1Z
    6076e0bd-2f0436d0 IHsKacHr
    6076e0bd-30a01b60 0An6jRkx

    My best guesstimation is that the random one is superior given that it doesn't require a rewrite of current FTN standards.

    It doesn't conform to the standard either...

    However I do plan to change that and then for sure the unixtime based
    one will be superior and unique for all time, nevermind 3 lousy years.

    I suggest you don't waist your time on fighting to get the existing standard changed. It's wasted energy.

    If you want a better unique identifier in ftn messages, create a new kludge (see my suggestion for the @UUID one, which needs a @RUID btw for replies), so you can do what you want, and make it as good as possible without having to consider existing software. Then write a proposal and convince software developers to implement it in their software.


    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to Maurice Kinal on Wed Apr 14 21:42:18 2021
    Hi Maurice,

    On 2021-04-14 15:57:11, you wrote to August Abolins:

    @MSGID: 1:153/7001 tmCYOYVw

    Please note the MSGID of this reply.

    Besides not conforming to the standard, and maybe cosing problems in software down the line, it also waists energy!

    Because it doesn't conform to the standard (not strictly hex chars), my tosser uses a different method for calculating a hash for this message (for dupe detection), which uses more cpu cycles. And thus heating up the planet more than a standard conforming MSGID. :-(

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Maurice Kinal@1:153/7001 to Wilfred van Velzen on Wed Apr 14 21:15:09 2021
    -={ 2021-04-14 21:15:09.121832584+00:00 }=-

    Hey Wilfred!

    It's not really a problem. Because collisions in the MSGID
    seldom happen...

    How would you know? If you are only referring to your software of choice then the above might be true, especially if it is a single user application which is common these days.

    Life is good,
    Maurice

    ... Se anweald næfre ne biþ god, buton se god sie þe hine hæbbe.
    Power is never good, unless the one who possesses it is good.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Maurice Kinal@1:153/7001 to Wilfred van Velzen on Wed Apr 14 21:19:56 2021
    -={ 2021-04-14 21:19:56.197907320+00:00 }=-

    Hey Wilfred!

    It doesn't conform to the standard.

    Understood. Not a big deal as it could easily become redundant and unneeded once a real standard is in place that doesn't require ANY kludges.

    It doesn't conform to the standard either...

    I believe you are wrong about that but then again you're spin on it might have validity simply because of obsolesence. So far the only issue I have seen is on one particular point software that buggers up the REPLY kludge but has no effect on what really matters.

    Speaking of nonconformity and obsolesence what is the deal with your bogus CHRS kludge? -> "CHRS: UTF-8 2" It might make someone question your credibilty on mattters of conformance to "standards". Not me of course but then I am not that anal when it comes to conformance to phoney-baloney kludges.

    I suggest you don't waist your time on fighting to get the
    existing standard changed. It's wasted energy.

    Again I disagree. Nothing ventured, nothing gained. We'll see but even if it fails I already feel like a winner and have for around 20 years. Now I am just looking to share the love. :::evil grin:::

    Life is good,
    Maurice

    ... Treow sceal on eorle, wisdom on were.
    Loyalty belongs in a warrior, wisdom in a man.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Maurice Kinal@1:153/7001 to Wilfred van Velzen on Wed Apr 14 21:46:10 2021
    -={ 2021-04-14 21:46:10.094938300+00:00 }=-

    Hey Wilfred!

    And thus heating up the planet more than a standard conforming
    MSGID. :-(

    You make an excellent case for eliminating the MSGID. I can easily get behind this idea. Stinkin' kludges.

    Life is good,
    Maurice

    ... Styran sceal mon strongum mode; storm oft holm gebringeþ.
    A strong mind must be steered; the sea often brings a storm.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From August Abolins@2:221/1.58 to Maurice Kinal on Wed Apr 14 18:12:00 2021
    Hello Maurice!

    ** On Wednesday 14.04.21 - 15:57, you wrote to me:

    I recall saying that your idea is superior since it doesn't
    require any changes to existing documentation regarding
    MSGIDs.

    The existing text could simply change "The serial number may be
    any eight character hexadecimal number, as long as it is
    unique" to "The serial number may be any eight character
    hexadecimal number or a randomized alphanumeric number [*] with
    the character set [a-z][A-Z][0-9], as long as it is unique"

    [*] a suggestion by August Abolins, 2:221/1.58

    The ftsc write-ups could serve as a guidebook for solutions and
    examples and help remove ambiguity and false interpretations.


    If I gave you the wrong impression I will now apologize for
    my lousy communication skills. I am obviously a lousy
    technical writer but in my defence I never claimed to be
    good at it.

    No worries. I probably have a greater fog that gets in my way
    understanding what other people write.


    ..Once 2106 rears it's ugly head there is nothing in my
    routine that will prevent it from adding an extra hex
    character but then it won't be compliant to the current
    documented MSGID/REPLY format.

    Even 2038 maybe of little concern for most of here right now. :(

    And, unless a system keeps each and every message beyond 3 years
    in their respective message bases (even that is possible) there
    is probably no urgency to maintain rigidly unique msgids

    However the routine based on random 8 character [:alnum:]
    regex should still be good to go if indeed my attempt at
    forwards compatibilty fails, which according to everyone is
    the most likely result.

    Yes.. it is sad that there is not much new or alternative
    emerging in the "ideas" department for FTN.

    I am on record saying that I am prepared to soldier on if
    indeed that happens. That won't stop me from trying again
    in the future but I cannot guarentee how long I can keep
    soldiering on. I am getting old.

    I do hope to see what transpires commencing 2038.

    --
    ../|ug

    --- OpenXP 5.0.49
    * Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)
  • From August Abolins@2:221/1.58 to Wilfred van Velzen on Wed Apr 14 18:18:00 2021
    Hello Wilfred!

    ** On Wednesday 14.04.21 - 21:42, you wrote to MK:

    @MSGID: 1:153/7001 tmCYOYVw
    Please note the MSGID of this reply.

    Besides not conforming to the standard, and maybe cosing
    problems in software down the line...

    It seems to be a problem for WinPoint when building a reply
    message. The REPLYID seems to result in 00000000.

    Because it doesn't conform to the standard (not strictly
    hex chars),

    You are adding words to the spec. "strictly" does not appear.

    ;) However, "may" is very clear. :D

    my tosser uses a different method for calculating a hash
    for this message (for dupe detection), which uses more cpu
    cycles. And thus heating up the planet more than a
    standard conforming MSGID. :-(

    They're all just a bunch of 1's and 0's in the end. It's all
    the same stuff. :D

    --
    ../|ug

    --- OpenXP 5.0.49
    * Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)
  • From August Abolins@2:221/1.58 to Wilfred van Velzen on Wed Apr 14 18:21:00 2021
    Hello Wilfred!

    ** On Wednesday 14.04.21 - 21:29, you wrote to MK:

    If you want a better unique identifier in ftn messages,
    create a new kludge (see my suggestion for the @UUID one,
    which needs a @RUID btw for replies), so you can do what
    you want, and make it as good as possible without having
    to consider existing software. Then write a proposal and
    convince software developers to implement it in their
    software.

    So, are kludges like the wild wild west where anything goes?
    That *is* a handy way to extend functionality and features.

    --
    ../|ug

    --- OpenXP 5.0.49
    * Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)
  • From August Abolins@2:221/1.58 to Maurice Kinal on Wed Apr 14 18:30:00 2021
    Hello Maurice!

    ..So far the only issue I have seen is on one particular
    point software that buggers up the REPLY kludge but has no
    effect on what really matters.

    Denis (using Winpoint) hasn't been seen lately. Maybe something
    got buggered up badly?

    Speaking of nonconformity and obsolesence what is the deal with your
    bogus CHRS kludge? -> "CHRS: UTF-8 2"

    That's telling him! :D

    I suggest you don't waist your time on fighting to get
    the existing standard changed. It's wasted energy.

    Again I disagree. Nothing ventured, nothing gained. We'll
    see but even if it fails I already feel like a winner and
    have for around 20 years. Now I am just looking to share
    the love. :::evil grin:::

    The only way of finding the limits of the possible is by going
    beyond them into the impossible. - Arthur C. Clarke

    While one person hesitates because he feels inferior, the other
    is busy making mistakes and becoming superior. - Henry C. Link

    Nothing is a waste of time if you use the experience
    wisely. - Auguste Rodin

    Great spirits have always encountered violent opposition from
    mediocre minds. - Albert Einstein

    You can adopt the attitude there is nothing you
    can do, or you can see the challenge as your call
    to action. - Catherine Pulsifer

    All glory comes from daring to begin. - William Shakespeare

    --
    ../|ug

    --- OpenXP 5.0.49
    * Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)
  • From August Abolins@2:221/1.58 to Wilfred van Velzen on Wed Apr 14 20:58:00 2021
    Hello Wilfred!

    ** On Wednesday 14.04.21 - 10:32, you wrote to me:

    But I think you are confusing the MSGID genererating side
    and the dupe detecting on the other side of the fence. ;)

    Nah.. I don't think I am.

    The MSGID generating side must try to prevent collisions.
    The dupe detecting side can only respond to it by making
    the detecting algorithm as robust as possible.

    I pretty much see it that way too.

    The idea behind generating the MSGID is to produce a string that
    is unique.

    The idea behind dupe detection is to identify with high
    certainty another message that is exactly the same.

    --
    ../|ug

    --- OpenXP 5.0.49
    * Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)
  • From Maurice Kinal@1:153/7001 to August Abolins on Thu Apr 15 02:43:02 2021
    -={ 2021-04-15 02:43:02.687523938+00:00 }=-

    Hey August!

    The ftsc write-ups could serve as a guidebook for solutions and
    examples and help remove ambiguity and false interpretations.

    FTA-1006 might be of interest to you wrt the subject at hand.

    Even 2038 maybe of little concern for most of here right now. :(

    Arguably we're still stuck back in 1995 or at best 1998 which makes the tagline below rather ominous given that was when I thought the two digit year should have gotten the heave-ho. :-|

    I think my tinfoil hat might need readjusting or perhaps I should turn off the random tagline thingy ... or both?

    Yes.. it is sad that there is not much new or alternative
    emerging in the "ideas" department for FTN.

    I think they are out there lurking. Before the election in FTSC_PUBLIC there was some chatter happening about the winds of change that hopefully will be restarted soon.

    I do hope to see what transpires commencing 2038.

    For me it is in the realm of possible but I don't know how active I'll be then ... if I make it that far that is. However I think I am well equipped for it and have been for quite some time now. Heck I have been experimenting with 2106 which I am positive I won't be here to see but am still highly interested in playing with the idea of it and hence the flexible seconds field of my so-called proposed MSGID serialno. Here is what I see happening exactly one second after the 2106 expiry date;

    100000000-00000000

    Note that the first hex field is now 9 hex characters instead of 8, while the nanosecond part following the ascii dash remains fixed at 8 hex characters. The first hex field will increase to 10 hex characters one second after "36812-02-20 00:36:15.000000000+00:00" in rfc-3339 speak. What are the odds that fidonet will have finally gotten over it's hardon for the two digit year before then?

    Life is good,
    Maurice

    ... Eall þæt mon untidlice onginþ, næfþ hit no æltæþne ende.
    Anything begun at the wrong time will never have a good end.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Maurice Kinal@1:153/7001 to August Abolins on Thu Apr 15 03:39:09 2021
    -={ 2021-04-15 03:39:09.713463110+00:00 }=-

    Hey August!

    Denis (using Winpoint) hasn't been seen lately. Maybe something
    got buggered up badly?

    If I am not mistaken he is upgrading to hpt etc. Hopefully we'll be hearing from him soon.

    That's telling him!

    You liked that one did you? Personally it matters not since it is a do nothing kludge. Whoever wrote it was obviously smoking some really bad stuff.

    Life is good,
    Maurice

    ... Fus sceal feran, fæge sweltan.
    Those who are ready must go, the doomed die.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Wilfred van Velzen@2:280/464 to Maurice Kinal on Thu Apr 15 10:43:55 2021
    Hi Maurice,

    On 2021-04-14 21:15:09, you wrote to me:

    It's not really a problem. Because collisions in the MSGID
    seldom happen...

    How would you know? If you are only referring to your software of choice then the above might be true, especially if it is a single user application
    which is common these days.

    If it would happen often in some software, it would get noticed...

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to Maurice Kinal on Thu Apr 15 10:48:18 2021
    Hi Maurice,

    On 2021-04-14 21:19:56, you wrote to me:

    It doesn't conform to the standard.

    Understood. Not a big deal as it could easily become redundant and unneeded once a real standard is in place that doesn't require ANY kludges.

    So you want to replace FTN with something else? Good luck with that...

    Don't be that Don Quichot fighting the imaginary windmills... ;-)

    It doesn't conform to the standard either...

    I believe you are wrong about that but then again you're spin on it might have validity simply because of obsolesence. So far the only issue I have seen is on one particular point software that buggers up the REPLY kludge but has no effect on what really matters.

    Your sample is way to small to conclude anything...

    Speaking of nonconformity and obsolesence what is the deal with your
    bogus CHRS kludge? -> "CHRS: UTF-8 2"

    I am aware of it, but havent' taken the time to fix it. More important things to do...

    It might make someone question your credibilty on mattters of
    conformance to "standards". Not me of course but then I am not that
    anal when it comes to conformance to phoney-baloney kludges.

    Yet you viciously mention it...


    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to August Abolins on Thu Apr 15 10:57:31 2021
    Hi August,

    On 2021-04-14 18:18:00, you wrote to me:

    @MSGID: 1:153/7001 tmCYOYVw
    Please note the MSGID of this reply.

    Besides not conforming to the standard, and maybe cosing
    problems in software down the line...

    It seems to be a problem for WinPoint when building a reply
    message. The REPLYID seems to result in 00000000.

    So that is the first discovered problem. There are probably more. And probably harder to discover...

    Because it doesn't conform to the standard (not strictly
    hex chars),

    You are adding words to the spec. "strictly" does not appear.

    ;) However, "may" is very clear. :D

    I beg to differ...

    my tosser uses a different method for calculating a hash
    for this message (for dupe detection), which uses more cpu
    cycles. And thus heating up the planet more than a
    standard conforming MSGID. :-(

    They're all just a bunch of 1's and 0's in the end. It's all
    the same stuff. :D

    But how we get there isn't...

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to August Abolins on Thu Apr 15 11:02:34 2021
    Hi August,

    On 2021-04-14 18:21:00, you wrote to me:

    If you want a better unique identifier in ftn messages,
    create a new kludge (see my suggestion for the @UUID one,
    which needs a @RUID btw for replies), so you can do what
    you want, and make it as good as possible without having
    to consider existing software. Then write a proposal and
    convince software developers to implement it in their
    software.

    So, are kludges like the wild wild west where anything goes?

    You can create new ones, and that still happens. (Like the @COLS: kludge recently added in synchronet)

    That *is* a handy way to extend functionality and features.

    Indeed.

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From August Abolins@2:221/1.58 to Wilfred van Velzen on Thu Apr 15 09:31:00 2021
    Hello Wilfred!

    ** On Thursday 15.04.21 - 10:57, you wrote to me:

    It seems to be a problem for WinPoint when building a
    reply message. The REPLYID seems to result in 00000000.

    So that is the first discovered problem. There are
    probably more. And probably harder to discover...

    I may have to spin up my Winpoint to see for myself. But
    apparently Winpoint is getting new life in development and the
    uber msgid could be accomodated. :D

    Because it doesn't conform to the standard (not strictly
    hex chars),

    You are adding words to the spec. "strictly" does not appear.

    ;) However, "may" is very clear. :D

    I beg to differ...

    According to fta-1006, the definitions are clear. But
    interestingly, the doc expired 20 years ago. Why a definition
    doc needs to expire (and not be replaced by something else)
    alludes me.

    They're all just a bunch of 1's and 0's in the end. It's
    all the same stuff. :D

    But how we get there isn't...

    Oh.. that's true enough. But I've made my point. Assuming that
    the serialno must be implemenet in hex is just that, an
    assumption.
    --
    ../|ug

    --- OpenXP 5.0.49
    * Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)
  • From Wilfred van Velzen@2:280/464 to August Abolins on Thu Apr 15 16:15:11 2021
    Hi August,

    On 2021-04-15 09:31:00, you wrote to me:

    ;) However, "may" is very clear. :D

    I beg to differ...

    According to fta-1006, the definitions are clear. But
    interestingly, the doc expired 20 years ago. Why a definition
    doc needs to expire (and not be replaced by something else)
    alludes me.

    I think I red somewhere that every ftsc document needs to be reviewed every 2 years... Maurice should know, he's a member! ;)

    They're all just a bunch of 1's and 0's in the end. It's
    all the same stuff. :D

    But how we get there isn't...

    Oh.. that's true enough. But I've made my point. Assuming that
    the serialno must be implemenet in hex is just that, an
    assumption.

    Well if most software expects a hex number, maybe the standard needs to be reviewed, and worded more strict. ;)

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Maurice Kinal@2:280/464.113 to Wilfred van Velzen on Thu Apr 15 15:47:57 2021
    -={ 2021-04-15 15:47:57.035208337+00:00 }=-

    Hey Wilfred!

    I think I red somewhere that every ftsc document needs to be
    reviewed every 2 years

    fta-1001.007. I believe it is a good idea.

    Well if most software expects a hex number, maybe the standard
    needs to be reviewed, and worded more strict. ;)

    Or not. As is I think it is clear enough but a review of all standards is a good idea including MSGID/REPLY.

    Life is good,
    Maurice

    ... Gyfena gehwilc underbæc besihþ.
    Every gift looks backwards.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)
  • From Wilfred van Velzen@2:280/464 to Maurice Kinal on Thu Apr 15 18:03:06 2021
    Hi Maurice,

    On 2021-04-15 15:47:57, you wrote to me:

    Well if most software expects a hex number, maybe the standard
    needs to be reviewed, and worded more strict. ;)

    Or not. As is I think it is clear enough but a review of all standards is a good idea including MSGID/REPLY.

    To review if they still describe current practice, or could be worded better, not to change them to something incompatible with current practice. ;)

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Maurice Kinal@1:153/7001 to Wilfred van Velzen on Thu Apr 15 17:00:22 2021
    -={ 2021-04-15 17:00:22.008942453+00:00 }=-

    Hey Wilfred!

    To review if they still describe current practice,

    Which is?

    or could be worded better, not to change them to something
    incompatible with current practice. ;)

    Nope. Speaking as a nodelisted sysop, as well as the only user of an official point system, and especially as a standing member of the FTSC I refuse to subscribe to mob rule which is where 'current practice' usually leads. On this particular subject of the MSGID/REPLY kludges my gut feeling is to leave the wording as is since it leaves open a door for improvement if and when it presents itself. I think it is clear enough without any alterations, up to and including my suggestion for a new and improved flexible hex character representation of unixtime.

    I look forward to the review of this particular document. I have much to say about it especially about the misuse of the MSGID to introduce proprietary addressing. That has to go no matter what harm it might bring to the software in question.

    Life is good,
    Maurice

    ... Leorna hwæthwugu æt ðam wisran, þæt þu mæge læran þone unwisran.
    Learn something from the wise, so you can teach the ignorant.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From August Abolins@2:221/1.58 to Maurice Kinal on Thu Apr 15 17:03:00 2021
    Hello Maurice!

    ** On Thursday 15.04.21 - 17:00, you wrote to WvV:

    ..as well as the only user of an
    official point system,...

    What system is that?


    --
    ../|ug

    --- OpenXP 5.0.49
    * Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)
  • From Maurice Kinal@2:280/464.113 to August Abolins on Thu Apr 15 21:29:50 2021
    -={ 2021-04-15 21:29:50.256275887+00:00 }=-

    Hey August!

    official point system,...

    What system is that?

    This one. It is a direct link to the Netherlands and is running on it's very own system via binkd. I like it very much despite it having the slowest cpu with the least amount of cores available to it.

    As far as MSGID is concerned the 8 hex character unixtime based output without any extras is good enough given that the MSGID is created whenever I create a MSG. No robotized MSG creation so collisions are unlikely and the 8 character hex unixtime as is has a shelf life up to 2106. Mind you there is nothing in my code that will prevent it from creating a 9 digit hex unixtime when the time comes but I won't be around to witness it.

    Also note the first line of the msg_body displays the rfc-3339 in nanoseconds and that is also available to me on this system for potential forwards compatibilty purposes.

    Also, also tonight when all the neighbours are in bed a reboot of the new gcc-10.3.0 based x86_64-motorshed-linux-gnu custom built for this machine will happen. I have to wait until then because it also acts as an access point to the internet for them.

    Life is good,
    Maurice

    ... Gewurdene wyrda, ðæt beoð ða feowere fæges rapas.
    Things which have happened: those are the four ropes of the doomed.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)
  • From Maurice Kinal@1:153/7001 to Wilfred van Velzen on Thu Apr 15 22:55:42 2021
    -={ 2021-04-15 22:55:42.015459666+00:00 }=-

    Hey Wilfred!

    Yet you viciously mention it...

    I call that therapy.

    Life is good,
    Maurice

    ... Monig biþ uncuþ treowgeþofta, teorað hwilum.
    Many a trusted friend will prove to be unknown, will fail at times.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From August Abolins@2:221/1.58 to Maurice Kinal on Thu Apr 15 20:38:00 2021
    Hello Maurice Kinal!

    ** On -={ 2021-04-15 22:55:42.015459666+00:00 }=-
    Maurice wrote to Wilfred..

    Yet you viciously mention it...

    I call that therapy.

    For whom? You, or Wilfred? :D

    --
    ../|ug

    --- OpenXP 5.0.49
    * Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)
  • From Maurice Kinal@2:280/464.113 to August Abolins on Fri Apr 16 01:06:54 2021
    -={ 2021-04-16 01:06:54.788566075+00:00 }=-

    Hey August!

    I call that therapy.

    For whom? You, or Wilfred? :D

    Hm. Maybe if I call it shock therapy it could cover both.

    Life is good,
    Maurice

    ... Cræfta gehwilc byþ cealde forgolden.
    Every deceit will be coldly repaid.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)
  • From August Abolins@2:221/1.58 to Maurice Kinal on Sat Apr 17 09:08:00 2021
    Hello Maurice Kinal!

    ** On { 2021-04-15 02:43:02.687523938+00:00 }, Maurice Kinal wrote to August Abolins:

    The ftsc write-ups could serve as a guidebook for
    solutions and examples and help remove ambiguity and false
    interpretations.

    FTA-1006 might be of interest to you wrt the subject at hand.

    But even that one "expired" twenty years ago. :( So.. is it
    valid today or not? :/

    --
    ../|ug

    --- OpenXP 5.0.49
    * Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)
  • From Maurice Kinal@1:153/7001 to August Abolins on Sat Apr 17 15:07:00 2021
    -={ 2021-04-17 15:07:00.446466642+00:00 }=-

    Hey August!

    But even that one "expired" twenty years ago. :( So.. is it
    valid today or not? :/

    As valid as any of the other ones. I think if there is a bone to pick with any document the FTSC_PUBLIC echo would be the place to start. Speaking for myself (all three of me) this conversation in this particular echoarea was a very good warmup for what could transpire if anyone were seriously considering a needed change. I still believe it could happen.

    Life is good,
    Maurice

    ... Ðys dogor þu geþyld hafa weana gehwylces.
    This day, have patience in every affliction.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From August Abolins@1:153/757.2 to Maurice Kinal on Sat Apr 17 09:12:25 2021
    As valid as any of the other ones. I think if
    there is a bone to pick with any document the
    FTSC_PUBLIC echo would be the place to start.

    I have highlighted a few clerical flubs in the recent past in there.

    Speaking for myself (all three of me) this
    conversation in this particular echoarea was a
    very good warmup for what could transpire if
    anyone were seriously considering a needed
    change. I still believe it could happen.

    With formal elections taking place, and 10 people at the helm, you'd think at least someone could fix a simple spelling mistake. :(
    --- SBBSecho 3.14-Linux
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757.2)
  • From Maurice Kinal@1:153/7001 to August Abolins on Sun Apr 18 03:18:23 2021
    -={ 2021-04-18 03:18:23.453963889+00:00 }=-

    Hey August!

    I have highlighted a few clerical flubs in the recent past in
    there.

    The nodal me thinks we have bigger fish to fry.

    and 10 people at the helm

    There's a helm?!?!?!?!

    Life is good,
    Maurice

    ... Ich habe Eichhörnchen in meiner Hose!
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From August Abolins@2:221/1.58 to Maurice Kinal on Sun Apr 18 08:36:00 2021
    Hello Maurice!

    ** On -={ 2021-04-18 03:18:23.453963889+00:00 }=- you wrote:

    The nodal me thinks we have bigger fish to fry.
    ^^^^^^^^^^^^^^^^^^

    and 10 people at the helm

    There's a helm?!?!?!?!

    Ok.. kitchen. Cooks in the kitchen. And only because you
    mentioned nodals (sic), noodles.

    --
    ../|ug

    --- OpenXP 5.0.49
    * Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)
  • From Maurice Kinal@1:153/7001 to August Abolins on Sun Apr 18 14:03:26 2021
    -={ 2021-04-18 14:03:26.305578442+00:00 }=-

    Hey August!

    The nodal me thinks we have bigger fish to fry.
    ^^^^^^^^^^^^^^^^^^
    and 10 people at the helm

    There's a helm?!?!?!?!

    Ok.. kitchen. Cooks in the kitchen. And only because you
    mentioned nodals (sic), noodles.

    I think rice goes better with fish.

    Life is good,
    Maurice

    ... Wel mon sceal wine healdan on wega gehwylcum.
    One does well to keep a friend on every road.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From August Abolins@2:221/1.58 to Maurice Kinal on Sun Apr 18 11:01:00 2021
    Hello Maurice!

    ** On Sunday 18.04.21 - 14:03, you wrote to me:

    The nodal me thinks we have bigger fish to fry.
    ^^^^^ ^^^^^^^^^^^^^^^^^^
    and 10 people at the helm

    There's a helm?!?!?!?!

    Ok.. kitchen. Cooks in the kitchen. And only because you
    mentioned nodals (sic), noodles.

    I think rice goes better with fish.

    Ok. The menu of savoury delights exists: FTS-XXXX, FTP-XXXX
    ..now get er done! <g>

    --
    ../|ug

    --- OpenXP 5.0.49
    * Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)
  • From Maurice Kinal@1:153/7001 to August Abolins on Sun Apr 18 22:57:13 2021
    -={ 2021-04-18 22:57:13.202960062+00:00 }=-

    Hey August!

    Ok. The menu of savoury delights exists: FTS-XXXX, FTP-XXXX
    ..now get er done! <g>

    I am the chief cook and bottle washer?

    I've been rethinking the rfc-3339 idea. Also spring cleaning (the weather has been fantastic the last week) and the second in the series of three x86_64-motorshed-linux-gnu upgrades. Maybe by the end of the week.

    Is there any item of interest to you?

    Life is good,
    Maurice

    ... Ne sceall se for horse murnan, se þe wile heort ofærnan.
    He who wants to catch a hart must not worry about his horse.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From August Abolins@2:221/1.58 to Maurice Kinal on Mon Apr 19 19:28:00 2021
    Hello Maurice!

    ** On Sunday 18.04.21 - 22:57, you wrote to me:

    I've been rethinking the rfc-3339 idea. Also spring
    cleaning (the weather has been fantastic the last week) and
    the second in the series of three x86_64-motorshed-linux-
    gnu upgrades. Maybe by the end of the week.

    This is my view as I take a glance above the laptop.

    https://photos.kolico.ca/tmp/window-IMG_20210418.jpg

    I think it was about 10 years since I touched that window. But
    I have symbiotic relationship with spiders inside and outside
    the house.

    Is there any item of interest to you?

    Not sure. It seems that you have some fine priority ideas.

    Based on MvdV's quick write-up it doesn't seem hard to get
    something started.


    --
    ../|ug

    --- OpenXP 5.0.49
    * Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)
  • From Maurice Kinal@1:153/7001 to August Abolins on Mon Apr 19 23:45:56 2021
    -={ 2021-04-19 23:45:56.368925895+00:00 }=-

    Hey August!

    This is my view as I take a glance above the laptop.

    That is a nice view, other than the window that is. ;-)

    Not sure. It seems that you have some fine priority ideas.

    I think so except a tad too radical for fidonet despite the fact that a simple update to the packed MSG header's datetime field only brings us up to date to 1989 standards. However it isn't obsolete ... yet. (YYYY-MM-DD hh:mm:ss(+|-)utc_offset). If the (+|-)utc_offset is dropped then the remainder fits in EXACTLY in the field specified for the DateTime field so it is attractive given that. However that is still too radical for the abandonware crowd who are being used as an excuse even though it is debatable whether or not these particular nodelisted sysops actually exist. Anytime I have asked for evidence I've been ignored ... or worse ... and then ignored. I don't actually mind since I've managed to survive it all as well as come up with suitable fixes to make it all work at my end of things.

    My personal favorite is the hex output of unixtime seconds-nanoseconds but moreso as a unique serialno such as used in MSGID/REPLY kludges. However I personally don't want to screw with that particular document especially considering how embedded it has become in fidonet MSGing. Also given that I have a fix that is good up to 2106 takes the heat off of any need to alter or replace fts-0009.001. Some clarification on what constitutes an origAddr would be helpful. As far as your suggestion for a 8 character serial number I believe it is already covered and is to it's favour although there are still those who will argue that point. Isn't that always the case?

    Life is good,
    Maurice

    ... Eaðe wis man mæg witan spell and eac secgan.
    Easily may a wise man understand a story, and tell it too.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From August Abolins@2:221/1.58 to Maurice Kinal on Tue Apr 20 09:04:00 2021
    Hello Maurice!

    ** On Monday 19.04.21 - 23:45, you wrote to me:

    This is my view as I take a glance above the laptop.

    That is a nice view, other than the window that is. ;-)

    My house has 14 windows + a glass sliding door and clear glass
    panels (about 18' high) surrounding the front door - and that's
    just on the upper level of the split-level home. There are 7
    more windows and another sliding door on the lower level. I
    used to be the one motivated to clean them every spring. Now,
    not so much. But I might tackle the one in the picture - before
    the blackflies emerge.

    (YYYY-MM-DD hh:mm:ss(+|-)utc_offset). If the
    (+|-)utc_offset is dropped then the remainder fits in
    EXACTLY in the field specified..

    My personal favorite is the hex output of unixtime seconds-
    nanoseconds but moreso as a unique serialno such as used in
    MSGID/REPLY kludges. However I personally don't want to
    screw with that particular document especially considering
    how embedded it has become in fidonet MSGing.

    Whatever direction you take, feel free to announce any advances
    and progress in FUTURE4FIDO (F4F). I would assume that most of
    the time discussion of any advances/changes are limited to
    echoes that are specific to particular BBS software. So,
    development news is scattered all over the place. But some
    tech-types lurk in F4F. I try to post newsworthy things that I
    might come across.
    --
    ../|ug

    --- OpenXP 5.0.49
    * Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)
  • From Maurice Kinal@1:153/7001 to August Abolins on Tue Apr 20 19:12:23 2021
    -={ 2021-04-20 19:12:23.425811071+00:00 }=-

    Hey August!

    But I might tackle the one in the picture - before the
    blackflies emerge.

    Those things are pure evil.

    Whatever direction you take, feel free to announce any advances
    and progress in FUTURE4FIDO (F4F).

    I'll have a looksee later as I am keeping a close eye on the two out of three upgrades I just 'finished' (<- yeah right). The third one should go rather quick now that I have the two slower ones out of the way. So far none of the neighbours have shown up carrying torches and pitchforks so I think the wireless hotspots are as hot as they ever were, possibly a tad warmer. Other than a quick test I haven't actually used that end of things lately. I do have a 10" tablet with binkd client running in a termux shell, just like mom used to do. It's fairly frugal at the moment but it can do fidonet MSGing as I have tested it before. Unfortunetly no gcc/glibc on there so I am going to have to come up with a better way to develop on that platform than currently exists (clang) or just use pure bash scripts which is what I was doing on there the last I used it ... other than binkd which was compiled on there using the native clang.

    Always something to do if one cares to. :-)

    Life is good,
    Maurice

    ... Winter sceal geweorpan, weder eft cuman, sumor swegle hat.
    Winter shall turn, good weather come again, summer, bright and hot.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Carol Shenkenberger@1:275/100 to Maurice Kinal on Sat Apr 24 15:16:34 2021
    Re: anyway the wind blows
    By: Maurice Kinal to August Abolins on Sun Apr 18 2021 02:03 pm

    -={ 2021-04-18 14:03:26.305578442+00:00 }=-

    Hey August!

    The nodal me thinks we have bigger fish to fry.
    ^^^^^^^^^^^^^^^^^^
    and 10 people at the helm

    There's a helm?!?!?!?!

    Ok.. kitchen. Cooks in the kitchen. And only because you
    mentioned nodals (sic), noodles.

    I think rice goes better with fish.

    Life is good,
    Maurice

    ... Wel mon sceal wine healdan on wega gehwylcum.
    One does well to keep a friend on every road.

    LOL! Sometimes!

    If fish is the primary item, then yes. If it is secondary, it may be added to a noodle bowl.

    --- SBBSecho 2.11-Win32
    * Origin: SHENK'S EXPRESS, shenks.synchro.net (1:275/100)
  • From Maurice Kinal@1:153/7001 to Carol Shenkenberger on Sun Apr 25 14:21:39 2021
    -={ 2021-04-25 14:21:39.573006446+00:00 }=-

    Hey Carol!

    If fish is the primary item, then yes.

    It is a very big fish which in itself makes it primary.

    If it is secondary, it may be added to a noodle bowl.

    Speaking for myself, I think pork goes best with noodles.

    Life is good,
    Maurice

    ... Heald hordlocan, hyge fæste bind mid modsefan.
    Hold close the treasure-chest, bind your thoughts fast within the heart. --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Carol Shenkenberger@1:275/100 to Maurice Kinal on Tue May 11 20:29:42 2021
    Re: anyway the wind blows
    By: Maurice Kinal to Carol Shenkenberger on Sun Apr 25 2021 02:21 pm

    -={ 2021-04-25 14:21:39.573006446+00:00 }=-

    Hey Carol!

    If fish is the primary item, then yes.

    It is a very big fish which in itself makes it primary.

    If it is secondary, it may be added to a noodle bowl.

    Speaking for myself, I think pork goes best with noodles.

    Life is good,
    Maurice

    ... Heald hordlocan, hyge fæste bind mid modsefan.
    Hold close the treasure-chest, bind your thoughts fast within the heart.

    Both go well with noodle bowls!

    xxcarol
    --- SBBSecho 2.11-Win32
    * Origin: SHENK'S EXPRESS, shenks.synchro.net (1:275/100)
  • From Maurice Kinal@1:153/7001 to Carol Shenkenberger on Fri May 14 17:32:53 2021
    -={ 2021-05-14 17:32:53.410791492+00:00 }=-

    Hey Carol!

    Both go well with noodle bowls!

    Both is good except not at the same time although to be honest I've never tried them together.

    Life is good,
    Maurice

    ... Æt þearfe mann sceal freonda to cunnian.
    In time of need, a man finds out his friends.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Tim Schattkowsky@2:240/1120.29 to August Abolins on Thu Nov 18 22:16:20 2021
    //Hallo August, //

    am *15.04.21* um *13:31:00* schriebst Du in der Area *ASIAN_LINK*
    an *Wilfred van Velzen* eine Mail zum
    Thema *"anyway the wind blows"*.

    It seems to be a problem for WinPoint when building a
    reply message. The REPLYID seems to result in 00000000.

    Probably true.

    So that is the first discovered problem. There are probably more. And
    probably harder to discover...

    I may have to spin up my Winpoint to see for myself. But apparently Winpoint is getting new life in development and the
    uber msgid could be accomodated. :D

    Will put it on the list, but with lower prio. Hasnt been an issue for a loooong time ...

    Bis denne ...
    Tim Schattkowsky
    --- WinPoint 376.2
    * Origin: Original WinPoint Origin! (2:240/1120.29)
  • From Tim Schattkowsky@2:240/1120.29 to Maurice Kinal on Fri Nov 19 16:40:12 2021
    //Hallo Maurice, //

    am *13.04.21* um *21:15:41* schriebst Du in der Area *ASIAN_LINK*
    an *August Abolins* eine Mail zum
    Thema *"anyway the wind blows"*.

    AREA:ASIAN_LINK
    @RESCANNED 2:240/1120
    @REPLY: 2:221/1.58@fidonet ef616eac
    @MSGID: 1:153/7001 sTW6u3OA
    @CHRS: UTF-8 4
    -={ 2021-04-13 21:15:41.032014984+00:00 }=-

    Test reply to see if WP now handles those invalid MSGID values nicer ;)

    Bis denne ...
    Tim Schattkowsky
    --- WinPoint 377.0
    * Origin: Original WinPoint Origin! (2:240/1120.29)
  • From Maurice Kinal@1:153/7001.2989 to Tim Schattkowsky on Fri Nov 19 15:29:06 2021
    Hey Tim!

    Test reply to see if WP now handles those invalid MSGID values
    nicer ;)

    "1:153/7001 sTW6u3OA" are both valid values for address and serialno.

    When quoting kludges you should replace the 0x01 prefix with the @ character.

    Thank you for the heads up. :-)

    Life is good,
    Maurice

    ... damned if you do ... damned if you don't ... so go to hell.
    --- GNU bash, version 5.1.8(1)-release (x86_64-moosile-linux-gnu)
    * Origin: More of us @ (1:153/7001.2989)