• Re: Suggestions: Area Ind

    From ACCESS DENIED@46:1/701 to AVON on Thu Jan 31 19:20:24 2019
    Hello Avon,

    On 14 Sep 14 14:09, Avon wrote to All:

    - allow for sorting of message bases by another variable
    (customisable). I have usenet echoareas linked to a fidonet address because of the gateway used but they all appear as if part of my
    FidoNet list of echoareas :-( If there was a seperate var. I could associate with each message base and then sort by it using the area
    index reader that would be good.

    Is there a specific reason you're using your Fidonet address when gating these newsgroups over? If they have nothing to do with Fidonet, you can probably set them to a different address, which would separate them from your other areas.

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20130910
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (46:1/701)
    Synchronet thePharcyde_ >> telnet://bbs.pharcyde.org (Wisconsin)
  • From G00R00@46:1/127 to AVON on Thu Jan 31 19:20:24 2019
    I have usenet echoareas linked to a fidonet address because of the
    gateway used but they all appear as if part of my FidoNet list of echoareas :-( If there was a seperate var. I could associate with each

    You already can define how they are divided into topics, by using the Network Addresses.

    If you want to separate them from FidoNet, try to make a UseNet category in your Network Addresses and assign that address to those bases. In other words:

    Address: Your FidoNet address
    Domain: fidonet
    Primary: No
    Description: UseNet Newsgroups

    Then assign that address to your newsgroup bases. They should show up within
    a category called "UseNet Newsgroups" in the listing after that.

    --- Mystic BBS v1.10 A52 (Windows)
    * Origin: Sector 7 [Mystic BBS WHQ] (46:1/127)
    Synchronet thePharcyde_ >> telnet://bbs.pharcyde.org (Wisconsin)
  • From AVON@46:3/103 to ACCESS DENIED on Thu Jan 31 19:20:24 2019
    On 09/14/14, Access Denied pondered and said...

    Is there a specific reason you're using your Fidonet address when gating these newsgroups over? If they have nothing to do with Fidonet, you can probably set them to a different address, which would separate them from your other areas.

    I use Nick Andre's Usenet service, they arrive with a FTN style address from the system that does the gating. If I want to post a reply I need to send it back via the same address.


    `I'm not expendable, I'm not stupid, and I'm not going' - Kerr Avon, Blake's 7

    --- Mystic BBS v1.10 A52 (Windows)
    * Origin: Agency BBS | telnet://agency.bbs.geek.nz (46:3/103)
    Synchronet thePharcyde_ >> telnet://bbs.pharcyde.org (Wisconsin)
  • From AVON@46:3/103 to G00R00 on Thu Jan 31 19:20:24 2019
    On 09/14/14, g00r00 pondered and said...

    You already can define how they are divided into topics, by using the Network Addresses.

    The thing is they arrive with a specific FTN address used by the gateway so
    if I change them to a different network address but still export using the echomail node I need to use.. will it work?

    I'm picking it will solve the display issue I have with my listings but introduce an issue posting back as the packet will have a bogus address on
    them and likely not be recognised by the gateway?


    `I'm not expendable, I'm not stupid, and I'm not going' - Kerr Avon, Blake's 7

    --- Mystic BBS v1.10 A52 (Windows)
    * Origin: Agency BBS | telnet://agency.bbs.geek.nz (46:3/103)
    Synchronet thePharcyde_ >> telnet://bbs.pharcyde.org (Wisconsin)
  • From WKITTY42@46:1/132 to AVON on Thu Jan 31 19:20:24 2019
    On 09/15/14, Avon said the following...

    I use Nick Andre's Usenet service, they arrive with a FTN style address from the system that does the gating. If I want to post a reply I need
    to send it back via the same address.

    this is definitely one instance where having the index reader grouping the areas by group would be very nice... in fact, it could do both or one or the other depending on how james decides to do the coding for it if he accepts
    the challenge ;)

    i started to suggest just switching the code to use the defined group assignments but then realized that grouping by address as current and then subgrouping by assigned group would be nice in some cases, too...

    FWIW: i think that this was also brought up in the past but perhaps the
    example given wasn't all that good... i dunno and i don't recall it i brought it up or if tess or someone else did...

    --- Mystic BBS v1.10 A52 (Windows)
    * Origin: (46:1/132)
    Synchronet thePharcyde_ >> telnet://bbs.pharcyde.org (Wisconsin)
  • From G00R00@46:1/127 to AVON on Thu Jan 31 19:20:24 2019
    The thing is they arrive with a specific FTN address used by the gateway so if I change them to a different network address but still export
    using the echomail node I need to use.. will it work?

    You are not using a different address. Use the same address with a different description (ie, UseNet) and then use that for the bases.

    --- Mystic BBS v1.10 A52 (Windows)
    * Origin: Sector 7 [Mystic BBS WHQ] (46:1/127)
    Synchronet thePharcyde_ >> telnet://bbs.pharcyde.org (Wisconsin)
  • From AVON@46:3/103 to G00R00 on Thu Jan 31 19:20:24 2019
    On 09/15/14, g00r00 pondered and said...

    You are not using a different address. Use the same address with a different description (ie, UseNet) and then use that for the bases.

    OK Will do thanks :-)


    `I'm not expendable, I'm not stupid, and I'm not going' - Kerr Avon, Blake's 7

    --- Mystic BBS v1.10 A52 (Windows)
    * Origin: Agency BBS | telnet://agency.bbs.geek.nz (46:3/103)
    Synchronet thePharcyde_ >> telnet://bbs.pharcyde.org (Wisconsin)
  • From G00R00@46:1/127 to AVON on Thu Jan 31 19:20:24 2019
    You are not using a different address. Use the same address with a different description (ie, UseNet) and then use that for the bases.

    OK Will do thanks :-)

    Let me know if that works for you!

    --- Mystic BBS v1.10 A52 (Windows)
    * Origin: Sector 7 [Mystic BBS WHQ] (46:1/127)
    Synchronet thePharcyde_ >> telnet://bbs.pharcyde.org (Wisconsin)
  • From AVON@46:3/103 to G00R00 on Thu Jan 31 19:20:24 2019
    On 09/15/14, g00r00 pondered and said...

    Let me know if that works for you!

    It didn't..

    Sep 16 21:12:28 Polling BINKP node 1:229/426
    Sep 16 21:12:28 Connecting to bbs.darkrealms.ca
    Sep 16 21:12:29 Connected
    Sep 16 21:12:29 DEBUG AuthState: 1 HH:0 NH:1
    Sep 16 21:12:29 DEBUG S NUL SYS Agency BBS
    Sep 16 21:12:29 DEBUG S NUL ZYZ Avon
    Sep 16 21:12:29 DEBUG S NUL VER Mystic/1.10 binkp/1.0
    Sep 16 21:12:29 DEBUG S ADR 3:772/1@fidonet 3:772/0@fidonet 3:770/0@fidonet 3:770/1@fidonet 3:57/0@fidonet 3:770/1@fidonet
    Sep 16 21:12:29 DEBUG AuthState: 2 HH:0 NH:1
    Sep 16 21:12:29 DEBUG R NUL OPT CRAM-MD5-9bfece4e4e101db8457525ee3fba99ee
    Sep 16 21:12:29 DEBUG AuthState: 2 HH:1 NH:0
    Sep 16 21:12:29 DEBUG R NUL SYS Darkrealms
    Sep 16 21:12:29 SYS Darkrealms
    Sep 16 21:12:29 DEBUG R NUL ZYZ Nick Andre
    Sep 16 21:12:29 ZYZ Nick Andre
    Sep 16 21:12:29 DEBUG R NUL LOC Toronto ON
    Sep 16 21:12:29 LOC Toronto ON
    Sep 16 21:12:29 DEBUG R NUL NDL 9600,TCP,BINKP
    Sep 16 21:12:29 NDL 9600,TCP,BINKP
    Sep 16 21:12:29 DEBUG R NUL TIME Tue, 16 Sep 2014 05:12:46 -0400
    Sep 16 21:12:29 TIME Tue, 16 Sep 2014 05:12:46 -0400
    Sep 16 21:12:29 DEBUG R NUL VER binkd/1.0a-521/Win32 binkp/1.1
    Sep 16 21:12:29 VER binkd/1.0a-521/Win32 binkp/1.1
    Sep 16 21:12:29 DEBUG R ADR 1:1/130@fidonet 1:229/426@fidonet
    1:12/2@fidonet 1:229/0@fidonet 10:10/131@league10 46:1/109@agoranet 57:257/1@gatornet 201:201/0@dbnet 201:201/1@dbnet 201:1000/1@dbnet 618:500/1@micronet 618:500/24@micronet
    Sep 16 21:12:29 DEBUG S PWD CRAM-MD5-1f03de3bb82efe510538f494a288eec1
    Sep 16 21:12:29 DEBUG AuthState: 5 HH:0 NH:1
    Sep 16 21:12:29 DEBUG R BSY Secure AKA 3:770/1@fidonet busy
    Sep 16 21:12:29 DEBUG AuthState: 5 HH:1 NH:0
    Sep 16 21:12:29 Authorization failed

    The adding the extra 3:770/1@fidonet caused the session to fail.

    When I made the domain = usenet it worked.

    Gotta say it seems a bit strange to have to announce to the world via bink sessions an address that is bogus just so I can sort a bunch of message bases to display nicely in the index reader.

    Do you think would could just get the reader to allow bases to be displayed
    by message groups or something similar?


    `I'm not expendable, I'm not stupid, and I'm not going' - Kerr Avon, Blake's 7

    --- Mystic BBS v1.10 A52 (Windows)
    * Origin: Agency BBS | telnet://agency.bbs.geek.nz (46:3/103)
    Synchronet thePharcyde_ >> telnet://bbs.pharcyde.org (Wisconsin)
  • From G00R00@46:1/127 to AVON on Thu Jan 31 19:20:24 2019
    It didn't..

    Sep 16 21:12:29 DEBUG R BSY Secure AKA 3:770/1@fidonet busy

    So BINKD is reporting a BUSY address if the AKA is on the line twice? This doesn't seem right to me. I (or someone) should probably ask them if this is intentional behavor.

    I should be able to filter it, so that so Mystic only sends the address once.

    Gotta say it seems a bit strange to have to announce to the world via
    bink sessions an address that is bogus just so I can sort a bunch of message bases to display nicely in the index reader.

    You shouldn't have to. I wonder if this is a BINKD bug?

    Do you think would could just get the reader to allow bases to be displayed by message groups or something similar?

    Probably not. We'll see.

    Groups in Mystic are not static they are calculated dynamically. One base often has many group memberships. Most people also use a global group, some use a "local" vs "networked" group, etc. If I were to try to sort by a "group" it'd give odd results (many bases would be in the list more than once). This makes it sloppy, confusing, and difficult to synchronize data between the duplicate entries.

    Address profiles are how static groups of bases are linked in Mystic, and it has always been that way. Whats the difference between using the address to define grouping, as opposed to any other method? The only difference is where you do it in the editor.

    The real issue here is BINKD refusing the connection which I can probably fix, otherwise it works as expected.

    --- Mystic BBS v1.10 A52 (Windows)
    * Origin: Sector 7 [Mystic BBS WHQ] (46:1/127)
    Synchronet thePharcyde_ >> telnet://bbs.pharcyde.org (Wisconsin)
  • From WKITTY42@46:1/132 to G00R00 on Thu Jan 31 19:20:24 2019
    On 09/16/14, g00r00 said the following...

    It didn't..

    Sep 16 21:12:29 DEBUG R BSY Secure AKA 3:770/1@fidonet busy

    So BINKD is reporting a BUSY address if the AKA is on the line twice?

    [spock] logically speaking, it seems to be correct... [/spock]

    This doesn't seem right to me. I (or someone) should probably ask them
    if this is intentional behavor.

    sounds like a plan ;)

    I should be able to filter it, so that so Mystic only sends the address once.

    there is that, too... but should mystic allow for an address to be entered
    more than once to start with? ;)

    Gotta say it seems a bit strange to have to announce to the world via bink sessions an address that is bogus just so I can sort a bunch of message bases to display nicely in the index reader.

    You shouldn't have to. I wonder if this is a BINKD bug?

    seems to be more related to having to use system addresses multiple times to group message (and file??) areas for the index reader... it seems to be
    another plus point to altering the grouping code to use mystic groups instead of addresses...

    consider if one wants to group all bbs areas together and they are pulled
    from different networks... then there's maybe grouping all FTN related areas (bbs, tossers, mailers, etc) together and having them coming from different networks...

    Do you think would could just get the reader to allow bases to be displayed by message groups or something similar?

    Probably not. We'll see.

    here's my vote to do so...

    Groups in Mystic are not static they are calculated dynamically. One

    right but there's still the base group number that never changes... couldn't that be used as it is in other programs?

    base often has many group memberships. Most people also use a global group, some use a "local" vs "networked" group, etc. If I were to try
    to sort by a "group" it'd give odd results (many bases would be in the list more than once). This makes it sloppy, confusing, and difficult to synchronize data between the duplicate entries.

    i don't see a problem at all with areas being listed in more than one group
    if they are actually configured to be in more than one group... it seems to
    me to be expected otherwise the area would be listed in only one group,
    right? ;)

    maybe the above will help in figuring out what to do to handle this problem...

    --- Mystic BBS v1.10 A52 (Windows)
    * Origin: (46:1/132)
    Synchronet thePharcyde_ >> telnet://bbs.pharcyde.org (Wisconsin)
  • From AVON@46:3/103 to WKITTY42 on Thu Jan 31 19:20:24 2019
    On 09/16/14, wkitty42 pondered and said...

    there is that, too... but should mystic allow for an address to be
    entered more than once to start with? ;)

    Yep agree with this - we should only be able to enter an address once IMHO.


    `I'm not expendable, I'm not stupid, and I'm not going' - Kerr Avon, Blake's 7

    --- Mystic BBS v1.10 A52 (Windows)
    * Origin: Agency BBS | telnet://agency.bbs.geek.nz (46:3/103)
    Synchronet thePharcyde_ >> telnet://bbs.pharcyde.org (Wisconsin)
  • From G00R00@46:1/127 to WKITTY42 on Thu Jan 31 19:20:24 2019
    there is that, too... but should mystic allow for an address to be
    entered more than once to start with? ;)

    Why not? If the Sysop thinks that they need to create 10 address entries with the same address then whos to say they should be denied of their dreams?!?! ;)

    i don't see a problem at all with areas being listed in more than one group if they are actually configured to be in more than one group... it seems to me to be expected otherwise the area would be listed in only
    one group, right? ;)

    It can get a bit messy this way. If someone has 450 bases, 10 are local, 440 are networked and they are split across 3 networks. They have the following groups:

    1 Local - 10 bases
    2 FidoNet - 400 bases
    3 AgoraNet - 20 bases
    4 ZeroNet - 20 bases
    5 Echomail - 440 bases
    6 Global - 450 bases

    This is a legit group setup for people who use Mystic.

    In the index reader, instead of having 440 bases categorized how they are
    now, you'll end up with 1440 bases, 1000 of them being duplicate bases just showing up in different categories.

    Its confusing, and it will make the list way slower because now Mystic has to update 1440 bases on the fly instead of 440. It will also have to search the entire list every time it would normally be able to work with a single base (because it has to update the duplicate entries too).

    Lots of recoding and extra work, just for something that really doesn't "fix" anything at all, but only introduces different problems. There are pros and cons of each approach.

    The address list (the way it works now) allows the most control over things, but yes it requires duplicate addresses to be defined if a person wants to make categories within the same message network...

    As a result of that, there are never duplicate bases though and the SysOp has complete control over where each base is placed.

    If I switched to a group system, maybe I could build in a group exclusion, so like global groups could be excluded from the list. Mystic's group system doesn't support this but maybe it could.

    maybe the above will help in figuring out what to do to handle this problem...

    I'm still not completely sold on switching to groups yet but I do want to
    play with the idea. Its not like systems have 10,000 message bases anymore, anyway.

    --- Mystic BBS v1.10 A52 (Windows)
    * Origin: Sector 7 [Mystic BBS WHQ] (46:1/127)
    Synchronet thePharcyde_ >> telnet://bbs.pharcyde.org (Wisconsin)
  • From WKITTY42@46:1/132 to G00R00 on Thu Jan 31 19:20:24 2019
    On 09/17/14, g00r00 said the following...

    there is that, too... but should mystic allow for an address to be entered more than once to start with? ;)

    Why not? If the Sysop thinks that they need to create 10 address
    entries with the same address then whos to say they should be denied of their dreams?!?! ;)

    :LOL:

    i don't see a problem at all with areas being listed in more than one group if they are actually configured to be in more than one group... seems to me to be expected otherwise the area would be listed in only one group, right? ;)

    It can get a bit messy this way. If someone has 450 bases, 10 are
    local, 440 are networked and they are split across 3 networks. They have the following groups:

    i've been thinking about this for several days now and the first thing that i see is the blurring of the line between tosser message groups and bbs message groups... they are not the same thing and they really shouldn't be... tosser message groups are for limiting access to other systems linked to the message areas... bbs message groups are for limiting access to individual users on the local system...

    IIRC, the index reader is based on the functionality of golded which is an external to the bbs sysop reader... like most other external sysop readers, they generally use the tosser's message group definitions and don't know anything about the bbs' message group definitions...

    i agree with your assessment about the problems of areas being in multiple groups but that's with them being in multiple bbs message groups... areas in the tosser are only ever in one tosser message group and i don't know of any tossers that allow an area to be in more than one group...

    with that said, i would base the index reader on the tosser's message groups (not addresses!) kinda like you have now but i would separate the tosser's message groups from the bbs' message groups... additionally, linked systems can be a member of several of the tosser's message groups so that they will have access to only those areas they are allowed... there may also be a need to have read and write levels for linked systems as a system may be placed on read-only status for a message area... basically the linked systems in the tosser are like the users in the bbs... each has similar options as far as groups they
    can access and read/write premissions but that's as far as it goes...

    consider that many operators just import or set up their areas with some sort of "backbone" areas file (eg: backbone.na)... those areas are all the ones carried on that distribution system but there's no distinction made in that list for (eg:) sysop only areas... in the tosser, this distinction is not needed because systems should be able to link to those areas... in the bbs, however, users may not be allowed to even read certain sysop only areas and in many cases, they aren't allowed to write in them...

    we see the same thing when it comes to "backbone" distributed regional and zonal areas... folks in other regions or zones may not be allowed access to read and/or write in those areas... in this case, the tosser groups may be
    used to split them from the general areas while both are pulled/fed to the
    same upstream distribution system(s)... in the bbs, the groups may be similar or not but defining the segregation in the bbs on a user level is more detailed...

    files areas are in the same prediciment, too... file tosser groups are not
    the same as bbs files areas groups... there are zonal, regional and network level file areas as well as private ones that only certain systems can even know about... on the bbs level, users may or may not be allowed access...

    individual area definitions would likely end up with a second group
    definition field... the first being used as now with the security format (ACS) and the second being for the tosser group the areas belong in... so i guess
    one might consider a secondary system based ACS but i don't know...

    FWIW: every time my FE or ALLFIX add new areas to my main BBS system, i have
    to go look them over and ensure that i get the permissions set properly for them for other systems' access as well as my bbs users' access... i gotta
    find my flags fields definitions sheet again, too... that's how i was limiting access to some areas in my RA...

    eg: security 25, no flags set - general user
    security 25, A1 - visiting sysop
    security 25, A2 - Z1 user
    security 25, A1,A2 - visiting Z1 sysop
    security 25, A1,A2,A3 - visiting Z1R18 sysop
    security 25, A1,A2,A3,A4 - visiting Z1R18N3634 sysop

    so to read a general sysop area, the user would have to have flag A1 turned on. to read a Z1-Only area open to all Z1 folks, flag A2 has to be on. to read a Z1-Only Sysops-Only area flags A1 and A2 have to both be on. yeah, it can get pretty deep and demented awfully damned quick without a cheatsheet... security levels alone are not sufficient expecially when one has visiting sysops from other regions, zones and even networks... i used to try to use security levels for that but couldn't... the flags help and the combination is somewhat
    easier but there can still be holes left...

    RA has four sets of flags.... each with 8 bits... A1-A8, B1-B8, C1-C8 and D1-D8 and even they may not be enough in some cases but RA does also allow for a area definition's access to require that a flag is off... i haven't even tried to start figuring out how to use the flags offered by mystic and systems like synchronet which seem to have only 26 flags with several of those being pre-dedicated to certain tasks or options (eg: QWK network account)...

    anyway, sorry for the rambling in the FWIW section... the main parts of this message are before that and i hope i got them written decently enough to express the problem as i see it and a possible solution...

    --- Mystic BBS v1.10 A52 (Windows)
    * Origin: (46:1/132)
    Synchronet thePharcyde_ >> telnet://bbs.pharcyde.org (Wisconsin)