Subj : Is binkp/d's security model kaputt? To : apam From : Oli Date : Sat Sep 18 2021 11:47 am apam wrote (2021-09-18): >> It's funny that the original topic was about binkd/p and soon we were >> talking about creating a new message network infrastructure/technology >> with FTS-compatible access. a> Why is binkd even a thing? What's the history of it? I don't know.. Apart a> from integrating with the binkley style outbound, why did they make a new a> protocol to transfer these messages? http://ftsc.org/docs/fts-1026.001 : Existing Fidonet Technical Standards and Fidonet Reference Library documents [FTS-0001], [FTS-0006], [EMSI] specify both session handshake procedures and transmission capabilities that imply: * non-reliable communication channel between mailers * low round-trip times in the communication channel between mailers. [...] Combination of these factors imposed the following requirements for the new Fidonet protocol: * error control can be eliminated throughout the session layer protocol for both handshake and default file transfer method * session setup procedure should minimize number of synchronization points for fast handshake * protocol should be insensitive to delays and robust with respect to timeouts * application flow control should be moved to file level; individual data frames do not need to be error checked nor acknowledged * protocol should be independent from both higher and lower layer protocols * protocol should be reasonably easy to implement and allow future extensions. >> I'm more interested in fixing the current software and standards. a> Why? The "current" software is kind of unfixable, it would require people a> with access to the current software's code having a desire to fix it. Apart from Mystic, most of the used software is open source. This doesn't mean anyone will develop any desire to fix or improve anything. But I doubt that starting something from scratch will be more successful. a> It would also require said people working together... Yeah ... not happening. a> Seems like the nostalgia is for most people things "like" they had in the a> 90s, not actually things they had in the 90s. Otherwise mystic wouldn't a> be so popular. Binkd wasn't a thing that far back either, True, true. But nostalgia isn't everything. Binkd appeared in the 90s and helped to keep Fidonet alive for a couple more years (if it's still alive is debatable). If there were no Binkd, maybe FTNs would running on another protocol, maybe EMSI over TCP, HTTP (although not the best fit for bidirectional file transfer) or nothing at all. a> or "the c64" etc you mean this one? https://retrogames.biz/thec64 : This is your fallback content in case JavaScript fails to load. The C64 The World’s Best-Selling Home Computer – Reborn, Again… a> If you pack this new software in a black box with a curses interface I a> bet people wouldn't even care :) :) I do. Or I don't. I don't know, the new BBS's are not that interesting anymore. Even in the 90s I downloaded my mail and read it offline. GUIs were already a thing ;-). Why not put a BBS on top of a news server, Matrix, XMPP, ...? Or create a BBS that compiles to WASM and works in the browser and can connect to other browser-BBS over WebRTC. a> Anyway, it all boils down to nothing if no one can be bothered to write a> new software. I think that's the real problem... BBSing and BBS-style networks are such a small niche that it is understandable. I feel the software history perspective is more important. It's sad that some FTN / BBS software just don't work anymore on newer systems. And some of the old stuff was better than some of the newer programs we have today. Maximus, Squish and many other software were delivered with proper documentation. Of course there was a lot of crappy software too. The thing is, there is no real direction and no bigger goals. The BBS scene just is ... --- * Origin: 1995| Invention of the Cookie. The End. (21:3/102) .