I dont think we should be "stuck" with how it was designed in the 90's.
I do think we must make sure we dont break anything if we make changes - so consideration must be there.
I've talked about using the ITN flag to show the telnet port. I still think that that is possible. (So it with the INA field could represent
how a person connects to a BBS.) There are also other existing flags
that could hold other data "U" for example. Or we can create our own. "WEB:....", "EML: ...", "SSH:...", etc which I dont think will break existing system, but I'm willing to try if somebody else is.
The only limit that I'm aware of, is that a flag can only be 32 chars in length, so may be limiting for some web urls or email addresses...
Can we move this thread over to FSX_NET to discuss further and let's see if we can:
- confirm a list of things we're trying to address / enhance etc.
- develop some new standardised flags for the fsxNet nodelist
- test this all out
As I understand it we have at least one mod that may/may not (I haven't used it) be pulling some info from a FTN nodelist that is used to allow mod users to telnet (or ssh?) to another system. We're trying to assist this mod or ??
There's also a webring thread going on looking to use the nodelist as a way to record some data for that?
Can we move this thread over to FSX_NET to discuss further
- confirm a list of things we're trying to address/enhance etc.
Yes, there is an mpl that Gryphon wrote awhile back, which is a bbs listing, that will allow the user to connect to another BBS. Users can
add their BBS info, etc.
It also comes with a another mpl that allows you to import the nodelist.txt file from Mystic into the (separate) BBS list.
The problem comes in with the importing from the nodelist, as the
nodelist gives connection info for mailers to connect, but not for callers. As the main bbs list mpl uses the format of bbs.castlerockbbs.com:23 for the address and port, when the information
is imported from the nodelist, it only pulls the bbs.castlerockbbs.com, and assumes port 23. If a system is not on port 23 it won't be able to connect. <whew>
I'm not sure if it's really worth changing the nodelist for this, or perhaps start an fsxNet BBS List that could be imported with a modified mpl...
There's also a webring thread going on looking to use the nodelist as way to record some data for that?
Once I am happy with my initial adjustments to node2bbi Im happy to
make it available to anyone who wants to test it. i still want to
remove a bunch of the garbage that it currently sees as a valid bbs. I also have some changes to BLAM that improve on its function. BTW: Where
is the author? I read somewhere that he is no longer available? I
don't want to step on his toes though after 4 years without an update Im guessing he wont mind?
1/ Incorporate Webring information into the nodelist.
- Website URL
- Telnet Port
- SSH port it required.
- System name as you'd like it formatted in the webring list.
I see Frank uses U to showcase SciNet nodes custom domain names but if
he was to add another user flag then what?
[snip]
INA:therockbbs.net,IBN,ITN:10023,U,therock.scinet-ftn.org
1. is the nodelist the best place to 'fix' the things were trying to
sort?
2. should we be shipping in the infopack or have online some where (or both) a dynamic txt file that can be used by mods etc. to pull the data needed from each node in the network for the needs of the mod?
Perhaps something like fsxNet F flags in the nodelist?
FTEL - telnet port
FSSH - ssh port
FTOR - tor address
Can folks let me know the file name they have on their systems? It seems
I have two, both the same contents I think but I need to nail down which file is the authoritative one and remove the other from HUBs and Agency
two combined as a "BBSLink" similar to the "Weblink" concept. SO ... I hope the aforementioned file names assist. If not, let me know and I'll send them to you.
I think to date my use of ITN flag to denote a BBS running on a non-standard telnet port has been incorrect as the flag I now think was intended from a mailer point of view (as the historical use is nodelist
as a tool for mailers) to show it a system accepting mail via Telnet was not on port 23 but port XYZ..
I'm not sure if use of ITN such I have been doing is the best way
forward.
Likewise the IBN does the same for BinkP mailers not running on the default port of 24554 and I use that IBN flag quite a bit for nodes and HUBs doing the same.
All of which leads me to think if we were to add flags to a fsxNet nodelist to help with a webring project or a mod like gy-blam perhaps we should probably be creating and using some fsxNet created user flags instead?
http://ftsc.org/docs/fts-5001.006 refers to the U flag and a limit of 32 chars per usage but U could be used multiple times in an entry. How I am not sure as how does anything discern one flag from another if the flag
is the same name??
I see Frank uses U to showcase SciNet nodes custom domain names but if
he was to add another user flag then what?
[snip]
INA:bbs.darkrealms.ca,IBN,U,darkrealms.scinet-ftn.org INA:therockbbs.net,IBN,ITN:10023,U,therock.scinet-ftn.org
[snip]
So I'm wondering
1. is the nodelist the best place to 'fix' the things were trying to
sort?
2. should we be shipping in the infopack or have online some where (or both) a dynamic txt file that can be used by mods etc. to pull the data needed from each node in the network for the needs of the mod?
3. If we agree things like
- non standard telnet ports
- ssh port
- tor port/address info
- what else needs to be added to this list?
...should be in the nodelist should be not be creating our own standardised user flags instead and then mods would use them?
One downside with the last idea is mods are only going to be able to use the fsxNet nodelist or whatever txt file that contain the flags we're after for whatever service they deliver. That's not a deal breaker to me but something to be aware of.
Perhaps something like fsxNet F flags in the nodelist?
FTEL - telnet port
FSSH - ssh port
FTOR - tor address
I'll stop there :)
Perhaps something like fsxNet F flags in the nodelist?
FTEL - telnet port
FSSH - ssh port
FTOR - tor address
SSH
TOR
keep using ITN for purposes it was not strictly intended for??
Gy-blam21 (verion 2.1) AND
node2bbi should be packaged within the gy-blam21 zip file. If not I can
Establish tags, combinations such as U,T or U,W. Confusingly, the standard states that you must follow the U flag with a comma. UTN: would be a prefect substitute for ITN: However, as I read it this would not
be in keeping with the standard?
Yeah, I think he added that for some DNS magic he wanted to implement.
He can speak to that. Interestingly, you will also note that he is
using the ITN:10023 flag for my board to ID my use of a non-standard telnet port ;)
1. is the nodelist the best place to 'fix' the things were trying to sort?
Perhaps not, but its already implemented and reasonably easy to control and scale.
2. should we be shipping in the infopack or have online some where (o both) a dynamic txt file that can be used by mods etc. to pull the da needed from each node in the network for the needs of the mod?
So long as you dont mind implementing yet another file to be managed, maintained, and processed....
Assuming a new file, SysOp Name, BBS Name, City, State, Country (etc). Also, perhaps its time to just refer to it as telnet port and not non-standard. If we are going to have a placeholder for the port we may as well include port 23 for those who still use it.
One downside with the last idea is mods are only going to be able to the fsxNet nodelist or whatever txt file that contain the flags we're after for whatever service they deliver. That's not a deal breaker to but something to be aware of.
Yeah, a good reason to TRY to stay with the FTN standard nodelist (if we can)
Perhaps something like fsxNet F flags in the nodelist?
FTEL - telnet port
FSSH - ssh port
FTOR - tor address
Im up for anything! Here for the beer mainly!!!!
I did hammer out a quick fix for node2bbi just cause it was fun. Godfather and I are testing but its not a pet of mine by any means ;)
Im primarily concerned with the webring project...
No, I dont think network specific is a good idea. There is no reason why othernets couldnt adopt the same flags. (And I think we can lead the othernets to do it, if there are clear advantages to do so - and the BBS mod, webring, etc are examples of them).
For TOR, I would suggest TOA - since the TOR address is a hostname
SSH
TOR
keep using ITN for purposes it was not strictly intended for??
I'm for this scenario...
1/ Incorporate Webring information into the nodelist.
- Website URL
- Telnet Port
- SSH port it required.
- System name as you'd like it formatted in the webring list.
No, I dont think network specific is a good idea. There is no reason othernets couldnt adopt the same flags. (And I think we can lead the
For TOR, I would suggest TOA - since the TOR address is a hostname
Could it be better to build some separate reference file that ships in
an infopack and can have all the tags and data per BBS node added to / removed from it..and that file becomes a sort of new master nodelist
style file that mods can use to pick up information required for the
mod to work?
Where did the W come from is that just an example tag?
Yep, I wonder if there is a line length limit for how much you can stuff on a single line before it becomes hard for a legacy system to handle
it? Even if many of the flags we might add are not known to it and you would hope it would ignore it.
I don't mind but I'm mindful it would not be the 'norm' for othernets... hence not something that could cross pollinate to othernets so easily. Then again if it worked ok and the format/specs were open any othernet could pick it up too.. so yeah I'm 50/50 on this idea.
A nodelist would cover most of this already I think.
Yes, I think so. A nodelist is a very old and specialized file designed for mailer connect info. It has nothing against BBSs or BBSing but it
was not designed with that in mind.. just FTN mailer connections.
A BBS list of some sort would be better for this purpose. The Telnet BBS guide is one such list that lists telnet, rlogin, ssh, web and ftp
connect info for any BBS that is listed in there.
There are many nodes listed in the nodelist (like mine) that don't have
a BBS connected so grabbing info from the nodelist would not be very useful in those cases.
Just reflecting on a post from Vorlon in Mystic echo.
I'm thinking if flags were added to the fsxNet nodelist they would
need ot be useful for cross FTN purposes not just for one specific
mod or project.
Perhaps look at it another way.. create a new document with all this information and derive a nodelist from it rather than deriving a bbs
list from the nodelist.
Avon wrote to All <=-
Could it be better to build some separate reference file that
ships in an infopack and can have all the tags and data per BBS
node added to / removed from it..and that file becomes a sort of
new master nodelist style file that mods can use to pick up
information required for the mod to work?
apam wrote to Avon <=-
Perhaps look at it another way.. create a new document with all
this information and derive a nodelist from it rather than
deriving a bbs list from the nodelist.
IMHO the actual nodelist should remain compliant with Fido/FTN
defined standards.
IMHO the actual nodelist should remain compliant with Fido/FTNCompletely agree! I think that what we are discussing is using the nodelist (for our purposes) within the standards. For the most part these standards have not changed in years. We should be able to use it and still remain within the guidelines. Otherwise, we will need to develop an entirely new system. Doable but 'worth the time'?
defined standards.
So, this might be the wine talking - and I've been out - but being compliant with Fido is not the priority (IMHO). "Not breaking" anything *IS*. Some folks might think that is the same thing, but I probably have this tanted view that changing the Fido standard is not done because
there are a few resistant to change.
Where I'm coming from is that there is no reason why we cant change the way we use the nodelist, if (and that is the priority), it does change
the way things work. Or said another way it does break anything that
does work.
(I'm really keen that the old stuff continues to work, but anything new works better :)
So, the new things that didnt exist (when the nodelist was invented), is email, TCP/IP and web links, etc. My theory is a BBS is always at an address (aka the INA field). If it provides a service, eg: binkp, that
is described by the IBN flag. If it provides a telnet service, that is described by the ITN flag. So why cant web be described by a "WEB" flag (for example), SSH be described by an "SSH" flag, etc. I think you get
the idea.
One of the goals of enhancing the nodelist is to not increase the
workload of the person managing it AND getting more value out of it. So I'm keen to see the "single source of truth" (aka a nodelist) be used
for multiple purposes.
The only doubt with this, is would a BBS exist that wasnt in a network (and thus not defined to a nodelist)? Does (and would) that exist - and how do we handle that scenario? (I'm of the opinion that that would be
the minority, if it existed at all...)
OK, the bottle is calling me.... :)
For TOR, I would suggest TOA - since the TOR address is a hostname
address, and the port that you connect to would still be goverened by the capability (telnet, ssh port, etc). (Although typing this, would you use SSH with TOR? Oli may provide a point of view...)
Just an example. Flags could be U,<anything>. One example could be U,T:10023 (which looks alot like a nonstandard Telnet port. U,S:22 an
SSH port.
Yes, I think so. A nodelist is a very old and specialized file
designed for mailer connect info. It has nothing against BBSs or
BBSing but it was not designed with that in mind.. just FTN
mailer connections.
It is designed so that nodes know how to talk to each other.
Basically, I think this is what we are trying to accomplish in these discussions? If we don't use the existing nodelist I believe we will
be building something that looks alot like it.
A BBS list of some sort would be better for this purpose. The
Telnet BBS guide is one such list that lists telnet, rlogin, ssh,
web and ftp connect info for any BBS that is listed in there.
Yes, its a nice list. Has it been picked up by any comm package or
other project such as BLAM or our webring? Is it well maintained?
There are many nodes listed in the nodelist (like mine) that
don't have a BBS connected so grabbing info from the nodelist
would not be very useful in those cases.
This is correct. However, if nets picked up on the usage of the flags (such as ITN:xxx for telnet ports or User flags such as those
suggested by Avon then the nodelist would be much more valuable. Don't
you think?
Whatever we decide, I think its good to discuss the possibilities
here. I got involved through Spectres webring project and then when Godfather mentioned that BLAM was seriously flawed. At the end of the
day we might be better off just developing a seperate solution that
these two platforms will be able to use and make it scalable for
future projects.
My versions are gy-blam21.zip and gyblam21.zip and i have a third with
the ibbs as a separate file but it also contains the blam contents. I think this last file will be the latest. What date do you have for when the files were created?
There are many nodes listed in the nodelist (like mine) that don't have a BBS connected so grabbing info from the nodelist would not be very useful in those cases.
I don't see why? Surely you'd just be flagged as pvt or unlisted?
Could it be better to build some separate reference file that ships i an infopack and can have all the tags and data per BBS node added to removed from it..and that file becomes a sort of new master nodelist style file that mods can use to pick up information required for the mod to work?
Yes, I think so. A nodelist is a very old and specialized file designed
A BBS list of some sort would be better for this purpose. The Telnet BBS
Where did the W come from is that just an example tag?
Just an example. Flags could be U,<anything>. One example could be U,T:10023 (which looks alot like a nonstandard Telnet port. U,S:22 an
SSH port.
Yep, I wonder if there is a line length limit for how much you can st on a single line before it becomes hard for a legacy system to handle it? Even if many of the flags we might add are not known to it and yo would hope it would ignore it.
Not that I have found. There are some limits on individual fields and there have been discussions about restrictions but at the time of those discussions it was determined that it would require too much effort to
I don't mind but I'm mindful it would not be the 'norm' for othernets hence not something that could cross pollinate to othernets so easily Then again if it worked ok and the format/specs were open any otherne could pick it up too.. so yeah I'm 50/50 on this idea.
As am I...
A nodelist would cover most of this already I think.
Yessir, it would. And thats the appeal (I guess)....
mentioned that BLAM was seriously flawed. At the end of the day we
might be better off just developing a seperate solution that these two platforms will be able to use and make it scalable for future projects.
Perhaps look at it another way.. create a new document with all this information and derive a nodelist from it rather than deriving a bbs
list from the nodelist.
Could it be better to build some separate reference file that
ships in an infopack and can have all the tags and data per BBS
node added to / removed from it..and that file becomes a sort of
new master nodelist style file that mods can use to pick up information required for the mod to work?
Yes, I think so.
IMHO the actual nodelist should remain compliant with Fido/FTN
defined standards.
Perhaps look at it another way.. create a new document with all
this information and derive a nodelist from it rather than
deriving a bbs list from the nodelist.
+1,000,000
IMHO the actual nodelist should remain compliant with Fido/FTN defined standards.
Completely agree! I think that what we are discussing is using the nodelist (for our purposes) within the standards. For the most part
these standards have not changed in years. We should be able to use it and still remain within the guidelines. Otherwise, we will need to develop an entirely new system. Doable but 'worth the time'?
So, this might be the wine talking - and I've been out - but being compliant with Fido is not the priority (IMHO). "Not breaking" anything *IS*. Some folks might think that is the same thing, but I probably have this tanted view that changing the Fido standard is not done because
there are a few resistant to change.
Where I'm coming from is that there is no reason why we cant change the way we use the nodelist, if (and that is the priority), it does change
the way things work. Or said another way it does break anything that
does work.
(I'm really keen that the old stuff continues to work, but anything new works better :)
So, the new things that didnt exist (when the nodelist was invented), is email, TCP/IP and web links, etc. My theory is a BBS is always at an address (aka the INA field). If it provides a service, eg: binkp, that
is described by the IBN flag. If it provides a telnet service, that is described by the ITN flag. So why cant web be described by a "WEB" flag (for example), SSH be described by an "SSH" flag, etc. I think you get
the idea.
One of the goals of enhancing the nodelist is to not increase the
workload of the person managing it AND getting more value out of it. So I'm keen to see the "single source of truth" (aka a nodelist) be used
for multiple purposes.
nodelist. I am modding the node2bbi importer with an exclude zone function so that non-compliant nodelists may be excluded. It will probably only ever be used by myself but Im having fun with it and I can easily convert it to whatever we decide to do.
One of the goals of enhancing the nodelist is to not increase the workload of the person managing it AND getting more value out of it. I'm keen to see the "single source of truth" (aka a nodelist) be used for multiple purposes.
That is the most appealing argument to using the existing nodelist. I'm thinking it will take minimal effort to tweak as opposed to starting from scratch. But again, Im on board with whatever the team decides.
The only doubt with this, is would a BBS exist that wasnt in a network
(and thus not defined to a nodelist)? Does (and would) that exist - and
how do we handle that scenario? (I'm of the opinion that that would be
the minority, if it existed at all...)
OK, the bottle is calling me.... :)
.. It's always the OVERtakers who keep the UNDERtakers busy.
--- SBBSecho 3.11-Linux
 * Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)
GY-Blam 7/21/16
Node2BBI 8/11/16
I know michael is working on one of the two and getting them to work. I
At the heart of this discussion should be what need(s) are we
trying to meet and then knowing that it becomes what mechanisms are currently present to meet that and what are their strengths and limitations, then what else could be created to meet the need(s)
and the pros and cons for doing so. This is what I have been
mulling...
GY-Blam 7/21/16
Node2BBI 8/11/16
I know michael is working on one of the two and getting them to work. I haven't had a chance to test anyting yet as my wifes B-Day was yesterday and with restrictions lifting it's turned into a week long event :)
The only BBS I can see that woulddn't be in the nodelist would be points or test setups/newcomers. To answer one of my own previous questions,
if someone wasn't interested in the webring, or posting a web url for whatever reason it could just be posted -unpublished- like the phone numbers.
On 05-30-20 08:04, Gamgee wrote to Avon <=-
IMHO the actual nodelist should remain compliant with Fido/FTN
defined standards.
On 05-31-20 15:45, Avon wrote to stizzed <=-
Perhaps a nodelist from any network could be used as the starter for something bigger and more extensible? I favor this idea over trying to rework a known list with inbuilt limitations.
Avon wrote to All <=-
I'm thinking if flags were added to the fsxNet nodelist they would need
ot be useful for cross FTN purposes not just for one specific mod or project.
I guess the question becomes what is really useful to know in a
nodelist that is not already there now?
Is it a case that showing SSH and TOR info is enough with flags created for each?
apam wrote to Avon <=-
Perhaps look at it another way.. create a new document with all this information and derive a nodelist from it rather than deriving a bbs
list from the nodelist.
On 31 May 2020 at 12:01a, alterego pondered and said...
So, this might be the wine talking - and I've been out - but
being compliant with Fido is not the priority (IMHO). "Not
breaking" anything *IS*. Some folks might think that is the
same thing, but I probably have this tanted view that changing
the Fido standard is not done because there are a few
resistant to change.
Yep I'm in general agreement with you in that we're not Fido and
can run things as we see fit.
But why *can't* the nodelist evolve into indicating bbs info too?
What is wrong with the nodelist serving mailer info *and* providing bbs info?
Infact.. the original nodelist *was* a bbs list. It listed the systems that wanted a way to move netmail from their bbses. Those systems were bbses open to the regular public. A user could take that list, and just use the phone number to call manually.
Later, things like the MO flag was adopted to indicate a system that
does not have bbs behind it.
Now, some people just want to *think* of the nodelist as a mailer-only oriented guide completely from the days of its inception. But I don't
buy it. The "thought process" basically devolved it into a machine-only list.
I really appreciate you tackling BLAM/node2bbs for the purposes of creating a bbslist for users.
I incorporate fidonet, z2pnt, micronet and fsxnet into OpenXP for one
big searchable database and do not encounter any problems. So, the standards seem to be handled OK.
It uses the 1st 5 fields to present: Sysop, Location, BBS name, node number and phone. The rest is lumped as Flags.
Maybe BLAM/node2bbs need adjustments to account for the standards it is not aware of. If those programs are parsing INA IBN etc.. I can see
where consistency would matter. I don't envy your task.
FsXNet is well poised to take FTN into the 21st century. The zone
number is an apt indication! LOL
Infact.. the original nodelist *was* a bbs list.
It listed the systems that wanted a way to move netmail from their
bbses. Those systems were bbses open to the regular public. A user
could take that list, and just use the phone number to call manually.
Now, some people just want to *think* of the nodelist as a mailer-only oriented guide completely from the days of its inception. But I don't
buy it. The "thought process" basically devolved it into a
machine-only list.
FsXNet is well poised to take FTN into the 21st century. The zone
number is an apt indication! LOL
Infact.. the original nodelist *was* a bbs list.Bzzzt! Wrong.
The nodelist has always contained info for mailer sessions. Most entries
Infact.. the original nodelist *was* a bbs list.
Bzzzt! Wrong.
The nodelist has always contained info for mailer sessions. Most
entries
So the only point that breaks down for me, is why was the "MO" flag created, if the nodelist was never intended for human consumption as
well?
Sure, as technology as evolved, mailers no longer use POTS to
communicate, but IP - so port definitions were created to faciliate
that. I think its reasonable for the human element to evolve to
include the port info as well.
THAT is a very good observation! If, as many seem to say that the nodelist is only for mailers, then the existence of the MO flag contradicts that claim. MO flag reveals that there is BBS factor that
was eventually considered in the nodelist.
A system without MO is announcing there is a BBS at that node.
Therefore, why not now include BBS info that fits today's use of IP connections in lieu of POTS.
The nodelist is and always has been for automating mail transfer
not BBS lookups/calls.
I concede. But I still don't believe why that cannot change for the
21st century.
The nodelist has evolved, the most recent evolution was the
inclusion of protocol:port numbers. There have been other
evolutions too but that will suffice for this example.
o The FidoNet NodeList is compiled so that computer systems
within FidoNet may communicate with each other.
Yes.. the "computer systems" assumes machines only.
Who authored that? Somebody who forgot about the MO flag? :)
What does the U,MOB entry *do* ?
How can today's mailers use it?
THAT doesn't seem to break any compilers. ;)
The nodelist has evolved, the most recent evolution was the
inclusion of protocol:port numbers. There have been other
evolutions too but that will suffice for this example.
The most recent change was allowing -Unpublished- for the phone number without having to have the PVT flag at the start of the node's line
entry.
But why *can't* the nodelist evolve into indicating bbs info too?
--- ENiGMA 1/2 v0.0.11-beta (linux; x64; 12.13.1)NuSkooler
Xibalba BBS @ xibalba.l33t.codes / 44510(telnet) 44511(ssh)
ENiGMA 1/2 BBS WHQ | Phenom | 67 | iMPURE | ACiDic
On Monday, June 1st Ogg muttered...
But why *can't* the nodelist evolve into indicating bbs info too?
"Your scientists were so preoccupied with whether or not they could,
they didn't stop to think if they should."
A flat file database, or whatever format you choose (json? xml?) with a parser that could generate a nodelist would be interesting.
I'd also like to be able to pull a telnet client dialing directory out
of it, too - since you'd be gathering user context info like hostname
and non- standard port info.
validity of the nodelist being used (smh). I have one more apology after this one, which I'm sure I'll discover later .. however I do sincerly apologize for bringing this topic up. I don't know how I framed up the
Re: Re: Nodelist Development
By: The Godfather to stizzed on Tue Jun 02 2020 02:10 am
validity of the nodelist being used (smh). I have one more apology a this one, which I'm sure I'll discover later .. however I do sincerly apologize for bringing this topic up. I don't know how I framed up t
I dont think you need to apologise.
I actually think what we talked about is good. Sure I have a view and others have a different one, but then, that's life.
At the end of the day, I dont mind which way we go - and even if its not the way "I would do it"... but I think the requirement is a worthy one.
On 06-01-20 14:19, Ogg wrote to Vk3jed <=-
But why *can't* the nodelist evolve into indicating bbs info too?
The U flag could be used for that and still remain compliant as one
last person in the fstc_public echo demonstrated with a good example.
Or.. utilize the system-name field to identify bbs connection info, of which there was also a good example.
What is wrong with the nodelist serving mailer info *and* providing bbs info?
On 06-01-20 15:03, Ogg wrote to Vk3jed <=-
Hello Vk3jed!
** On Sunday 31.05.20 - 16:21, Vk3jed wrote to Avon:
And here's another reason for using something other than a nodelist.
Using nodelists would generate a gazillion entries (well over a dozen)
for this one system, one for each AKA, while a user oriented BBS
listing would would only need one.
Why would the same nodelist need additional AKAs? Just pick one, especially the one affiliated with the fsxnet nodelist that is a member
of fsxnet and that serves its echos.
I can already "serve up" (ie. lookup) BBS info with OpenXP's nodelist search. Most IBN INA flags already match the FQDN that I would need to use in Netrunner, for example. The only thing missing might be the SSH
or true telnet port intended for a manual login. However, I use a combination of telnetbbsguide and ipingthereforeiam to track down the correct port number.
On 06-02-20 14:04, tenser wrote to poindexter FORTRAN <=-
Even better: make DNS the source of record and derive
a textual nodelist for legacy software from that. So
many thorny problems come out in the wash.
I appreciate the work you're doing on this. Doesn't sound like you're going to please everyone, nor are you required to even try. I had
someone suggest I learn to script and change it myself. Obviosly, I'm working toward being able to do so within many areas I'm excited to
learn, but not there yet. It's your time, your decision. I think the
horse is beaten and its really up to a network owner and or someone that knows how to script, to partnet up and test it out. I'm happy to be someone who tests, as thats a way I can contribute NOW. If that task doesn't want to be taken on by either, then it's a dead horse, in which case it would be worthwhile for SysOps removing the popular mod from
their own BBS's so it's not negatively impacting others by defaulting to port 23 -- and there are many who use it; some of which are debating the validity of the nodelist being used (smh). I have one more apology
after this one, which I'm sure I'll discover later .. however I do sincerly apologize for bringing this topic up. I don't know how I
framed up the question, however, my intent was to ask if anyone who had the mod had discovered the "fix," and to delectaly point out to those BBS's using it that the dang thing wasn't working. I shall be more careful with my questions moving forward.
Interesting option to explore. Whatever is used, I agree on using that source to generate the legacy nodelist format. If it's decided that DNS is not the best formt either, that information could also be generated.
I'm confident that you will get there. I also think we will make a great team!
Yeah, I am coming to the conclusion that the new BBSINFO format is where we are going. I have been exactly in the middle since this started and
I'll gladly test and provide input as you like. If you work on the GY-BLAM portion, I'd like to dinker with a set of menus that can be
added to highlight the mods full capability. It's really a cool mod that I'm working on to use on other areas of the BBS in my spare time -- to learn coding.
On 06-03-20 03:33, tenser wrote to Vk3jed <=-
On 02 Jun 2020 at 09:35p, Vk3jed pondered and said...
Interesting option to explore. Whatever is used, I agree on using that source to generate the legacy nodelist format. If it's decided that DNS is not the best formt either, that information could also be generated.
Sure. It's all text; it's malleable and easily converted
from one format to another.
The bit about DNS that's useful is that it's distributed,
redundant, reliable, and requires little maintenance once
set up. For FSXNet this isn't such a big deal, really,
but for other networks with decentralized control it allows
for decentralized maintenance.
Here's a sketch of what a zone (in the DNS sense) source file
might look like for a hypothetical nodelist entry:
| Sysop: | Weed Hopper |
|---|---|
| Location: | Clearwater, FL |
| Users: | 14 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 102:48:13 |
| Calls: | 40 |
| Files: | 50,067 |
| D/L today: |
99 files (17,373K bytes) |
| Messages: | 268,227 |