Hi g00r00

I've started taking a feed from Hub 3 as well as Hub 2, and I've noticed that I'm getting a duplicate message from 3/101 - but its not being tagged as duplicate because the content has been changed along the way.

(Is anybody else sending duplicates from Spectre?)

So here is some info:
Message from Spectre on Hub 3:
X-FTN-PATH 3/101
Message-ID <5E6855D3.9345.fsx_gen@dev.bbs.leenooks.net>
when_written 5E684BFC 0294 Wed Mar 11 2020 01:25 pm UTC+11:00
when_imported 5E6855D3 9258 Wed Mar 11 2020 02:06 pm AEDT
data field[0] TEXT_BODY, offset 0, length 277
data field[1] TEXT_TAIL, offset 277, length 94

Message from Spectre from Hub 3:
X-FTN-PATH 3/101 100
Message-ID <5E6855DD.32625.fsx_gen@bbs.leenooks.net>
when_written 5E684BFC 0294 Wed Mar 11 2020 01:25 pm UTC+11:00
when_imported 5E6855DD 9258 Wed Mar 11 2020 02:07 pm AEDT
data field[0] TEXT_BODY, offset 0, length 277
data field[1] TEXT_TAIL, offset 277, length 94

Message from Spectre from Hub 2:
X-FTN-PATH 3/101 100 2/100
Message-ID <5E6855FB.32626.fsx_gen@bbs.leenooks.net>
when_written 5E684BFC 0294 Wed Mar 11 2020 01:25 pm UTC+11:00
when_imported 5E6855FB 9258 Wed Mar 11 2020 02:07 pm AEDT
data field[0] TEXT_BODY, offset 0, length 272
data field[1] TEXT_TAIL, offset 272, length 94

The message is subject "Altered Carbon" from Spectre to "Anybody", dated Mar 11, 2020 01:25pm (UTC+11).

You'll notice that the message from Hub 2 is 5 chars smaller than it is on the Hub 3 (and the message as I received it from Hub 3).

Why are 5 chars missing? I'm suspecting its those soft-cr's, but happy to give you a hex dump of the messages if that helps.
...deon


... Professionals build the Titanic, amateurs built the Ark.
--- SBBSecho 3.10-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

Hello alter,

Hi g00r00

I've started taking a feed from Hub 3 as well as Hub 2, and I've
noticed that I'm getting a duplicate message from 3/101 - but its not being tagged as duplicate because the content has been changed along
the way.

(Is anybody else sending duplicates from Spectre?)

Yes, I see that too.. I noticed a couple of them today.

It has something to do with his soft CRs I think. They get stripped when they get tossed by mystic (the soft CRs) and make the rounds agian (AFAICT).

Ttyl :-),
Al

--- GoldED+/LNX 1.1.5-b20180707
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)

I've started taking a feed from Hub 3 as well as Hub 2, and I've noticed that I'm getting a duplicate message from 3/101 - but its not being
tagged as duplicate because the content has been changed along the way.

(Is anybody else sending duplicates from Spectre?)

Yes I think I have seen a couple of dupes from him show up in my dupe base.

As far as the rest, I can't really comment on it. Messages that pass through a Mystic hub will be the same every time they pass through. You shouldn't have multiple uplinks sending you the same echomail base.

Since I don't have the data you have, I can't really dig into it but you can email me specific findings to mysticbbs@gmail.com or Netmail me on FSX if
you'd like!

--- Mystic BBS v1.12 A46 2020/03/10 (Windows/64)
* Origin: Sector 7 (21:1/108)

On 12 Mar 2020, g00r00 said the following...

through a Mystic hub will be the same every time they pass through. You shouldn't have multiple uplinks sending you the same echomail base.

That's something that's been talked about experimenting with and is currently going on in Fido, particularly in Europe. Multiple redundant feeds.

-=>Richard Miles<=-
-=>Captain Obvious<=-
-=>bbs.shadowscope.com<=-

--- Mystic BBS v1.12 A46 2020/03/07 (Windows/32)
* Origin: Shadowscope BBS | bbs.shadowscope.com | Temple, GA (21:1/157)

through a Mystic hub will be the same every time they pass through. shouldn't have multiple uplinks sending you the same echomail base.

That's something that's been talked about experimenting with and is currently going on in Fido, particularly in Europe. Multiple redundant feeds.

Well its not part of how FIDO was created and you may see a lot of issues depending on the software you're using.

Different processors can handle different things. Some software like GT Power screw up the date field format that will ruin anything that uses CRC checks involving the date field (Mystic will fix this issue before tossing it others may not too) others truncate at 79, 255, 1024 characters or not at all.

So if you're doing that the tossers have to be the same or compatible, and it will absolutely not work with some legacy stuff. I can always update Mystic for that but others will never be updated.

--- Mystic BBS v1.12 A46 2020/03/12 (Windows/64)
* Origin: Sector 7 (21:1/108)

Re: Re: Message mangling?
By: g00r00 to alter ego on Thu Mar 12 2020 12:57 am

Since I don't have the data you have, I can't really dig into it but you can email me specific findings to mysticbbs@gmail.com or Netmail me on FSX if you'd like!

I'll see if I can get some actual packets so that we can truely compare what is
sent and received.

Since 3/101 sends to 3/100 (Synchronet) - I'll capture the packet as its received.

Then from 3/100, I'll capture what is sent to 2/100 (Mystic) and then we'll be able to compare that to what 2/116 receives from it.

But to confirm, I think in the past folks did some diagnoses, and it seemed to be Soft CRs were modified on the way - and the believe was that Mystic was stripping them.

As far as the rest, I can't really comment on it. Messages that pass through a Mystic hub will be the same every time they pass through. You

So - you dont change any messages with Soft CRs?
...deon


... The only good government.is a bad one in a hell of a fright.
--- SBBSecho 3.10-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

Re: Re: Message mangling?
By: g00r00 to Captain Obvious on Thu Mar 12 2020 12:15 pm

Well its not part of how FIDO was created and you may see a lot of issues depending on the software you're using.

But in theory you shouldnt though right?

I thought a fundamental rule was that mail passing through a system is not modified (except for adding to SEEN-BY and PATH)?
...deon


... Always forgive your enemies - nothing else annoys them as much.
--- SBBSecho 3.10-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

But to confirm, I think in the past folks did some diagnoses, and it seemed to be Soft CRs were modified on the way - and the believe was
that Mystic was stripping them.

So - you dont change any messages with Soft CRs?

This has been convered here a lot of times, recently.

Don't worry about sending the packets.

As I've explained though, that what you're attempting to do is outside of the scale of Fidonet and it will be broken often times depending on what systems
it will pass through.

--- Mystic BBS v1.12 A46 2020/03/12 (Windows/64)
* Origin: Sector 7 (21:1/108)

Re: Re: Message mangling?
By: g00r00 to alterego on Thu Mar 12 2020 07:29 pm

So - you dont change any messages with Soft CRs?

This has been convered here a lot of times, recently.

It was discussed, but I dont recall the conclusion - can you reshare it, or somebody - I'm curios...

As I've explained though, that what you're attempting to do is outside of the scale of Fidonet and it will be broken often times depending on what systems it will pass through.

Is it? I actually didnt think it was, and it was actively used in a Fidonet.

Anyway, the goal here is redundancy, and I think its not unreasonable to aim for it. Do you have a different view?

Why cant we make our BBS systems interoperate this way? I would think it would be awesome, if we can source messages from more than 1 place - so that any impacts of a system being down are unnoticed.
...deon


... The only tool diplomacy has is language. Hodin of Gideon, stardate 5423.4. --- SBBSecho 3.10-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

Hello alterego,

I thought a fundamental rule was that mail passing through a system is
not modified (except for adding to SEEN-BY and PATH)?

That is right. Many things are going to take the wonky train if things are changed in transit.

Ttyl :-),
Al

--- GoldED+/LNX
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)

Anyway, the goal here is redundancy, and I think its not unreasonable to aim for it. Do you have a different view?

I think redundancy is a good idea, I just don't think this approach is the
best way for a lot of what I consider to be good reasons. I have had plans
in the works for the past 1-2 years to address all of these things and more
in a meaningful way, unfortunately it has moved rather slow due to life.

I'll try to give you some more detail about all of it in the future its just that I am sort of pressed or time and I don't want to spend it rehashing this stuff at the moment rather than actually spending time working on things.

Not trying to be an ass even though it might come off that way, I just don't want to get caught up doing a lot of talking and not any progression over the next few days.

--- Mystic BBS v1.12 A46 2020/03/12 (Windows/64)
* Origin: Sector 7 (21:1/108)

I thought a fundamental rule was that mail passing through a system i not modified (except for adding to SEEN-BY and PATH)?

That is right. Many things are going to take the wonky train if things
are changed in transit.

CC: Alterego

I'll try to explain some of my take on this since Alterego was also inquiring but I don't want to get into spending hours of wasted time on this crap as I get so caught up in talking that nothing ever gets done lately (and its
getting frustrating to me). Anyway...

[snip]

Yes, but yet it has happened this way for the entirity of FidoNet.

Look at the constant rescan regurgitation that we've seen over the years of thousands of messages because rescans can't reproduce the same message they sent downstream the first time (well, Mystic can but others don't).

It just happened a couple of weeks ago.

Others truncate at 79 characters, 255 characters and 1024 characters, or don't at all. Some have bugs that change date fields or other fields mistakenly that change the CRC values.

This is the whole reason this approach to "redundancy" is not a strong one.

In order to make this actually work in a good way, a layer on top of the existing FTN needs to be put in place and that has to have strict standards for how messages are sent and stored and they must be able to reproduce the original message at all times on any system that supports the layer. New software can use this layer for redundancy in a peer-to-peer fashion with having to deal with old software that will break it.

You can't go back and change the legacy software that doesn't do exactly what you want, and even existing software is guilty of changing content. Mystic for example changes it up front, correcting common software bugs and wrapping it so content isn't lost on legacy systems. Its then stored in a way that Mystic can reproduce the original message that passed through *at any time*, meaning you can get a stream of original messages and do a rescan and they will caught as dupes by EVERY downlink. The price of that is slight "fixes" to data on the front load but it has saved thousands of shit dupe dumps too.

Other systems send it raw to the downlink, but when a rescan happens the content is changed (either unintentially or intentionally) and we end up with the constant reguritation of shit into the network because of it. We've seen this happen time and time again, most recently a few weeks ago. It doesn't happen with Mystic because of what it does. And this is actually a real problem that we've seen many times, and solution to it.

The "problem" being brought up here isn't one if you use FidoNet by its intended topology, its a "self created" issue and is something that never happens unless you make it. However, the issue with the rescan happens regularly enough that its a legit use case that could use a solution.

Neither way is right.

A new well defined layer can sit on FTN and be compatible and offer the solution to *both* of the issues I've mentioned. Paul and I have been (slowly) working on this for the past 2 years (far less since I was afk for 8 months).

It not only (in theory because its not fully functional) handles that but a whole bunch of other things that make everything much better, and its fully backwards compatible. This is the real way things need to be done to successfully fix some of the current limitations we have today in my opinion without alienating old software or introducing risk by allowing them.

Sure the remaining active authors can get on the same page and that will be a good step (and I understand why its brought up here) but it needs to be done on both ends (toss and rescan), and it won't address the fact that there will always be some people using legacy systems that mess it up (although honestly thats much less than it used to be).

You guys cry foul because Mystic fixes issues on the front load and ignore
the fact that the software you might be championing can't rescan without creating an entirely new range of messages causing DupeGate 2015, 2016, 2017, 2018, 2020, etc.

There needs to be an effort to make things right for the right reasons (not saying you aren't about the right reasons Al so thats not directed towars you, but others sure as hell have obvious intentions to cause shit not to actually create something functional).

--- Mystic BBS v1.12 A46 2020/03/12 (Windows/64)
* Origin: Sector 7 (21:1/108)

Hello g00r00,

Look at the constant rescan regurgitation that we've seen over the
years of thousands of messages because rescans can't reproduce the
same message they sent downstream the first time (well, Mystic can but others don't).

Those quarterly rescans are just ugly. If we can understand the problem we can get to the solution.

Others truncate at 79 characters, 255 characters and 1024 characters,
or don't at all. Some have bugs that change date fields or other
fields mistakenly that change the CRC values.

Not all software was written with longevity in mind. A lot of software has been
written to get the job done in the here and now without thinking about the future or how this or that will affect other nodes on the network.

This is the whole reason this approach to "redundancy" is not a strong one.

I wasn't thinking about redundency. My comment was simply about changing content in transit. Mail shouldn't change in transit for many reasons.

In order to make this actually work in a good way, a layer on top of
the existing FTN needs to be put in place and that has to have strict standards for how messages are sent and stored and they must be able
to reproduce the original message at all times on any system that
supports the layer. New software can use this layer for redundancy in
a peer-to-peer fashion with having to deal with old software that will break it.

I wasn't sure but this makes clear your intentions.

You guys cry foul because Mystic fixes issues on the front load and
ignore the fact that the software you might be championing can't
rescan without creating an entirely new range of messages causing
DupeGate 2015, 2016, 2017, 2018, 2020, etc.

Indeed, Mystic doing the wrong thing trying to do the right thing.

Is it possible when implementing this layer on top of FTN that you mention, that it can work on the Fido side as expected, not changing mail in transit?

There needs to be an effort to make things right for the right reasons (not saying you aren't about the right reasons Al so thats not
directed towars you, but others sure as hell have obvious intentions
to cause shit not to actually create something functional).

I hope this doesn't come off as against the idea of a layer on top of FTN. It's
not meant as such. I don't have enough info to be for or against it.

Ttyl :-),
Al

--- GoldED+/LNX 1.1.5-b20180707
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)

On 12 Mar 2020, alterego said the following...

Why cant we make our BBS systems interoperate this way? I would think it would be awesome, if we can source messages from more than 1 place - so that any impacts of a system being down are unnoticed.

We can, and have been doing so for probably about 3-4 years now I believe.
All we're doing in Fidonet is linking to multiple systems for the same echos, and letting the dupe checkers take care of the extra messages. Basically the message that arrives on your system first is the one that you process. You'll receive that same message from every other system you're linked to for said echo but the dupe checker will take care of all of the extras.

This idea was specifically done for Fidonet because some people (hubs) were letting power get to their heads, and deciding themselves which messages were going to their downlinks, and which were not. Some of us decided to work around that, and make sure this couldn't be done ever again. Needless to say most of those who were guilty of trying to play God have stepped down from their positions and/or have become a lot less significant.

Anyway, this is not how FSXnet operates; nor does it need to. Avon has a
great handle on things and FSX seems to be even more active than Fidonet now, with about 99.9% less drama.

Accession

--- Mystic BBS v1.12 A46 2020/02/29 (Linux/64)
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (21:1/200)

On 13 Mar 2020, g00r00 said the following...

Not trying to be an ass even though it might come off that way, I just don't want to get caught up doing a lot of talking and not any
progression over the next few days.

For some reason, I just pictured you wearing a ventilated dust mask, with a roll of toilet paper on your desk besides your keyboard, while announcing another prealpha! ;)

Accession

--- Mystic BBS v1.12 A46 2020/02/29 (Linux/64)
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (21:1/200)

On 13 Mar 2020, g00r00 said the following...

There needs to be an effort to make things right for the right reasons (not saying you aren't about the right reasons Al so thats not directed towars you, but others sure as hell have obvious intentions to cause
shit not to actually create something functional).

To be fair, the 'others' had obvious intentions to block at least half of the world from a very popular (at the time) echo. We created what we did to
bypass that and make those offending systems less relied upon. It worked, and it can never happen again.

Now then, is it needed anywhere else? Nope. ;)

Accession

--- Mystic BBS v1.12 A46 2020/02/29 (Linux/64)
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (21:1/200)

On 14 Mar 2020, Accession said the following...

--- Mystic BBS v1.12 A46 2020/02/29 (Linux/64)
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (21:1/200)

Just making sure I'm up to date. ;)

Accession

--- Mystic BBS v1.12 A46 2020/03/11 (Linux/64)
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (21:1/200)

For some reason, I just pictured you wearing a ventilated dust mask,
with a roll of toilet paper on your desk besides your keyboard, while announcing another prealpha! ;)

Thats not all that inaccurate lol

--- Mystic BBS v1.12 A46 2020/03/15 (Windows/64)
* Origin: Sector 7 (21:1/108)

On 15 Mar 2020 at 06:56a, g00r00 pondered and said...

For some reason, I just pictured you wearing a ventilated dust mask, with a roll of toilet paper on your desk besides your keyboard, while announcing another prealpha! ;)

Thats not all that inaccurate lol

This borders on TMI :)

--- Mystic BBS v1.12 A46 2020/03/12 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Re: Message mangling?
By: Accession to alterego on Sat Mar 14 2020 08:09 am

We can, and have been doing so for probably about 3-4 years now I believe.

I think your response has not taken into the full thread.

Anyway, this is not how FSXnet operates; nor does it need to. Avon has a

It is how it is operating, and the Hubs are meshing so that messages sent to any Hub 1,2,3,4 are also sent to any other Hub 1,2,3,4. So Hub 1 is not the top
of the tree - if it were down, messages would still flow between 2,3,4.

My question was in response to g00r00's comment - because it appears that Mystic is modifying message in transit, resulting in the non-Mystic systems getting duplicates (when those systems have more than 1 uplink). He has a specific view on why it is doing that, and it seems like the result of that is why we're seeing the duplicates.

I'd like to see it fixed, but I'd also like to see how he could achieve his goal at the same time..
...deon


... Mistrust first impulses, they are always good.
--- SBBSecho 3.10-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

On 15 Mar 2020, alterego said the following...

We can, and have been doing so for probably about 3-4 years now I bel

I think your response has not taken into the full thread.

That's very possible. I logged in to like 800 new messages, so jumped ahead quite a bit. ;)

Anyway, this is not how FSXnet operates; nor does it need to. Avon ha

It is how it is operating, and the Hubs are meshing so that messages
sent to any Hub 1,2,3,4 are also sent to any other Hub 1,2,3,4. So Hub 1 is not the top of the tree - if it were down, messages would still flow between 2,3,4.

If I remember correctly, most of these hubs you speak of are run by the same guy (Avon). He may have picked up some help on the workload that I'm unaware of, though. So while it is somewhat a similar operation (only the mesh part, and that entire mesh is still top of the tree). It was being compared to Fidonet, in which the mesh is somewhere in the middle of the tree. But now
that I have focused more on your points here, a mesh network is still a mesh network no matter where it is. ;)

I'd like to see it fixed, but I'd also like to see how he could achieve his goal at the same time..

I don't think it's possible to do both, to be honest. There are other BBS softwares out there that create out of spec messages. If you "fix" these messages anywhere in a mesh type network, there will always be false duplicates, as most software's dupe checkers consider it a completely new message even if a small header string most people don't even see is altered. Even if said original message was passed on, and the "fixed" message was
stored locally, I would assume it would still break threading and whatnot
when the "fixed" message is replied to.

Accession

--- Mystic BBS v1.12 A46 2020/03/11 (Linux/64)
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (21:1/200)

Re: Message mangling?
By: Accession to alterego on Sun Mar 15 2020 08:39 am

I don't think it's possible to do both, to be honest. There are other BBS softwares out there that create out of spec messages. If you "fix" these messages anywhere in a mesh type network, there will always be false duplicates, as most software's dupe checkers consider it a completely new message even if a small header string most people don't even see is

That's my point exactly. You DONT fix messages - when passing them on.

I get it may be desirable to fix messages so they render nicely locally - but when in transit you leave them as is.

This approach, IMHO, should work with both modern and legacy BBS software.

g00r00's goal is that when you "rescan" the messages, you get them exactly as they were when first sent - this is a great goal - but to achieve it, you need to store the original message as received (and therefor unmodified). I dont think Mystic is achieving this, because if (as per how this thread started), if
3/100 sends a message to 2/100 with Soft-CRs in it, and rescanned it back, would it still have those Soft-CRs in it? I'm guessing not (because, when 2/100
forwards it on they dont.)
...deon


... An independent is a guy who wants to take the politics out of politics.
--- SBBSecho 3.10-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

I get it may be desirable to fix messages so they render nicely locally
- but when in transit you leave them as is.

It has nothing to do with "render nicely locally" as I have explained countless times here. There is no reason to discuss any of this further when you just ignore what is said and inject whatever it is that you want to.

It stops the flood of thousands of message rescans we've seen happen here (as we just saw happen two weeks ago) and it solves a MUCH bigger problem than your self-created issue by using a topology not intended to be used in FidoNet.

It also wraps text for legacy software that literally LOSES MESSAGE CONTENT if you don't provide data in a way they can read it. Since Mystic was traditionally used with a lot of of Forum/TG hacks it makes a lot of sense why a Mystic hub might want their downlinks to get complete messages.

I've already adressed this no less than 4 or 5 times in the last two months which I know you've seen. And I've made clear my plans in the past.

Your philosophy of anything is off topic here and you've said what you need to have said. Either drop it and move on, or leave as you don't even use Mystic to begin with.

--- Mystic BBS v1.12 A46 2020/03/15 (Windows/64)
* Origin: Sector 7 (21:1/108)

I get it may be desirable to fix messages so they render nicely locally
- but when in transit you leave them as is.

As my final follow up to this:

http://ftsc.org/docs/fts-0001.016

To be very clear, below is what FTS-0001 says on Message Text. And your argument is that Mystic is incorrectly ignoring 8DH and 0AH when the FTS-0001 very specifically says they should be ignored.

Message Text

Message text is unbounded and null terminated (note exception below).

A 'hard' carriage return, 0DH, marks the end of a paragraph, and must
be preserved.

So called 'soft' carriage returns, 8DH, may mark a previous
processor's automatic line wrap, and should be ignored. Beware that
they may be followed by linefeeds, or may not.

All linefeeds, 0AH, should be ignored. Systems which display message
text should wrap long lines to suit their application.

--- Mystic BBS v1.12 A46 2020/03/15 (Windows/64)
* Origin: Sector 7 (21:1/108)

To be very clear, below is what FTS-0001 says on Message Text. And your argument is that Mystic is incorrectly ignoring 8DH and 0AH when the FTS-0001 very specifically says they should be ignored.

Are they ignored or removed when encountered by mutil?

--- BBBS/Li6 v4.10 Toy-4
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106.1)

It also wraps text for legacy software that literally LOSES MESSAGE CONTENT if
you don't provide data in a way they can read it. Since Mystic was
traditionally used with a lot of of Forum/TG hacks it makes a lot of sense why
a Mystic hub might want their downlinks to get complete messages.

That is the job of the tosser used to import messages to one of those legacy softwares, it is not mutils job.

Mutil should not change mail in transit.

--- BBBS/Li6 v4.10 Toy-4
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106.1)

Re: Re: Message mangling?
By: g00r00 to alterego on Mon Mar 16 2020 11:23 am

g00r00

It has nothing to do with "render nicely locally" as I have explained countless times here. There is no reason to discuss any of this further

Wow, this message has a tone that I wasnt really expecting. You sound really frustrated over this topic. I've learnt that when there is "tone" or frustration in messages that it generally mean that either party dont understand each other, and after reading yours I am of the belief that you really do not understand me. I'll back that up below.

First, you've explained "countless times" - but I do not recall the conversations nor the answer to my concerns. I think I've even asked for it to be resent, and if it was sent, I still didnt see it. Sadly I know as a developer, you'll often be asked the same thing by multiple people it goes with
the territory. IMHO, you shouldnt see that as a bad thing, Ive always used that as an opportunity to change my response, since clearly the other person in
the conversation can never read what is on your mind, nor will they have the same methods of recall.

when you just ignore what is said and inject whatever it is that you want

And for the record, I dont think I "ignore what is said" - I have no intentions
here - its just BBS software. I do have goals for things to improve, be better, be easier, provide more value and often spend time to read back through
my messages, and back them them up with examples and reason. I was planning on
doing that here with some packets but before I got there, this happened. For the record, my goal was not tell you what "is wrong" but so you can understand what "I see" and perhaps educate me or agree. After all, that was what I thought was the foundation of this net.

It stops the flood of thousands of message rescans we've seen happen here

Sorry, I dont understand your response "it stops the flood of thousands of message rescans" - I am however curious to understand this. And I dont see how this response relates to what I'm seeing...

It also wraps text for legacy software that literally LOSES MESSAGE

"It wraps text for legacy software" - this I do think, IMHO, is not right. I know there are groups of people here who have views on message wrapping. What you do to "render nicely locally" (which was the basis of that comment) is purely up to you and you could do anything - but to wrap text (or for that matter modify the message portion of text) for downstream nodes (if that is what you mean), I do not think is right.

The packets you create should be in a format so that other "legacy software" can collect them IS something that you should do (but that doesnt extend to the
"message" content within them) - and there are, as far as I am aware, a few different "packet formats". Accept this as my view on this topic - and agree to
disagree if you dont. But dont tell me to move on if you dont like my comment,
it really doesn't foster anything positive.

Thanks for the quote to fts-0001.16, I'm actually aware of it. Your quoting of it has told me two things:

1) We have a disconnect on our conversation. ie: You dont understand what I am asking. You quote "your argument is that Mystic is incorrectly ignoring 8DH and
0AH" - that is NOT what I'm saying at all. I am saying that Mystic SHOULD be ignoring it, and appears as if it is not. I'm happy to back that up with evidence, which I'll probably do anyway, just to make sure my arguments is valid. But I am further confused now, because you "wrap test for legacy software" - that doesnt sound like ignoring to me.

2) "So called software returns 8DH ... should be ignored." And I'm asking you if Mystic is ignoring them, because it appears that it is not - and I think it should be.

And lastly, no I dont use a Mystic system, you are correct - but I do send mail
to it and receive mail from it. If the system I'm using is the cause of the issue that I am asking about, I'm happy to explore that further - and given I can see the source code I would (or I'd ask the author). I was just actually asking here first as a) conversation and b) discovery.
...deon


... Blessed are the young, for they shall inherit the national debt.
--- SBBSecho 3.10-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

To be very clear, below is what FTS-0001 says on Message Text. And your argument is that Mystic is incorrectly ignoring 8DH and 0AH when the FTS very specifically says they should be ignored.

Are they ignored or removed when encountered by mutil?

It doesn't matter either way, because if your tosser is ignoring them then they are a non-factor in dupe checking.

So the question you should be asking is if your TOSSER is properly ignoring them when it calculates its dupe value because it seems it does not?

--- Mystic BBS v1.12 A46 2020/03/15 (Windows/64)
* Origin: Sector 7 (21:1/108)

Wow, this message has a tone that I wasnt really expecting. You sound really frustrated over this topic. I've learnt that when there is "tone" or frustration in messages that it generally mean that either party dont understand each other, and after reading yours I am of the belief that
you really do not understand me. I'll back that up below.

The very first response from you here you started putting words in my mouth with a pretty stupidly toned response. I almost immediately twitted you
then, and I probably should have.

Even though you were told this stuff has already been recently discussed and I explained to you that I did not want that discussion here yet again, you refused to go read the past discussion yourself. And not only that, you continued to sit here, disregard what I said, and keep pushing.

I responded to you, and left you with no questions. I asked you to stop, you still didn't.

We are not misunderstanding, you just refuse to hear anything that isn't what you want to hear. You refuse to do any research before you speak. I've shown you the FTS.

It shouldn't matter if the characters are there or not, if your tosser is properly ignoring them as per the FTS then the dupe CRC value will be the same whether they are there or not (as it is with Mystic). If your tosser doesn't do that, then its not ignoring those characters its including them.

If you think there is FTS that says that those ignored characters should be ignored EXCEPT they should be included only when calculating a duplicate CRC value for message text, then go ahead and show us where it says that.

As I explained to you, the FTS isn't written well enough to account for what you're trying to do, because too much is left open to interpretation and lots of variation occurrs in implementation (and it can also be contradictory too)

...And while you're doing that you can show us the discussion in FTS that
talks about a multiple hub to single node topology too.

--- Mystic BBS v1.12 A46 2020/03/15 (Windows/64)
* Origin: Sector 7 (21:1/108)

It also wraps text for legacy software that literally LOSES MESSAGE CONTE
you don't provide data in a way they can read it. Since Mystic was
traditionally used with a lot of of Forum/TG hacks it makes a lot of sens
a Mystic hub might want their downlinks to get complete messages.

That is the job of the tosser used to import messages to one of those legacy softwares, it is not mutils job.

Sorry, but you don't get to decide what the job of the software I create is, and I can't imagine why you think you get to decide that. If I want to create software that acts as a layer to legacy software that my choice.

Beyond that, you were here for the other discussions. I agreed right off the bat that I was going to back the wrapping out because its no longer used enough to warrant it, and its already been done.

So rather than jumping into conversations not addressed to you to throw out shit no one is asking for, on a topic I specifically asked you guys to chill on, just refrain next time.

Especially when you already know its a non issue, it makes you just come off as a trouble maker.

--- Mystic BBS v1.12 A46 2020/03/15 (Windows/64)
* Origin: Sector 7 (21:1/108)

Re: Re: Message mangling?
By: g00r00 to alterego on Mon Mar 16 2020 03:47 pm

James,

The very first response from you here you started putting words in my mouth with a pretty stupidly toned response. I almost immediately twitted you then, and I probably should have.

I responded to you, and left you with no questions. I asked you to stop, you still didn't.

So I have no idea who you think you were having a conversation with, I really dont think it was me. Regardless, this really isnt a good way to conduct yourself.

I did a quick scan of the message echo - because I really was drawing a blank to you claims on a prior conversation. I do recall you doing a dummy spit - wasnt me though.

So here's what I found. In the last year or so, I've been involved in a total of 72 messages in this echo, according to my dump from SBBS. 35 originated from
me.

The first message you appeared in after your hiatus was 15th Oct, if I have researched correctly. My first post after this date was Jan 22 - less than 2 months ago.

Prior to the 15th date, I contributed on discussions about Mystic and QWK and that rescans to my HUB (a mystic system) which returned me bad packets - because I switched out Mystic for Synchronet and I rescanned to get old messages.

In Jan we had a brief discussions about semaphores and MIS shutdown. Then also a discussions about Open sourcing.

In Feb, their was a brief comment on TEMP vars and SSL.

On the 11 Mar, I raised the subject "Message mangling ?"

I think you have been asked reasonable questions (which I dont think you have answered, and it almost seems like you are avoiding it), and for the record, I would have accepted your answer. Its your software, and I dont use it.

If you answer was - yes I modify messages in transit, I would have shared that I dont think that that is right - I'm allowed to do that, and we could have agreed to disagree and move on.

But I dont care anymore, you behavior and tone speak forthemselves.

mouth with a pretty stupidly toned response. I almost immediately twitted you then, and I probably should have.

BTW: I chuckled when I read this.
...deon


... Chuck Norris doesn't study martial arts, the martial arts study Chuck Norris.
--- SBBSecho 3.10-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

But I dont care anymore, you behavior and tone speak forthemselves.

You do seem to care, because you refuse to stop.

My behavior is fine. I was very open with you and explained that I didn't want this here. You refused to listen, and you seem to lack the self-awareness to take any responsibility for the outcome.

Please stop claiming you don't care, and just move on.

--- Mystic BBS v1.12 A46 2020/03/16 (Windows/64)
* Origin: Sector 7 (21:1/108)

That is the job of the tosser used to import messages to one of those legacy softwares, it is not mutils job.

Mutil should not change mail in transit.

Reading that back this morning I think that could be taken different ways. I mean that in general terms.

When anyone is tossing mail, (bbbs bogus, mutil, sbbsecho, fe or any other) mail should not be changed in transit. If it is then unexpected and unwanted things can happen downstream.

--- BBBS/Li6 v4.10 Toy-4
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106.1)

Re: Re: Message mangling?
By: g00r00 to alterego on Mon Mar 16 2020 11:10 pm

But I dont care anymore, you behavior and tone speak forthemselves.

You do seem to care, because you refuse to stop.

Oh, I wasnt clear - I was talking about your software.

want this here. You refused to listen, and you seem to lack the self-awareness to take any responsibility for the outcome.

<chuckle>

I'd bought up the issue elseware - more really to see if I was on the right path, or not. So far it seems I am, but the jury might not be out yet.
...deon


... I belong to no organized party - I am a democrat.
--- SBBSecho 3.10-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

But I dont care anymore, you behavior and tone speak forthemselves.

You do seem to care, because you refuse to stop.

Oh, I wasnt clear - I was talking about your software.

But you do care. Because you're still posting messages (the last one where
you insulted me repeatedly while claiming you've done nothing was cute).

I'd bought up the issue elseware - more really to see if I was on the right path, or not. So far it seems I am, but the jury might not be out

That weird. I thought you don't care?

Jesus dude, just go back and read the fucking previously discussions. There
is already a tosser that has had all of this addressed that is available for testing. Youd know that this was the plan if you took a little time like I asked you to to read up. You'd also know if you took my advice and did this privately, which you didn't.

Instead you insult me, talk about how you don't care (when you so very obviouosly can't let anything go) while you continue to keep this stuff up.

Just gonna put you on filter at this point. You might be the quickest to get
t here in 23 years (although I think there are only 5 or 6 people who've managed this in that timespan) so congratuations!

--- Mystic BBS v1.12 A45 2020/02/18 (Linux/64)
* Origin: Cyberia BBS | cyberiabbs.zapto.org | San Jose, CA (21:1/120)

Re: Message mangling?
By: g00r00 to alterego on Mon Mar 16 2020 09:52 pm

Oh, I wasnt clear - I was talking about your software.

But you do care. Because you're still posting messages (the last one

Hmm... nope, I dont.

I'd bought up the issue elseware - more really to see if I was on
the right path, or not. So far it seems I am, but the jury might not
be out

That weird. I thought you don't care?

Do I care that mail tossers should modify messages in transit - yes, I do. Do I
care if you fix yours, nope, now I dont.

Jesus dude, just go back and read the fucking previously discussions. There is already a tosser that has had all of this addressed that is available for testing. Youd know that this was the plan if you took a

Didnt see any note on it.

little time like I asked you to to read up. You'd also know if you took my advice and did this privately, which you didn't.

Dont recall this either.

But it only started by asking if your mail tosser modifies mail in transit - which I now think is true based on this thread. I know others who are interested in this answer too, so I still believe its a reasonable information to share publically.

Just gonna put you on filter at this point. You might be the quickest to

Cool, I think we got to the answer in the end...
...deon


... ARRRRRGGGHHH!!!!...Tension breaker, had to be done.
--- SBBSecho 3.10-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)