Hello John Dovey!
** On Monday 17.05.21 - 07:55, John Dovey wrote to All:
Future Messaging Proposal - 16 May 2021
This just to establish that I'm besotted with online
communication and file sharing.
I'm sure much of what you described represents a similar
experience that many (here) have besotted.
I've investigated (and implemented to various degrees of
success) different networks types, including "SneakerNet"
and Mesh Networks.
The latter two sound like good candidates of a good story that
you're hold back from us!
..a distributed messaging and resource sharing project
that I'm exploring together with a colleague living in the
UK who works across rural Africa, in some of the most
disconnected communities it's possible to imagine. My
focus is on local communities in Panama who are almost as
isolated.
Before AOL managed to infest everyone's homes, I yearned to
popularize dialup BBSing in my community primarily wrt to
messaging. I had modest success (within 10 months) with about
10 regular local callers who were chiefly interested in the
email gateway that I arranged with a hub located in another
province. I was poised to expand from 2 lines to 8. The
underground wires into the home are still here.
The current iteration of BBS systems is pretty much
dominated by Synchronet and Mystic.
Being still currently developed, they can adjust to the needs
and interests that people ask about.
What underlies all these disparate pieces of software is a
series of old ideas. Some really good principles and
realization of those principles and some things which just
aren't in tune with the modern way of doing things.
Ah.. the modern way of doing things. Tablets and smartphones
come to mind, don't they? :)
The most glaring omission is a simple app for Android or
IOS. There are "point" systems (such as GoldEd+) and the
configurations that they require, but they are at best
clunky and difficult.
HotdogED and Aftershock are also a couple of valiant attempts.
There's a nice presentation and comparison of those here:
http://ambrosia60.dd-dns.de/fidonet/fidonet-on-smartphones.htm
BUT support/development for them is dubious.
But of the entire list of nodes on the latest nodelists,
there is a bare handful which advertise an actual phone
number.
I think it's pretty cool that support for using a contactable
phone number could still be useful even in some of the earlier
communities were the copper hasn't been pulled out, yet.
the monolithic centralized services.. frm Twitter to
WhatsApp and everything else in between. .. have arisen as
commercial purveyors of other peoples information and
treat their customers as the product. From my reading and
experience I suspect that it was an almost prescient
vision which formulated the concept of FidoNet; one truly
before it's time.
I doubt that Tom Jennings and first developers had a prescient
vision of a future in which commercialization of people's use
for messaging and data-mining of its contents would emerge as
to influence the design of fidonet technology. ;) The
greatest influence was simply reduction of long-distance costs.
In my opinion, FidoNet at its core is a store-and-forward
system which was meant to resilient and flexible enough to
route around outages and breakdowns and unreliable links.
Absolutely.
The first nodelist could apparently jot handle more than
250 nodes, and the zone/net/hub/node system arose almost
as a kludge to handle the growth to over 19000 entries in
the nodelist at its peak.
I was not aware (or I forgot) about the initial 250 node
limitation. Interesting.
When I established my newest board, I was invited to join
my local zone and facilitate the local region, with the
assumption that all my traffic would, as is traditional,
route through the region to the Zone hub and then onto the
"backbone".
Ah.. but netmail and echomail are two different elements to the
equation. I think the "tradition" to stick with documented
(nodelist) topolgy pertained to netmail. Echomail arrived
later, and as certain echos were only available from certain
systems, sourcing them or finding a feed, could be under the
complete discretion of the sysop processing those messages.
As I proceeded to set this up, I found it completely
trivial to add feeds to and from Europe, Russia and New
Zealand for conferences carried there and not within my
Zone. I could also have picked up all my conferences from
one of those and simply ignore everyone else in my Zone. I
thought that was a little ride though. It is only
tradition that restricted me to using the normal routing.
The topology as arranged in a fidonet nodelist is still
basically just a geographical map of systems all tidily
organized into their specific regions. But sysops can still
route, feed, and make crash connections any way that works.
And I'd like to add: Total user selection of what they
want to see, and technical decisions where and how it is
routed.
For that to work, users need to be informed of what's
available. Unless a user understands what the OTHERNETS, ELIST
or ECHO_ADS are, and how to interpret the "area" summaries in
STATS, then the echos remain obscure and get little attention.
The areas list in the FIDOGAZETTE publication is pretty good
though. But again, users need to know that's where to look.
I'm not truly an expert in all of this stuff, more a
generalist and an enthusiastic amateur, so please take
that into consideration.
I haven't heard much expertise from the assumed experts, so
anything sounds good at this point! :D
What I believe is imperative is that the barrier to entry
needs to be lowered drastically. It should be as simple as
clicking on a download button and filling in a few fields.
Entry by whom? Sysops? Users? Probably both. I concur!
Some sysops (particular those that host and promote othernets)
do a pretty good job promoting their othernet and BBSes on
dedicated websites.
We need to think in terms of Mesh networking, not some
sort of star topology mindset. I'm not necessarily talking
about the transport layer, but the arrangement of the
network.
I bet the mesh|star|fidoweb approach has probably taken place.
As I understand it, some top echomail movers already have
established redundant connections and let fidonet's dupe-
checking technology take care of things.
By this I mean that someone should choose to join the
network and connect automatically to peers. These could be
geographically distant but close in network terms or vice
versa.
As already stated above, I think that is already the approach
wrt echomail. Now, as to "connect automatically" ..do you mean
some kind of AI that would make or suggest those arrangements?
Scenario 1: There is a remote village, physically distant
from any network connection whatsoever. [...] The point of
this scenario is to illustrate that the current concept of
dialup BBS (now shifted to Telnet et al) is in some ways a
shift away from the roots of FidoNet. This disconnected
store and forward model is what the network was designed
for.
I never thought of what fidonet has become that way.
Interesting point. However, I'm not sure if your arguing in
favour of store-n-forward or against it.
My proposal is that we need to look for a different
network authentication and routing model. One that handles
the instant connectivity just well as it does the
completely irregular and unreliable links.
Ah.. AI enters fidonet? That would be cool!
It's also become clear that there is reason to be
concerned about the platforms that provide the major
communications at the moment. We've seen these platforms
being used in places and at tokes where they've made an
incredible difference, such as during the Arab Spring, the
Hong Kong protests and then during various natural
disasters etc. We've also seen them be cut off completely
by governments or by the providers to whole communities or
to individuals.
Yes.. turning "off" those platforms seems to be incredibly
easy. And even shutting down whole internet trunks into and out
of a country does not seem impossible. And if fidonet rides
within those trunks, then fidonet is cut off too.
The anarchic nature of FidoNet was designed to prevent
that. I'm also pretty convinced that when it was designed
the initial intention of the Internet/DARPAnet played a
part that is to survive a nuclear attack. .. We need to
return to that.
I would use the term ad-hoc vs anarchic. ;) As for Internet/
DARPAnet being designed to survive a nuclear attack.. I doubt
that was able to be tested! :D However and EMP-based attack
could neutralize a variety of electronics, that's for sure. In
that case, not even ad-hoc networks would be immune.
One of the largest concerns people have expressed is worry
over "encryption". What they truly mean is not encryption
per se, but privacy. That, in my opinion, shouldn't be
part of the network but a software layer on top. PGP comes
to mind as a good model. Building that in to clients
should be a best practice and part of the standard.
I've heard that in the recent releases of Thunderbird,
encryption support is now built-in c/o Enigma.
Some fidonet systems indicate encryption (ie privacy) by
designating an ENC flag in their nodelist entry. It seems more
prevalent in Z2 though. Ultimately, privacy is only possible
between users who both subscribe to end-point systems that fly
the ENC flag.
It seems that most people establish a BBS primarily for
their own use. That is that they are the primary user, and
additional users are pretty sparse. It's for this reason
(and others) that I'd suggest that the focus should be
catering for this. [...] They could be collaborative
efforts arranged on the fly. [...] Once a user or system
has Registerd themselves on the app, there should be an
automated process where it announces them to the network
at large and where the information gets collated via a
distributed database of some sort.
Isn't that what places like TelnetBBS Guide and
ipingthereforeim try to do? The latter system seems to monitor
the liveness of every telnet bbs pretty much in realt-time by
frequent reports.
Both systems have "latest bbses added" ..or something like
that.
The SBBS BBS list is an example of one way of doing this.
That list is amazing. It's the only one that summarizes all the
services on a particular BBS in a simple at-a-glance table. I
personally think the "Networks" is particularly useful.
The various message formats are archaic and ridiculous in
a lot of ways. There should be a standard implementation
that is accessible on all devices.
Most sysops stop at JAM format. And that is primarily limited
to desktop pcs. Sysops don't seem to have a smartphone/tablet
concern.
My personal preference would be for SQLite due to it's
ease of use and ubiquitous distribution (how many billions
of android and iOS devices have it Pre-installed?)
If SQLite is already built into android devices, it seems
shameful not to capitalize on it.
The display format! ANSI for crying out loud! Surely we
can do better than that? Why about send SVG commands which
are rendered on the device? Maybe using the Cairo graphics
libraries or their equivalent? I know RIPTerm was an
early. Semi-proprietary version of this.
All that is graphics stuff beyond my tech knowledge. I still
struggle with hearing the limitations of implementing UTF-8 in
fidonet. :(
Maybe it's time to develop a new standard which is simple
and easy to implement? It beggars belief that we are using
software that is actually designed with VT100 terminals in
mind.
To a certain extent, plain-ol' text is the best, especially for
message content. Everything else is fluff. ;) *BOLD*
_Underline_ #inverse# and /italic/ are fine tools, but that's
about as far as things go in fidonet.
Having said this, nothing prevents us from separating the
display layer from the transmission layer. If we design
the protocol sufficiently well, then that could also be
relatively agnostic, or at least provide fallback options.
For example, negotiation with the client with "new RIP"
preferred, falling back to in descending order, Rendered
SVG, PNG, HTML, ANSI and ASCII.
THAT would indeed be very interesting! But how would the least
common denominator system in the network deal with that,
especially if their software is from the archaic/depricated
vault?
Seems to me that a new fidonet of modern (still-in-development)
systems would be the best route, or.. at the very least,
dedicated echos for this experimentation and growth.
Telnet. Ask anyone under thirty who is not in IT to use
telnet and you may as well have spoken in a foreign
language.
NOT if you steer those people to TelenetBBS Guide! ;) They
will at least think that telnet is "the little box on the
screen" that allows "connection" to a BBS from that list. :D
Composing messages. Make it something like Markdown so
it's also agnostic and the formatting is deferred to the
client.
Syncronet, OpenXP, and now Fido2telebot achieve some of this!
Images. There aren't any. This is probably the biggest
reason for the poor uptake after the lack of clients for
devices.
Yeah.. the newer generations all seem to expect visual candy.
I'd suggest though that rather than duplicate http for
this, [...] possibly making them "out of band". [...]
which render independently of the message..
Telegram's solution is kinda like that. It works well. On the
flipside of that, the Fido2telebot renders an
http:// link of
an image direct from the host-fidonet BBS.
Images and video etc are, of course, big attractions to
users (just look at the growth of Instagram and TikTok)
OMG, Tiktok content can be so mindless! If our users are to be
gleened from that demographic then fidonet is indeed doomed!
:/ Furthermore, some people tell me that Instagram is where
most people hang out. BUT again, that is not the best way to
gauge the relevance of images in fidonet. Some easy support of
image content would be nice, but hopefully it wouldn't be a
feature that takes away from the salient nature of text
messaging.
They're also bandwidth hogs. I think this is where the
"control by the user" needs to be rigorously built in,
there is a simple and enforceable way to select where and
how images are accepted.
It's the bandwidth hogs that concern me. An out of band
solution sounds pretty good!
Spam. Spam kills message board and conferences if not
killed instantly. That's why there must be some mechanism
to deal with it. Maybe ...
I don't think that fidonet has had any major issues with that.
The weakest holes in the wall for that are systems that gate
messages into and out of newsgroups. But the buck usually
stops at the sysop's system and can be dealt with fairly
readily if a sysop is reachable and paying attention.
Reputation. [...] for example, if you're reputation is low
(or your rank is 'Noob'), there are only certain things
you can do, or certain conferences you can join. The
longer you are part of the system, the more you
participate in certain activities etc, the more tour
reputation/rank can change.
Hmmm, sounds like the social-ranking system in China. LOL.
If, for example, no messages are accepted from noobs,
[...]
That's already the filter built into Fido2telebot. The user has
to "talk" to the bot manually to "register" to the network. If
that fails, then their posts never enter the network. Not so
in fidonet however. A spammer, or troll can just move to
another BBS in the network.
[...] hit-and-run spammers who use images won't be able to
generate new user IDs to post them. If there is an
algorithm that sees a user posting the same content
hundreds of times, or hundreds of messages from the same
address, or other variations on the theme, then they can
be flagged as potentially spammers and handled
programmatically.
Uh-oh.. so much for all the stats and monthly rules postings
that sysops and their bots love to post, especially in the
echos that no one is reading! LOL
I believe this is vital however, that it be programmed in
and that the rules are enforced programmatically and not
by people, as it's less prone to all sorts of nonsense we
see on existing platforms. [...] there's nothing to stop
him ignoring the flags and accepting those messages, but
also nothing stopping all the other nodes from both
refusing to accept them as well as refusing to forward
them on.
Fidonoet/othernet systems don't seem to be infested by
unsolicited/automated spam so much. Owners of an othernet or
syops carrying an echo can already react pretty quickly and cut
off problem people or other systems.
I have numerous other thoughts, but I hope this is enough
to generate some debate.
Hey.. keep them coming.
--
../|ug
--- OpenXP 5.0.50
* Origin: FUTURE4FIDO =
https://t.me/joinchat/SV_BQ0XcbSRoP4bt (2:221/1.58)