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?
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?
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.
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...
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.
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.
Hmm, still a single point of failure? :)
Back to single point of failure. :(
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?
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.
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.
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.
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
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.
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)?
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.
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).
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.
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.
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.
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.
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
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.
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.
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.
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.
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 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.
Probably not considering FTN "standards" are pretty immobile.
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 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 :)
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.
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.
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.
fidonet is run by 95 year old men who are stuck in 1984.
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).
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.
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 :)
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?
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 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.
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'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>
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.
Taking a Cockroach type approach, deduping isn't even really a issue. Essntially everyone would be sharing the same global, distributed database.
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. :)
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 :)
old drinking buddy used to say. Some was questionable, others ingenius
in design.
duplicate Net's. This is why such a stink is made about Seen-by
stripping.
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
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.
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>
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.
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.
Actually, I'm not suggesting this approach.
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.
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
I'm curious why on both of those points? Seems like CockroachDB would be perfect to simply create a cluster for the network.
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)
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)
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!
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)
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..
Feel free to elaborate etc. Tenser :)
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.
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! :)
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 do remember seeing others pick at Mystic, often times unfairly. I take the same sort of shit with D'Bridge.
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.
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.
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.
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.
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... ;)
Hilariously enough, one of the major offenders I saw was using Mystic like a year or so ago lol!
Quoting Atreyu to Tiny <=-
When are we going drinking?
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.
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. ;)
Something else about me usually "swells up", but I am met with crickets chirping when I air my greivances to the wonderful Fido community.
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. ;)
Quoting Atreyu to Tiny <=-
I'm in Oshawa twice a month...
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
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.
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.
Why the f*ck where they blocking the Fido echo? Who made that decision? Bring me the head of.
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!
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 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
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).
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
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.
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".
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. ;)
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,
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).
Sysop: | echicken |
---|---|
Location: | Toronto, Ontario |
Users: | 2,224 |
Nodes: | 6 (0 / 6) |
Uptime: | 15:45:51 |
Calls: | 14,143 |
Files: | 295 |
Messages: | 551,317 |