I get asked every once in a while how (or from whom) to get an FTN feed for DOVE-Net.
I've never really done that (that I recall), as I find FTN network management to be a hassle (creating/linking/de-linking nodes, cleaning
up old outbound files, etc.).
Is anyone currently feeding DOVE-Net via FTN? What zone number you
using? I know different folks have fed DOVE-Net via FTN over the years, but no official othernet zone was ever chosen that I'm aware of.
I've never really done that (that I recall), as I find FTN network management to be a hassle (creating/linking/de-linking nodes, cleaning up old outbound files, etc.).
Is anyone currently feeding DOVE-Net via FTN? What zone number you using? I know different folks have fed DOVE-Net via FTN over the years, but no official othernet zone was ever chosen that I'm aware of.
I happen to be using 723 as the zone number, and I have no problem if you ever
ant/need to send them my way for a feed.
I get asked every once in a while how (or from whom) to get an FTN feed for DOVE-Net.
I have been for quite some time now. I started doing it because Synchronet isn't my main hub for Fidonet and othernets, I use husky/binkd for that. So I pull Dovenet from Vert with my Synchronet BBS and then send everything over to my hub via FTN. I've fed like 3 people for a number of years (that don't have the ability to do QWK polling - usually using older BBS software).
I happen to be using 723 as the zone number, and I have no problem if you ever want/need to send them my way for a feed.
On 1/21/2024 11:11 PM, Digital Man -> All wrote:
I get asked every once in a while how (or from whom) to get an FTN feed for DOVE-Net.
This reminded me of a question I had for you. What are you using to gate SYNCDATA, SYNCHRONET, SYNC_PROGRAMMING, and SYNC_SYSOPS to Fidonet?
Whatever it is, Deuce's upside down question mark in his name seems to be causing some wierdness (=?unknown-8bit?q?Deuc=D0=B5 in the From field).
However, when I pull Dovenet from you via my Synchronet BBS and transfer it to my hub via FTN, it displays fine. Made me wonder if you were doing something different in regards to getting it over to Fidonet?
gate SYNCDATA, SYNCHRONET, SYNC_PROGRAMMING, and SYNC_SYSOPS toSBBSecho. <shrug>
to be causing some wierdness (=?unknown-8bit?q?Deuc=D0=B5 in the
From field).
Uh... I'm not exporting (or converting to) quoted-printable text, so
maybe that's something happening on your end?
transfer it to my hub via FTN, it displays fine. Made me wonder if
you were doing something different in regards to getting it over
to Fidonet?
Nope. That's a unicode character (a special 'e' he used to defeat IRC
name alerts for him) and so the messages should be exported to FTN with CHRS: UTF-8.
Other than that, nothing special.
On 1/23/2024 2:14 AM, Digital Man -> Accession wrote:
>> This reminded me of a question I had for you. What are you using to
gate SYNCDATA, SYNCHRONET, SYNC_PROGRAMMING, and SYNC_SYSOPS toSBBSecho. <shrug>
>> Whatever it is, Deuce's upside down question mark in his name seems
to be causing some wierdness (=?unknown-8bit?q?Deuc=D0=B5 in the
From field).
Uh... I'm not exporting (or converting to) quoted-printable text, so maybe that's something happening on your end?
>> However, when I pull Dovenet from you via my Synchronet BBS and
transfer it to my hub via FTN, it displays fine. Made me wonder if
you were doing something different in regards to getting it over
to Fidonet?
Nope. That's a unicode character (a special 'e' he used to defeat IRC name alerts for him) and so the messages should be exported to FTN with CHRS: UTF-8.
Other than that, nothing special.
So the only difference I'm seeing here, is both of them have the CHRS: UTF-8 kludge, however, the one you're gating to Fidonet has:
Content-Type: text/plain; charset=us-ascii; format=flowed
... and the one I'm getting from you via Dovenet/QWK and gating it over my own FTN has:
Content-Type: text/plain; charset=utf-8; format=flowed
So I can't imagine that's something I'm doing here, unless I'm doing something different from you which is causing it to work better on my side.
Are you possibly using the "Export ASCII Only" option in SCFG? Mine is set to no.
And FYI, this is when I read via a newsreader so maybe it's something that is not noticed on the BBS itself. *shrug*
"Content-Type" isn't a FidoNet header field. Are you reading the echo via NNTP or something?
Well, whatever you you're using to view the message is apparently adding Content-Type header fields and doing some quoted-printable encoding. These are "FidoNet things".
So maybe read the messages on the BBS, view the headers on the BBS, to see what's different.
So maybe read the messages on the BBS, view the headers on the BBS, to see what's different.
The QWK packet configuration on your Synchronet hub (VERT) has the option to toggle UTF-8 support in messages. Is it on or off for your QWKnet account?
If the FTN messages with the UTF-8 character in the header are reaching your system with the "CHRS: UTF-8" kludge line in tact (view the message header stored in the message base to find out, e.g. using smbutil), then there's nothing wrong with my uplink or any other link along the way, but rather something wrong in the parsing/rendering of the message header on your BBS. I'm not saying there isn't a Synchronet issue at play here, just asking questions.
It's on. And as far as I know there's nothing wrong with DDMsgReader in this regard. I've never seen anything like this before.
I think the problem is that if the character he's using in his name is a UTF-8 character, while the message is posted with a CHRS: CP437 kludge.
On Wed, 24 Jan 2024 17:42:04 -0800, Digital Man -> Accession wrote:
The QWK packet configuration on your Synchronet hub (VERT) has the option to toggle UTF-8 support in messages. Is it on or off for your QWKnet account?
It's on. And as far as I know there's nothing wrong with DDMsgReader in this regard. I've never seen anything like this before.
When I download and process a QWK packet from VERT, it displays with an upside down question mark, which if I remember right, is what Synchronet is supposed to do if the character can't be displayed.
This version of the
message, if I'm not mistaken uses a UTF-8 character in his name, and the message has a CHRS: CP437 kludge. So mark this one as "maybe correct," yes?
Even though I still have doubts about using a UTF-8 character with a CP437 kludge.
I also get SYNC_PROGRAMMING via Fidonet. The path on these specific messages is you, to Wilfred, to me. I don't doubt any of those 3 systems having proper UTF-8 support.
However, the same message when read on Fidonet now has a CHRS: UTF-8 kludge. So if a UTF-8 character was posted with a CP437 kludge, I would think that would break it already. Then when an attempt to translate it to UTF-8 is made, and possibly breaks it even more, No?
If the FTN messages with the UTF-8 character in the header are reaching your system with the "CHRS: UTF-8" kludge line in tact (view the message header stored in the message base to find out, e.g. using smbutil), then there's nothing wrong with my uplink or any other link along the way, but rather something wrong in the parsing/rendering of the message header on your BBS. I'm not saying there isn't a Synchronet issue at play here, just asking questions.
I think the problem is that if the character he's using in his name is a UTF-8 character, while the message is posted with a CHRS: CP437 kludge. This will break it immediately, won't it?
After that, it doesn't matter what
translations are done, as it's already messed up.
Or am I completely missing something here?
When I look at your QWKnet account (PHARCYDE) on Vertrauen, I see it is in fact configured to convert UTF-8 to CP437 chars:
[U] Include UTF-8 Characters : No
This is contrary to what you said above "It's on".
I suspect if you change your QWK packet configuration on Vertrauen to include UTF-8 chars, you'll see the same behavior between the DOVE-Net and FidoNet versions of these same messages, that later of which I understand you're having problem viewing correctly with DDMsgReader. I'm not clear if there's an actual Synchronet problem with those messages imported via FTN or not, but there does not appear to be any problem with the messages imported via QWK based on what I've researched and described above.
All that said, what's with your accusations of me being defensive and not caring? We're just going to pretend that didn't happen? Is this how you normally treat people that are trying to help you?
On Thu, 25 Jan 2024 18:28:46 -0800, Digital Man -> Accession wrote:
When I look at your QWKnet account (PHARCYDE) on Vertrauen, I see it is in fact configured to convert UTF-8 to CP437 chars:
[U] Include UTF-8 Characters : No
This is contrary to what you said above "It's on".
SCFG > Networks > QWK Packet Networks > Network Hubs > VERT > Include UTF-8 Characters = Yes.
Also all sub-boards (QWK, FTN, all of them) have UTF-8 enabled here.
Or is that setting for when I send messages to you via QWK?
This is what I thought you were referring to. I had no idea I had to set it on your BBS also. Not really sure I've ever had to do that before, either. Thanks for the heads up.
I suspect if you change your QWK packet configuration on Vertrauen to include UTF-8 chars, you'll see the same behavior between the DOVE-Net and FidoNet versions of these same messages, that later of which I understand you're having problem viewing correctly with DDMsgReader. I'm not clear if there's an actual Synchronet problem with those messages imported via FTN or not, but there does not appear to be any problem with the messages imported via QWK based on what I've researched and described above.
Changed now on VERT. We will see.
All that said, what's with your accusations of me being defensive and not caring? We're just going to pretend that didn't happen? Is this how you normally treat people that are trying to help you?
At first, it didn't seem at all that you were trying to help, but rather blowing me off by blaming me in every which way you could. Some of your responses to me (in the past as well) occasionally come off (whether it's meant or not) quite condescending.
Apologies for taking some of the things you say the wrong way. Sometimes text is hard to figure out how one is speaking to another, and I put my guard up when I thought you were doing the same. This definitely isn't the first time, and probably won't be the last. :(
Okay, thanks for acknowleding it. Hopefully it will be the last time. I definitely *am* trying to help you. I'm not sure why we're having this conversation in "DOVE-Net Sysops" (not really the right conference for Synchronet help) either.
asking a Dovenet Sysop related question about something. Even the fix to my problem
was related to a new QWK setting for.. Dovenet.
At first, it didn't seem at all that you were trying to help, but rather blowing me off by blaming me in every which way you could. Some of your responses to me (in the past as well) occasionally come off (whether it's meant or not) quite condescending.
I see a color change in the TEARLINE, which ends in the QWK TEARLINE. Is that what you're referring to?
On Fri, 26 Jan 2024 21:32:26 -0600, Accession -> Mro wrote:
I see a color change in the TEARLINE, which ends in the QWK TEARLINE. Is that what you're referring to?
My bad, that would be two origin lines, not tear lines. Either way, my guess is that something you're using is translating "_" as a color code.
Re: FTN feed for DOVE-Net
By: Accession to Accession on Fri Jan 26 2024 03:41 pm
On Fri, 26 Jan 2024 21:32:26 -0600, Accession -> Mro wrote:
I see a color change in the TEARLINE, which ends in the QWK TEARLINE. Is that what you're referring to?
My bad, that would be two origin lines, not tear lines. Either way, my guess is that something you're using is translating "_" as a color code.
yeah i exported it and looked at it and just saw the _ there.
not sure what synchronet is doing.
yeah i exported it and looked at it and just saw the _ there.
not sure what synchronet is doing.
On Fri, 26 Jan 2024 23:14:20 -0600, Mro -> Accession wrote:
yeah i exported it and looked at it and just saw the _ there.
not sure what synchronet is doing.
No idea. After I sent that message, I thought maybe you were wondering why there were two origin lines from my system, and maybe you highlighted the text in question instead. But, at least it's not me this time. :D
Regards,
Nick
i believe it is a feature that should be removed!
i believe it is a feature that should be removed!
It can be, by you.
According to the link DM posted, it's a per sub-board option in SCFG that is by default disabled. You must have enabled it.
"The default behavior is currently not to parse and apply Markup Codes in displayed message text."
According to the link DM posted, it's a per sub-board option in SCFG that is by default disabled. You must have enabled it.
"The default behavior is currently not to parse and apply Markup Codes in displayed message text."
here's what i have for that sub
Toggle Options Ý -------------------------------------Ý
?ÝPost Using Real Names No Ý
ÝUsers Can Edit Posts Yes Ý
ÝUsers Can Delete Posts Last Ý
ÝDefault On for New Scan Yes Ý
ÝForced On for New Scan Yes Ý
ÝDefault On for Your Scan Yes Ý
ÝPublic 'To' User Yes Ý
ÝAllow Message Voting No Ý
ÝAllow Message Quoting Yes Ý
ÝAllow Message Tagging No Ý
ÝSuppress User Signatures No Ý
ÝPermanent Operator Msgs No Ý
ÝCompress Messages (LZH) Yes Ý
ÝApply Markup Codes Hide Ý <<---
ÝExtra Attribute Codes Yes Ý
?ÝWord-wrap Messages Yes Ý -------------------------------------+
so i shouldn't SEE them, right?
but when i go in there it says
[Ý][?]--------------------------------------+
Interpret/Display Markup Codes in Messages Ý --------------------------------------------Ý
ÝYes Ý
ÝYes and Hide the Markup Characters Ý
ÝNo Ý --------------------------------------------+
to me, having it set to hide means you won't see them.
to me, having it set to hide means you won't see them.
And you're not seeing them. If you don't want the markup codes interrpted/parsed/applied, set this to "No" and then you will see the codes/symbols.
Re: FTN feed for DOVE-Net
By: Digital Man to MRO on Sat Jan 27 2024 02:40 pm
to me, having it set to hide means you won't see them.
And you're not seeing them. If you don't want the markup codes interrpted/parsed/applied, set this to "No" and then you will see the codes/symbols.
so shouldn't these be in the extra attribute codes section
in message options?
so shouldn't these be in the extra attribute codes section
in message options?
Not unless a sysop wants to disable them globally. I think per-sub makes more sense. And they're not really attribute codes in the same sense that "pipe codes" and such are.
total crap feature, you should take it out. I don't see why anybody would want it, use it or even suggest it.
| Sysop: | Chris Crash |
|---|---|
| Location: | Huntington Beach, CA. |
| Users: | 557 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 96:50:34 |
| Calls: | 10,385 |
| Files: | 5 |
| Messages: | 360,723 |
