165
Team,

Here is my first stab at opening conversation regarding data structure and format for a new BBSINFO standard. This example would follow the Fido standard of a flat file with one record per line, CR/LF terminated with comma
delimiters and no spaces (using underscores instead). It would differ from the Fido format in that there would be data length limits.

Type BBSINFO = Record
Net : Integer; // BBS NET NUMBER
Node : Integer; // BBS NODE NUMBER
BbsName : String[30]; // BBS NAME (My New BBS)
Location : String[30]; // BBS LOCATION (City, State, Country
SysopName : String[30]; // SYSOP NAME (Johnny SysOp)
Phone : String[15]; // BBS PHONE NUMBER (888-555-1212)
BbsTN : String[30]; // BBS TELNET URL W/PORT (bbs.do ain.tld:23)
BbsWeb : String[30]; // BBS WEBSITE URL (www.bbs.domain.tld)
BbsSSH : String[30]; // BBS SSH URL W/PORT (bbs.domain.tld:2 )
Nodes : String[3]; // TOTAL # OF NODES SUPPORTED (DIALUP & TELNET)
Software : String[20]; // BBS SOFTWARE (Mystic v1.12 a45)
Delete : Boolean; // FLAG FOR DELETION BY DOWNSTREAM SYSTEMS
Verified : LongInt; // DATE INFO WAS VERIFIED
LognType : Byte; // LOGIN TYPE (1=realname/2=handle/3=choic )
cType : Byte; // BBS TYPE (1=dialup/2=telnet/3=both
Res : Array[1..6] of Byte; (CAN BE EXTENDED)
END

EXAMPLE for 'THE ROCK': ,156,The_ROCK_BBS_III,Goshen_IN,Michael_Batts,,therockbbs.net:10023,www.therock bs.net,,3,Mystic_BBS_v1.12_a45,0,20200602,2,NUL

NOTE: I have no dialup number nor do I support SSH so those records are missing (empty)

A note on record lengths: It is advisable to limit record lengths (something Fido wanted to do but by the time they considered implementation the nodelist was t too large to be considered feasible). Remember, in many cases we are working with 80 column displays so field limits will be important to providing aesthetically pleasing display from applications.

Yeah, I know, it looks alot like a nodelist but I think that it is clear
that the nodelist works for that which it was designed, getting mailers
(if not BBS's) to communicate with one another and in some cases to provide a 'phonelist'for users. Isnt this what our goals are? As I said at the top,
this is just my toss-up to get the conversation started, should Avon decide to go in the direction of a BBSINFO standard. If there are recommendations from developers to t he contrary it would be helpful to provide your own examples of what the structure would look like. Non-programmers might just want to present their ideas, explanations and reasons.

This may be way off base and my feelings wont be hurt if its totally shot down.
However, I would expect the courtesy of a similar effort being presented in rebuttal.

Thanks!!!!

.\\ichael Batts
a.k.a. stizzed (because, why not?)
SysOp, The ROCK BBS III

--- Mystic BBS v1.12 A45 2020/02/18 (Windows/32)
* Origin: The ROCK bbs III - therockbbs.net - TELNET:10023 (21:4/156)

On 02 Jun 2020, stizzed said the following...

BbsTN : String[30]; // BBS TELNET URL W/PORT (bbs.do ain.tld:23)
BbsSSH : String[30]; // BBS SSH URL W/PORT (bbs.domain.tld:2 )

I haven't been following this closely, so maybe this has been discussed. If so, feel free to disregard.

Should there be specific fields mapped to only certain protocols like BbsTn & BbsSH?

If we want to consider the future and also take other protocols into consideration (like rlogin for example), would it be better to have a BbsURI1
& BbsURI2 and then specify the protocol in the data field?

e.g:

BbsURI1 : String[40]; // FULL BBS URL W/PORT (telnet://bbs.domain.tld:23) BbsURI2 : String[40]; // FULL BBS URL W/PORT (rlogin://bbs.domain.tld:513)

Then if something new & snazzy comes out like SSH 3.0, the existing fields
can simply be updated with a new protocol (e.g. ssh3://blah) instead of
having to add a new field down the road.

This would also reduce the risk of having a field that largely goes unused in the future like the phone number field in the current nodelist.

It of course would add come complexity when parsing/compiling the file, for sure, but may save some headaches down the road.


Jay

--- Mystic BBS v1.12 A45 2020/02/18 (Windows/32)
* Origin: Northern Realms BBS | bbs.nrbbs.net | Binbrook, ON (21:3/110)

165
Hi Jay!

Should there be specific fields mapped to only certain protocols like BbsTn & BbsSH?

If we want to consider the future and also take other protocols into consideration (like rlogin for example), would it be better to have a BbsURI1 & BbsURI2 and then specify the protocol in the data field?

e.g:

BbsURI1 : String[40]; // FULL BBS URL W/PORT (telnet://bbs.domain.tld:23) BbsURI2 : String[40]; // FULL BBS URL W/PORT (rlogin://bbs.domain.tld:513)

Then if something new & snazzy comes out like SSH 3.0, the existing
fields can simply be updated with a new protocol (e.g. ssh3://blah) instead of having to add a new field down the road.

This would also reduce the risk of having a field that largely goes
unused in the future like the phone number field in the current nodelist.

It of course would add come complexity when parsing/compiling the file, for sure, but may save some headaches down the road.

Thanks for jumping in!

I COMPLETELY agree! That makes better sense. Using the (initial)
known identifiers of telnet://, rlogin://, ssh://, www://, etc... With no limit on the identifiers? Is that what you're thinking? Any other
identifiers you thinking about?

.\\ichael Batts
a.k.a. stizzed (because, why not?)
SysOp, The ROCK BBS III

--- Mystic BBS v1.12 A45 2020/02/18 (Windows/32)
* Origin: The ROCK bbs III - therockbbs.net - TELNET:10023 (21:4/156)

On 02 Jun 2020 at 01:35p, stizzed pondered and said...

Here is my first stab at opening conversation regarding data structure
and format for a new BBSINFO standard. This example would follow the
Fido standard of a flat file with one record per line, CR/LF terminated with comma delimiters and no spaces (using underscores instead). It
would differ from the Fido format in that there would be data length limits.

This conflates two things:

1. A text serialization of some structured data.
2. A binary format for a data structure representing that data.

For (2), specific record layouts are an implementation detail.
For a specification that is (presumably) implemented by many
different systems, there's no need to specify them; they will
vary by language and target system.

For (1), if you're already making a departure from the existing
nodelist format, then take the opportunity to use one of the
many existing structured text formats. JSON and its variants,
protocol buffers or a variant and their text serializations,
even XML would have significant advantages over an ersatz format.
In particular, they're all extensible and parsers exist for any
number of languages and environments.

In other words, what you really want to define isn't so much a
file format as a schema.

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

On 02 Jun 2020, stizzed said the following...

no limit on the identifiers? Is that what you're thinking? Any other identifiers you thinking about?

Correct, no limit on protocol identifiers. It also might be worthwhile
upping the character limit on those URI fields. If my domain name was northernrealmsbbs.com, that's already 22 characters.

The only other identifier I can come up with off hand would be gopher, but there may be more.

Perhaps we could eliminate the BbsWeb and just include 3 or 4 BbsURI fields, that way if someone accepts telnet, ssh & rlogin but they don't have a
website, they could also advertise their gopher hole. (I think that's what they're called?)

Jay

--- Mystic BBS v1.12 A45 2020/02/18 (Windows/32)
* Origin: Northern Realms BBS | bbs.nrbbs.net | Binbrook, ON (21:3/110)

165

This conflates two things:

1. A text serialization of some structured data.
2. A binary format for a data structure representing that data.

For (2), specific record layouts are an implementation detail.
For a specification that is (presumably) implemented by many
different systems, there's no need to specify them; they will
vary by language and target system.

For (1), if you're already making a departure from the existing
nodelist format, then take the opportunity to use one of the
many existing structured text formats. JSON and its variants,
protocol buffers or a variant and their text serializations,
even XML would have significant advantages over an ersatz format.
In particular, they're all extensible and parsers exist for any
number of languages and environments.

In other words, what you really want to define isn't so much a
file format as a schema.

Thanks for sorting that out for me, tenser. I was speaking more to the data that could be included than to any specific format (though it was mentioned). I could have put it in any structured format but did so I my language. I do appreciate your very quick clarification but would ask for your indulgence on these differences as we try to work through the project. Im hoping that the majority of participants see the post as a start to the conversation and not a complete or even accurate representation of what we want or need.

Thank you!!!

.\\ichael Batts
a.k.a. stizzed (because, why not?)
SysOp, The ROCK BBS III

--- Mystic BBS v1.12 A45 2020/02/18 (Windows/32)
* Origin: The ROCK bbs III - therockbbs.net - TELNET:10023 (21:4/156)

165
And yessir, referring to the conversation as a Proposed Schema is fine... ;)

.\\ichael Batts
a.k.a. stizzed (because, why not?)
SysOp, The ROCK BBS III

--- Mystic BBS v1.12 A45 2020/02/18 (Windows/32)
* Origin: The ROCK bbs III - therockbbs.net - TELNET:10023 (21:4/156)

165

On 02 Jun 2020, stizzed said the following...

no limit on the identifiers? Is that what you're thinking? Any othe identifiers you thinking about?

Correct, no limit on protocol identifiers. It also might be worthwhile upping the character limit on those URI fields. If my domain name was northernrealmsbbs.com, that's already 22 characters.

I see that. I the original nodelist developers must have considered that they didnt want to limit the field sizes until the thing became unwieldy. I can easily see that happening if we dont find a way to consolidate some of these different (but likely mostly the same) URIs...

The only other identifier I can come up with off hand would be gopher,
but there may be more.

Perhaps we could eliminate the BbsWeb and just include 3 or 4 BbsURI fields, that way if someone accepts telnet, ssh & rlogin but they don't have a website, they could also advertise their gopher hole. (I think that's what they're called?)

Never even thought about using gopher so that is a question best left to someone else. How many sysops do you think have gopher holes? ;) Do ya think that adding all these web, rlogin, gopher and other protocols is gonna raise the hackles on some who just want to stick to the old bbs stuff the way it was...??

.\\ichael Batts
a.k.a. stizzed (because, why not?)
SysOp, The ROCK BBS III

--- Mystic BBS v1.12 A45 2020/02/18 (Windows/32)
* Origin: The ROCK bbs III - therockbbs.net - TELNET:10023 (21:4/156)

On 02 Jun 2020, stizzed said the following...

think that adding all these web, rlogin, gopher and other protocols is gonna raise the hackles on some who just want to stick to the old bbs stuff the way it was...??

I think the point of this exercise is to change the way things are. Since we're not using the nodelist, we get to come up with something new.

Syncronet can be made available via http. There may very well be a Syncronet board out there that is *only* accessible via the web. If they want to be included on this new list, they would only be using one of the provided
fields.

Since we can't know which combination of protocols people are using today
or which protocols will be available in the future, maybe the most flexible method would be to give people 3 or 4 fields where they can be reached, and they can decide what goes into those fields.

Jay

--- Mystic BBS v1.12 A45 2020/02/18 (Windows/32)
* Origin: Northern Realms BBS | bbs.nrbbs.net | Binbrook, ON (21:3/110)

165

I think the point of this exercise is to change the way things are.
Since we're not using the nodelist, we get to come up with something new.

Yeap!

Since we can't know which combination of protocols people are using today or which protocols will be available in the future, maybe the most flexible method would be to give people 3 or 4 fields where they can be reached, and they can decide what goes into those fields.

I think that we will be forced to develop TAGS that can be used as
identifiers within those fields. If we do so then the number of fields could be limitless. I do still believe that the field lengths should be limited, however.

.\\ichael Batts
a.k.a. stizzed (because, why not?)
SysOp, The ROCK BBS III

--- Mystic BBS v1.12 A45 2020/02/18 (Windows/32)
* Origin: The ROCK bbs III - therockbbs.net - TELNET:10023 (21:4/156)

BbsName : String[30]; // BBS NAME (My New BBS)
Location : String[30]; // BBS LOCATION (City, State, Country
SysopName : String[30]; // SYSOP NAME (Johnny SysOp)
Phone : String[15]; // BBS PHONE NUMBER (888-555-1212)
BbsTN : String[30]; // BBS TELNET URL W/PORT (bbs.domain.:23)
BbsWeb : String[30]; // BBS WEBSITE URL
BbsSSH : String[30]; // BBS SSH URL
W/PORT (bbs.domain.tld:2 )
Nodes : String[3]; // TOTAL # OF

A couple of notes.

Make the lengh of the fields that are 30 char longer. If your going to
list the website url for example, 30 characters will run out very
quickly.

Make the phone number have ebough for a country code (+61-xxx-xxx-xxxx),
then people wont have to look it up.

Listing the telnet/ssh etc ports with the domain lised is going to add
more. How about just list the protocols and port.





\/orlon
VK3HEG


--- MagickaBBS v0.15alpha (Linux/armv6l)
* Origin: \/orlon Empire: Sector 550 (21:1/195.1)

Make the lengh of the fields that are 30 char longer. If your going
to list the website url for example, 30 characters will run out
very quickly.

I don't think an arbitary length should be set at all.

Maybe a length is required for data structures in MPL - then I guess MPL
will have to truncate long strings, but theres always going to be
something that doesn't fit.

But that is implementation specific, and not required if using a format
like JSON, YAML, XML, etc.

I think making a document that looks like a nodelist but isn't a node
list is a really bad idea, it might make it easier to port code that
reads a nodelist, but it makes it harder for any other purpose.

Andrew


--- MagickaBBS v0.15alpha (Linux/x86_64)
* Origin: HappyLand - telnet://magickabbs.com:2023/ (21:1/126)

On 03 Jun 2020 at 04:37p, apam pondered and said...

I don't think an arbitary length should be set at all.

Indeed. It's 2020; most languages support strings that are
variable length. Fixed-length records are kind of silly.

I think making a document that looks like a nodelist but isn't a node
list is a really bad idea, it might make it easier to port code that
reads a nodelist, but it makes it harder for any other purpose.

I agree with everything that apam wrote.

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

tenser around Wednesday, June 3rd...

I agree with everything that apam wrote.

+1



--

NuSkooler
Xibalba BBS @ xibalba.l33t.codes / 44510(telnet) 44511(ssh)
ENiGMA 1/2 BBS WHQ | Phenom | 67 | iMPURE | ACiDic

--- ENiGMA 1/2 v0.0.11-beta (linux; x64; 12.13.1)
* Origin: Xibalba -+- xibalba.l33t.codes:44510 (21:1/121)

On 02 Jun 2020 at 01:35p, stizzed pondered and said...

Team,

Here is my first stab at opening conversation regarding data structure
and format for a new BBSINFO standard. This example would follow the

Thanks for putting this forward. :)

I'm going to comment on the fields first as opposed to how they could be captured, their specs etc.

Net : Integer; // BBS NET NUMBER
Node : Integer; // BBS NODE NUMBER

Have you considered Zone? I'm just wondering if it would be necessary to capture that for anything, granted there are a number of zones in use in FTN land and a BBS could be a member of several. Perhaps all the more reason to capture the info?

BbsName : String[30]; // BBS NAME (My New BBS)
Location : String[30]; // BBS LOCATION (City, State, Country
SysopName : String[30]; // SYSOP NAME (Johnny SysOp)

all things I would expect to see, mirrors the key info in a nodelist really.

Phone : String[15]; // BBS PHONE NUMBER (888-555-1212)

I guess, but phone is going the way of the dinosaur. I guess if this is all about trying to provide as much info on a system that *may* offer this connectivity then I agree keep it on the list.

BbsTN : String[30]; // BBS TELNET URL W/PORT (bbs.do ain.tld:23)
BbsSSH : String[30]; // BBS SSH URL W/PORT (bbs.domain.tld:2 )

I wonder if there are other protocols worth capturing? Does for example TOR count?

BbsWeb : String[30]; // BBS WEBSITE URL (www.bbs.domain.tld)

Yep

Nodes : String[3]; // TOTAL # OF NODES SUPPORTED (DIALUP & TELNET)

Not of interest to me but could be to some I guess...

Software : String[20]; // BBS SOFTWARE (Mystic v1.12 a45)

Yep

Delete : Boolean; // FLAG FOR DELETION BY DOWNSTREAM SYSTEMS

I don't understand that one

Verified : LongInt; // DATE INFO WAS VERIFIED

I guess this speaks to some external checking system right?

LognType : Byte; // LOGIN TYPE (1=realname/2=handle/3=choic )
cType : Byte; // BBS TYPE (1=dialup/2=telnet/3=both

If we have telnet and say phone number defined would we need BBS TYPE?

Not sure if LOGIN TYPE is needed, but yeah can see how some would want to
state that.

How about something for Networks carried?

Perhaps something for times available if it was say only running weeknights
and weekends?

Perhaps something to capture some info about the theme of the BBS or assign a number of tags to capture some high level categorization of the BBS

Something to denote Country

Something to capture languages available on the system e.g. English and
Spanish echos

Something that could (a bit like the verified tag) show days uptime / last heard from..

Perhaps if the system could report number of callers per day something to capture that, calls per week, per month, year ... most active day, most inactive day of the week.

Just some rando ideas :)

A note on record lengths: It is advisable to limit record lengths (something Fido wanted to do but by the time they considered implementation the nodelist was t too large to be considered feasible). Remember, in many cases we are working with 80 column displays so field limits will be important to providing aesthetically pleasing display
from applications.

I think as to how the data could be stored, the format etc. I also thought of something like a JSON format that is extensible (and I'm not an active user
of this data format) but my hunch is it would be more useful to contemporary coders as a way of getting data in/out of this file.

To the suggestions of using DNS, yes I also see merit, but I would like to suggest we try to find a way where we don't depend solely on DNS as the solution if we were to apply something being worked on as a file format /
data base to DNS.

Good in my view to have more than one way to get at the data or modify it.

I do like a decentralized approach and wonder aloud how correct data entry of records by those contributing could be for want of a better word policed such that duff or incomplete data was not accepted in any given data field?

If we did use DNS records (and again I am showing my lack of knowledge here) could software
1) scrape a nodelist
2) parse that to DNS text etc records
3) allow people via web admin form/portal to add of amend perhaps not the actual zone file records up front, but edit what the contents of some of the TXT fields would be using some kind of online form?

That software could generate some agreed nightly JSON or similar file that could be peered between a number of systems like a daily master nodelist and used by devs as another source of data for applications to pull info from.

I'm just trying to figure out how data however it is rendered and stored is best updated and by whom and how as time goes by?

So many questions :)

This is fun.

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

165
Hey Avon!

Thanks for putting this forward. :)

No problem, just trying to keep things moving. There are folks out there better than I to help see it through but we need to keep talking about it and it seemed we were stuck on whether of not to use the existing nodelist. I sensed that a new format was the favorite and your response seems to confirm that! ;)

I'm going to comment on the fields first as opposed to how they could be captured, their specs etc.

Net : Integer; // BBS NET NUMBER
Node : Integer; // BBS NODE NUMBER

Have you considered Zone? I'm just wondering if it would be necessary to capture that for anything, granted there are a number of zones in use in FTN land and a BBS could be a member of several. Perhaps all the more reason to capture the info?

That depends upon whether or not this is a tiered network requiring
membership or just a file that is maintained by someone. If we just want a file that is maintained by someone then jumping on the Telnet BBS List is probably something to consider. I think that the idea of a list
maintained by a single person has already been rejected as problematic if/when that person is no longer interested. In any case, my first blush was to copy the existing zone,net, node list format to make conversion simpler. If that
is unpopular or unnecessary then we can do whatever the spirit moves us to
do. Or, better put, whatever we can get the group to agree on.

BbsName : String[30]; // BBS NAME (My New BBS)
Location : String[30]; // BBS LOCATION (City, State, Country
SysopName : String[30]; // SYSOP NAME (Johnny SysOp)

all things I would expect to see, mirrors the key info in a nodelist really.

Yes, but see above for reasons for and against...

Phone : String[15]; // BBS PHONE NUMBER (888-555-1212)

I guess, but phone is going the way of the dinosaur. I guess if this is all about trying to provide as much info on a system that *may* offer
this connectivity then I agree keep it on the list.

I think that it is still maintained in modern lists such as the Telnet BBS List as many nostalgic SysOps are still running dialup. Should we exclude them for 15 characters in a datafile? (asking for a friend)... ;)

BbsTN : String[30]; // BBS TELNET URL W/PORT (bbs.do ain.tld:23
BbsSSH : String[30]; // BBS SSH URL W/PORT (bbs.domain.tld:2 )

I wonder if there are other protocols worth capturing? Does for example TOR count?

Absolutely! There are already other recommendations for including other protocols that I missed.

BbsWeb : String[30]; // BBS WEBSITE URL (www.bbs.domain.tld)

Yep

Nodes : String[3]; // TOTAL # OF NODES SUPPORTED (DIALUP & TEL

Not of interest to me but could be to some I guess...

Yeap!

Software : String[20]; // BBS SOFTWARE (Mystic v1.12 a45)

Yep

;)

Delete : Boolean; // FLAG FOR DELETION BY DOWNSTREAM SYSTEMS

I don't understand that one

Something like this could be used by processors to remove entries from the list. Without a plan for distributing the list this may not be necessary.

Verified : LongInt; // DATE INFO WAS VERIFIED

I guess this speaks to some external checking system right?

A date that the entry was confirmed to be working. This was pulled from the Telnet BBS List format

LognType : Byte; // LOGIN TYPE (1=realname/2=handle/3=choic
cType : Byte; // BBS TYPE (1=dialup/2=telnet/3=both

If we have telnet and say phone number defined would we need BBS TYPE?

Again, pulled from the Telnet BBS List. And no, we would not need this if telnet and dialup data were already there.

Not sure if LOGIN TYPE is needed, but yeah can see how some would want to state that.

Lets people choose real name or handle boards. Some folks today will NOT use their real names on a board.

How about something for Networks carried?

Standardizing that data could be difficult but something to consider.

Perhaps something for times available if it was say only running weeknights and weekends?

Yeap, like the availability tags in the nodelist

Perhaps something to capture some info about the theme of the BBS or assign a number of tags to capture some high level categorization of the BBS

This is getting really detailed and I'm not sure how large we want to let this go but yes, nothing would be off the table for consideration.

Something to denote Country

Absolutely, separate fields for City, State, Country would be appropriate.

Something to capture languages available on the system e.g. English and Spanish echos

I like this one!

Something that could (a bit like the verified tag) show days uptime /
last heard from..

Depending upon how we manage the list this (like the verified tag) could be maintained. Automation and accuracy could be an issue.

Perhaps if the system could report number of callers per day something to capture that, calls per week, per month, year ... most active day, most inactive day of the week.

Perhaps difficult to capture and distribute but certainly an interesting project for a bored developer! ;)

Just some rando ideas :)

Just what we need!

A note on record lengths: It is advisable to limit record lengths (something Fido wanted to do but by the time they considered implementation the nodelist was t too large to be considered feasible Remember, in many cases we are working with 80 column displays so fie limits will be important to providing aesthetically pleasing display from applications.

I think as to how the data could be stored, the format etc. I also
thought of something like a JSON format that is extensible (and I'm not
an active user of this data format) but my hunch is it would be more useful to contemporary coders as a way of getting data in/out of this file.

To the suggestions of using DNS, yes I also see merit, but I would like
to suggest we try to find a way where we don't depend solely on DNS as
the solution if we were to apply something being worked on as a file format / data base to DNS.

Deciding on a storage format is going to be a key factor in how and who will use the list. JSON, XML, CSV, DNS, etc each have their strengths and limitations. Should we wait to decide on the format until our information needs are identified? Ill compile a list of what information to store has already been discussed and post it later today. We should probably focus on that list first?

Good in my view to have more than one way to get at the data or modify
it.

I do like a decentralized approach and wonder aloud how correct data
entry of records by those contributing could be for want of a better
word policed such that duff or incomplete data was not accepted in any given data field?

If we did use DNS records (and again I am showing my lack of knowledge here) could software
1) scrape a nodelist
2) parse that to DNS text etc records
3) allow people via web admin form/portal to add of amend perhaps not the actual zone file records up front, but edit what the contents of some of the TXT fields would be using some kind of online form?

We are going to have differing opinions on the use of DNS. DNS, like the nodelist has a standard and from where I sit the things we are discussing
today have no better chance of making it into DNS than they do the existing nodelist.

That software could generate some agreed nightly JSON or similar file
that could be peered between a number of systems like a daily master nodelist and used by devs as another source of data for applications to pull info from.

That is what I was thinking (or similar). Others will have different ideas.

I'm just trying to figure out how data however it is rendered and stored is best updated and by whom and how as time goes by?

Yeap!

So many questions :)

This is fun.

HAHAHAHA! It is...

.\\ichael Batts
a.k.a. stizzed (because, why not?)
SysOp, The ROCK BBS III

--- Mystic BBS v1.12 A45 2020/02/18 (Windows/32)
* Origin: The ROCK III - therockbbs.net - TELNET:10023 (21:4/156)