Hey All!

I am going to "crosspost" this msg in LINUX. I haven't seen any real traffic there in awhile so I don't believe it will have an negative effects. Besides it probably won't get past my uplink if indeed MSGIDs are universal and not just limited to the AREA as far as dupe checking goes.

What are the odds?

Life is good,
Maurice

^-^-^-@@-^-^-^
(..)-----;
||---||
^^ ^^
... A Møøse once bit my sister ...
--- GNU bash, version 5.0.18(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hello Maurice,

I am going to "crosspost" this msg in LINUX. I haven't seen any real traffic there in awhile so I don't believe it will have an negative effects. Besides it probably won't get past my uplink if indeed
MSGIDs are universal and not just limited to the AREA as far as dupe checking goes.

What are the odds?

About 50/50 I'd say.

I just see one copy of this message in here. If any dupes did arrive they would be discarded as long as my tosser sees it as a dupe.

Ttyl :-),
Al

--- GoldED+/LNX 1.1.5-b20180707
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

Hey Alan!

What are the odds?

About 50/50 I'd say.

Not from this angle. The dupe that isn't really a dupe is the one you replied to in this AREA:LINUX.

I just see one copy of this message in here.

The original is in ASIAN_LINK. Check in there and then reply.

If any dupes did arrive they would be discarded as long as my
tosser sees it as a dupe.

Check ASIAN_LINK. I see both the original in ASIAN_LINK and the so-called dupe in LINUX and they are EXACTLY the same other than AREA. Also confirm that the MSGID is EXACTLY the same in both. They both show up on the EuroPoint which means that they both got tossed by my uplink there -> 2:280/464. Since 2:280/464 tossed them both then they both got tossed by you since your node is the first tosser both those msgs saw. Also they were both packed here -> 1:153/7001, in the same pkt so it isn't like there were multiple files to deal with. In other words dupe checking looks to be limited to AREA. No? Without knowing for sure I am guessing that is supposed to happen. If not then there is another bug.

Life is good,
Maurice

^-^-^-@@-^-^-^
(..)-----;
||---||
^^ ^^
... A Møøse once bit my sister ...
--- GNU bash, version 5.0.18(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hello Maurice,

Check ASIAN_LINK. I see both the original in ASIAN_LINK and the
so-called dupe in LINUX and they are EXACTLY the same other than AREA. Also confirm that the MSGID is EXACTLY the same in both.

Yes, I see that message in ASIAN_LINK also and it looks the same. The same date, time, content and MSGID.

They both show up on the EuroPoint which means that they both got
tossed by my uplink there -> 2:280/464. Since 2:280/464 tossed them
both then they both got tossed by you since your node is the first
tosser both those msgs saw. Also they were both packed here -> 1:153/7001, in the same pkt so it isn't like there were multiple files
to deal with. In other words dupe checking looks to be limited to
AREA. No?

That's what it seems at least here and 280/464.

Without knowing for sure I am guessing that is supposed to happen. If
not then there is another bug.

I would use a unique MSGID even when cross posting. They seem to get tossed OK here and 280/464 but you never know what could happen along the way. There might be a tosser in the wild that will see an identical message with an identical MSGID that will toss it aside.

Ttyl :-),
Al

--- GoldED+/LNX 1.1.5-b20180707
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

Hey Alan!

but you never know what could happen along the way

The story of my life.

Life is good,
Maurice

^-^-^-@@-^-^-^
(..)-----;
||---||
^^ ^^
... A Møøse once bit my sister ...
--- GNU bash, version 5.0.18(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hello Maurice!

03 Dec 20, Maurice Kinal wrote to All Fourone:

I am going to "crosspost" this msg in LINUX.

Besides it probably won't get past my uplink if indeed MSGIDs are universal and not just limited to the AREA as far as dupe checking
goes.

FTN dupe handling is based on "per area". There is no universial dupecheck.

For example every squish messagebase *.sqd file has it's own *.dqd dupedatabase file.

Regards

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Monobox (2:240/77)

* Originally in LINUX
* Crossposted in FORTESTINGONLY

Hello Maurice!

03 Dec 20, Maurice Kinal wrote to Alan Ianson:

In other words dupe checking looks to be limited to AREA. No?
Without knowing for sure I am guessing that is supposed to happen.

Yes. You are talking about two different mechansims. Crossposts and dupechecks.

Crossposting is an editor function. The "Crossposted in" line above is set by my editor but there is no kludge for the tosser that this mail is crossposted.

The dupecheck is for breaking routing loops and to keep away dupes from the echoarea users. It isn't designed for universal traffic reduction.

Regards

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Monobox (2:240/77)

Hey Kai!

FTN dupe handling is based on "per area". There is no universial dupecheck.

So far I agree with the above 100% given that both my uplinks tossed both msgs without any issues. I see them on the EuroPoint as unaltered, not counting PATH and SEEN_BY of course, from what I know to be a fact is the original msg given that I created it. They are all identical other than the AREA.

For example every squish messagebase *.sqd file has it's own
*.dqd dupedatabase file.

I've used squish for ages but it is overkill from a single user perspective.

Life is good,
Maurice

^-^-^-@@-^-^-^
(..)-----;
||---||
^^ ^^
... A Møøse once bit my sister ...
--- GNU bash, version 5.0.18(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hi Maurice,

On 2020-12-03 14:03:13, you wrote to Kai Richter:

FTN dupe handling is based on "per area". There is no universial
dupecheck.

So far I agree with the above 100% given that both my uplinks tossed both msgs without any issues.

It doesn't matter that you agree with it. ;-)

It's not the standard, so it might cause problems on other systems with different tossers...

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hello Maurice!

03 Dec 20 14:03, you wrote to Kai Richter:

Hey Kai!

FTN dupe handling is based on "per area". There is no universial
dupecheck.

So far I agree with the above 100% given that both my uplinks tossed
both msgs without any issues. I see them on the EuroPoint as
unaltered, not counting PATH and SEEN_BY of course, from what I know
to be a fact is the original msg given that I created it. They are
all identical other than the AREA.

If the dupecheck was universal, crossposting would have to generate
different message id's.

Kees

--- GoldED+/LNX 1.1.5--b20180707
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hello Maurice!

03 Dec 20, Maurice Kinal wrote to Kai Richter:

FTN dupe handling is based on "per area". There is no universial
dupecheck.

So far I agree with the above 100% given that both my uplinks tossed
both msgs without any issues. I see them on the EuroPoint as
unaltered, not counting PATH and SEEN_BY of course, from what I know
to be a fact is the original msg given that I created it. They are
all identical other than the AREA.

For example every squish messagebase *.sqd file has it's own
*.dqd dupedatabase file.

I've used squish for ages but it is overkill from a single user perspective.

I wasn't talking about the software squish. Any squish messagebase compatible tosser should be able to use the *.sq? and *.dqd files.

--- GNU bash, version 5.0.18(1)-release (x86_64-motorshed-linux-gnu)

Maybe i didn't noticed the background of your question. If that is the editor that creates the complete message and you are looking for confirmation that it does everything correct, then i could tell that golded does not create the same MSGIDs for the crossposted message:

5fc90f4d
5fc90f4c

The crossposting does have +1. Which is the "failsafe" behavior for msgid-based dupecheck procedures.

Regards

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Monobox (2:240/77)

Hey Kees!

If the dupecheck was universal, crossposting would have to
generate different message id's.

"If" being the operative word. So far that doesn't appear to be the case. Then again how would anyone know for sure unless someone catches and reports it.

Life is good,
Maurice

^-^-^-@@-^-^-^
(..)-----;
||---||
^^ ^^
... A Møøse once bit my sister ...
--- GNU bash, version 5.0.18(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hey Kai!

Maybe i didn't noticed the background of your question.

It was not a question on my part so you didn't really miss anything. However your answer has been most informative. Thank you.

For my part I am attempting to make 1:153/7001 a potential wireless access point for offline readers and am going to keep everything to a bare minimum. So far it looks like only the MSGID is required to successfully transverse the whole of fidonet. Thus a point-like setup between 1:153/7001 and any user on the wireless should have the user's app generate it's own MSGID that will ensure uniqueness no matter if another user on the wireless generates the EXACT same serialno since the origaddr will ensure uniqueness due to the point part of the origaddr. This isn't that far off from a numbered userbase on a BBS where by default the sysop is listed as number 1. Thus whether universal or AREA based any half-assed dupechecker should have no issues with the output.

For the record I am using the "^AMSGID: origaddr serialno" format as specified in fts-0009.001.

Life is good,
Maurice

... Monig mon hæfð micel feax on foran heafde, 7 wyrð færlice calu.
Many a man has plenty of hair on his head, and suddenly goes bald.
--- GNU bash, version 5.0.18(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hello Maurice!

03 Dec 20, Maurice Kinal wrote to Kai Richter:

For my part I am attempting to make 1:153/7001 a potential wireless
access point for offline readers and am going to keep everything to a
bare minimum.

Offline Readers is a another chapter and i do not know much about that.

So far it looks like only the MSGID is required to successfully
transverse the whole of fidonet. Thus a point-like setup between 1:153/7001 and any user on the wireless should have the user's app generate it's own MSGID that will ensure uniqueness no matter if
another user on the wireless generates the EXACT same serialno since
the origaddr will ensure uniqueness due to the point part of the
origaddr.

As far as i remember offline readers like QWK are an interface to a BBS and act like online BBS users. And like online BBS users they are operating with the main aka of the BBS.

This isn't that far off from a numbered userbase on a BBS where by
default the sysop is listed as number 1.

I can't remember how QWK uses the usernumber index. Maybe that was part of the BBS responsibilties.

Thus whether universal or AREA based any half-assed dupechecker
should have no issues with the output.

For the record I am using the "^AMSGID: origaddr serialno" format as specified in fts-0009.001.

If you're going to use point numbers then you do not have an offline reader - it's a point software. "Offline reader" could be used even for fully featured node systems too, just because fidonet is an offline network. It's basics are store and forward if connected and disconnect after packages sent.

Regards

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Monobox (2:240/77)

Re: i've been duped ... or was i?
By: Kai Richter to Maurice Kinal on Fri Dec 04 2020 05:38 am

This isn't that far off from a numbered userbase on a BBS where by default the sysop is listed as number 1.

I can't remember how QWK uses the usernumber index.

It doesn't. :-)

Maybe that was part of the BBS responsibilties.

Yup. Just confirming for ya,
--
digital man

Synchronet/BBS Terminology Definition #63:
SAUCE = Standard Architecture for Universal Comment Extensions (ACiD)
Norco, CA WX: 58.0øF, 13.0% humidity, 0 mph WNW wind, 0.00 inches rain/24hrs --- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On 12-04-20 05:38, Kai Richter wrote to Maurice Kinal <=-

As far as i remember offline readers like QWK are an interface to a BBS and act like online BBS users. And like online BBS users they are operating with the main aka of the BBS.

Yeah, offline mail is accessed through an ordinary user account, not a point system, so messages posted by offline users (like this message) appear the same as locally online posted messages, for all intents and purposes. :)

This isn't that far off from a numbered userbase on a BBS where by
default the sysop is listed as number 1.

I can't remember how QWK uses the usernumber index. Maybe that was part
of the BBS responsibilties.

You talking about QWK mail posted by a user? That's posted from within the user's account, so it's the BBS's responsibility. QWK networked messages, OTOH, arrive from multiple users, but they're not offline mail (even though they use the same format), they are network messages, more like FTN, except there's no FTN address, kludges, routing information, etc. There is some QWK networking information though, especially on Synchronet based networks, thanks to DM's QWK estensions.

If you're going to use point numbers then you do not have an offline reader - it's a point software. "Offline reader" could be used even for fully featured node systems too, just because fidonet is an offline network. It's basics are store and forward if connected and disconnect after packages sent.

Network wise, a point system is more like a fully fledged FTN node (with some differences in handling SEENBYs, because those are only 2D).


... And on the 8th day God said, "Murphy, you're in charge."
=== MultiMail/Win v0.51
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)

Hey Kai!

If you're going to use point numbers then you do not have an
offline reader - it's a point software.

I'll go along with that ... for now.

Life is good,
Maurice

... Sceal þegna gehwilc geþylde nimon.
Every man must acquire patience.
--- GNU bash, version 5.0.18(1)-release (aarch64-unknown-linux-android)
* Origin: Little Mikey's ARM - Ladysmith BC, Canada (1:153/7001.4013)

Hello Maurice!

03 Dec 2020 03:18, Maurice Kinal wrote to Alan Ianson:

but you never know what could happen along the way

The story of my life.

what life ?

^-^-^-@@-^-^-^
(..)-----;
||---||
^^ ^^

nice cow :)


Regards Benny

... too late to die young :)

--- Msged/LNX 6.1.2 (Linux/5.9.12-gentoo-x86_64 (x86_64))
* Origin: I will always keep a PC running CPM 3.0 (2:230/0)

Hello Kai!

03 Dec 2020 11:19, Kai Richter wrote to Maurice Kinal:

For example every squish messagebase *.sqd file has it's own *.dqd dupedatabase file.

in husky it can be global dupedatabase for all areas, but i only use it non global pr area as default


Regards Benny

... too late to die young :)

--- Msged/LNX 6.1.2 (Linux/5.9.12-gentoo-x86_64 (x86_64))
* Origin: I will always keep a PC running CPM 3.0 (2:230/0)

Hey Benny!

what life ?

It ain't much but I call it home.

^-^-^-@@-^-^-^
(..)-----;
||---||
^^ ^^

nice cow :)

You know darn well that it's an ascii depiction of the mythical Magnulv the Møøse just before he ascended into Valhalla to take his rightful place on the shores of Gwillim Lake.

Life is good,
Maurice

... Gold geriseþ on guman sweorde... sinc on cwene.
Gold is fitting for a man's sword, precious things for a woman.
--- GNU bash, version 5.0.18(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

On 03 Dec 2020, Maurice Kinal said the following...

Hey All!

I am going to "crosspost" this msg in LINUX. I haven't seen any real traffic there in awhile so I don't believe it will have an negative effects. Besides it probably won't get past my uplink if indeed MSGIDs are universal and not just limited to the AREA as far as dupe checking goes.

What are the odds?

Life is good,
Maurice

^-^-^-@@-^-^-^
(..)-----;
||---||
^^ ^^
... A Møøse once bit my sister ...
--- GNU bash, version 5.0.18(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Looks fine here :)

--- Mystic BBS v1.12 A47 2021/01/05 (Linux/64)
* Origin: Omicron Theta * Horn Lake MS * linux.winserver.org (1:116/18)

On 03 Dec 2020, Maurice Kinal said the following...

If any dupes did arrive they would be discarded as long as my
tosser sees it as a dupe.

I swear! It wasn't my fault this time! :)

--- Mystic BBS v1.12 A47 2021/01/05 (Linux/64)
* Origin: Omicron Theta * Horn Lake MS * linux.winserver.org (1:116/18)

-={ 2021-01-11 22:41:39.898111909+00:00 }=-

Hey Robert!

^-^-^-@@-^-^-^
(..)-----;
||---||
^^ ^^
... A Møøse once bit my sister ...
--- GNU bash, version 5.0.18(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Looks fine here :)

It sure does. I see the utf-8 characters survived despite the lack of a CHRS kludge. Gotta love it.

I haven't heard from you in ages. Where have you been hiding?

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 Brain - Ladysmith BC, Canada (1:153/7001)