• 3D SEEN-BY

    From Avon@21:1/101 to All on Wed Dec 19 21:05:47 2018
    One for the developers.

    Do you think with newer versions of Mystic, Enigma, Magicka, Synchronet etc. that a new standard of three dimensional seen by lines could be agreed upon?

    I'm thinking how this could help solve dupe loops between systems that
    carry echomail that is linked between zones and/or are meshed between
    multiple BBS to ensure redundancy of traffic flow.

    Just thought I'd chuck this idea out for debate/discussion.

    --- Mystic BBS v1.12 A40 2018/12/16 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From deon@21:2/116.1 to Avon on Wed Dec 19 08:30:01 2018
    On 12/19/18, Avon said the following...
    Do you think with newer versions of Mystic, Enigma, Magicka, Synchronet etc. that a new standard of three dimensional seen by lines could be agreed upon?

    I've been working on this from another angle - that said I'm a long way off before having something functioning.

    I've been building a "mail hub" concept - software focused for mail hubs,
    that if used by "top of the tree" (ZCs in FTN speak) - the existing SEEN-BY standard could be used. The concept is around providing a "highly available" top the tree. The 3rd D (across zone) transfers would occur here - so 2D SEEN-BY's could remain.

    How was it done before when Fido was zones 1-6?

    I think the problem comes about, because the implementation of "the
    network" changed when IP came along - because anybody can (and do) get
    anything from anyone.

    FTN wasnt designed for this scenario from what I've learnt.

    If we all followed the existing branches, and polled our hubs (who in turn
    poll RC/ZC) - then seen-bys can stay the way they are.

    This is not followed because leaves are concerned with two things:

    * An uplink may disappear unexpectedly (loss of continuity)
    * An uplink may filter traffic

    Do you think it could ever be possible that anybody who runs an HUB could
    agree to not filter and "give notice" if they dont want to be a hub
    anymore? Oh, and by definition they carry everything for in case their downstream wants it.

    (I'm sure this is not a problem in this zone ;)

    That said, what I'm building could be used to have "highly available" hubs as well...

    ...deon

    _--_|\ | Deon George
    / \ | Chinwag BBS - A BBS on a PI in Docker!
    \_.__.*/ |
    V | Coming from the 'burbs of Melbourne, Australia

    --- Mystic BBS v1.12 A39 2018/04/21 (Raspberry Pi/32)
    * Origin: Chinwag | MysticBBS in Docker on a Pi! (21:2/116.1)
  • From NuSkooler@21:1/121 to Avon on Wed Dec 19 03:18:31 2018

    On Tuesday, December 18th Avon muttered...
    Do you think with newer versions of Mystic, Enigma, Magicka, Synchronet etc. that a new standard of three dimensional seen by lines could be agreed upon?

    I'm sure a new kludge could be developed, but the existing kludge would need to
    be as-is to work with older software.

    Are you just wanting a better way to prevent *sending* packets to systems that have alredy seen them?




    --- ENiGMA 1/2 v0.0.9-alpha (linux; x64; 10.13.0)
    * Origin: Xibalba -+- xibalba.l33t.codes:44510 (21:1/121)
  • From vk3jed@21:1/109.1 to deon on Wed Dec 19 11:24:02 2018
    On 19-Dec-2018 14:30, deon wrote to Avon <=-

    On 12/19/18, Avon said the following...
    Do you think with newer versions of Mystic, Enigma, Magicka, Synchronet etc. that a new standard of three dimensional seen by lines could be agreed upon?

    I've been working on this from another angle - that said I'm a long way off before having something functioning.

    I've been building a "mail hub" concept - software focused for mail
    hubs, that if used by "top of the tree" (ZCs in FTN speak) - the
    existing SEEN-BY standard could be used. The concept is around
    providing a "highly available" top the tree. The 3rd D (across zone) transfers would occur here - so 2D SEEN-BY's could remain.

    Hmm, still a single point of failure? :)

    How was it done before when Fido was zones 1-6?

    I think the problem comes about, because the implementation of "the network" changed when IP came along - because anybody can (and do) get anything from anyone.

    There was some of that in the POTS era - I was able to source Fidonet from at least 2 systems, but it wasn't the done thing. Today, we have Fidoweb, which deliberately uses redundant feeds, because IP makes this a lot more convenioent
    to do.

    FTN wasnt designed for this scenario from what I've learnt.

    If we all followed the existing branches, and polled our hubs (who in
    turn poll RC/ZC) - then seen-bys can stay the way they are.

    Back to single point of failure. :(

    This is not followed because leaves are concerned with two things:

    * An uplink may disappear unexpectedly (loss of continuity)
    * An uplink may filter traffic

    Yes, the first is always possible, the second shouldn't happen, but has been known to.

    Do you think it could ever be possible that anybody who runs an HUB
    could agree to not filter and "give notice" if they dont want to be a
    hub anymore? Oh, and by definition they carry everything for in case
    their downstream wants it.

    At least make it available on passthru

    (I'm sure this is not a problem in this zone ;)

    That said, what I'm building could be used to have "highly available"
    hubs as well...

    I think the expectation these days is not to have a single point of failure, because that's now easily done. In the dialup days, it wasn't economical for a
    number of reasons, but that is no longer true.


    ... Heisenberg may have slept here.
    --- MultiMail/Win
    * Origin: Bush Track BBS (21:1/109.1)
  • From Avon@21:1/101 to deon on Thu Dec 20 02:50:23 2018
    On 12/19/18, deon pondered and said...

    I've been building a "mail hub" concept - software focused for mail hubs, that if used by "top of the tree" (ZCs in FTN speak) - the existing SEEN-BY standard could be used. The concept is around providing a
    "highly available" top the tree. The 3rd D (across zone) transfers would occur here - so 2D SEEN-BY's could remain.

    I think if folks still linked in a top down manner that would work, but these days they don't, they link up, down, left and right :)

    How was it done before when Fido was zones 1-6?

    Software would strip seen-by etc. data between zones, in fact a tosser I use for my Fido HUB (Fastecho) currently has that hard coded in to it so I can't turn it off :( I'm looking to move the HUB to Mystic in the not too distant future but setting it all up (lots of echonodes and message bases) is a slow job for the holidays.

    I think the problem comes about, because the implementation of "the network" changed when IP came along - because anybody can (and do) get anything from anyone.

    I don't see that as a problem. Rather a reflection of IP traffic driving FTN communications now vs the old dial up POTS days which meant overheads were higher and connectivity was less immediate, so a top down structure helped a lot and reflected a network structure that was more geographical in nature.

    FTN wasnt designed for this scenario from what I've learnt.

    Yep

    Do you think it could ever be possible that anybody who runs an HUB could agree to not filter and "give notice" if they dont want to be a hub anymore? Oh, and by definition they carry everything for in case their downstream wants it.

    I think anyone who runs a system does so on their terms so in saying that, anything is possible (or not)

    Best, Paul

    --- Mystic BBS v1.12 A40 2018/12/16 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From deon@21:2/116.1 to vk3jed on Wed Dec 19 13:57:16 2018
    On 12/19/18, vk3jed said the following...
    Hmm, still a single point of failure? :)
    Back to single point of failure. :(

    Nope, and nope.

    I doesnt need to be "single" system at the top of the tree. It could be more than 1, (I'm thinking 3), and they could each be in sync with a single copy
    of the source. Ingest at any trunk, a single source of the truth.

    If a trunk goes offline, you poll another trunk and continue on as if it was always who you polled. This concept is pretty normal in business use cases.

    So like fidoweb I guess, but the synchronization is not done via FTN, its done a layer higher.

    ...deon

    _--_|\ | Deon George
    / \ | Chinwag BBS - A BBS on a PI in Docker!
    \_.__.*/ |
    V | Coming from the 'burbs of Melbourne, Australia

    --- Mystic BBS v1.12 A39 2018/04/21 (Raspberry Pi/32)
    * Origin: Chinwag | MysticBBS in Docker on a Pi! (21:2/116.1)
  • From Avon@21:1/101 to NuSkooler on Thu Dec 20 03:02:18 2018
    On 12/18/18, NuSkooler pondered and said...

    I'm sure a new kludge could be developed, but the existing kludge would need to be as-is to work with older software.

    Are you just wanting a better way to prevent *sending* packets to
    systems that have alredy seen them?

    There's been some instances in fido where a circular path has occurred with
    out dupe detection taking place because of interzone stripping of SEEN-BY data... and (in my view) not helped also by a lack a 3D info in the kludges. So in short, yep :)

    If an additional kludge was agreed and added would legacy systems just ignore it or could it cause harm to them if trying to process a packet with such a kludge in it?

    --- Mystic BBS v1.12 A40 2018/12/16 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Avon@21:1/101 to vk3jed on Thu Dec 20 03:17:24 2018
    On 12/19/18, vk3jed pondered and said...

    from at least 2 systems, but it wasn't the done thing. Today, we have Fidoweb, which deliberately uses redundant feeds, because IP makes this
    a lot more convenioent to do.

    Imagine something more along the lines of torrent tech that allowed BBS to
    just announce they were available to the wider network to share/send messages to others.

    In some ways a Usenet scenario also, whereby the data just flows between
    peered servers and folks just post to newsgroups/echos etc. call them what
    you will... and that post is sent out as 'news' to the other BBS

    Perhaps what we need is our developers to work on an agreed implementation of Usenet tech/methdologies but apply it to the various BBS packages.

    That way anyone can spin up a BBS and a NNTP style server or let's say a
    BBSNTP server (thinking new here :)) and hook in to available echomail areas etc and in turn relay them on to others systems they peer with.

    Downside with this (like Usenet) is that it can end up with lots of groups
    with little traffic (think fido) where really want you want (in my view) is some overarching management of group creation - much like the early days of Usenet (Big 8) - so you don't get runaway groups being created.

    Thinking as a I type

    Let's say as network admin I could allow/deny requests for fsxnet.boats to
    be created by anyone on the system as I was the authoritative owner of
    fsxnet.* .. that's also the same as Usenet with admins using PGP signed keys and control messages creating / deleting newsgroups that are signed by the owners of the hierarchies.

    Just not sure this is a good path to follow or if it's more a case of reinventing the wheel? But I like the idea of a bespoke implementation of Usenet methodologies for a 2019 BBS future network. One I'd enjoying helping
    to develop / take part in.

    But back to security, that would need to be paramount, some groups would not want to be publicly discoverable, all would want to ensure messages were transported in a secure (no man in the middle etc.) fashion. There would
    need to be a good robust delivery mechanism using a flat non hierarchal approach.

    --- Mystic BBS v1.12 A40 2018/12/16 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Vk3jed@21:1/109 to deon on Thu Dec 20 01:25:00 2018
    On 12-19-18 08:57, deon wrote to vk3jed <=-

    So like fidoweb I guess, but the synchronization is not done via FTN,
    its done a layer higher.


    So if I'm understanding, there's a "virtual hub" that is actually multiple systems, which are in a mesh configuration using some other protocol (other than traditional FTN)?


    ... Bed & Breakfast: two things the kids will never make for themselves.
    === MultiMail/Win v0.51
    --- SBBSecho 3.03-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)
  • From Vk3jed@21:1/109 to Avon on Thu Dec 20 01:40:00 2018
    On 12-19-18 22:17, Avon wrote to vk3jed <=-

    Imagine something more along the lines of torrent tech that allowed BBS
    to just announce they were available to the wider network to share/send messages to others.

    Interesting idea.

    In some ways a Usenet scenario also, whereby the data just flows
    between peered servers and folks just post to newsgroups/echos etc.
    call them what you will... and that post is sent out as 'news' to the other BBS

    OK,

    Downside with this (like Usenet) is that it can end up with lots of
    groups with little traffic (think fido) where really want you want (in
    my view) is some overarching management of group creation - much like
    the early days of Usenet (Big 8) - so you don't get runaway groups
    being created.

    It might take a bit of thought. Certainly Usenet style distribution could work, but there might need to be some control protocols to allow management of group(echo) creation. Unless it breaks something, I would still like to see some look of FTN addressing, even if the underlying transport is something totally different to what we know as FTH echomail.

    Thinking as a I type

    Let's say as network admin I could allow/deny requests for fsxnet.boats
    to be created by anyone on the system as I was the authoritative owner
    of fsxnet.* .. that's also the same as Usenet with admins using PGP signed keys and control messages creating / deleting newsgroups that
    are signed by the owners of the hierarchies.

    Just not sure this is a good path to follow or if it's more a case of reinventing the wheel? But I like the idea of a bespoke implementation
    of Usenet methodologies for a 2019 BBS future network. One I'd enjoying helping to develop / take part in.

    I'd like to see it implemented as a new transport for FTN mail. Not sure if that's too limiting, or whether we have to come up with something new. Whatever it is, the messages will need to at least partially backwards compatible with FTN in terms of internal content/headers.

    But back to security, that would need to be paramount, some groups
    would not want to be publicly discoverable, all would want to ensure messages were transported in a secure (no man in the middle etc.)
    fashion. There would need to be a good robust delivery mechanism using
    a flat non hierarchal approach.

    Agree on all counts. However, current systems have become less secure, as Internet connections have replaced landlines. So securing our links is very important, since we've dropped the ball on that one for the most part.


    ... Black holes are outa sight!
    === MultiMail/Win v0.51
    --- SBBSecho 3.03-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)
  • From deon@21:2/116.1 to Vk3jed on Wed Dec 19 15:29:35 2018
    On 12/19/18, Vk3jed said the following...
    So if I'm understanding, there's a "virtual hub" that is actually
    multiple systems, which are in a mesh configuration using some other protocol (other than traditional FTN)?

    Yup.

    What I started building (before I got distracted with ANSItex) - is a replicated mail store using CockroachDB (infact I'm going to use Cockroach
    for ANSItex as well, and the resulting mailstore).

    With CockroachDB you can have multiple "nodes" and each is a replicated/syncronised copy of the database. This synchronization is done securely.

    Since I'm a docker fan (I've probably preached that too many
    times), it would be a docker app - then folks can run it on Windows, Linux or MAC - the only pre-requesite is to install docker - and time to up and
    running is really short.

    So in a ZC model - lets say Paul was Node 1 (Z21), Al was node 2 (Z32) and
    you were node 3 (VKradio Zone - sorry, dont know your zone number).

    Data coming into Z21 would be stored in the DB, and feed to downlinks (other Z21 hubs/nodes). The ingest via Node 1 is replicated automatically to node 2 and 3 at the DB layer.

    Any VKradio nodes could also subscribe to the Z21 echos and node 3
    would supply them to Zvkradio downlinks. (The database would need to keep
    track of what was sent downstream, but dupe detecting lowers that as a
    core requirement in existing software - but I would still implement it.)

    Now, if Z21 went offline (temporarily or permanently), those Z21 downstream links could connect to Z32 or Zvkradio (manually/automatically) and collect/submit mail, BAU (as if they were always doing that).

    When Z21 came back online (same or new host), it would sync up and continue
    to feed the Z21 downlinks.

    The feed to the downlinks is via normal FTN protocols (I'm thinking Bink -
    but it should work with QWK as well I guess).

    In a related comment, I would (and plan) to include nodelist management in
    the database as well (since I need some node details in there anyway) - so nodes could "apply online", "be approved" and automatically appear in the nodelist - automating the management and distribution of it. (And I plan on using Netmail to interact with this management.)

    My thoughts about creating this are based around:
    * Making it easier for new users to connect - we now have a database of "available echos" and the ability to get them - and "online application" can get somebody online quickly.
    * Working with legacy software - so BINKP initially, but EMSI as well should
    be possible.
    * Using the original FTN "network" - hence the interaction via Netmail.
    * The debate between Fidoweb and NAB and which one is better is moot, since
    its the best of both worlds (I hope - I am hoping we can be a happy family again).
    * ZC could still "control their zone", but if folks didnt like it,
    they could jump to another zone and continue their feeds.
    * Reduce duplication. How many echos do we need on Mystic, etc?

    Now this is all sounds OK on paper - and I know there might be
    political and technical reasons why it wont work, but Im still going to
    explore it (and fine tuning it along the way if needed)...

    ...deon

    _--_|\ | Deon George
    / \ | Chinwag BBS - A BBS on a PI in Docker!
    \_.__.*/ |
    V | Coming from the 'burbs of Melbourne, Australia

    --- Mystic BBS v1.12 A39 2018/04/21 (Raspberry Pi/32)
    * Origin: Chinwag | MysticBBS in Docker on a Pi! (21:2/116.1)
  • From Digital Man@21:1/183 to Avon on Wed Dec 19 09:35:32 2018
    Re: 3D SEEN-BY
    By: Avon to All on Wed Dec 19 2018 04:05 pm

    One for the developers.

    Do you think with newer versions of Mystic, Enigma, Magicka, Synchronet etc. that a new standard of three dimensional seen by lines could be agreed upon?

    Probably not considering FTN "standards" are pretty immobile.

    I'm thinking how this could help solve dupe loops between systems that
    carry echomail that is linked between zones and/or are meshed between multiple BBS to ensure redundancy of traffic flow.

    Just thought I'd chuck this idea out for debate/discussion.

    The FidoNet "mesh" (aka "FidoWeb") solved this problem by disallowing duplicate net/node combinations between the meshed zones (1-4 or is it 1-6?), so that you really don't even need the zone number any more (it's implied if you can lookup the net/node combo). It's a stupid hack, but there are so few addresses actually used in each FidoNet zone, it's completely viable today. This feature in SBBSecho is called "ZoneBlind" and was added specifically for this purpose.

    digital man

    This Is Spinal Tap quote #19:
    Oh then, maybe it's not green. Anyway this is what I sleep in sometimes.
    Norco, CA WX: 52.2°F, 89.0% humidity, 0 mph SSW wind, 0.00 inches rain/24hrs --- SBBSecho 3.06-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)
  • From NuSkooler@21:1/121 to deon on Wed Dec 19 16:16:02 2018

    On Wednesday, December 19th deon was heard saying...
    What I started building (before I got distracted with ANSItex) - is a replicated mail store using CockroachDB (infact I'm going to use Cockroach for ANSItex as well, and the resulting mailstore).

    I'm a huge fan of Cockroach DB, good to see it mentioned here. For data backing, security, and quorum it could be ideal for something like this. It leaves legacy systems in the cold though. Handling certfiicates may be a bit of
    a pain ... maybe.

    The issue of trust still remains though. Say I'm hooked up to super fancy new encrypted messaging.... and I just export to FTN. Doh! The system is broke.

    How far have you gotten with this experiment? Certainly sounds interesting.




    --- ENiGMA 1/2 v0.0.9-alpha (linux; x64; 10.13.0)
    * Origin: Xibalba -+- xibalba.l33t.codes:44510 (21:1/121)
  • From Atreyu@21:1/176 to Avon on Wed Dec 19 18:25:57 2018
    On 19 Dec 18 16:05:47, Avon said the following to All:

    Do you think with newer versions of Mystic, Enigma, Magicka, Synchronet etc. that a new standard of three dimensional seen by lines could be agreed upon?

    I sure hope not... I would be a fierce critic of such a proposal and as Fidonet ZC1 I would strongly be against any system in my zone running it.

    I'm thinking how this could help solve dupe loops between systems that
    carry echomail that is linked between zones and/or are meshed between multiple BBS to ensure redundancy of traffic flow.

    It does not help, it just creates another kludge, another code mess, another thing for the FTSC to argue over.

    The problem with dupe-loops has to do with systems running software that either is improperly configured, or strips the seen-by's. Those Sysops
    should fix these problems by running correctly-configured or compliant software, instead of putting the onus on BBS and mailer authors to fix it all.

    Atreyu

    --- Renegade vY2Ka2
    * Origin: Joey, do you like movies about gladiators? (21:1/176)
  • From deon@21:2/116.1 to NuSkooler on Thu Dec 20 02:31:42 2018
    On 12/19/18, NuSkooler said the following...
    I'm a huge fan of Cockroach DB, good to see it mentioned here. For data backing, security, and quorum it could be ideal for something like this. It leaves legacy systems in the cold though. Handling certfiicates may
    be a bit of a pain ... maybe.

    Well, I'm hoping that it wont. The ZC(s) is(are) still "a hub", so they still feed downstream with FTN protocols for legacy environments.

    So yes, all ZCs (or possibly a collection of Hubs) would collaborate on
    keeping the database active (certficates, etc), but would talk to other
    systems using legacy protocols. (I'm thinking BINKP in the initial case, but
    it doesnt have to be just BINKP).

    I'm it might also open up a new "transport" protocol directly with the ZC
    that is secure, effecient, etc...

    The issue of trust still remains though. Say I'm hooked up to super
    fancy new encrypted messaging.... and I just export to FTN. Doh! The system is broke.

    If you want "secure" messaging yes. Anybody connected to a hub can do
    anything with the packets they receive.

    I think to have "secure" messaging, then you'd need a centralised message hub that everybody connects into... hmm... I've been thinking of that for my ANSItex BBS...

    Its the old "centralised" vs "distributed" issues. With centralised you can control it more (and control is not really the right word here, because some folks have their hairs raise on the back of the necks) and distributed means points of redundancy.

    How far have you gotten with this experiment? Certainly sounds interesting.

    Its been in my head for months, and I started building the messaging about a month ago. Then I got distracted when I put together ANSItex.

    With family and christmas, it'll slow down a bit too... :(

    ...deon

    _--_|\ | Deon George
    / \ | Chinwag BBS - A BBS on a PI in Docker!
    \_.__.*/ |
    V | Coming from the 'burbs of Melbourne, Australia

    --- Mystic BBS v1.12 A39 2018/04/21 (Raspberry Pi/32)
    * Origin: Chinwag | MysticBBS in Docker on a Pi! (21:2/116.1)
  • From Tiny@21:1/130.4 to Atreyu on Wed Dec 19 21:45:52 2018
    another thing for the FTSC to argue over.

    Nick... Come on man. The FTSC means jack squat. Othernets are the
    future, fidonet is run by 95 year old men who are stuck in 1984. You
    know this, you are the one who taught me this. Don't worry about
    fidonet, it's dead.

    Shawn

    --- MagickaBBS v0.12alpha (Linux/armv7l)
    * Origin: A Tiny slice o pi (21:1/130.4)
  • From Atreyu@21:1/176 to Tiny on Wed Dec 19 22:00:02 2018
    On 19 Dec 18 16:45:52, Tiny said the following to Atreyu:

    Nick... Come on man. The FTSC means jack squat. Othernets are the future, fidonet is run by 95 year old men who are stuck in 1984. You
    know this, you are the one who taught me this. Don't worry about
    fidonet, it's dead.

    When are we going drinking?

    Atreyu

    --- Renegade vY2Ka2
    * Origin: Joey, do you like movies about gladiators? (21:1/176)
  • From Avon@21:1/101 to Atreyu on Thu Dec 20 16:28:16 2018
    On 12/19/18, Atreyu pondered and said...

    Do you think with newer versions of Mystic, Enigma, Magicka, Synchronet that a new standard of three dimensional seen by lines could be agreed

    I sure hope not... I would be a fierce critic of such a proposal and as Fidonet ZC1 I would strongly be against any system in my zone running it.

    Interesting, OK thanks for the feedback.

    I'm thinking how this could help solve dupe loops between systems that carry echomail that is linked between zones and/or are meshed between multiple BBS to ensure redundancy of traffic flow.

    It does not help, it just creates another kludge, another code mess, another thing for the FTSC to argue over.

    But what of other zones, message networks, developers who wish to advance things in different directions other than the established technical standards that originated in Fidonet?

    FTSC folks in Fido may choose to argue but other people active in networks
    such as this one may opt to be progressive and develop new stuff, new ways of doing things etc. I think that is a good thing. It's a ethos of this network
    - being experimental :)

    My raising 3D seen-by's as a potential suggestion for developers was borne out of feedback I had got in Fido about running software that stripped interzonal kludges. You probably know that anyways :) So as part of my efforts to help progress this I've put the suggestion out there :)

    The problem with dupe-loops has to do with systems running software that either is improperly configured, or strips the seen-by's. Those Sysops

    In my case I am using Fastecho for 3:770/1 and it is hard coded to strip
    them. I've approached the author and the likelyhood for a fix is slim. I'm looking to move to Mystic as an attempted fix in the coming month.

    either is improperly configured, or strips the seen-by's. Those Sysops should fix these problems by running correctly-configured or compliant software, instead of putting the onus on BBS and mailer authors to fix
    it all.

    I am not putting the onus as you suggest. I am suggesting what I think might
    be a good idea and looking for developers to engage with to discuss the technical pros and cons of the idea.

    The technical frame of reference may (or may not be) guided by a desire to remain within the defined legacy standards of established FTN.

    Best, Paul

    --- Mystic BBS v1.12 A40 2018/12/16 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From apam@21:1/125 to Avon on Thu Dec 20 13:45:54 2018
    But what of other zones, message networks, developers who wish to
    advance things in different directions other than the established
    technical standards that originated in Fidonet?

    I think the problem would be, people would use these differing standards
    on fidonet without knowing.

    If we're going to look at building a better network, in my mind it would
    be better to be something completely different. Fidonet can then keep
    their FTN the way it is.

    Andrew

    --- MagickaBBS v0.12alpha (Linux/x86_64)
    * Origin: The Fat Sandwich - sandwich.hopto.org:2023 (21:1/125)
  • From Atreyu@21:1/176 to Apam on Wed Dec 19 23:08:51 2018
    On 20 Dec 18 08:45:54, Apam said the following to Avon:

    I think the problem would be, people would use these differing standards
    on fidonet without knowing.

    If we're going to look at building a better network, in my mind it would
    be better to be something completely different. Fidonet can then keep
    their FTN the way it is.

    The Internet? 8-)

    Atreyu

    --- Renegade vY2Ka2
    * Origin: Joey, do you like movies about gladiators? (21:1/176)
  • From Atreyu@21:1/176 to Avon on Wed Dec 19 23:23:48 2018
    On 20 Dec 18 11:28:16, Avon said the following to Atreyu:

    either is improperly configured, or strips the seen-by's. Those Sysops should fix these problems by running correctly-configured or compliant software, instead of putting the onus on BBS and mailer authors to fix it all.

    I am not putting the onus as you suggest. I am suggesting what I think might be a good idea and looking for developers to engage with to discuss the technical pros and cons of the idea.

    I am not opposed to hearing new ideas, but I am speaking from first-hand experience maintaining code for both BBS software and a major mailer/tosser package. Its easy to write Fido code, but its a nightmare when it goes wrong and its a minefield of standards that may or may not be accepted as such.

    Kludges are what they are... kludging/fudging/messing around with a standard from the mid 80's to fit the current technical needs. Maybe its better to have a new type of message network that does not use existing FTN standard, thereby absolving existing systems from being complacent in trading mail that is not "standard". The pro of that, would be not having to adhere to 1980's tech... think of WWIVNET or Relaynet (I think), the one for PC-Board.

    Atreyu

    --- Renegade vY2Ka2
    * Origin: Joey, do you like movies about gladiators? (21:1/176)
  • From Digital Man@21:1/183 to apam on Wed Dec 19 20:24:31 2018
    Re: Re: 3D SEEN-BY
    By: apam to Avon on Thu Dec 20 2018 08:45 am

    But what of other zones, message networks, developers who wish to advance things in different directions other than the established technical standards that originated in Fidonet?

    I think the problem would be, people would use these differing standards
    on fidonet without knowing.

    If we're going to look at building a better network, in my mind it would
    be better to be something completely different. Fidonet can then keep
    their FTN the way it is.

    I would agree with this. If you can't enhance FTN in a backwards compatible manner (e.g. adding new CTRL/Kludge line definitions would be fine), then there's really no point in starting with anything currently defined for FTN. It's all crap.

    digital man

    Synchronet "Real Fact" #21:
    The first commericial sale of Synchronet was to Las Vegas Playground BBS (1992).
    Norco, CA WX: 72.9°F, 42.0% humidity, 0 mph WSW wind, 0.00 inches rain/24hrs --- SBBSecho 3.06-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)
  • From Avon@21:1/101 to apam on Thu Dec 20 17:36:53 2018
    On 12/20/18, apam pondered and said...

    But what of other zones, message networks, developers who wish to advance things in different directions other than the established technical standards that originated in Fidonet?

    I think the problem would be, people would use these differing standards on fidonet without knowing.

    They could do. I guess code could be added if developers wanted their
    software to remain applicable/compatiable within Fidonet. Something like
    code that said if Zone = 1,2,3,4 then behave xyz else do 123 ... so that stuff didn't break? Sounds a pain to me though :)

    If we're going to look at building a better network, in my mind it would be better to be something completely different. Fidonet can then keep their FTN the way it is.

    Can't say I disagree :)

    --- Mystic BBS v1.12 A40 2018/12/16 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Avon@21:1/101 to Atreyu on Thu Dec 20 17:45:27 2018

    On 12/19/18, Atreyu pondered and said...

    I am not opposed to hearing new ideas, but I am speaking from first-hand experience maintaining code for both BBS software and a major mailer/tosser package. Its easy to write Fido code, but its a nightmare when it goes wrong and its a minefield of standards that may or may not
    be accepted as such.

    Yep fair enough Nick.. and I am mindful of your experience in this space. The key point you raise is the 'Fido' code and assorted standards issues and I certainly empathize with the pain it must be to juggle all of those balls.

    Kludges are what they are... kludging/fudging/messing around with a standard from the mid 80's to fit the current technical needs. Maybe its better to have a new type of message network that does not use existing FTN standard, thereby absolving existing systems from being complacent
    in trading mail that is not "standard". The pro of that, would be not having to adhere to 1980's tech... think of WWIVNET or Relaynet (I
    think), the one for PC-Board.

    I totally agree and I think some of the others that have been posting in this thread are also saying similar things. I'm totally up for it and hope we can (as a group) flesh out ideas that find common interest / acceptance between interested developers and users of the software of ways to build a new type
    of message network.

    I can't envisage many would want to go to a ton of effort to create something that may end up operating in isolation of a bunch of other similar systems.

    --- Mystic BBS v1.12 A40 2018/12/16 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Avon@21:1/101 to Digital Man on Thu Dec 20 18:03:42 2018
    On 12/19/18, Digital Man pondered and said...

    Probably not considering FTN "standards" are pretty immobile.

    I'm back tracking in my replies, but I think we both agree developing new things beyond the rigidity of established FTN standards is likely to be a
    more productive way forward :)

    The FidoNet "mesh" (aka "FidoWeb") solved this problem by disallowing duplicate net/node combinations between the meshed zones (1-4 or is it 1-6?), so that you really don't even need the zone number any more (it's implied if you can lookup the net/node combo). It's a stupid hack, but there are so few addresses actually used in each FidoNet zone, it's completely viable today. This feature in SBBSecho is called "ZoneBlind" and was added specifically for this purpose.

    I'm learning new stuff here.. so the Fido policy was along the lines of there is only one 770/1 (it happens to be in Zone 3) and no one else should create
    a 1:770/1 or 2:770/1 etc. - is that correct? Interesting. And yep, if this is true I agree it would work given the diminishing numbers of addresses etc.
    but would fail if the network went into growth. Kudos on the ZoneBlind
    feature for SBBSecho :)

    --- Mystic BBS v1.12 A40 2018/12/16 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Atreyu@21:1/176 to Avon on Thu Dec 20 00:32:34 2018
    On 20 Dec 18 13:03:42, Avon said the following to Digital Man:

    I'm learning new stuff here.. so the Fido policy was along the lines of ther is only one 770/1 (it happens to be in Zone 3) and no one else should create a 1:770/1 or 2:770/1 etc. - is that correct? Interesting. And yep, if this i true I agree it would work given the diminishing numbers of addresses etc. but would fail if the network went into growth. Kudos on the ZoneBlind feature for SBBSecho :)

    This is correct, but for a few reasons both technically and politically.

    There are many things about why stuff in Fidonet "is what it is", as my old drinking buddy used to say. Some was questionable, others ingenius in design.

    For example. Fidonet issues a different nodelist per-zone. The nodelist I produce is different than that Zone 2 and 3 and 4 produces. This was done to overcome speed and indexing issues from the days when the Nodelist compiling was done on IBM XT's and Tandy 1000's; where a typical compile could last
    over 45 minutes. Therefore, each Zone placed its Zone-centric entries at the top of the list while other zones came last. It also eliminated fighting over who would be in control of publishing the Nodelist (related to the IFNA I think). To this day, I have to carry this design decision from 1980's...

    With the proliferation of 2D-only systems having to intermix at the time with then-new 3D-systems, the stripping feature was added to many tossers. There was a bunch of mudslinging and folks creating Nets deliberately to cause havoc with Seen-by lines and all that.

    The general concensus amongst all ZC's in Fidonet now, is not to allow duplicate Net's. This is why such a stink is made about Seen-by stripping.

    Atreyu

    --- Renegade vY2Ka2
    * Origin: Joey, do you like movies about gladiators? (21:1/176)
  • From g00r00@21:1/112 to Avon on Thu Dec 20 01:12:53 2018
    Imagine something more along the lines of torrent tech that allowed BBS
    to just announce they were available to the wider network to share/send messages to others.

    Many many years ago I did have the start of "MysticNet" which was similar to what you're speaking about. But I am hesitant to push for it. I think some
    of the Synchronet people did something like that too... At the end of the day the BBS scene is too small to segregate too much based on proprietary protocols, and so we end up getting stuck with FTN.

    --- Mystic BBS v1.12 A39 2018/04/21 (Windows/32)
    * Origin: Black Flag <ACiD Telnet HQ> blackflagbbs.com (21:1/112)
  • From g00r00@21:1/112 to Atreyu on Thu Dec 20 01:17:30 2018
    Do you think with newer versions of Mystic, Enigma, Magicka, Synchronet that a new standard of three dimensional seen by lines could be agreed

    I sure hope not... I would be a fierce critic of such a proposal and as Fidonet ZC1 I would strongly be against any system in my zone running it.

    No offense here but FidoNet is probably one of the least significant factors these days. Its dead and the majority of authors pushing forward do not consider it a primary network.

    I am not suggesting we all go rogue and make a mess, but the idea that some random person on FidoNet has some sort of control over anything at this point
    I think isn't a very accurate view.

    --- Mystic BBS v1.12 A39 2018/04/21 (Windows/32)
    * Origin: Black Flag <ACiD Telnet HQ> blackflagbbs.com (21:1/112)
  • From apam@21:1/125 to Digital Man on Thu Dec 20 16:16:08 2018
    I would agree with this. If you can't enhance FTN in a backwards
    compatible manner (e.g. adding new CTRL/Kludge line definitions would
    be fine), then there's really no point in starting with anything
    currently defined for FTN. It's all crap.

    What about your work on QWK networking? Would that work in a
    decentralized way like others are wanting? As I understand it with
    dovenet, VERT is at the top of the tree, but could it be done in a way
    like Paul is thinking? If so, then we'd just have to turn on FTP-SSL,
    implement your QWK additions and good to go?

    Andrew

    --- MagickaBBS v0.12alpha (Linux/x86_64)
    * Origin: The Fat Sandwich - sandwich.hopto.org:2023 (21:1/125)
  • From Satchmo@21:4/144 to Tiny on Thu Dec 20 06:56:31 2018
    On 12/19/18, Tiny said the following...

    fidonet is run by 95 year old men who are stuck in 1984.

    This might have made me chuckle just a little bit ;-)

    --- Mystic BBS v1.12 A39 2018/04/21 (Raspberry Pi/32)
    * Origin: Sonic BBS | sonicbbs.ddns.net (21:4/144)
  • From Vk3jed@21:1/109 to deon on Thu Dec 20 17:09:00 2018
    On 12-19-18 10:29, deon wrote to Vk3jed <=-

    What I started building (before I got distracted with ANSItex) - is a replicated mail store using CockroachDB (infact I'm going to use
    Cockroach for ANSItex as well, and the resulting mailstore).

    <snip>

    Yeah, I think there's definitely merit to this idea, well worth exploring. And it would mainly be those offering hub services, as well as those who wanted multiple feeds that would implement this, with legacy systems being able to connect to individual nodes as they do today via binkp, etc.

    I also agree that the system should do its own de-duping, and not rely on other dupe detection. Having in-protocol de-duping should allow it to be 100% reliable, if properly designed. This will also take the pressure off FTN dupe checkers. We would need to ensure nodes using legacy FTN connect to the network at only one point. If they want redundant feeds, they would need to install their own "new technology" node, then feed off that.

    Since I'm a docker fan (I've probably preached that too many
    times), it would be a docker app - then folks can run it on Windows,
    Linux or MAC - the only pre-requesite is to install docker - and time
    to up and running is really short.

    Depending on what we're running, docker is a blessing or a pain. aaabut in this instance, if the system is built from the ground up for Docker, that makes sense.



    ... Hangnail: Coat hook.
    === MultiMail/Win v0.51
    --- SBBSecho 3.03-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)
  • From Digital Man@21:1/183 to Avon on Wed Dec 19 23:14:26 2018
    Re: Re: 3D SEEN-BY
    By: Avon to Digital Man on Thu Dec 20 2018 01:03 pm

    On 12/19/18, Digital Man pondered and said...

    Probably not considering FTN "standards" are pretty immobile.

    I'm back tracking in my replies, but I think we both agree developing new things beyond the rigidity of established FTN standards is likely to be a more productive way forward :)

    The FidoNet "mesh" (aka "FidoWeb") solved this problem by disallowing duplicate net/node combinations between the meshed zones (1-4 or is it 1-6?), so that you really don't even need the zone number any more (it's implied if you can lookup the net/node combo). It's a stupid hack, but there are so few addresses actually used in each FidoNet zone, it's completely viable today. This feature in SBBSecho is called "ZoneBlind" and was added specifically for this purpose.

    I'm learning new stuff here.. so the Fido policy was along the lines of there is only one 770/1 (it happens to be in Zone 3) and no one else should create
    a 1:770/1 or 2:770/1 etc. - is that correct?

    Correct, that's the new policy (as of several years ago anyway), yes.

    Interesting. And yep, if this
    is true I agree it would work given the diminishing numbers of addresses etc.
    but would fail if the network went into growth. Kudos on the ZoneBlind feature for SBBSecho :)

    Sure. Not hard. It violates the long-standing FTN specs/standards in important and critical ways (e.g. doesn't strip SEENBYs when crossing zone-blind zones) and I was very resistent to the request initially, but shrugged off the specs and just went with it. Whatever. :-)

    FTN domains are useless too. <shrug>

    digital man

    This Is Spinal Tap quote #42:
    What day the Lord created Spinal Tap and couldn't he have rested on that day? Norco, CA WX: 65.3°F, 55.0% humidity, 0 mph SSW wind, 0.00 inches rain/24hrs --- SBBSecho 3.06-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)
  • From Digital Man@21:1/183 to apam on Wed Dec 19 23:21:39 2018
    Re: Re: 3D SEEN-BY
    By: apam to Digital Man on Thu Dec 20 2018 11:16 am

    I would agree with this. If you can't enhance FTN in a backwards compatible manner (e.g. adding new CTRL/Kludge line definitions would
    be fine), then there's really no point in starting with anything currently defined for FTN. It's all crap.

    What about your work on QWK networking? Would that work in a
    decentralized way like others are wanting?

    I can't think of why not. QWK isn't really a great message networking scheme either, but at least it was easily extensible and the problems with the original QWK/QWKE specs could be pretty trivilally worked-around. It is easy to spew extraneous text in messages when things are misconfigured, and that does happen, but nobody screams too loud about it.

    As I understand it with
    dovenet, VERT is at the top of the tree, but could it be done in a way
    like Paul is thinking? If so, then we'd just have to turn on FTP-SSL, implement your QWK additions and good to go?

    I'm not really sure what the role of "FTP-SSL" is in that idea, but sure. In fact, I don't really understand the "big picture" of a decentralized but secure (encrypted) message network. I don't really get it. <shrug>

    digital man

    Synchronet "Real Fact" #91:
    Captured chat with Wayne Bell: http://wiki.synchro.net/history:waynebell_chat Norco, CA WX: 65.3°F, 55.0% humidity, 0 mph SSW wind, 0.00 inches rain/24hrs --- SBBSecho 3.06-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)
  • From NuSkooler@21:1/121 to apam on Thu Dec 20 00:21:24 2018

    On Wednesday, December 19th apam was heard saying...
    If we're going to look at building a better network, in my mind it would be better to be something completely different. Fidonet can then keep their FTN the way it is.

    This.

    I like having the oldschool FTN-style stuff. However, I'd like to build something brand new. It would be nice to get some of x/84 guys in the loop so those boards could be on as well.





    --- ENiGMA 1/2 v0.0.9-alpha (linux; x64; 10.13.0)
    * Origin: Xibalba -+- xibalba.l33t.codes:44510 (21:1/121)
  • From NuSkooler@21:1/121 to Vk3jed on Thu Dec 20 00:32:15 2018

    On Wednesday, December 19th Vk3jed was heard saying...
    I also agree that the system should do its own de-duping, and not rely on other dupe detection. Having in-protocol de-duping should allow it to be 100% reliable, if properly designed. This will also take the pressure off FTN dupe checkers. We would need to ensure nodes using legacy FTN connect to the network at only one point. If they want redundant feeds, they would need to install their own "new technology" node, then feed off that.

    Taking a Cockroach type approach, deduping isn't even really a issue. Essntially everyone would be sharing the same global, distributed database. I suppose a given DB would represent a single network. Deciding what nodes can do
    admin type tasks may be tricky.

    If the DB were just a backing, then one could have a simple protocol to go to/from that older "legacy" systems would have a easier time (think doors, etc.) interacting with.



    --- ENiGMA 1/2 v0.0.9-alpha (linux; x64; 10.13.0)
    * Origin: Xibalba -+- xibalba.l33t.codes:44510 (21:1/121)
  • From NuSkooler@21:1/121 to Digital Man on Thu Dec 20 00:34:37 2018

    On Wednesday, December 19th Digital Man was heard saying...
    Sure. Not hard. It violates the long-standing FTN specs/standards in important and critical ways (e.g. doesn't strip SEENBYs when crossing zone-blind zones) and I was very resistent to the request initially, but shrugged off the specs and just went with it. Whatever. :-)

    I implemented a couple FTN kludges slightly out of spec (similar to how SBBS does IIRC) and some of the FidoNet proper folks lost their shit over it. Seems work just fine though :)





    --- ENiGMA 1/2 v0.0.9-alpha (linux; x64; 10.13.0)
    * Origin: Xibalba -+- xibalba.l33t.codes:44510 (21:1/121)
  • From apam@21:1/125 to Digital Man on Thu Dec 20 17:35:54 2018
    I'm not really sure what the role of "FTP-SSL" is in that idea, but
    sure. In fact, I don't really understand the "big picture" of a decentralized but secure (encrypted) message network. I don't really
    get it. <shrug>

    I should probably have said FTP-TLS, it would check the box next to
    "encrypted" transfers and still work pretty much the same way as now.

    To be honest I don't really understand it either, as the messages are all public anyway. As nu pointed out it could be good for "semi-public"
    messages in that only users that are authorized can read a network - but
    I don't really see that happening.

    The decentralized part I get, in that it keeps running even if a hub goes
    down.

    What BBSes really need is synergy, the cloud and a samophlange. :)

    Andrew

    --- MagickaBBS v0.12alpha (Linux/x86_64)
    * Origin: The Fat Sandwich - sandwich.hopto.org:2023 (21:1/125)
  • From Atreyu@21:1/176 to G00R00 on Thu Dec 20 02:05:45 2018
    On 19 Dec 18 20:17:30, G00R00 said the following to Atreyu:

    No offense here but FidoNet is probably one of the least significant factor these days. Its dead and the majority of authors pushing forward do not consider it a primary network.

    I respect your opinion, no offense taken... It takes a lot to "offend" me. 8-)

    However... Mystic is being used by quite a bit of people in Fidonet, I'm
    sure you would not deny that. A lot of people love your software. I appreciate the fact that you take time to work on it, seriously.

    Yes, Fido's numbers are very low compared to the glory-days. I don't want to carry on with this topic here, I'm happy to at least get a reply from you
    about the INTL.

    Atreyu

    --- Renegade vY2Ka2
    * Origin: Joey, do you like movies about gladiators? (21:1/176)
  • From deon@21:2/116.1 to NuSkooler on Thu Dec 20 07:52:41 2018
    On 12/19/18, NuSkooler said the following...
    Taking a Cockroach type approach, deduping isn't even really a issue. Essntially everyone would be sharing the same global, distributed database.

    Actually, I'm not suggesting this approach.

    I'm only suggesting that a "group of ZCs", or a "group of Hubs" (representing the same zone) share a common DB (for redundancy) - although the "group of Hubs" is thinking aloud, I probably wouldnt suggest it that way.

    The database is a repository of "mail". IE: Echomail Areas and the messages contained within.

    Those boards then could be shared out to zones (if a zone wanted to be apart
    of it). So if, for example, FidoNet said no way, the zones 1-4 do it there
    way. If zones 21, 32, 1337 did, then those echmail areas and accompanying echomail area all in the same DB.

    Exports downstream to Z21 nodes (from ZC to a hub/node), would export a Fido packet, with SEEN-BY's, PATHs and other kludges as if it was a single zone. That way it supports the legacy software.

    ...deon

    _--_|\ | Deon George
    / \ | Chinwag BBS - A BBS on a PI in Docker!
    \_.__.*/ |
    V | Coming from the 'burbs of Melbourne, Australia

    --- Mystic BBS v1.12 A39 2018/04/21 (Raspberry Pi/32)
    * Origin: Chinwag | MysticBBS in Docker on a Pi! (21:2/116.1)
  • From Digital Man@21:1/183 to apam on Wed Dec 19 23:55:25 2018
    Re: Re: 3D SEEN-BY
    By: apam to Digital Man on Thu Dec 20 2018 12:35 pm

    I'm not really sure what the role of "FTP-SSL" is in that idea, but sure. In fact, I don't really understand the "big picture" of a decentralized but secure (encrypted) message network. I don't really
    get it. <shrug>

    I should probably have said FTP-TLS, it would check the box next to "encrypted" transfers and still work pretty much the same way as now.

    Yeah, I knew what you meant: "ftps".

    To be honest I don't really understand it either, as the messages are all public anyway. As nu pointed out it could be good for "semi-public"
    messages in that only users that are authorized can read a network - but
    I don't really see that happening.

    The decentralized part I get, in that it keeps running even if a hub goes down.

    What BBSes really need is synergy, the cloud and a samophlange. :)

    <grin>

    digital man

    Synchronet/BBS Terminology Definition #3:
    ASCII = American Standard Code for Information Interchange
    Norco, CA WX: 64.9°F, 55.0% humidity, 0 mph SSW wind, 0.00 inches rain/24hrs --- SBBSecho 3.06-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)
  • From Digital Man@21:1/183 to NuSkooler on Thu Dec 20 00:05:49 2018
    Re: Re: 3D SEEN-BY
    By: NuSkooler to Digital Man on Wed Dec 19 2018 07:34 pm


    On Wednesday, December 19th Digital Man was heard saying...
    Sure. Not hard. It violates the long-standing FTN specs/standards in important and critical ways (e.g. doesn't strip SEENBYs when crossing zone-blind zones) and I was very resistent to the request initially, but shrugged off the specs and just went with it. Whatever. :-)

    I implemented a couple FTN kludges slightly out of spec (similar to how SBBS does IIRC) and some of the FidoNet proper folks lost their shit over it. Seems work just fine though :)

    Sure. Many FTN nodes *think* they know what the specs say, when they don't. I covered one particular case (Synchronet/SBBSecho's FTN MSGID's) in detail here: http://wiki.synchro.net/faq:misc#ftn_msgid

    digital man

    Synchronet "Real Fact" #8:
    Synchronet was originally intended as a replacement for WWIV BBS software. Norco, CA WX: 64.6°F, 55.0% humidity, 0 mph SSW wind, 0.00 inches rain/24hrs --- SBBSecho 3.06-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)
  • From Avon@21:1/101 to Atreyu on Thu Dec 20 21:39:18 2018
    On 12/19/18, Atreyu pondered and said...

    old drinking buddy used to say. Some was questionable, others ingenius
    in design.

    I love this line :) I could be a quote from a history book about Fido :)

    duplicate Net's. This is why such a stink is made about Seen-by
    stripping.

    Gotcha and thanks for the recap. Really helpful :)

    --- Mystic BBS v1.12 A40 2018/12/16 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From vk3jed@21:1/109.1 to NuSkooler on Thu Dec 20 08:44:34 2018
    On 20-Dec-2018 06:32, NuSkooler wrote to Vk3jed <=-

    Taking a Cockroach type approach, deduping isn't even really a issue. Essntially everyone would be sharing the same global, distributed

    In otherwords, deduping is an inherent property of a distributed database.

    database. I suppose a given DB would represent a single network.
    Deciding what nodes can do
    admin type tasks may be tricky.

    More thought needed? :)

    If the DB were just a backing, then one could have a simple protocol to
    go to/from that older "legacy" systems would have a easier time (think doors, etc.) interacting with.

    And we want to make sure everyone is on the same page, network wise, even though they may be on different protocols.


    ... A Canadian? It's like an American, without the gun, with health care.
    --- MultiMail/Win
    * Origin: Bush Track BBS (21:1/109.1)
  • From Avon@21:1/101 to Digital Man on Thu Dec 20 22:01:14 2018
    On 12/19/18, Digital Man pondered and said...

    Sure. Not hard. It violates the long-standing FTN specs/standards in important and critical ways (e.g. doesn't strip SEENBYs when crossing zone-blind zones) and I was very resistent to the request initially, but shrugged off the specs and just went with it. Whatever. :-)
    FTN domains are useless too. <shrug>

    I get the feeling you would be happy to create 'new stuff' removed from the confines of older FTN standards etc.

    --- Mystic BBS v1.12 A40 2018/12/16 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Digital Man@21:1/183 to Avon on Thu Dec 20 01:16:09 2018
    Re: Re: 3D SEEN-BY
    By: Avon to Digital Man on Thu Dec 20 2018 05:01 pm

    On 12/19/18, Digital Man pondered and said...

    Sure. Not hard. It violates the long-standing FTN specs/standards in important and critical ways (e.g. doesn't strip SEENBYs when crossing zone-blind zones) and I was very resistent to the request initially, but shrugged off the specs and just went with it. Whatever. :-)
    FTN domains are useless too. <shrug>

    I get the feeling you would be happy to create 'new stuff' removed from the confines of older FTN standards etc.

    Yeah. I do most of my innovation (for message networking) for QWK networks (though some of those innovations extend easily to FTN or NNTP). I don't really see a need for a completely new message networking scheme. And I'd be happy to experiment and innovate on top of FTN as well, but there's a couple of issues there:
    1. Most FTN software is closed-source abandonware and thus can't likely change 2. Most of the FidoNet nodes "in charge" are very resistent to any changes
    (so any experimental changes would have to be invisible to those guys)

    digital man

    This Is Spinal Tap quote #44:
    It really, it does disturb me, but i'll rise above it; I'm a professional. Norco, CA WX: 63.3°F, 57.0% humidity, 0 mph SW wind, 0.00 inches rain/24hrs
    --- SBBSecho 3.06-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)
  • From tenser@21:1/188 to apam on Thu Dec 20 04:42:22 2018
    On 12/20/18, apam said the following...

    If we're going to look at building a better network, in my mind it would be better to be something completely different. Fidonet can then keep their FTN the way it is.

    Hear, hear!

    --- Mystic BBS v1.12 A39 2018/04/21 (Raspberry Pi/32)
    * Origin: ACiD Underworld // blackflag.acid.org:31337 (21:1/188)
  • From NuSkooler@21:1/121 to deon on Thu Dec 20 03:40:09 2018

    On Wednesday, December 19th deon was heard saying...
    Actually, I'm not suggesting this approach.

    On Wednesday, December 19th deon muttered...
    Exports downstream to Z21 nodes (from ZC to a hub/node), would export a Fido packet, with SEEN-BY's, PATHs and other kludges as if it was a single zone. That way it supports the legacy software.

    I'm curious why on both of those points? Seems like CockroachDB would be perfect to simply create a cluster for the network. The data layer (Cockroach) can be abstracted from the protocol -- again with something completely new. FTN
    already works, I don't see the point of continuing to put new tech on it really.




    --- ENiGMA 1/2 v0.0.9-alpha (linux; x64; 10.13.0)
    * Origin: Xibalba -+- xibalba.l33t.codes:44510 (21:1/121)
  • From NuSkooler@21:1/121 to Digital Man on Thu Dec 20 03:42:29 2018

    On Wednesday, December 19th Digital Man muttered...
    Sure. Many FTN nodes *think* they know what the specs say, when they don't. I covered one particular case (Synchronet/SBBSecho's FTN MSGID's) in detail here: http://wiki.synchro.net/faq:misc#ftn_msgid

    Hehe, pretty sure that's what got them fired up. ENiG's MSGID: https://github.com/NuSkooler/enigma-bbs/blob/0.0.9-alpha/core/ftn_util.js#L145

    (I even ref sync here)



    --- ENiGMA 1/2 v0.0.9-alpha (linux; x64; 10.13.0)
    * Origin: Xibalba -+- xibalba.l33t.codes:44510 (21:1/121)
  • From deon@21:2/116.1 to NuSkooler on Thu Dec 20 11:09:42 2018
    On 12/19/18, NuSkooler said the following...
    I'm curious why on both of those points? Seems like CockroachDB would be perfect to simply create a cluster for the network.

    It would, so I am suggesting that that cluster be "at the top" - IE: a highly reliable source for downstream to connect to.

    I'm assuming:
    * downstream is still legacy FTN nodes, that some people will still want to run.
    * downstream people will come and go - and some may start with old software... * "the top" are in it for the long term - and if there is a hub in the
    middle, they are in it for the long term too..
    * "the top" and "hubs" pass through everything, or rather make everything
    they see available downstream...

    I think I mentioned this before, that it then opens up an opportunity for a
    new protocol (or way) to connect directly to the top and submit to/feed from it... (which would then do away with FTN and/or hubs).

    (I'm also thinking if that there are too many at the top, its an opportunity for somebody to break something - since it is all auto replicated to
    everybody else, and therefore breaking it for everybody...)

    I personally dont see anything wrong with FTN - it gets "a mail" from "A" to "C", via "B". That side of it works well.

    Some of the reasons it has gone south of late, is because of people:
    * concerns that the top might be filtering (which leads that I'll get what I want from somebody else - and somebody else happily offers it)
    * my uplink will disappear or stop responding - and I'll loose connectivity until I re-establish it from another uplink

    (I think this has lead to other problems - ineffeciency and
    duplication )

    I'm wondering if I can help address those reasons a different way and
    hopefully get "all the zones together" since there is so few of us...

    ...deon

    _--_|\ | Deon George
    / \ | Chinwag BBS - A BBS on a PI in Docker!
    \_.__.*/ |
    V | Coming from the 'burbs of Melbourne, Australia

    --- Mystic BBS v1.12 A39 2018/04/21 (Raspberry Pi/32)
    * Origin: Chinwag | MysticBBS in Docker on a Pi! (21:2/116.1)
  • From Avon@21:1/101 to Digital Man on Fri Dec 21 00:23:35 2018
    On 12/19/18, Digital Man pondered and said...

    I get the feeling you would be happy to create 'new stuff' removed from confines of older FTN standards etc.

    Yeah. I do most of my innovation (for message networking) for QWK
    networks (though some of those innovations extend easily to FTN or
    NNTP). I don't really see a need for a completely new message networking scheme. And I'd be happy to experiment and innovate on top of FTN as
    well, but there's a couple of issues there:
    1. Most FTN software is closed-source abandonware and thus can't likely change 2. Most of the FidoNet nodes "in charge" are very resistent to
    any changes (so any experimental changes would have to be invisible to those guys)

    I'd be interested to get your thoughts as to what could / might come across from QWK (which I admit to knowing little about and of using) to the likes of NNTP etc.

    With respect to innovating on top of FTN I think you've pretty much answered your chances of doing so within (let's say) a Fido zone, here (for what it's worth) I'm totally open to experimenting with changes to FTN stuff but like
    the idea of new pathways of connectivity predicated on re-purposed or
    extended tech.

    Re new message networking scheme / protocol - I guess it all depends on what can be envisaged as being possible with such a thing and if what is mooted is seen as an advance or advantage over what is used/know of now. Dunno..

    --- Mystic BBS v1.12 A40 2018/12/16 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From vk3jed@21:1/109.1 to Digital Man on Thu Dec 20 12:36:40 2018
    On 20-Dec-2018 07:16, Digital Man wrote to Avon <=-

    of FTN as well, but there's a couple of issues there:
    1. Most FTN software is closed-source abandonware and thus can't likely change 2. Most of the FidoNet nodes "in charge" are very resistent to
    any changes
    (so any experimental changes would have to be invisible to those
    guys)

    These are the reasons I'm interested in a more modern transport that uses FTN addressing, but under the hood is something optimised for a mesh topology where
    there is real time connectivity all of the time (barring network failures).


    ... I have a mind like a steel... uh... thingy.
    --- MultiMail/Win
    * Origin: Bush Track BBS (21:1/109.1)
  • From Avon@21:1/101 to All on Fri Dec 21 01:38:37 2018
    On 12/19/18, tenser pondered and said...

    On 12/20/18, apam said the following...

    If we're going to look at building a better network, in my mind it wo be better to be something completely different. Fidonet can then keep their FTN the way it is.

    Hear, hear!

    I realized after starting this and the other thread that Tenser has also
    kicked off some similar thought processes as documented in his blog at fat-dragon.org

    From the 'goals' post

    "I should state some goals up front.

    An explicit goal is to not do things that made sense for DOS, dial-ups, and Fido Techology Network (FTN)-style messaging. Rather, the point is to deliberately do things differently because many of the things that made sense for those systems were dictated by their limitations. Given that modern
    systems don't have the same limitations, there is no reason to continue to being bound by those decisions. "

    and this bit

    "I want to explore taking the sorts of things we did on mainframes and
    Unix/VMS networks contemporaneously with BBSes and bring them to a new audience."

    So I just wanted to throw this out in to the mix as part of the broader discussions taking place here at the moment.

    Feel free to elaborate etc. Tenser :)

    Best, Paul

    --- Mystic BBS v1.12 A40 2018/12/16 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Digital Man@21:1/183 to NuSkooler on Thu Dec 20 05:13:04 2018
    Re: Re: 3D SEEN-BY
    By: NuSkooler to Digital Man on Wed Dec 19 2018 10:42 pm


    On Wednesday, December 19th Digital Man muttered...
    Sure. Many FTN nodes *think* they know what the specs say, when they don't. I covered one particular case (Synchronet/SBBSecho's FTN MSGID's) in detail here: http://wiki.synchro.net/faq:misc#ftn_msgid

    Hehe, pretty sure that's what got them fired up. ENiG's MSGID: https://githu b.com/NuSkooler/enigma-bbs/blob/0.0.9-alpha/core/ftn_util.js#L145

    (I even ref sync here)

    I'd +1 your post, but alas, can't do that over FTN. :-)

    digital man

    Synchronet "Real Fact" #18:
    Rob Swindell first learned to program in C by hacking on WWIV BBS software. Norco, CA WX: 63.7°F, 41.0% humidity, 0 mph SW wind, 0.00 inches rain/24hrs
    --- SBBSecho 3.06-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)
  • From Digital Man@21:1/183 to Avon on Thu Dec 20 05:19:08 2018
    Re: Re: Innovations
    By: Avon to Digital Man on Thu Dec 20 2018 07:23 pm

    On 12/19/18, Digital Man pondered and said...

    I get the feeling you would be happy to create 'new stuff' removed from confines of older FTN standards etc.

    Yeah. I do most of my innovation (for message networking) for QWK networks (though some of those innovations extend easily to FTN or NNTP). I don't really see a need for a completely new message networking scheme. And I'd be happy to experiment and innovate on top of FTN as
    well, but there's a couple of issues there:
    1. Most FTN software is closed-source abandonware and thus can't likely change 2. Most of the FidoNet nodes "in charge" are very resistent to any changes (so any experimental changes would have to be invisible to those guys)

    I'd be interested to get your thoughts as to what could / might come across from QWK (which I admit to knowing little about and of using) to the likes of NNTP etc.

    Well, with QWK, I added message voting (e.g. +1, -1) and distributed polls (single or multiple-choice). The same could be done with NNTP or FTN if there was enough interest.

    With respect to innovating on top of FTN I think you've pretty much answered your chances of doing so within (let's say) a Fido zone, here (for what it's worth) I'm totally open to experimenting with changes to FTN stuff but like the idea of new pathways of connectivity predicated on re-purposed or extended tech.

    Yup. I posted a query in FTSC_PUBLIC to see if there was any interest from other FTN software developers. Never got a response.

    Re new message networking scheme / protocol - I guess it all depends on what can be envisaged as being possible with such a thing and if what is mooted is seen as an advance or advantage over what is used/know of now. Dunno..

    If there was same major problem with QWK networking or NNTP even, then I suppose I might consider something completely new, but I haven't really run into any kind of innovation dead-end with the existing formats/protocols. FTN has the crazy politics, but that doesn't mean innovation is completely impossible within it, just somewhat limited.

    digital man

    This Is Spinal Tap quote #22:
    David St. Hubbins: Here lies David St. Hubbins... and why not?
    Norco, CA WX: 63.7°F, 41.0% humidity, 0 mph SW wind, 0.00 inches rain/24hrs
    --- SBBSecho 3.06-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)
  • From tenser@21:1/113 to Avon on Thu Dec 20 10:58:10 2018
    On 12/20/18, Avon said the following...

    Feel free to elaborate etc. Tenser :)

    I need to get back to writing that stuff, but I'm traveling
    at the moment and so time has been short.

    In general, it occurs to me that much of what people are
    describing already exists in the USENET world and formerly
    existed in the UUCP world.

    Many folks will associate USENET with NNTP, but that's not
    necessarily the case; USENET actually originated on the
    UUCP network and NNTP came later.

    The critical thing that sets USENET apart is that it is
    based on a peer-to-peer model, as opposed to the hub-and-spoke
    model of FTN-style networks. Back when I ran a USENET news
    server (using INN on an RS/6000 running AIX!!) I was one
    of half a dozen news servers on our campus and peered with
    four or five other servers; of course, this was using NNTP,
    but news flowed through that mesh without reliance on a
    central hub.

    Also back in the UUCP days, and carried forward into the
    Internet with hostnames, is the idea of decoupling _names_ from
    _addresses_. In UUCP, site names were unique and could be
    chained using a simple syntax. This let people specify
    paths between systems and users, letting them route around
    damage, etc, but also facilitating a simple method for
    specifying what systems had already seen, say, a news article
    and what path it had taken through the network. This was
    preserved into the NNTP-days of USENET. DNS and
    Internet routing take this to another level in which the
    network itself handles routing between systems and names
    are discoverable and resolved using the network.

    In contrast, FTN-style networking conflates names with
    addresses, leading to all sorts of complexity (both technical
    and political). Combined with the installed base of
    abandonware problem, it's a quagmire of stagnation. Yuck.
    In defense, however, it's easy to see why this was done:
    nothing required BBS systems to maintain any sort of syntactic
    discipline for their names. This was baked into UUCP and
    the ARPANET going into the Internet from the start. Still,
    with the emergence of BBS store-and-forward networking, sites
    could have adopted a nickname for transfer purposes. That
    never happened.

    Kernighan and Pike wrote an interesting and relevant paper
    that they presented at Usenix in Summer, 1985 titled "The
    Hideous Name": http://doc.cat-v.org/bell_labs/the_hideous_name/the_hideous_name.pdf
    Note the conclusion where they cite Doug McIlroy saying,
    "bad notations can stifle progress. Roman numerals hobbled
    mathematics for a millennium but were propagated by custom
    and by natural deference to authority." I think that's
    precisely what has happened in the BBS world with FTN networking.
    FTN addresses are bad notation because they explicitly encode
    information that's essentially irrelevant to the user. Who cares
    what zone or network a system is on, or whether it's a "point" or
    not? I, as a user, just want to send a message to someone on
    another machine.

    But there's no reason BBSes couldn't repurpose other technology;
    indeed, lots of BBS systems support NNRP, if not NNTP. More
    broadly, there is no reason BBSes couldn't repurpose the _model_
    but build on newer technology.

    Something I've been kicking around is the idea encoding messages
    into some kind of extensible structured format like JSON and wrapping
    them in HTTP requests for transmission. One might even embed the
    messages into a syndication format like Atom for distribution over
    HTTP; one can use robust web infrastructure without HTML and the user-interface/browser side of things, taking advantage of things
    like well-defined support for TLS, load balancers, caches,
    authentication frameworks, etc. This is the direction we're taking
    the conferencing software on grex.org, though it's all written as
    Go programs that talk over Unix-domain sockets.

    --- Mystic BBS v1.12 A39 2018/04/21 (Raspberry Pi/32)
    * Origin: Alcoholiday / Est. 1995 / alco.bbs.io (21:1/113)
  • From g00r00@21:1/112 to Atreyu on Thu Dec 20 17:04:30 2018
    However... Mystic is being used by quite a bit of people in Fidonet, I'm sure you would not deny that. A lot of people love your software. I appreciate the fact that you take time to work on it, seriously.

    Yep it runs a pretty big list of FTN-networks too and as well as hubs.

    I do appreciate the feedback and I do try to follow standards and do things right, so please don't take that as me being defiant. I just don't feel like FidoNet occupies the same space as it used to and I don't know how much it should remain as an influence over what the rest of us are doing.

    My experience is many of the serious Fido heads strictly on Fido are difficult to work with, nit picky, and unreasonable. So please understand why I am a little hesitant when someone comes here touring their "Fido rank" and picking at my software! :)

    I don't think your intentions are anything but good and I do appreciate and will address issues you may have. Just know that the majority of my experiences with Fido people (the kind of try to flex their 'rank') has been quite the opposite.

    --- Mystic BBS v1.12 A39 2018/04/21 (Windows/32)
    * Origin: Black Flag <ACiD Telnet HQ> blackflagbbs.com (21:1/112)
  • From Atreyu@21:1/176 to G00R00 on Thu Dec 20 17:38:26 2018
    On 20 Dec 18 12:04:30, G00R00 said the following to Atreyu:

    My experience is many of the serious Fido heads strictly on Fido are difficu to work with, nit picky, and unreasonable. So please understand why I am a little hesitant when someone comes here touring their "Fido rank" and pickin at my software! :)

    Not once did I tour-rank with you or attempt to pick at your software. I just pointed out an issue with the INTL kludge. Which you have promptly
    fixed, thank you. Thats all... I made a suggestion about verbage for the INI file; it was only a suggestion and not to be taken as anything more.

    I do remember seeing others pick at Mystic, often times unfairly. I take the same sort of shit with D'Bridge.

    Atreyu

    --- Renegade vY2Ka2
    * Origin: Joey, do you like movies about gladiators? (21:1/176)
  • From vk3jed@21:1/109.1 to g00r00 on Fri Dec 21 10:00:41 2018
    On 20-Dec-2018 23:04, g00r00 wrote to Atreyu <=-

    Yep it runs a pretty big list of FTN-networks too and as well as hubs.

    I for one use Mystic as a hub for multiple FTN networks, and love it in that role. :)


    ... He's dead, Jim; kick him yourself if you don't believe me.
    --- MultiMail/Win
    * Origin: Bush Track BBS (21:1/109.1)
  • From g00r00@21:1/112 to Atreyu on Fri Dec 21 16:49:23 2018
    I do remember seeing others pick at Mystic, often times unfairly. I take the same sort of shit with D'Bridge.

    You have no idea. The same jackoffs were reporting my project to SourceForge/GPL and spamming my forums and bugtracker with nonsense. These
    are people who would start doing this that I never even spoke with prior to
    the things they were doing.

    Not only that, they were blocking the MYSTIC echo in zone 2 from getting in
    or out just for the sake of being assholes, and no one did anything. Even
    with that, the MYSTIC echo was the most active echo on FidoNet at the time...

    But when people go out of the way to jeopardize the integrity of the network over their personal issues and temper tantrums and no one does anything, that is when the network as a whole becomes insignificant. These were people in leadership roles, too. This is the reason why networks like FSX started to thrive instead.

    Hilariously enough, one of the major offenders I saw was using Mystic like a year or so ago lol!

    Also, sorry I wasn't trying to imply that you WERE on the offense, just that my default assumption is that is what I get when a Fido person comes along. I know from chatting with you briefly in the past over the years that you do not
    seem like one of those people.

    --- Mystic BBS v1.12 A39 2018/04/21 (Windows/32)
    * Origin: Black Flag <ACiD Telnet HQ> blackflagbbs.com (21:1/112)
  • From Black Panther@21:1/186 to g00r00 on Fri Dec 21 15:10:42 2018
    On 12/21/18, g00r00 said the following...

    But when people go out of the way to jeopardize the integrity of the network over their personal issues and temper tantrums and no one does anything, that is when the network as a whole becomes insignificant. These were people in leadership roles, too. This is the reason why networks like FSX started to thrive instead.

    Don't let them bother you. You are an great developer, working on an awesome software package. We love having you here on fsxNet! :)

    comes along. I know from chatting with you briefly in the past over the years that you do not seem like one of those people.

    From what I have seen, Nick is a great guy, who does everything he can to
    help others. Although, I don't think we should tell him, as his head might swell up... ;)


    ---

    Black Panther(RCS)
    a.k.a. Dan Richter
    Sysop - Castle Rock BBS
    telnet://bbs.castlerockbbs.com
    http://www.castlerockbbs.com
    The sparrows are flying again....

    --- Mystic BBS v1.12 A39 2018/04/21 (Linux/64)
    * Origin: Castle Rock BBS - bbs.castlerockbbs.com (21:1/186)
  • From Atreyu@21:1/176 to G00R00 on Fri Dec 21 18:16:50 2018
    On 21 Dec 18 11:49:23, G00R00 said the following to Atreyu:

    You have no idea. The same jackoffs were reporting my project to SourceForge/GPL and spamming my forums and bugtracker with nonsense. These are people who would start doing this that I never even spoke with prior to the things they were doing.

    I can only imagine... But I will assume, it is simular to a request I received once to add JAM support to D'Bridge. When I replied that it would take a significant rewrite of the tosser-code which has functioned trouble-free since 1988, that reply was construed to "It sucks" or "Its not that hard to implement overlays or an API" (As if I did not think of those things already)

    And the threads from there would quickly descend into nonsense, in particular by two individuals; one of a tosser that has his freaking credits as a menu option (I'm not kidding, guess which one), and another who has only one tiny utility to his credit but apparently knows what mailer-code should be doing... especially when it comes to Events or Node definitions. Frustrating.

    One challenge I have in trying to port D'Bridge to Linux, is the use of a then-commercial library called B-Tree ISAM, which is used heavily by the Queue and Nodelist compiler code. Although it is open-source now, it is updated for Delphi, and I need to fix several portions for "TP7 compatible" syntax so I can try a test compile with FreePascal.

    Then theres all the assembler code, dialup modem stuff, and a lot of tricks that were done to make it run for the days of IBM XT's and Tandy 1000's. The people who request a cross-OS version may have good intentions, but it is often difficult for me to explain the scope of the work involved to port it.

    Also, sorry I wasn't trying to imply that you WERE on the offense, just that default assumption is that is what I get when a Fido person comes along. I k from chatting with you briefly in the past over the years that you do not seem like one of those people.

    That network has been silent for the most part lately, aside from usual political shenanigans. When I bring up the subject of masturbation, manscaping or shaving my anus, nobody wants to engage me on that topic. Sadly.

    Atreyu

    --- Renegade vY2Ka2
    * Origin: Joey, do you like movies about gladiators? (21:1/176)
  • From Atreyu@21:1/176 to Black Panther on Fri Dec 21 18:17:33 2018
    On 21 Dec 18 10:10:42, Black Panther said the following to G00R00:

    From what I have seen, Nick is a great guy, who does everything he can to help others. Although, I don't think we should tell him, as his head might swell up... ;)

    Something else about me usually "swells up", but I am met with crickets chirping when I air my greivances to the wonderful Fido community.

    Atreyu

    --- Renegade vY2Ka2
    * Origin: Joey, do you like movies about gladiators? (21:1/176)
  • From NuSkooler@21:1/121 to g00r00 on Fri Dec 21 17:49:21 2018

    On Friday, December 21st g00r00 muttered...
    Hilariously enough, one of the major offenders I saw was using Mystic like a year or so ago lol!

    Hahaha!



    --- ENiGMA 1/2 v0.0.9-alpha (linux; x64; 10.13.0)
    * Origin: Xibalba -+- xibalba.l33t.codes:44510 (21:1/121)
  • From Joacim Melin@21:2/130 to g00r00 on Sat Dec 22 02:20:15 2018
    Why the f*ck where they blocking the Fido echo? Who made that decision? Bring
    me the head of...


    --- NiKom v2.5.0dev
    * Origin: Delta City (deltacity.se, Vallentuna, Sweden) (21:2/130.0)
  • From Tiny@21:1/130.4 to Atreyu on Sat Dec 22 04:17:46 2018
    Quoting Atreyu to Tiny <=-

    When are we going drinking?

    I'm down anytime. We'd have to meet in the middle in Pickering since
    you won't do the shwa, and I won't do the smoke. ;)

    Shawn

    ... Hope is a good breakfast, but a bad supper.
    --- Blue Wave/386
    * Origin: A Tiny slice o pi (21:1/130.4)
  • From vk3jed@21:1/109.1 to Atreyu on Sat Dec 22 05:39:03 2018
    On 22-Dec-2018 00:17, Atreyu wrote to Black Panther <=-

    Something else about me usually "swells up", but I am met with crickets chirping when I air my greivances to the wonderful Fido community.

    Sounds like you don't need the little blue pill! :D

    And yes, the rubbish that goes on in Fidonet is ridiculous. :/ At least we're a friendly lot in here. :)


    ... Law of Supply: It's yours if you don't need nor want it.
    --- MultiMail/Win
    * Origin: Bush Track BBS (21:1/109.1)
  • From Atreyu@21:1/176 to Tiny on Sat Dec 22 00:29:45 2018
    On 21 Dec 18 23:17:46, Tiny said the following to Atreyu:

    When are we going drinking?

    I'm down anytime. We'd have to meet in the middle in Pickering since
    you won't do the shwa, and I won't do the smoke. ;)

    I'm in Oshawa twice a month...

    Atreyu

    --- Renegade vY2Ka2
    * Origin: Joey, do you like movies about gladiators? (21:1/176)
  • From Black Panther@21:1/186 to Atreyu on Sat Dec 22 02:07:13 2018
    On 12/21/18, Atreyu said the following...

    Something else about me usually "swells up", but I am met with crickets chirping when I air my greivances to the wonderful Fido community.

    Perhaps we need to add some echos to Fidonet...

    ANAL_BLEACHING
    MASTURBATION
    MANSCAPING

    I vote for you for moderator of these new echos. ;)


    ---

    Black Panther(RCS)
    a.k.a. Dan Richter
    Sysop - Castle Rock BBS
    telnet://bbs.castlerockbbs.com
    http://www.castlerockbbs.com
    The sparrows are flying again....

    --- Mystic BBS v1.12 A39 2018/04/21 (Linux/64)
    * Origin: Castle Rock BBS - bbs.castlerockbbs.com (21:1/186)
  • From vk3jed@21:1/109.1 to Black Panther on Sat Dec 22 13:58:48 2018
    On 22-Dec-2018 08:07, Black Panther wrote to Atreyu <=-

    ANAL_BLEACHING
    MASTURBATION
    MANSCAPING

    I vote for you for moderator of these new echos. ;)

    Haha why not? There's a lot of worse stuff going around Fidonet. ;)


    ... MS-DOS: MR-DOS's sister; DR DOS: MS-DOS's Gynecologist.
    --- MultiMail/Win
    * Origin: Bush Track BBS (21:1/109.1)
  • From Tiny@21:1/130.4 to Atreyu on Sat Dec 22 17:54:48 2018
    Quoting Atreyu to Tiny <=-

    I'm in Oshawa twice a month...

    Let me know. I'm normally home from work by 4:30pm, and currently not
    working weekends. I can also cut out early tues, wed or thurs.

    Shawn

    ... We'd like to apologise for that last apology...
    --- Blue Wave/386
    * Origin: A Tiny slice o pi (21:1/130.4)
  • From g00r00@21:1/112 to Atreyu on Sat Dec 22 15:27:49 2018
    I can only imagine... But I will assume, it is simular to a request I received once to add JAM support to D'Bridge. When I replied that it
    would take a significant rewrite of the tosser-code which has functioned trouble-free since 1988, that reply was construed to "It sucks" or "Its not that hard to implement overlays or an API" (As if I did not think of those things already)

    You can't win! When its something they want, its easy. When its something you're working on it, its stupid or too hard. I originally was going to make an IREX replacement instead of building all of this stuff into Mystic but people on FidoNet "talked me out of it" by telling me that I couldn't do it, that it was too hard to do, etc.

    And the threads from there would quickly descend into nonsense, in particular by two individuals; one of a tosser that has his freaking credits as a menu option (I'm not kidding, guess which one), and another

    Oh yep I know. Thats one of the offenders with me too. Not surprising I suppose. And if I am not mistaken, didn't that person not even write the tosser they just got the code afterwards and slapped their name on it in obnoxious ways? I remember giving him shit about the credits lol

    One challenge I have in trying to port D'Bridge to Linux, is the use of
    a then-commercial library called B-Tree ISAM, which is used heavily by
    the Queue and Nodelist compiler code. Although it is open-source now, it is updated for Delphi, and I need to fix several portions for "TP7 compatible" syntax so I can try a test compile with FreePascal.

    Yeah that is a pain. Way back in the days I had a license to Async Professional that I used in a commercial project and I always wanted to use it in Mystic but I knew that I would have to port to OS/2 and Windows pretty early on in Mystic's life so I never did.

    Now its opened sourced though, and I eventually hacked just the protocols into Mystic's code similar to what you will have to do (this is where Mystic's X/Y/Z modem come from).

    Then theres all the assembler code, dialup modem stuff, and a lot of tricks that were done to make it run for the days of IBM XT's and Tandy 1000's. The people who request a cross-OS version may have good intentions, but it is often difficult for me to explain the scope of the work involved to port it.

    Yeah that can be a pain. A lot of those old programs address the screen using memory location and used basic ASM functions for string handling. But then some people wrote ASM to speed up key parts of program logic and those people are totally screwed.

    There are just other things to worry about too. DOS is not the same as
    Linux and things aren't always so plug and play when you first start porting from DOS.

    That network has been silent for the most part lately, aside from usual political shenanigans. When I bring up the subject of masturbation, manscaping or shaving my anus, nobody wants to engage me on that topic. Sadly.

    Blasphemy! How dare they!

    --- Mystic BBS v1.12 A39 2018/04/21 (Windows/32)
    * Origin: Black Flag <ACiD Telnet HQ> blackflagbbs.com (21:1/112)
  • From g00r00@21:1/112 to Joacim Melin on Sat Dec 22 15:44:33 2018
    Why the f*ck where they blocking the Fido echo? Who made that decision? Bring me the head of.

    I don't know this was years ago. The reason was just irrational behavior. The same people were also saying they wanted anyone using Mystic BBS to be prevented from being on Fido at some point too.

    These were major Zone 2 hubs and I don't remember who it was specifically. If Access Denied is still active (not sure) he might remember more as he was my FidoNet hub at the time (still is).

    --- Mystic BBS v1.12 A39 2018/04/21 (Windows/32)
    * Origin: Black Flag <ACiD Telnet HQ> blackflagbbs.com (21:1/112)
  • From NuSkooler@21:1/121 to g00r00 on Sat Dec 22 15:10:18 2018

    On Saturday, December 22nd g00r00 was heard saying...
    political shenanigans. When I bring up the subject of masturbation, manscaping or shaving my anus, nobody wants to engage me on that
    topic.
    Sadly.
    Blasphemy! How dare they!

    Rotfl


    --- ENiGMA 1/2 v0.0.9-alpha (linux; x64; 10.13.0)
    * Origin: Xibalba -+- xibalba.l33t.codes:44510 (21:1/121)
  • From Atreyu@21:1/176 to G00R00 on Sun Dec 23 00:33:33 2018
    On 22 Dec 18 10:27:49, G00R00 said the following to Atreyu:

    You can't win! When its something they want, its easy. When its something you're working on it, its stupid or too hard. I originally was going to mak an IREX replacement instead of building all of this stuff into Mystic but people on FidoNet "talked me out of it" by telling me that I couldn't do it, that it was too hard to do, etc.

    Oh man you lucked out by NOT writing an Irex replacement. That it
    something pretty much *every* long-time Sysop wants. But the problem is
    that something like that is really a complex program to support. The biggest thing that turned me away from doing that, was for the reason that if it does not work the first time, Sysops would just say "It sucks", not appreciating what it is that is trying to be accomplished.

    When I took over the D'Bridge code from the original author in 2004/2005, I was handed quite the task of even removing MS-DOS Share support (don't ask), and then how do I make it do Binkd? I must have spent MANY nights trying to figure out the best way. Then I decided to take the path of least resistance - Just "wedge" it between the existing mailer Queue and the open-source BinkD. Simply put, D'Bridge just ships with whatever the current/stable version of BinkD for Win32 or OS/2. I took the path of least resistance... or drama.

    It worked out nicely because, if the open-source BinkD gets updated by the Russians with new features, connection, encryption... whatever, the D'Bridge Sysop can just drop-in the replacement. The mailer Queue code that I wrote just converts the proprietary Base36 into BSO format. Thats all it does and it works flawlessly. At that point I just said "There you go, lets move onward".

    When I saw the headaches you had with getting Mystic to talk to Irex, I'm like, "That poor bastard" Lol

    Oh yep I know. Thats one of the offenders with me too. Not surprising I suppose. And if I am not mistaken, didn't that person not even write the tosser they just got the code afterwards and slapped their name on it in obnoxious ways? I remember giving him shit about the credits lol

    That author's other job is to act as the self-appointed Nodelist Police, but thats another story. I don't like talking too much shit about others but its amusing that as much criticism I take, he (and others like him) are quick to Areafix/Allfix stuff from my system. If I'm doing such a shit job, why bother to set up a full feed?

    Now its opened sourced though, and I eventually hacked just the protocols in Mystic's code similar to what you will have to do (this is where Mystic's X/ modem come from).

    The one thing that was interesting when I looked at the Zmodem code in D'Bridge was that it was written with something which must have been unique for its time... Split screen chat during file transfers. The datestamp of that code I believe was 1990/1991, something like that. Not even any assembler stuff, it was pure Pascal even for the CRC32.

    Atreyu

    --- Renegade vY2Ka2
    * Origin: Joey, do you like movies about gladiators? (21:1/176)
  • From g00r00@21:1/112 to Atreyu on Sun Dec 23 03:28:19 2018
    Oh man you lucked out by NOT writing an Irex replacement. That it something pretty much *every* long-time Sysop wants. But the problem is that something like that is really a complex program to support. The

    Well, its pretty much already a part of Mystic now. My version of IREX was going to go a step further since it would have included the message tosser
    too. All of the BINKP/FTP/Directory mailers are in Mystic instead. FTP,
    NNTP servers, etc all in Mystic.

    that if it does not work the first time, Sysops would just say "It
    sucks", not appreciating what it is that is trying to be accomplished.

    Yep I agree. It takes a while to get it right and the way some people behave is just ridiculous.

    take the path of least resistance - Just "wedge" it between the existing mailer Queue and the open-source BinkD. Simply put, D'Bridge just ships with whatever the current/stable version of BinkD for Win32 or OS/2. I took the path of least resistance... or drama.

    Not a bad idea if you are okay with it. BINKD is well tested, and developing BINKP was quite annoying because of the various implementations that are problematic but were never fixed. Mystic had its issues along the way, but I was quick to address them. Things like MBSE, Argus and IREX have problems
    that will never be addressed (actually not sure about MBSE anymore).

    It worked out nicely because, if the open-source BinkD gets updated by
    the Russians with new features, connection, encryption... whatever, the D'Bridge Sysop can just drop-in the replacement. The mailer Queue code that I wrote just converts the proprietary Base36 into BSO format. Thats all it does and it works flawlessly. At that point I just said "There
    you go, lets move onward".

    Sounds pretty cool. One of these days I'll have to download D'Bridge... Its been a really really long time since I looked at any of the traditional mailers!

    --- Mystic BBS v1.12 A39 2018/04/21 (Windows/32)
    * Origin: Black Flag <ACiD Telnet HQ> blackflagbbs.com (21:1/112)
  • From KrUpTiOn@21:2/105.1 to Black Panther on Wed Dec 26 07:34:18 2018
    Re: Re: 3D SEEN-BY
    By: Black Panther to Atreyu on Fri Dec 21 2018 09:07 pm

    On 12/21/18, Atreyu said the following...

    Perhaps we need to add some echos to Fidonet...

    ANAL_BLEACHING
    MASTURBATION
    MANSCAPING

    I vote for you for moderator of these new echos. ;)


    LOL!!!


    I have a funny feeling those would be the most active echos in FIdoNet history! Regards,
    KrUpTiOn
    --- SBBSecho 3.04-Linux
    * Origin: thenewfrontier2.hopto.org:2333 (Akron, OH) (21:2/105.1)
  • From Black Panther@21:1/186 to KrUpTiOn on Wed Dec 26 21:22:23 2018
    On 12/26/18, KrUpTiOn said the following...

    Perhaps we need to add some echos to Fidonet...

    ANAL_BLEACHING
    MASTURBATION
    MANSCAPING

    I vote for you for moderator of these new echos. ;)

    I have a funny feeling those would be the most active echos in FIdoNet history! Regards,

    Maybe that's what Fido needs to get more people interested again...


    ---

    Black Panther(RCS)
    a.k.a. Dan Richter
    Sysop - Castle Rock BBS
    telnet://bbs.castlerockbbs.com
    http://www.castlerockbbs.com
    The sparrows are flying again....

    --- Mystic BBS v1.12 A39 2018/04/21 (Linux/64)
    * Origin: Castle Rock BBS - bbs.castlerockbbs.com (21:1/186)
  • From Andrew Leary@21:4/105 to g00r00 on Fri Dec 28 07:57:11 2018
    Hello g00r00!

    22 Dec 18 22:28, you wrote to Atreyu:

    Not a bad idea if you are okay with it. BINKD is well tested, and developing BINKP was quite annoying because of the various
    implementations that are problematic but were never fixed. Mystic had
    its issues along the way, but I was quick to address them. Things
    like MBSE, Argus and IREX have problems that will never be addressed (actually not sure about MBSE anymore).

    If you have documented evidence of a BinkP problem in MBSE, I'd like to see it. I've been through the code more times than I can count, and am not aware of any issues. It does have several work arounds in it for bugs in other BinkP mailers (Taurus and IREX, IIRC.) I do have an issue connecting with 1 downlink who runs Mystic 1.11, but I believe this is caused by a bug in Mystic that you fixed a while ago, since I connect to several Mystic 1.12 systems many times a day without issues.

    Andrew

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (21:4/105)