Subj : Re: Future Messaging Proposal To : John Dovey From : August Abolins Date : Sun May 23 2021 05:25 pm Hello John Dovey! ** On Monday 17.05.21 - 07:55, John Dovey wrote to All: JD>> Future Messaging Proposal - 16 May 2021 JD>> This just to establish that I'm besotted with online JD>> communication and file sharing. I'm sure much of what you described represents a similar experience that many (here) have besotted. JD>> I've investigated (and implemented to various degrees of JD>> success) different networks types, including "SneakerNet" JD>> and Mesh Networks. The latter two sound like good candidates of a good story that you're hold back from us! JD>> ..a distributed messaging and resource sharing project JD>> that I'm exploring together with a colleague living in the JD>> UK who works across rural Africa, in some of the most JD>> disconnected communities it's possible to imagine. My JD>> focus is on local communities in Panama who are almost as JD>> 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. JD>> The current iteration of BBS systems is pretty much JD>> dominated by Synchronet and Mystic. Being still currently developed, they can adjust to the needs and interests that people ask about. JD>> What underlies all these disparate pieces of software is a JD>> series of old ideas. Some really good principles and JD>> realization of those principles and some things which just JD>> 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? :) JD>> The most glaring omission is a simple app for Android or JD>> IOS. There are "point" systems (such as GoldEd+) and the JD>> configurations that they require, but they are at best JD>> 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. JD>> But of the entire list of nodes on the latest nodelists, JD>> there is a bare handful which advertise an actual phone JD>> 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. JD>> the monolithic centralized services.. frm Twitter to JD>> WhatsApp and everything else in between. .. have arisen as JD>> commercial purveyors of other peoples information and JD>> treat their customers as the product. From my reading and JD>> experience I suspect that it was an almost prescient JD>> vision which formulated the concept of FidoNet; one truly JD>> 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. JD>> In my opinion, FidoNet at its core is a store-and-forward JD>> system which was meant to resilient and flexible enough to JD>> route around outages and breakdowns and unreliable links. Absolutely. JD>> The first nodelist could apparently jot handle more than JD>> 250 nodes, and the zone/net/hub/node system arose almost JD>> as a kludge to handle the growth to over 19000 entries in JD>> the nodelist at its peak. I was not aware (or I forgot) about the initial 250 node limitation. Interesting. JD>> When I established my newest board, I was invited to join JD>> my local zone and facilitate the local region, with the JD>> assumption that all my traffic would, as is traditional, JD>> route through the region to the Zone hub and then onto the JD>> "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. JD>> As I proceeded to set this up, I found it completely JD>> trivial to add feeds to and from Europe, Russia and New JD>> Zealand for conferences carried there and not within my JD>> Zone. I could also have picked up all my conferences from JD>> one of those and simply ignore everyone else in my Zone. I JD>> thought that was a little ride though. It is only JD>> 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. JD>> And I'd like to add: Total user selection of what they JD>> want to see, and technical decisions where and how it is JD>> 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. JD>> I'm not truly an expert in all of this stuff, more a JD>> generalist and an enthusiastic amateur, so please take JD>> that into consideration. I haven't heard much expertise from the assumed experts, so anything sounds good at this point! :D JD>> What I believe is imperative is that the barrier to entry JD>> needs to be lowered drastically. It should be as simple as JD>> 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. JD>> We need to think in terms of Mesh networking, not some JD>> sort of star topology mindset. I'm not necessarily talking JD>> about the transport layer, but the arrangement of the JD>> 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. JD>> By this I mean that someone should choose to join the JD>> network and connect automatically to peers. These could be JD>> geographically distant but close in network terms or vice JD>> 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? JD>> Scenario 1: There is a remote village, physically distant JD>> from any network connection whatsoever. [...] The point of JD>> this scenario is to illustrate that the current concept of JD>> dialup BBS (now shifted to Telnet et al) is in some ways a JD>> shift away from the roots of FidoNet. This disconnected JD>> store and forward model is what the network was designed JD>> 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. JD>> My proposal is that we need to look for a different JD>> network authentication and routing model. One that handles JD>> the instant connectivity just well as it does the JD>> completely irregular and unreliable links. Ah.. AI enters fidonet? That would be cool! JD>> It's also become clear that there is reason to be JD>> concerned about the platforms that provide the major JD>> communications at the moment. We've seen these platforms JD>> being used in places and at tokes where they've made an JD>> incredible difference, such as during the Arab Spring, the JD>> Hong Kong protests and then during various natural JD>> disasters etc. We've also seen them be cut off completely JD>> by governments or by the providers to whole communities or JD>> 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. JD>> The anarchic nature of FidoNet was designed to prevent JD>> that. I'm also pretty convinced that when it was designed JD>> the initial intention of the Internet/DARPAnet played a JD>> part that is to survive a nuclear attack. .. We need to JD>> 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. JD>> One of the largest concerns people have expressed is worry JD>> over "encryption". What they truly mean is not encryption JD>> per se, but privacy. That, in my opinion, shouldn't be JD>> part of the network but a software layer on top. PGP comes JD>> to mind as a good model. Building that in to clients JD>> 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. JD>> It seems that most people establish a BBS primarily for JD>> their own use. That is that they are the primary user, and JD>> additional users are pretty sparse. It's for this reason JD>> (and others) that I'd suggest that the focus should be JD>> catering for this. [...] They could be collaborative JD>> efforts arranged on the fly. [...] Once a user or system JD>> has Registerd themselves on the app, there should be an JD>> automated process where it announces them to the network JD>> at large and where the information gets collated via a JD>> 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. JD>> 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. JD>> The various message formats are archaic and ridiculous in JD>> a lot of ways. There should be a standard implementation JD>> 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. JD>> My personal preference would be for SQLite due to it's JD>> ease of use and ubiquitous distribution (how many billions JD>> 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. JD>> The display format! ANSI for crying out loud! Surely we JD>> can do better than that? Why about send SVG commands which JD>> are rendered on the device? Maybe using the Cairo graphics JD>> libraries or their equivalent? I know RIPTerm was an JD>> 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. :( JD>> Maybe it's time to develop a new standard which is simple JD>> and easy to implement? It beggars belief that we are using JD>> software that is actually designed with VT100 terminals in JD>> 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. JD>> Having said this, nothing prevents us from separating the JD>> display layer from the transmission layer. If we design JD>> the protocol sufficiently well, then that could also be JD>> relatively agnostic, or at least provide fallback options. JD>> For example, negotiation with the client with "new RIP" JD>> preferred, falling back to in descending order, Rendered JD>> 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. JD>> Telnet. Ask anyone under thirty who is not in IT to use JD>> telnet and you may as well have spoken in a foreign JD>> 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 JD>> Composing messages. Make it something like Markdown so JD>> it's also agnostic and the formatting is deferred to the JD>> client. Syncronet, OpenXP, and now Fido2telebot achieve some of this! JD>> Images. There aren't any. This is probably the biggest JD>> reason for the poor uptake after the lack of clients for JD>> devices. Yeah.. the newer generations all seem to expect visual candy. JD>> I'd suggest though that rather than duplicate http for JD>> this, [...] possibly making them "out of band". [...] JD>> 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. JD>> Images and video etc are, of course, big attractions to JD>> 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. JD>> They're also bandwidth hogs. I think this is where the JD>> "control by the user" needs to be rigorously built in, JD>> there is a simple and enforceable way to select where and JD>> how images are accepted. It's the bandwidth hogs that concern me. An out of band solution sounds pretty good! JD>> Spam. Spam kills message board and conferences if not JD>> killed instantly. That's why there must be some mechanism JD>> 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. JD>> Reputation. [...] for example, if you're reputation is low JD>> (or your rank is 'Noob'), there are only certain things JD>> you can do, or certain conferences you can join. The JD>> longer you are part of the system, the more you JD>> participate in certain activities etc, the more tour JD>> reputation/rank can change. Hmmm, sounds like the social-ranking system in China. LOL. JD>> If, for example, no messages are accepted from noobs, JD>> [...] 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. JD>> [...] hit-and-run spammers who use images won't be able to JD>> generate new user IDs to post them. If there is an JD>> algorithm that sees a user posting the same content JD>> hundreds of times, or hundreds of messages from the same JD>> address, or other variations on the theme, then they can JD>> be flagged as potentially spammers and handled JD>> 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 JD>> I believe this is vital however, that it be programmed in JD>> and that the rules are enforced programmatically and not JD>> by people, as it's less prone to all sorts of nonsense we JD>> see on existing platforms. [...] there's nothing to stop JD>> him ignoring the flags and accepting those messages, but JD>> also nothing stopping all the other nodes from both JD>> refusing to accept them as well as refusing to forward JD>> 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. JD>> I have numerous other thoughts, but I hope this is enough JD>> 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) .