Text 10821, 120 rader
Skriven 2010-09-28 13:40:39 av Michiel van der Vlist (2:280/5555)
     Kommentar till en text av Richard Webb (1:116/901.0)
Ärende: PVT Nodes
=================
Hello Richard,

On Sunday September 19 2010 16:05, you wrote to me:

 MvdV>> All true. But it is a long way from striving for universal
 MvdV>> connectivity and not reaching a 100% to knowingly and willingly
 MvdV>> throwing it overboard by reducing the requirement of being ablke
 MvdV>> to receive mail during ZMH by adding "from his NC".

 RW> ACknowledged and granted.  But, moot for the email tunneling connected
 RW> node, etc.

Speaking about e-mail tunneling, I never considered those as a "direct
connection". It uses store and forward through a third party on a level higher
than the packet level, and it is not real time. From my POV e-mail tunneling is
routed mail.

Nevertheless... since my software supports it, I have enabled it on my system
some years ago. Nobody - other than those I asked to test it - ever used it to
deliver mail to my system, but it did attract spam. To be contactable ny e-mail
tunnel, one has to publish an e-mail address in the nodelist and apparently the
spammers have discovered the nodelist as a source of e-mail addresses.  So I
disabled it and threw away the e-mail address.

 MvdV>> Plus of course, sometimes one wants some privacy. In the past I
 MvdV>> have often used crasmail for the sole reason that I did not want
 MvdV>> my mail to be read by others. Some others in particular.

 RW> <rotfl>  Understand that one.  YEah there's always pgp and
 RW> other such encryption schemes, but according to strict
 RW> reading of policy they're verboten as well unless all those
 RW> in the routing path agree to route encrypted traffic.

Which in practice is hard to get. Particularly from those I do not want to read
my mail....

I think we missed an opportunity here. When we - FidoNet - had encouraged our
users - when we still had lots of them - to massively encrypt their mail, it
might have become "standard procedure" to do so and it would have been e lot
harder for governments to push restrictions.

 RW>> We have evolved quite a bit since the days of the founding
 RW>> fathers of Fido.  A good number of connection schemes, all
 RW>> incompatible with each other.

 MvdV>> Which is a mixed blessing and partly unneeded.

 RW> True, but take away any of those connection schemes and you
 RW> deny some nodes connectivity in any form.  I haven't ever
 RW> really tried to parse the nodelist to see how many are email tunneling
 RW> only, how many pots only, etc.  wOuld be an interesting exercise,
 RW> especially for a snooze article for somebody <hint hint>.

Hmmm....

 RW> IN the name of all inclusive nobody gets shut out we may have, in the
 RW> long run shot ourselves in the foot.

Indeed we may. We may have kept some in by allowing a multitude of connection
methods, but how many have left us because they got fed up with having to deal
with so much incompatibility? Someone playing devil's advocate may point out
that the decline of Fidonet set in after we allowed systems not FTS-001
connectible via POTS. Suggesting a causal relationship....

 RW> tHe best defense against this is those systems which offer a variety
 RW> of ways to connect, i.e. pots; binkd; telnet; ftp.  sYstems with
 RW> enough horsepower can offer multiple connection schemes, and can then
 RW> with some willingness to do it stand in the gaps.

Supporting multiple connection methods however puts an extra strain on hosts
and hubs. With shrinking nets, it is hard enough to find candidates as it is.
In my net I have delegates the host function to someone who in addition to
several IP related connection methods, offers POTS and ISDN. He is the only one
left who can offer all that and when he quits, I will have no choice but to
settle for less.

 MvdV>> Regarding coinnection methods, it is not P4 that has to evolve.
 MvdV>> P4 states one must be able to receive and send mail via FTS-0001
 MvdV>> but allows for having the minimum required protocol changed
 MvdV>> through the FTSC. Unfortunately their are other hurdles on that
 MvdV>> road... :-(

 RW> YEp, that's a job for you ftsc folks <grin>.

As I mentioned, there are other hurdles on that road...

 MvdV>> Many thing just work better if one can agree on a few things.
 MvdV>> How would the roads look like if we could not agree which side
 MvdV>> to drive on and we settled for agreeing to disagree?

 RW> AGain a point of agreement.  But, in this case, we have to
 RW> go from where we are, and that was what we were given, an
 RW> agreement to disagree.  IT's up to current fido folks to
 RW> sort it out, and, the place for that, as you noted, is the ftsc.

I wish it were that easy. The problem is that the FTSC has no authority of its
own. Its playing field is limited to what the *C's are willing to give. As it
is, the ftsc is pretty much limited to "documenting current practise".

 MvdV>> "Agree to disagree" certainly did not help and still does not help
 MvdV>> in keeping FidoNet together. OTOH, I do not think FidoNet could
 MvdV>> have been "saved" by better coordination and agreeing on standards.
 MvdV>> FidoNet served a purpose of affordable access to a world wide
 MvdV>> network for lots of individuals. And then something better came up.
 MvdV>> Better for most anyway.

 RW> YOu might be right there, but for many even when I took my
 RW> node down in Iowa fidonet was still the only low cost method of access
 RW> to the world of computer comms.

That is history. Not only is fidonet no longer the only affordable way, it is
no longer the best way for most either. If I have a problem with my Honda
motorcycle, I do not bother with Fidonet, I just go to the website dedicated to
the model in question. That is where I find the knowhow.


Cheers, Michiel

--- GoldED+/W32-MINGW 1.1.5-b20070503
 * Origin: http://www.vlist.org (2:280/5555)