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)