I'm trying to figure out how to configure binkd for reliable security. I see several problems. Part design flaw of the binkp protocol (and FTN tradition), part implementation.

1) Passwords stored in clear text
It's not ideal, but I can live with that. At least it allows MD5-CRAM, which is not very secure, but better than clear plaintext over the wire.

2) Password is one way authentication only
The client side (the calling system) does send a password, but there is no authentication of the server. It's not really a fully "pwd protected session" as binkd suggests. A man-in-the-middle can ignore the password (or accept any password) and binkd still would log a "pwd protected session".

3) CRYPT cannot be enforced
If I understand it correctly, a CRYPT session only works when both sides use the same password. It's kind of an indirect authentication of both sides. Unfortunately there is no simple way in binkd to enforce CRYPT. Standard binkd does not prevent man-in-the-middle with CRYPT.

4) No direct node address mapping
For sessions with multiple AKAs the protocol does not allow sending files from a specific AKA and/or to a specific AKA. This has several implications:

5) nonsecure inbound might be delivered to 'secure' inbound
If the session is "pwd protected" everything will be stored in the 'secure' inbound directory, even files and PKTs for AKAs that don't have a password.

6) The ibox field is a joke
Just because you configured an ibox for a node, doesn't mean that all files for that node will always be put in that ibox. The ibox also might receive files for other nodes.

7) check-pkthdr does not always work reliable
Similar problem with check-pkthdr. We cannot always reliably predict the From- and To-AKA for a PKT in a multi-AKA session.


IMHO binkd/binkp offers lots of pseudo security and several security and usability pitfalls. Are there any good workarounds or do we need a binkp/2.0?

---
* Origin: . (21:3/102)

Re: Is binkp/d's security model kaputt?
By: Oli to All on Thu Sep 02 2021 09:42 am

I'm trying to figure out how to configure binkd for reliable security. I see several problems. Part design flaw of the binkp protocol
(and FTN tradition), part implementation.

IMHO binkd/binkp offers lots of pseudo security and several security and usability pitfalls. Are there any good workarounds or do we
need a binkp/2.0?

So I too, would love to see many improvements - that sees this retro hobby still function (with the retro software), but at the core, it leverages modern technologies for the benefits that they bring (improved security, improved authentication, improved authorisation, alternative transport methods).

I actually dont think a binkp/2.0 should do it all (but it probably could). I would also like to see other transport mediums in use - perhaps packet radio, perhaps something like lora - so that systems could communicate independantly of being dependant on a "service provider" (which means whatever is sent between 2 systems should be efficiently sent).

I have a few things to sort out with my new mailer, and then I'd be in a position to proto type something new - but I guess that's only useful if there is something else that uses it too. It would be nice to know that other mailer developers were inspired to make enhancements as well.


...ëîåï
--- SBBSecho 3.14-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

On 02 Sep 2021 at 09:42a, Oli pondered and said...

IMHO binkd/binkp offers lots of pseudo security and several security and usability pitfalls. Are there any good workarounds or do we need a binkp/2.0?

What you really need is an HTTPS-based transport.

Part of the issue is that there is the protocol (which is superfluous)
and the implementation(s), which vary widely in terms of quality and robustness. All of the points you raise with the protocol are obviated
by using HTTPS instead: mutual authentication, secure transport, etc;
also compression, parallelization, transfer resumption, checksumming,
etc.

I propose an exchange where a client connects to a server, GET's a list
of articles offered by the server from a generic "offer" resource. The
offer list includes a resource identifying each article. The client
retrieves whatever it's interested in via a normal HTTP GET against the corresponding resource.

The client indicates the disposition of everything it was offered by
posting to a generic "ack" resource; the body of the post is basically
the same list but with a disposition for each article: "ack" (received),
"nack" (neither received nor wanted) or "defer" (will try again later).
The default for an article missing from the list is "defer". Note that
simply completing a successful GET is not the same as an "ack"; the
requesting side may have some difficulty saving the article, etc, so it
must wait for an "ack" before removing the article from a list bound
for the requester.

The inverse of this would also be done: an HTTP "POST" to the offer
resource; the server resource to the POST would contain a body (this is unusual, but allowed by the protocol) of a list of articles to send
and resources to send them to: the client would then execute HTTP "PUT" requests for each article indicated by the server. Finally, it would
issue a "GET" against the "ack" resource to retrieve the disposition
of each article it offered to the server, as above.

A text-based serialization for article data using something like JSON
would also be nice.

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

deon wrote (2021-09-02):

I'm trying to figure out how to configure binkd for reliable
security. I see several problems. Part design flaw of the binkp
protocol (and FTN tradition), part implementation.

IMHO binkd/binkp offers lots of pseudo security and several security
and usability pitfalls. Are there any good workarounds or do we need
a binkp/2.0?

So I too, would love to see many improvements - that sees this retro
hobby still function (with the retro software), but at the core, it leverages modern technologies for the benefits that they bring (improved security, improved authentication, improved authorisation, alternative transport methods).

For me it's important that it is still simple and works for slow computers and slow connections. And what are modern technologies? Contemporary software is 80% bloat and waste of resources. I'm running Fidonet software, because I don't need 1GB of download and disk space to compile a rust application that does some basic stuff. Or run a messaging server in Python, that wastes a ton of bandwidth and is so complicated that the re-implementation in Go takes forever. Or software where the only supported installation method is a docker container in linux (which installs all the DB software you are already running again).

But that is only a little general rant. I'm very much interested in any new developments in FTN land. What I would like to see is further simplification. The Fidonet standards are a convoluted mess. We have the message as the central building block. I wouldn't touch the message format, because that would break compatibility and would lead to a different network. Everything else can easily be changed. We can use another transmission protocol, just create a nodelist flag (or use DNS SRV records). We don't have to use PKT files (their not even a standard) for transmission. We can get rid of the weird and limited BSO. Tossing / routing could be handled differently ...

I actually dont think a binkp/2.0 should do it all (but it probably
could). I would also like to see other transport mediums in use - perhaps packet radio, perhaps something like lora - so that systems could communicate independantly of being dependant on a "service provider"
(which means whatever is sent between 2 systems should be efficiently sent).

Developing for IoT, low-bandwidth and unreliable connections is not a bad idea. I'm not sure if binkp is the best protocol for these types of transports.

I have a few things to sort out with my new mailer, and then I'd be in a position to proto type something new - but I guess that's only useful if there is something else that uses it too. It would be nice to know that other mailer developers were inspired to make enhancements as well.

Good luck with that ;-). Maybe BinkIt, but the rest? Binkd gets only bug fixes and even PRs get ignored. The last time I checked Mystic it was still a binkp/1.0 mailer. ifcico, mbcico, d'bridge, ...?

The best chance would be a drop-in replacement for binkd. Or if it's based on another protocol, something that can run beside the binkp mailer and use the same BSO.

---
* Origin: . (21:3/102)

Am 03.09.21 schrieb tenser@21:1/101 in FSX_NET:

Hallo tenser,

What you really need is an HTTPS-based transport.

Oh no, not again the idea to pack everything into HTTP/HTTPS.
While this is tempting, I think the main part of the said problems with
BinkP could be solved by using a TLS secured connection.

The idea behind binkp was that eg. existing tosser software could be used together with a new mailer component which then talks to other systems.

So your idea would not only replace the mailer but also many other parts
of existing software with new programs.

And btw, there is already another protocol which exchanges such data based
on messages and message lists: NNTP. There is even a SSL-enabled version, NNTPS.

I think the key feature of BinkP is the compatibility with existing
programs.
So if your idea has this in mind, it would be great :)

Regards,
Anna

--- OpenXP 5.0.50
* Origin: Imzadi Box Point (21:3/127.1)

tenser wrote (2021-09-03):

On 02 Sep 2021 at 09:42a, Oli pondered and said...

IMHO binkd/binkp offers lots of pseudo security and several
security and usability pitfalls. Are there any good workarounds or
do we need a binkp/2.0?

What you really need is an HTTPS-based transport.

Part of the issue is that there is the protocol (which is superfluous)
and the implementation(s), which vary widely in terms of quality and robustness. All of the points you raise with the protocol are obviated
by using HTTPS instead: mutual authentication, secure transport, etc;
also compression, parallelization, transfer resumption, checksumming,
etc.

I thought about that too and I'm still not sure if I like or dislike the idea. It would make programming a mailer a lot easier. It's not hard to extend the protocol and less likely that you break compatibility to older mailers. It's even thinkable that in a parallel timeline they developed an http-based FTN protocol in the 90s and binkd was never a thing.

But it would be just another step to the complete HTTPification of the internet. Maybe just switch to the Internet Mail format ...

A text-based serialization for article data using something like JSON
would also be nice.

.... and something like JMAP ;P

---
* Origin: . (21:3/102)

On 03 Sep 2021 at 11:16a, Oli pondered and said...

The Fidonet standards are a convoluted mess.

Not only that, they're not as efficient as people think. There's
a lot of wasted space in .PKT (space for fields that are never filled
in), and the need to record every node that's seen a message doesn't
seem scalable. USENET solved this by including a routing path as
articles transited the network; this mean that one could cheaply
detect loops when communicating with peers.

We have the message as the central
building block. I wouldn't touch the message format, because that would break compatibility and would lead to a different network.

I thought about these problems a bit when I wrote ginko, and became
convinced that the real solution was to serve legacy systems at the
edge. For backbones and hubs, use new formats with a standard
canonicalization and checksumming for duplicate detection and article identification, but only translate to/from legacy formats when
communication with legacy software.

Everything else can easilyI
be changed. We can use another transmission protocol, just create a nodelist flag (or use DNS SRV records). We don't have to use PKT files (their not even a
standard) for transmission. We can get rid of the weird and limited BSO. Tossing / routing could be handled differently ...

Honestly? The whole hunk of poo ought to be tossed and re-architected.
Using the things we've improved on in the last 40 years will actually
simplify the whole mess, making it easier to move to IoT devices and
so on.

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 03 Sep 2021 at 12:16p, acn pondered and said...

I think the key feature of BinkP is the compatibility with existing programs.

This is easily handled by an adapter layer at the edge.

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 03 Sep 2021 at 11:55a, Oli pondered and said...

But it would be just another step to the complete HTTPification of the internet. Maybe just switch to the Internet Mail format ...

You say that as if it's a bad thing, though I wouldn't use
the RFC822-descended mail formats. But Fidonet (and all
extant FTN networks) have depended on the Internet for decades;
they've just used hobbyist protocols designed by amateurs that
are fragile and poorly conceived. By using something standard,
they could actually take advantage of infrastructure to be
more robust, performant and secure...probably simpler, too.

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

tenser wrote (2021-09-04):

On 03 Sep 2021 at 12:16p, acn pondered and said...

I think the key feature of BinkP is the compatibility with existing
programs.

This is easily handled by an adapter layer at the edge.

What or where is the edge in a p2p network. And why is there always a tendency to centralize the shit out of FTNs?

---
* Origin: . (21:3/102)

acn wrote (2021-09-03):

What you really need is an HTTPS-based transport.

Oh no, not again the idea to pack everything into HTTP/HTTPS.
While this is tempting, I think the main part of the said problems with BinkP could be solved by using a TLS secured connection.

Yes and no. A simple TLS approach would get you a secured connection and optionally authentication (of one or both sides). We already use binkps, that part is solved.

The problem is in the design of binkp, which replicated some of the design problems of EMSI. The moment one or both sides presents multiple addresses anything goes. Unauthenticated transmissions might be put in the 'secure' inbound, inboxes don't work reliably. The last line of defense are 8 character uppercase ASCII passwords in the PKT and TIC files.

I could imagine ways to negotiate the client and server address with some certificate and SNI magic over TLS before the binkp sessions starts and then do a session only for a single address for each side. But I don't believe that is what you suggested (wäre ein bißchen von von hinten durch die Brust ins Auge). I would expect all kind of new problems and when today several mailers don't even get a basic TLS session right. I also wouldn't put too much logic in the TLS layer as there are alternative encrypted transports, for example Tor, i2p, lokinet and some other overlay networks / p2p VPNs.

The idea behind binkp was that eg. existing tosser software could be used together with a new mailer component which then talks to other systems.

Which could be done again with a new mailer protocol, even if it was based on HTTP.

---
* Origin: . (21:3/102)

On 03 Sep 2021 at 05:41p, Oli pondered and said...

What or where is the edge in a p2p network. And why is there always a tendency to centralize the shit out of FTNs?

I'd define the edge as anywhere that legacy systems contact the network.
As for centralizing...that's part of the design of FTN; it's very
hierarchical and there's non-trivial overhead to setting up a hub.

I think with an HTTP-based protocol, it becomes much easier to actually
make it a mesh. Any node that's running the HTTP service can, in
principle, peer with any other node ... much like USENET.

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 04 Sep 21 03:28:35, Tenser said the following to Oli:

You say that as if it's a bad thing, though I wouldn't use
the RFC822-descended mail formats. But Fidonet (and all
extant FTN networks) have depended on the Internet for decades;
they've just used hobbyist protocols designed by amateurs that
are fragile and poorly conceived. By using something standard,
they could actually take advantage of infrastructure to be
more robust, performant and secure...probably simpler, too.

While that is very true, the problem is the hobbyist protocols designed by amateurs are here to stay, thats what the vast majority of Sysops appear to be comfortable with. BinkD was the last "real" innovation because it solved a problem which were the hodgepodge cumbersome scripting, FTP and TransX/Email methods of the time. There has not been one single FTN innovation since then that is worthy of being adapted on such a mass-scale like BinkD was.

Every couple of years or so this same exact topic comes up, almost verbatim, and after some banter about why it would be great to use something else/something better... even if someone is spot-on correct with something technically, eventually there is that realization that FTN's are what they
are and won't change. Then that convo fizzles out. Sysops are just happy trading banter on a flawed/obsolete network because they made it just work.

Anything beyond that just goes over their heads, its too complicated, too "techie".

Atreyu

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (21:1/176)

IMHO binkd/binkp offers lots of pseudo security and several security and usability pitfalls. Are there any good workarounds or do we need a binkp/2.0?

We need to make sure other platforms are not broken if we go to another revision.

... No one knows what's next, but everybody does it.

--- Mystic BBS v1.12 A47 2021/08/19 (Windows/32)
* Origin: Inland Utopia BBS (21:4/108)

Re: Re: Is binkp/d's security model kaputt?
By: tenser to Oli on Sat Sep 04 2021 03:24 am

Howdy,

Not only that, they're not as efficient as people think. There's
a lot of wasted space in .PKT (space for fields that are never filled
in), and the need to record every node that's seen a message doesn't
seem scalable.

Yes I've been working on this randomly after the last few months - trying things out as I think of something.

There are 2 parts to a packet - header and payload, and I think the header can be reduced quite a bit (currently its 58 chars). I've created a format that is 50 chars - for a full 5D packet, although I'm wondering if the 5D idea should be dropped and only 4D retained (that brings it back to 37 chars). It could be trimmed a bit more if the "src" was taken from the calling system, saving another 8 chars. Using the packet name itself could reduce the header by a further 8 chars or so - and I'm playing with that idea. (So its down to 21 from todays 58).

With the header, the receiving system could calculate a checksum on the packet and determine whether it accepts the payload. (Because its seen that packet before or not - or if it needs to resume from an offset.)

The payload is the messages, and they too could have a "header" (which it kinda has today) and (sub) "payload" portion that determines if the message is accepted is discarded (I havent thought this part through yet). The idea being from the message header the tosser decides whether it is a dupe, loop, too old, or relevant "area" without having to process the current seen-by/path/msgid, etc.

I thought about these problems a bit when I wrote ginko, and became convinced that the real solution was to serve legacy systems at the
edge. For backbones and hubs, use new formats with a standard canonicalization and checksumming for duplicate detection and article identification, but only translate to/from legacy formats when
communication with legacy software.

This is the approach that I've been thinking of too. I also want to bring in an element of high availability, so that a single hub going offline (scheduled or awol) that another system accepts the packets (without having to rebuild them).

Honestly? The whole hunk of poo ought to be tossed and re-architected.
Using the things we've improved on in the last 40 years will actually simplify the whole mess, making it easier to move to IoT devices and
so on.

Yup, there is no reason that the "core" follow the old ways.


...ëîåï
--- SBBSecho 3.14-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

Re: Is binkp/d's security model kaputt?
By: Oli to deon on Fri Sep 03 2021 11:16 am

Hi

Or software where the only supported installation method is a docker container in linux (which installs all the DB software you are already running again).

So this comment pricked up my ears.

I like docker for many reason (from the developers point of view and the consumers) - and installing everything again (I'm paraphrasing your comment) is not a requirement.

In many deployments, it does look like if I have 5 LEMP stacks, you end up with 5 DB instances, 5 PHP instances, 5 NGINX instances - but that doesnt take up 5 x the space (of the applications). Is that what you meant, and your concern, by your comment?

For those 5 LEMP environments, you could end up with 1 NGINX, 1 DB and 5 PHPs - but most deployments dont do this for scalabilty and availablity reasons (which is, IMHO, one of the core benefits of docker).


...ëîåï
--- SBBSecho 3.14-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

Re: Is binkp/d's security model kaputt?
By: Oli to tenser on Fri Sep 03 2021 05:41 pm

What or where is the edge in a p2p network. And why is there always a tendency to centralize the shit out of FTNs?

What does a p2p version of FTN look like?

How do you get chronological, reliable, availabile file and mail transfers?


...ëîåï
--- SBBSecho 3.14-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

On 03 Sep 2021 at 05:23p, Atreyu pondered and said...

scripting, FTP and TransX/Email methods of the time. There has not been one single FTN innovation since then that is worthy of being adapted on such a mass-scale like BinkD was.

I wonder if this is more to do with the lack of people about with the skills
to do such things? I'd love to be able to code and contribute but I don't really have those skills and I think I am not alone.

That said, there are some very talented people active in FTN networks like
this one and others, that do have some coding chops that could be bought to bear on such things. I'm certainly open to trying a fsxNet 2.0 running under
a totally different infrastructure if/when/should someone develop something
we could trial.

Every couple of years or so this same exact topic comes up, almost verbatim, and after some banter about why it would be great to use something else/something better... even if someone is spot-on correct
with something technically, eventually there is that realization that FTN's are what they are and won't change. Then that convo fizzles out. Sysops are just happy trading banter on a flawed/obsolete network
because they made it just work.

I don't think the ending is as set as this suggests. It almost feels like a Terminator moment to me :) 'The future is not set and is what we make it"
It's more the case of someone(s) having the time and interest to devote to
such an endeavor and collaborate on such things.

Sure if there are folks/sysops that are happy with the status quo and the settings/direction that had been about for many years, all well and good. But if there are people interested in being experiential in deigning and
developing new ways of running messaging/file sharing networks based upon
what is seen to be the best bits of FTN blended with tools and ticks of today then I'm interested :)

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 04 Sep 2021 at 03:24a, tenser pondered and said...

seem scalable. USENET solved this by including a routing path as
articles transited the network; this mean that one could cheaply
detect loops when communicating with peers.

Yes this is a good system. Like the bang paths of UUCP days.

I thought about these problems a bit when I wrote ginko, and became convinced that the real solution was to serve legacy systems at the
edge. For backbones and hubs, use new formats with a standard canonicalization and checksumming for duplicate detection and article identification, but only translate to/from legacy formats when communication with legacy software.

I recall you working on Ginko and we doing some tests some years back to get compatibility with legacy FTN stuff :) I agree with your comments above.

I think when it comes to discussions such as these whereby folks are keen to innovate the inevitable tensions arise between the boundless opportunities of innovation without hindrance of being tied to legacy systems / ways of doing
/ dogma etc. vs. wanting some way for those very same legacy systems to be
able to take part if they wish.

Honestly? The whole hunk of poo ought to be tossed and re-architected. Using the things we've improved on in the last 40 years will actually simplify the whole mess, making it easier to move to IoT devices and
so on.

:)

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 02 Sep 2021 at 09:41p, deon pondered and said...

So I too, would love to see many improvements - that sees this retro
hobby still function (with the retro software), but at the core, it leverages modern technologies for the benefits that they bring (improved security, improved authentication, improved authorisation, alternative transport methods).

I agree with the ideas of using modern technologies to bring improvements in security (end to end encryption / authentication etc.), mesh or p2p decentralized networking, and very importantly alternative transport methods.

I'm not too sure just how much needs to be built to accommodate legacy/retro software though. If catering to legacy is a must then that would limit what
can be done. I also think if the early devs of FTN tried too much to cater to the early FTN stuff there would be little innovation perhaps?

I guess subject to what is seen to be most important some of those other
items on the list above may fall off the must haves lists? I'm not sure I am not a developer.

At it's heart I liked the FTN approach for it's historical ability during
POTS days to facilitate a store and forward network that anyone could take
part in with reasonable ease using their own readily available gear from home.

I worry that with our global reliance on the Internet for communications
we're all way to heavily dependent on a system that (let's say during a time
of war) would be quickly targeted by bad actors/countries leading to swift
and sudden communications blackouts. When I look at the maritime cables that
a large chunk of global communications flow through and think about how
quickly a hostile force opting to cut them would lead to significant intercontinental impacts... my mind quickly drifts into pondering ways to
stay communications resilient at times of adversity (natural or man made).

could). I would also like to see other transport mediums in use -
perhaps packet radio, perhaps something like lora - so that systems
could communicate independantly of being dependant on a "service
provider" (which means whatever is sent between 2 systems should be efficiently sent).

Yep, totally agree, have wanted to / am keen to experiment more in this area too. I think the real trick would be how to make those international links work. In POTS time we had international toll calls. In this future era if the cables are cut are we left with HF radio gear and anything in orbit not taken out by bad actors? I've been pondering the whole IoT and LoraWAN space a possible place to shift FTN style (or some new generation) of messaging
packet across :)

I have a few things to sort out with my new mailer, and then I'd be in a position to proto type something new - but I guess that's only useful if there is something else that uses it too. It would be nice to know that other mailer developers were inspired to make enhancements as well.

I think with Tenser (possibly Apam) and yourself you could find a few people interested in collaborating from a coding point of view. Even if you just create the tools and systems and allow others to start using them with some time/critical mass/rising levels of interest... then I think other developer type folks may raise their heads and show interest.

A lot of it comes back to what is the ideal state / system / network thought
to be desirable to build.

In my head I'd have a Raspberry Pi I could connect to the internet or packet radio or LORA etc. and some software that I could advertise myself as being a member of a given wider network. I'd allow messages to flow through and
onwards from my little system (like we do in FTNs) and mesh with anyone who wanted to mesh with me. As I meshed with others I'd build a picture of the nodes in the network and be able to message them like we do with direct or routed netmail.

I'm going to stop now, I'm rambling :)

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 04 Sep 21 19:50:30, Avon said the following to All:

I wonder if this is more to do with the lack of people about with the skills to do such things? I'd love to be able to code and contribute but I don't really have those skills and I think I am not alone.

Its definately not for lack of tech talent, its more of a lack of desire from the Sysops to embrace it, because there is just no big pressing demand for it. If there were demands for a new packet format, P2P distribution, decentralized messages and nodelists etc... all of it would have been solved decades ago.

The second problem is FTN software traditionally continues the trend of backwards compatibility. That stifles any serious innovation.

There are good reasons why many talented developers jumped ship years ago...

Atreyu

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (21:1/176)

deon wrote (2021-09-04):

Not only that, they're not as efficient as people think. There's
a lot of wasted space in .PKT (space for fields that are never filled
in), and the need to record every node that's seen a message doesn't
seem scalable.

Yes I've been working on this randomly after the last few months - trying things out as I think of something.

There are 2 parts to a packet - header and payload, and I think the
header can be reduced quite a bit (currently its 58 chars). I've created
a format that is 50 chars - for a full 5D packet, although I'm wondering
if the 5D idea should be dropped and only 4D retained (that brings it
back to 37 chars).

I would keep the 5D. We are waiting for decades for full 5D support and you want to drop it now, when there is a chance to do it properly?
How do you get from 50 to 37 chars by removing the domains? AFAIK there is also no official length limit of the domain. Some FSC suggest 8 byte, others 64k bytes. Binkd is hard coded to 32 bytes.

It could be trimmed a bit more if the "src" was taken
from the calling system, saving another 8 chars. Using the packet name itself could reduce the header by a further 8 chars or so - and I'm
playing with that idea. (So its down to 21 from todays 58).

:) What are the remaining 21 chars?

I thought about these problems a bit when I wrote ginko, and became
convinced that the real solution was to serve legacy systems at the
edge.

Honestly? The whole hunk of poo ought to be tossed and re-architected.

Yup, there is no reason that the "core" follow the old ways.

edge, core, legacy systems ... interesting choice of words for something that doesn't even exist.

What is it good for if we don't even manage to have proper FTN-style paragraphs and quotes?

---
* Origin: 1995| Invention of the Cookie. The End. (21:3/102)

deon wrote (2021-09-04):

What or where is the edge in a p2p network. And why is there always a
tendency to centralize the shit out of FTNs?

What does a p2p version of FTN look like?

Fidonet technology was always and still is peer-to-peer. Maybe not in the DHT / file sharing sense, but in the sense that all nodes (and even some points) are running the same kind of software and can call each other. Yes, people do like to build some hierarchical structures on top of it, but this is not a requirement.

---
* Origin: 1995| Invention of the Cookie. The End. (21:3/102)

Hello Avon!

04 Sep 21 20:16, you wrote to deon:

When I look at the maritime cables that a large chunk of global communications flow through and think about how quickly a hostile
force opting to cut them would lead to significant intercontinental impacts... my mind quickly drifts into pondering ways to stay

All it takes is a ship to drop anchor in the wrong spot and a cable is taken out.
Or just walking into the building holding the cable landing site and turning off the router!

There was a cut to the southern cross cable network just this year due to a ship...

Btw: The NZ cable landing sites are at

Whenuapai, New Zealand, TNZ cable landing station
Takapuna, New Zealand, TNZ cable landing station





Vorlon


--- GoldED+/LNX 1.1.5-b20180707
* Origin: Dragon's Lair BBS, Telnet: dragon.vk3heg.net (21:1/195)

Re: Is binkp/d's security model kaputt?
By: Oli to deon on Sat Sep 04 2021 12:18 pm

I would keep the 5D. We are waiting for decades for full 5D support and you want to drop it now, when there is a chance to do it
properly?

Yeah, but what value does 5D provide, or what problem does it solve (today)?

How do you get from 50 to 37 chars by removing the domains? AFAIK there is also no official length limit of the domain. Some FSC
suggest 8 byte, others 64k bytes. Binkd is hard coded to 32 bytes.

The only reference to domain that I could find was FSP-1028 which describes the domain as 8 chars and what those chars can be. The 8 chars can be encoded in 6 bits for each char, or 6 bytes for all 8 chars. In my working of a new packet header, I have 12 chars allocated for the domains, but I'm thinking it could be saved, if 5D wasnt considered.

:) What are the remaining 21 chars?

In reality, I think a packet header can be very short possibly shorter that 21 chars/bytes (havent really thought it through in detail). If there is proper authentication of the sender, then a packet from the sender doesnt need to have the senders details in the packet header, nor even a packet password. In fact it may not need the receipients details in the header either - but some other method of identifing whether the receipient will accept and process what the sender is sending - date/packet sequence number, or just a verifiable "signature" etc.

Ultimately the recipient of a packet processes the contents, and decides whether to accept or reject each item in the contents.

Yup, there is no reason that the "core" follow the old ways.

edge, core, legacy systems ... interesting choice of words for something that doesn't even exist.

I disagree - there was always a "core", and in some respects there still is. "Someobody" assigns you with an address that has a parent. Some othernets operate that way even though "fidonet" (or some systems) try not to. That core represents the subset of systems in a network that offers and a majority of systems collects mail from. It also represents a guarantee of a system to collect mail from, if you dont have other arrangements.

What is it good for if we don't even manage to have proper FTN-style paragraphs and quotes?

Well that's not a problem for the "infastructure" to solve, but I agree, it would be nice if it was handled consistently.


...ëîåï
--- SBBSecho 3.14-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

deon wrote (2021-09-05):

Re: Is binkp/d's security model kaputt?
By: Oli to deon on Sat Sep 04 2021 12:18 pm

I would keep the 5D. We are waiting for decades for full 5D support
and you want to drop it now, when there is a chance to do it
properly?

Yeah, but what value does 5D provide, or what problem does it solve (today)?

"640K ought to be enough for anybody" [1]

Today, it doesn't solve much, because it usually only works at the mailer level (kind of). I'm not sure if there is software that fully supports 5D down to the message base and mail reader. It would give a better separation of FTNs and better support for multi-zone othernets. Maybe it's overkill, but you never know what people are using the software for (as in fun and experimental). Maybe there will be some network that makes use of the full 64-bit (60 bit) address space. I don't know. I think it's just backwards trying to get rid of the 5D addresses. It's an old idea and it persisted. Yes, you could design a modern tech fidonet software for only a limited amount of users / othernets. But why?

RFC 1883 (IPv6) was published 1995 (development started much earlier) when only minority of people had access to the internet. Today IPv6-only is still no fun:

$ host -t AAAA docker.com
docker.com has no AAAA record

How do you get from 50 to 37 chars by removing the domains? AFAIK
there is also no official length limit of the domain. Some FSC
suggest 8 byte, others 64k bytes. Binkd is hard coded to 32 bytes.

The only reference to domain that I could find was FSP-1028 which
describes the domain as 8 chars and what those chars can be.

http://ftsc.org/docs/frl-1028.002 :
This document is a Fidonet Reference Library Document (FRL)
This document preserves FSP-1028.002 which was not considered for
promoting to a standard.

Nope, was rejected as a standard.

The 8 chars can be encoded in 6 bits for each char, or 6 bytes for all
8 chars.

Do you really want to add complexity just for saving 4 bytes? On a network were a big chunk of the content are redundant quotes (because the world hasn't figured out a way to reference these quotes. just copy them again and again. Is Ted Nelson still alive?). Or where we transmit the nodelist over and over again, because it's more convenient than a nodediff.

:) What are the remaining 21 chars?

In reality, I think a packet header can be very short possibly shorter
that 21 chars/bytes (havent really thought it through in detail). If
there is proper authentication of the sender, then a packet from the
sender doesnt need to have the senders details in the packet header, nor even a packet password. In fact it may not need the receipients details
in the header either - but some other method of identifing whether the receipient will accept and process what the sender is sending -
date/packet sequence number, or just a verifiable "signature" etc.

If we were exchanging mails via floppy disks or as email attachments, ftp upload, etc a packet header is useful. But with a properly designed protocol most (if not all) of the data in the packet header is redundant or becomes only a line in your tosser's log.

Unfortunately the binkp protocol copied the behavior modem mailers and still relies on packet passwords. If a binkp session were limited to one address on each side, files could be easily and reliably put into a specific inbox like

fsxnet/21.3.102.0/inbox/21.2.116.0-secure fsxnet/21.3.102.0/inbox/21.99.99.1-noauth

edge, core, legacy systems ... interesting choice of words for
something that doesn't even exist.

I disagree - there was always a "core", and in some respects there still is. "Someobody" assigns you with an address that has a parent.

Everyone who has power over the nodelist is part of the core? This seems to be more a social / organizational / I-like-to-wear-a-*C-hat thing than a technical necessity.

Some
othernets operate that way even though "fidonet" (or some systems) try
not to.

So there isn't always a defined core?

That core represents the subset of systems in a network that
offers and a majority of systems collects mail from.

but every node with a good enough tosser and mailer can become part of that subset or can decide to become a leaf node again. Or has arranged private peering with other nodes.

There was a time were the majority of system (in some regions) who collect mails were points. who was part of the core then?

It also represents a
guarantee of a system to collect mail from, if you dont have other arrangements.

There are no guarantees. And why would you need guarantees if you can make other arrangements?

What is it good for if we don't even manage to have proper FTN-style
paragraphs and quotes?

Well that's not a problem for the "infastructure" to solve, but I agree,
it would be nice if it was handled consistently.

The infrastructure (or "core") is not really the problem. It's the user interface, stupid. And it sucks big time.



[1] Bill Gates never said this.

---
* Origin: 1995| Invention of the Cookie. The End. (21:3/102)

On 03 Sep 2021 at 05:23p, Atreyu pondered and said...

While that is very true, the problem is the hobbyist protocols designed
by amateurs are here to stay, thats what the vast majority of Sysops appear to be comfortable with. BinkD was the last "real" innovation because it solved a problem which were the hodgepodge cumbersome scripting, FTP and TransX/Email methods of the time. There has not been one single FTN innovation since then that is worthy of being adapted on such a mass-scale like BinkD was.

I suspect you are right, but I also suspect that the people who
are content with binkp don't care about the security model etc.
There's only so much lipstick one can put on a pig, after all.

Every couple of years or so this same exact topic comes up, almost verbatim, and after some banter about why it would be great to use something else/something better... even if someone is spot-on correct
with something technically, eventually there is that realization that FTN's are what they are and won't change. Then that convo fizzles out. Sysops are just happy trading banter on a flawed/obsolete network
because they made it just work.

I don't see why people can't make incremental progress towards
a new protocol. A mechanism based on e.g. HTTP (and one might
notice that the protocol I sketched is kinda like streaming
NNTP, FWIW) could be used backbones between hubs, with binkp
remaining for edge nodes; over time, as software-still-under-
development adopts the new protocols, and as binkp becomes
increasingly archaic, fewer and fewer systems will use the
latter. Eventually, it'll be a handful that are using a
compatibility layer.

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 08 Sep 21 05:52:51, Tenser said the following to Atreyu:

I suspect you are right, but I also suspect that the people who
are content with binkp don't care about the security model etc.
There's only so much lipstick one can put on a pig, after all.

Correct.

I don't see why people can't make incremental progress towards
a new protocol. A mechanism based on e.g. HTTP (and one might
notice that the protocol I sketched is kinda like streaming
NNTP, FWIW) could be used backbones between hubs, with binkp
remaining for edge nodes; over time, as software-still-under-
development adopts the new protocols, and as binkp becomes
increasingly archaic, fewer and fewer systems will use the
latter. Eventually, it'll be a handful that are using a
compatibility layer.

Very simple why we can't make progress towards a new protocol - The BinkD protocol just works. There simply is no incentive to change whatsoever.

I'm not sure where you get the concept of "backbones and hubs" from as that is a relic of the dialup days where you had a few Napoleon-types dictating what they would and would not carry. Whenever I see someone mention "backbones and hubs" that person clearly does not understand FTN distribution in 2021.

Today you can get a feed from anywhere. Anyone can start an Echo, an
FTN, really anything. You don't need permission to do whatever. There is so much meshing and peering taking place now that no one system can affect
the distribution of Echomail for others. Everyone is in fact that "edge
node", even me. The only time the hub-and-spoke model applies is for Netmail and nodelist management.

I like the idea of security improvements to BinkD but anything beyond that is just lipstick on a pig as you say... and nobody wants to wear brown. People like what they have now. I tell anyone with ideas for better mail transport that you're better off starting your own FTN where everyone runs your code, your software.

Atreyu

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (21:1/176)

On 09/02/21, Oli said the following...

I'm trying to figure out how to configure binkd for reliable security. I see sev eral problems. Part design flaw of the binkp protocol (and FTN tradition), part implementation.

1) Passwords stored in clear text
It's not ideal, but I can live with that. At least it allows MD5-CRAM, which is not very secure, but better than clear plaintext over the wire.

[snip]

Hey Oli, I was wondering if any of these bugs/issues have been raised with
the developers? It's open source right?

--- Mystic BBS v1.12 A39 2018/04/21 (Linux/64)
* Origin: sonicbbs.co.uk :: Yorkshire, UK (21:4/144)

Hey Oli, I was wondering if any of these bugs/issues have been raised
with the developers? It's open source right?

It is, but developers are not very receptive to bugs/issues, even if you
fix them yourself and offer the fixes.

I've had a pull request sitting in github for months, that probably
hasn't even been looked at let alone commented on.

Andrew

--
|03Andrew Pamment |08(|11apam|08)
|13Happy|10Land |14v2.0|08!|07


--- Talisman v0.24-dev (Linux/x86_64)
* Origin: HappyLand v2.0 - telnet://happylandbbs.com:11892/ (21:1/182)

Satchmo wrote (2021-09-08):

On 09/02/21, Oli said the following...

I'm trying to figure out how to configure binkd for reliable
security. I see sev eral problems. Part design flaw of the binkp
protocol (and FTN tradition), part implementation.

1) Passwords stored in clear text
It's not ideal, but I can live with that. At least it allows
MD5-CRAM, which is not very secure, but better than clear plaintext
over the wire.

[snip]

Hey Oli, I was wondering if any of these bugs/issues have been raised with the developers?

Maybe these issues have been discussed in the past, I don't know. It's not that a new unknown vulnerability has been discovered. These are problems that are baked in the binkp (protocol) and the Binkleyterm-Style-Outbound. This is what you get, if standardization means documenting stuff that has been in use for a long time (instead of creating well designed standards in working groups and having a back and forth between specification and implementation).

Most of the problems are not binkd specific, but exist also for other binkp mailers.

It's open source right?

Right. And I'm trying to figure out how hard it is to implement some workarounds.

---
* Origin: 1995| Invention of the Cookie. The End. (21:3/102)

apam wrote (2021-09-08):

Hey Oli, I was wondering if any of these bugs/issues have been raised
with the developers? It's open source right?

It is, but developers are not very receptive to bugs/issues, even if you fix them yourself and offer the fixes.

I've had a pull request sitting in github for months, that probably
hasn't even been looked at let alone commented on.

Long periods of no response are not unusual in the binkd github repo. I hope there will be some reaction from @pgul in the next couple of weeks. If not the repos needs an additional maintainer or an 'official' fork.

---
* Origin: 1995| Invention of the Cookie. The End. (21:3/102)

On 04 Sep 2021 at 09:31a, deon pondered and said...

There are 2 parts to a packet - header and payload, and I think the
header can be reduced quite a bit (currently its 58 chars). I've created
a format that is 50 chars - for a full 5D packet, although I'm wondering if the 5D idea should be dropped and only 4D retained (that brings it
back to 37 chars). It could be trimmed a bit more if the "src" was taken from the calling system, saving another 8 chars. Using the packet name itself could reduce the header by a further 8 chars or so - and I'm playing with that idea. (So its down to 21 from todays 58).

Well, I'm not so much interested in shaving bytes off of these
data as I am reducing structural inefficiencies that cause things
to, say, grow linearly with the size of the network. The Path:
mechanism used on USENET to detect duplicates and loops seems
universally superior to FTN's `SEEN-BY` lines.

In terms of actual data sent over the wire, however, a textual
serialization using an extensible format seems superior to binary
formats. For that matter, the entire FTN naming scheme seems
antiquated, though I don't see a great way to remove that short
of a wholesale replacement (which may itself be worthwhile).

With the header, the receiving system could calculate a checksum on the packet and determine whether it accepts the payload. (Because its seen that packet before or not - or if it needs to resume from an offset.)

Yup. A collision-resistent hash as a mechanism for detecting
duplicates seems reasonable. Taking again from USENET, where
"Message-Id:" was defined to be globally unique, a similar
mechanism could be used here. Again, we run into the legacy
angle; to support legacy systems, it'd have to be something
else, even though FTN has defined a message-id equivalent,
since it's not universally implemented.

Yup, there is no reason that the "core" follow the old ways.

Agreed.

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 04 Sep 2021 at 07:50p, Avon pondered and said...

Sure if there are folks/sysops that are happy with the status quo and the settings/direction that had been about for many years, all well and
good. But if there are people interested in being experiential in
deigning and developing new ways of running messaging/file sharing networks based upon what is seen to be the best bits of FTN blended with tools and ticks of today then I'm interested :)

I think there's a natural tension here in that, for a lot of
folks, the motivation is to tinker with the old stuff, while
for others it's about setting up a communications mechanism.

I think there is a way in which both can be accommodated, by
selectively placing translation layers on what I refer to as
the "edge" of the network. But yeah, it's a hobbyist thing,
so....

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 04 Sep 2021 at 07:55p, Avon pondered and said...

I thought about these problems a bit when I wrote ginko, and became convinced that the real solution was to serve legacy systems at the edge. For backbones and hubs, use new formats with a standard canonicalization and checksumming for duplicate detection and article identification, but only translate to/from legacy formats when communication with legacy software.

I recall you working on Ginko and we doing some tests some years back to get compatibility with legacy FTN stuff :) I agree with your comments above.

Yeah, I think that was about a year and a half ago, but then
the pandemic kicked off and I haven't had a chance to get back
to it. The intent is to import FTN messages into an NNTP
server (and back). It just requires that most precious of
commodities: time. :-)

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 04 Sep 2021 at 12:41p, Oli pondered and said...

Fidonet technology was always and still is peer-to-peer. Maybe not in
the DHT /
file sharing sense, but in the sense that all nodes (and even some
points) are running the same kind of software and can call each other. Yes, people do like to build some hierarchical structures on top of it, but this is not a requirement.

That's only true in a literal sense, in that any node _can_ send to
any other node, but it's kind of not true in practice and in the shape
of the network; it's really designed to be hub-and-spoke, to mirror
the way the PSTN worked.

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Re: Re: Is binkp/d's security model kaputt?
By: tenser to deon on Thu Sep 09 2021 02:08 am

Howdy,

Well, I'm not so much interested in shaving bytes off of these
data as I am reducing structural inefficiencies that cause things
to, say, grow linearly with the size of the network. The Path:
mechanism used on USENET to detect duplicates and loops seems
universally superior to FTN's `SEEN-BY` lines.

So while I've been watching and involved in this thread - for me there are 2 topics at play (both important), and I know when I've been talking about 1, there is a response to it assuming the other.

The two items that I think are involved:

* Packets - which is a bundle of messages - sent by Mailers

* Messages - which is what ends up in a BBS - processed by Tossers
Yes, I agree, (some) users are ineffecient with messages, with verbose dialog and (verbose?) unnessary quoting. I dont think there is any solution here since everybody is different and has a unique way the they understand, process and respond to messages. There are some opportunities for effeciencies though (that I havent explored in detail) when processing messages - like compression.

So for "Packets" (and message headers/meta data), I am interested in shaving off as many bytes as possible. I would love to see other network mediums available to use (if anything to play with), and the things I'm interested in is packet radio, lorawan and whatever else I can find (that I can use as a hobby).

The thing I've noticed with those mediums, is for long distance, you have low bandwidth, and in the case of LoRa, since it is using unlicensed radio spectrums, you have limits imposed by duty cycles and dwell times. These limits means you can only send low volumes of data. (Yes, I recognise that LoRa itself is probably out of scope with the ability to send only around 50-224 bytes every 5 seconds may make it next to useless.)

So trimming a current 58 byte "packet" header to something a lot smaller has value (and trimming message headers/meta data would too). For example, why send a representation of date, which currently consumes 12 bytes (with only a 2 char year and no timezone), when it can be packed into binary using 6 bytes that includes a 4 digit year and timezone - and a few bits left over (ditching timezone and assuming utc would save 1 more byte). In fact, for a packet header why include it at all and replace it with 6 bytes of a SHA-1 signature (similiar to how git lets you use short SHAs) that can be used to validate the sender of the packet is a valid sender? Those extra 6 bytes could be used to send data. (That's where my head is at anyway.)

In terms of actual data sent over the wire, however, a textual
serialization using an extensible format seems superior to binary
formats.

So I'm not in agreement with this (for the reasons above). And while Oli made a similar point, I think if you have a "published" function that parses a binary packet (or message) header back into a human readable form, that is an improvement all round.

For that matter, the entire FTN naming scheme seems
antiquated, though I don't see a great way to remove that short
of a wholesale replacement (which may itself be worthwhile).

What ideas are you thinking?

... reducing structural inefficiencies that cause things
to, say, grow linearly with the size of the network. The Path:
mechanism used on USENET to detect duplicates and loops seems
universally superior to FTN's `SEEN-BY` lines.

Is there are reference somewhere that I can read up on? I'm not familiar with this, and agree, it would be beneficial to improve this (as I do agree there are scalable limits in the current method).

Yup. A collision-resistent hash as a mechanism for detecting
duplicates seems reasonable. Taking again from USENET, where
"Message-Id:" was defined to be globally unique, a similar
mechanism could be used here.

Does a "message id" need to be globally unique? It kind can be, when you add source address + echoarea to it. (And those values are needed on their own as part of processing a message.)


...ëîåï
--- SBBSecho 3.14-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

On 09/08/21, apam said the following...

Hey Oli, I was wondering if any of these bugs/issues have been raised with the developers? It's open source right?

It is, but developers are not very receptive to bugs/issues, even if you fix them yourself and offer the fixes.

Aww damn. Yeah - that always sucks.

--- Mystic BBS v1.12 A39 2018/04/21 (Linux/64)
* Origin: sonicbbs.co.uk :: Yorkshire, UK (21:4/144)

On 09 Sep 2021 at 02:10a, tenser pondered and said...

I think there's a natural tension here in that, for a lot of
folks, the motivation is to tinker with the old stuff, while
for others it's about setting up a communications mechanism.

I think there is a way in which both can be accommodated, by
selectively placing translation layers on what I refer to as
the "edge" of the network. But yeah, it's a hobbyist thing,
so....

I agree motivations vary subject to who is coming to the table to play etc :)

That said there are a regular group of voices that arise asking (along the lines of) 'couldn't we do it better / more secure / in another way not
needing to be encumbered by past dogma etc.'

I think just because stuff works and some don't necessarily want to change software and current FTN style systems (fair enough, it's their call) that should not preclude others who want to try / experiment etc. from giving it a go.

I'm certainly supportive at looking to do things differently. I confess at times I may be a bit stuck in 'older ways' also but that said if I could ring fence the current sections of FTN stuff in Z21 so that stuff does not break
but start up other instances of new stuff that could do message handling,
node management etc. differently and using better 2021 practices / tools I'd
be open to doing so.

Where I am lacking is in coding skills to do that but I enjoy working with people who are able to create stuff digitally. Thinking back on my collaboration with g00r00 and Mystic the fun for me was in being able to suggest features and other iterative ideas and stuff that came about as a progress of one idea building on another. I do miss that. But I don't miss being called things I was not.

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 09 Sep 2021 at 02:13a, tenser pondered and said...

Yeah, I think that was about a year and a half ago, but then
the pandemic kicked off and I haven't had a chance to get back
to it. The intent is to import FTN messages into an NNTP
server (and back). It just requires that most precious of
commodities: time. :-)

It's a good idea in that it could provide a more up to date way of gating between things than we have now. I mean I'm using some old stuff from 2000
that hasn't been touched since. Newer options are most welcome here - says
the fellow running his own NNTP setup.

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 09 Sep 2021 at 12:32p, deon pondered and said...

So for "Packets" (and message headers/meta data), I am interested in shaving off as many bytes as possible. I would love to see other network mediums available to use (if anything to play with), and the things I'm interested in is packet radio, lorawan and whatever else I can find
(that I can use as a hobby).

[snip]

The thing I've noticed with those mediums, is for long distance, you
have low bandwidth, and in the case of LoRa, since it is using

[snip]

So trimming a current 58 byte "packet" header to something a lot smaller has value (and trimming message headers/meta data would too). For
example, why send

I agree with you here. I'm not a networking / packet guru but simpler with
the most communication bang for byte would be the way to go when talking
about RF comms.

For that matter, the entire FTN naming scheme seems
antiquated, though I don't see a great way to remove that short
of a wholesale replacement (which may itself be worthwhile).

What ideas are you thinking?

I'm wondering also :) I like the idea of teasing out other possible ways of doing this stuff.

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 04 Sep 2021 at 06:54a, Atreyu pondered and said...

Its definately not for lack of tech talent, its more of a lack of desire from the Sysops to embrace it, because there is just no big pressing demand for it.

Since I got back circa 2013 into FTN circles I certainly seen little technically driven innovation.

But I'm not convinced it's all about a lack of perceived demand. You mentioned from time to time this subject comes up.

I suspect things move slowly or stall thereafter for a few reasons:

a) a lack of demand by some in FTN communities who are quite happy with the status quo and perhaps think 'if it ain't broke don't fix it'.

b) a lack of motivated people in FTN circles with the current tech smarts and spare time to create new tools/ways to innovate beyond current established FTN tech/methodologies.

c) a mix of intents that drive/motiavte people on this topic. Some may want
to build only new and legacy integration be dammed, others may want to always be backwards compatible in what they do with legacy FTN stuff. None of this
is right or wrong but I often see that topic as a point of tension when the wider subject comes up.

If there were demands for a new packet format, P2P
distribution, decentralized messages and nodelists etc... all of it
would have been solved decades ago.

Demand is but one reason as to why stuff gets built and established. People
can be curious and wonder 'what if', others tinker because they just can etc. It's that spirit that is perhaps best embodied in the Fidonet story that underpins my counter argument to what your suggesting.

The second problem is FTN software traditionally continues the trend of backwards compatibility. That stifles any serious innovation.

I agree it doesn't make innovations easier. I guess it comes down to what rules of engagement any developer wants to adopt (or not) when they looking at these questions. If they choose to just build and create something new with only fringe tie-ins to current FTN then so be it. I think if they create something that is seen to be of value and benefit then people will vote with their 'usage' feet. I sorta feel the shift from EMSI mailers to BinkD is an
example of that over time.

Best, Paul

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

tenser wrote (2021-09-09):

I recall you working on Ginko and we doing some tests some years
back to get compatibility with legacy FTN stuff :) I agree with
your comments above.

Yeah, I think that was about a year and a half ago, but then
the pandemic kicked off and I haven't had a chance to get back
to it. The intent is to import FTN messages into an NNTP
server (and back). It just requires that most precious of
commodities: time. :-)

Will it support the Gatebau '97 standard? Or is the NNTP server only for local news clients? (like JamNNTPd).

---
* Origin: 1995| Invention of the Cookie. The End. (21:3/102)

Avon wrote (2021-09-10):

The second problem is FTN software traditionally continues the
trend of backwards compatibility. That stifles any serious
innovation.

I agree it doesn't make innovations easier. I guess it comes down to what rules of engagement any developer wants to adopt (or not) when they
looking at these questions. If they choose to just build and create something new with only fringe tie-ins to current FTN then so be it. I think if they create something that is seen to be of value and benefit
then people will vote with their 'usage' feet. I sorta feel the shift
from EMSI mailers to BinkD is an example of that over time.

But binkd / binkp mailers are very similar to EMSI mailers. It uses the same BSO inbound/outbound, it sends the same files. You can add it to most traditional FTN setups without changing much. That's very different to running the "core" on new technology and only have binkp/pkt/tic on the "edge".

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.

I'm more interested in fixing the current software and standards.

---
* Origin: 1995| Invention of the Cookie. The End. (21:3/102)

Am 10.09.21 schrieb Oli@21:3/102 in FSX_NET:

Hallo Oli,

But binkd / binkp mailers are very similar to EMSI mailers. It uses the
same BSO inbound/outbound, it sends the same files. You can add it to most traditional FTN setups without changing much. That's very different to running the "core" on new technology and only have binkp/pkt/tic on the "edge".

But I guess that's the reason it was used by so many people: because
it was/is a drop-in replacement.
Many people have built their BBSes and message setups over many years
with that specific setup and changing that in a bigger way meant to
throw away this work and start from scratch.
Just replacing the part that was out of date with another part that
fills this gap was the way to go.

I'm more interested in fixing the current software and standards.

That's a good intention.

I hope that eg. OpenXP would still be compatible with your ideas.
Because, as I see it, many of the original authors of this (really
great and superior to most other similar) program aren't part of the
current development team. And as I understand it, the current team
mostly only fixes small bugs - but there won't be much progress eg.
for new platforms (arm...) and there won't be big rewrites eg. of the
BinkP part.

I guess something like this might be true for other parts of FTN
software...

Regards,
Anna

--- OpenXP 5.0.50
* Origin: Imzadi Box Point (21:3/127.1)

On 10 Sep 2021 at 07:02a, Oli pondered and said...

Will it support the Gatebau '97 standard? Or is the NNTP server only for local news clients? (like JamNNTPd).

Well, my NNTP server is intended to be the message store for
my BBS, and that's it; that is, I don't intend to peer with
anyone else necessarily. Certainly, I have no upstream to the
public USENET, nor do I intend to.

As for the Gatebau standards... My German is pretty bad, so
probably only incidentally.

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

tenser wrote (2021-09-13):

On 10 Sep 2021 at 07:02a, Oli pondered and said...

Will it support the Gatebau '97 standard? Or is the NNTP server
only for local news clients? (like JamNNTPd).

Well, my NNTP server is intended to be the message store for
my BBS, and that's it; that is, I don't intend to peer with
anyone else necessarily. Certainly, I have no upstream to the
public USENET, nor do I intend to.

In this case it doesn't really matter if it's Gatebau compatible.

Let's hope nobody else gets the idea to use your software and misuse it for usenet <-> echomail gating ;-). Like soupgate that was never intended to work as a public gateway, but still is used by several systems.

As for the Gatebau standards... My German is pretty bad, so
probably only incidentally.

For the MSGID conversion there is an English document:

http://fidogate.sourceforge.net/msgid.html

---
* Origin: 1995| Invention of the Cookie. The End. (21:3/102)

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.

Why is binkd even a thing? What's the history of it? I don't know.. Apart
from integrating with the binkley style outbound, why did they make a new protocol to transfer these messages?

I'm more interested in fixing the current software and standards.

Why? The "current" software is kind of unfixable, it would require people
with access to the current software's code having a desire to fix it.

It would also require said people working together...

Look at fsxnet for example, an FTN network, now, I would say 90% of the
network runs mystic software. Not some DOS bbs that saw it's last release
in 1995.

That last 10% probably run synchronet, some other software or a very very
tiny few actually run software (that is connected to fsxnet) from eons
ago.

Even that software that hasn't seen an update since 1995 probably has
message bases compatible with Squish or JAM.

So we could put lipstick on a pig so to say and keep FTN only. FSXnet
isn't fidonet, it doesn't need to be married to the technology - WWIVnet
and DOVEnet both use other systems, so one could create a new network technology, and have it working with BBSes.

Seems like the nostalgia is for most people things "like" they had in the
90s, not actually things they had in the 90s. Otherwise mystic wouldn't
be so popular. Binkd wasn't a thing that far back either, or "the c64" etc

If you pack this new software in a black box with a curses interface I
bet people wouldn't even care :)

Anyway, it all boils down to nothing if no one can be bothered to write
new software. I think that's the real problem... not enough people care
about security / privacy, just look at a discussion from a few months ago
re: SSH.

Andrew

--
|03Andrew Pamment |08(|11apam|08)
|13Happy|10Land |14v2.0|08!|07


--- Talisman v0.24-dev (Linux/x86_64)
* Origin: HappyLand v2.0 - telnet://happylandbbs.com:11892/ (21:1/182)

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.

Why is binkd even a thing? What's the history of it? I don't know.. Apart from integrating with the binkley style outbound, why did they make a new 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.

Why? The "current" software is kind of unfixable, it would require people 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.

It would also require said people working together...

Yeah ... not happening.

Seems like the nostalgia is for most people things "like" they had in the 90s, not actually things they had in the 90s. Otherwise mystic wouldn't
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.

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…

If you pack this new software in a black box with a curses interface I
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.

Anyway, it all boils down to nothing if no one can be bothered to write
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)

On 18 Sep 2021 at 04:57p, apam pondered and said...

Why is binkd even a thing? What's the history of it? I don't know.. Apart from integrating with the binkley style outbound, why did they make a new protocol to transfer these messages?

I did a small amount of research into this when I wrote Ginko.
What I gathered is that Fidonet was very much a thing in the
former Soviet Union, but by the mid 1990s, those countries
were starting to get access to the Internet. They didn't want
to lose the communities or networks, so wanted to figure out
how to bridge the legacy technologies they were using onto the
Net.

But why invent a new protocol? Probably a few reasons. First,
I imagine that at the time most users were still using dialup
Internet services, so there was a desire to keep overhead low.
Binkp was initially fairly good at being full-duplex and avoiding
what they call, "synchronization points" (or some such) between
client and server: once password acknowledgement is done, you
enter effectively a streaming data transfer stage and that's
basically it. At least, that's how it was at first. The protocol
was updated over time as deficiencies in that model were found
to try and make it more robust.

Second, I don't think it was as obvious then as it is now that
the world wide web was going to be such a force. Existing Internet
protocols to build on would have been NNTP, SMTP, FTP and HTTP.
Of those, NNTP would have been the most obvious, but it doesn't
fit super neatly into the Fidonet way of doing things, where
messages aren't (generally) transferred as "messages" per se, but
rather as compressed packets that potentially contain multiple
messages. Since they presumably wanted to retain compatibility
with closed-source BBS packages, they'd either have to have some
kind of translation layer or do something different. Similarly,
SMTP kind of falls down for similar reasons, plus, spam was
becoming a big deal and I imagine it was conflated with notions
of using SMTP. FTP without passive mode had problems connecting
to end-user machines (since transfer is done over a separate TCP
connection specified by PORT commands, etc). That leaves HTTP,
but it was a pretty immature protocol in 1996, when binkp's first
spec was proposed (HTTP/1.1, which is the first really reasonable
version, wasn't specified until 1999).

I suspect a third reason is lack of familiarity with the Internet
in general and the "fun" factor of building one's own protocol.
In the mid-1990s, lots of stuff got thrown at the wall.

Today, it's clear that building something on top of HTTP is the
correct design decision, but we see that with 30 years of the web
and 25 years of binkp.

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 18 Sep 2021 at 11:47a, Oli pondered and said...

Why? The "current" software is kind of unfixable, it would require peo 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.

I honestly don't care about Mystic. I can't run it on my systems,
and the author is a jerk who doesn't want to work with others.

It would also require said people working together...

Yeah ... not happening.

This is the rub. The BBS community was always pretty insular and
didn't look outside of itself enough. The result is the state of
affairs now.

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

I honestly don't care about Mystic. I can't run it on my systems,
and the author is a jerk who doesn't want to work with others.

I don't particularly care about mystic either (as you know), but don't
want to lose those who seem to be tethered to it.

and while building something on top of HTTPS would be fun, it's kind of pointless if no one uses it.

I got all excited by this idea a few days ago and started adding "json exporting" to postie (my mail tosser / scanner) and learning go to make a server/client, but the enthusiasm has fizzled a bit (mainly due to other
stuff preoccupying my mind)

Plus, I don't really know the best way to do the transmission, I was
thinking just using POST with a node number and password and having the
server respond with json messages in the response.

Thinking about having a client requesting particular messages but not
sure how that would work at being interoperable with older systems (ie message-ids are all over the place... if they exist at all)

I'm not sure if it's worth building, I mean, why not just go all the way
and rip out echomail from the bbs and just put in an NNTP client.

I suppose why do any of this at all, when we could just setup a
private phpBB or something and chat on that? I guess the interest is in tinkering and experimenting.

Andrew
--
|03Andrew Pamment |08(|11apam|08)
|13Happy|10Land |14v2.0|08!|07


--- Talisman v0.24-dev (Linux/x86_64)
* Origin: HappyLand v2.0 - telnet://happylandbbs.com:11892/ (21:1/182)

On 22 Sep 2021 at 02:07p, apam pondered and said...

Plus, I don't really know the best way to do the transmission, I was thinking just using POST with a node number and password and having the server respond with json messages in the response.

I've been reading about another dev who is interested in using NNCP as a tool for getting messages from A to B

He writes

[snip]

If you haven't heard of it, NNCP [1] is to UUCP approximately what ssh is to rsh/telnet. NNCP is asynchronous, delay-tolerant for fire-and-forget secure reliable files, file requests, Internet mail (and now NEWS) and commands transmission. All packets are integrity checked, end-to-end encrypted, explicitly authenticated by known participants public keys. Onion encryption
is applied to relayed packets. Each node acts both as a client and server, can use push and poll behaviour model. NNCP can operate over a lot of
transports: Internet, USB sticks, tapes, CD-ROMs, ssh, Dropbox, etc.

So basically it's UUCP for the modern world. I've used NNCP for everything from automated git repo synchronization to hundreds-of-GB ZFS backup streams.

And I now intend to offer Usenet feeds to interested people that would like to receive them over NNCP. The setup is easier than with UUCP, the environment
is more secure, and the approach is so similar that it needs only a tiny bit
of glue to drop in to INN in place of UUCP.

[snip]

Not sure if this thinking or approach is of any use as to what you are
thinking of tinkering with but I can approach said gentleman and invite him
to fsxNet and/or pass on some contact details to you via email if you felt there was any interest. I suspect he may be interested in what you both are kicking around too. :)

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Avon wrote (2021-09-22):

On 22 Sep 2021 at 02:07p, apam pondered and said...

Plus, I don't really know the best way to do the transmission, I was
thinking just using POST with a node number and password and having
the server respond with json messages in the response.

I've been reading about another dev who is interested in using NNCP as a tool for getting messages from A to B

http://www.nncpgo.org/

---
* Origin: 1995| Invention of the Cookie. The End. (21:3/102)

On 22 Sep 2021 at 07:30a, Oli pondered and said...

http://www.nncpgo.org/

My web browser says danger danger when I try to load that one Oli.

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Avon wrote (2021-09-22):

On 22 Sep 2021 at 07:30a, Oli pondered and said...

http://www.nncpgo.org/

My web browser says danger danger when I try to load that one Oli.

your browser thinks it's clever and automatically uses https:// and then returns a warning, because the certificate is not signed by the gods of WWW. See http://www.nncpgo.org/Mirrors.html

You can ignore the warning (if your browser allows it) or use this mirror, which uses a certificate that your browser is not afraid of:

https://nncp.mirrors.quux.org/

It is similar to Fidonet mailers and UUCP.

It's written in Go, but I don't see any support for Windows.

---
* Origin: 1995| Invention of the Cookie. The End. (21:3/102)

Re: Re: Is binkp/d's security model kaputt?
By: apam to tenser on Wed Sep 22 2021 02:07 pm

Plus, I don't really know the best way to do the transmission, I was thinking just using POST with a node number and password and having the server respond with json messages in the response.

So I'm probably going to go down this path - but I'll provide options.

IE: if you specify a packet version, your HTTP post will give you a binary "bundle" of messages. If not, you get a json collection of mesages. That way, "old" systems can get packets that can be used by their old software, but something like wget could get their bundles. For "new" systems, it'll be a more <insert reliable, secure, scalable, ?...> way of getting mail.

(In the back of my mind, I also want to optimise, compress, reduce what needs to be sent between the two systems, in case its not an internet connection between them.)

I havent thought it through in detail, nor am I ready yet - got a few other things I'm tackling at the moment. But happy to throw up a test bed to see if it works...

I'm not sure if it's worth building, I mean, why not just go all the way
and rip out echomail from the bbs and just put in an NNTP client.

Nah, part of the enjoyment its using the old stuff as it was used when we were ankle biters.


...ëîåï
--- SBBSecho 3.14-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

Re: Re: Is binkp/d's security model kaputt?
By: Avon to apam on Wed Sep 22 2021 05:36 pm

I've been reading about another dev who is interested in using NNCP as a tool for getting messages from A to B

Hmm, this sounds interesting. Not heard of it - so I'm going to be doing some reading...



...ëîåï
--- SBBSecho 3.14-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

I've been reading about another dev who is interested in using NNCP

as a tool for getting messages from A to B

Hmm, this sounds interesting. Not heard of it - so I'm going to be
doing some reading...

I agree, the nncp does look interesting, but I had never heard of it
before either (but then I don't know a lot about UUCP either, except that
I've heard of it)

Will have a further look at oli's link, i had a quick look and it looks
like it could almost be a drop in replacement.

Andrew

--
|03Andrew Pamment |08(|11apam|08)
|13Happy|10Land |14v2.0|08!|07


--- Talisman v0.24-dev (Linux/x86_64)
* Origin: HappyLand v2.0 - telnet://happylandbbs.com:11892/ (21:1/182)

IE: if you specify a packet version, your HTTP post will give you a
binary "bundle" of messages. If not, you get a json collection of
mesages. That way, "old" systems can get packets that can be used by
their old software, but something like wget could get their bundles.
For "new" systems, it'll be a more <insert reliable, secure, scalable,
?...> way of getting mail.

That's a good idea.

Are you already working on a way to use HTTPS etc? I knew you had a
project you're working on, but didn't realize what it was..

You and tenser are probably much more clued up on secure, scalable...
etc.. do you think JSON is the way to go for stored / transmitted
messages?

I'm thinking if you're doing something and I'm doing something it'd be
good if those somethings could talk to each other :)

Andrew

--
|03Andrew Pamment |08(|11apam|08)
|13Happy|10Land |14v2.0|08!|07


--- Talisman v0.24-dev (Linux/x86_64)
* Origin: HappyLand v2.0 - telnet://happylandbbs.com:11892/ (21:1/182)

apam wrote (2021-09-22):

do you think JSON is the way to go for stored / transmitted
messages?

IMHO:

1.) JSON sucks.
(No idea why I pitched the idea to use JSON instead of XML to the CouchDB guys)

2.) It's especially stupid as a format for encoding mails. It sucks for 8-bit text that is not UTF-8. You have to escape everything and/or do charset translation.

3.) You cannot transport binary data without encoding it to base64 or something similar first.

Of course you can encode the header fields in JSON and get the message body as a binary blob via another HTTP request. Maybe just use a variation of JMAP (https://jmap.io/spec-mail.html)?


I still don't see the appeal in using text based protocols and interchange formats.

4.) JSON sucks for config files too.

---
* Origin: 1995| Invention of the Cookie. The End. (21:3/102)

Re: Re: Is binkp/d's security model kaputt?
By: apam to deon on Wed Sep 22 2021 06:22 pm

Howdy,

Are you already working on a way to use HTTPS etc? I knew you had a
project you're working on, but didn't realize what it was..

Not HTTPS specifically (at this stage anyway). What I've created so far is an FTN mailer and tosser using:
* mongodb for mail storage. I'm not settled on mongo, but tried it out because I wanted to try it out - never having used it before, and I wanted to see what all the fuss was about. Also I want to try out active-active replication, so that multiple systems (me and anothers) could be an authoritive hub for mail. The idea being if one of us is down, DNS could flick you to another site to deliver and get your mail. When you come back online, the backend re-syncs automatically with what it missed out on.

* postgresql - I started out on psql only because I may go to CockroachDB (which talks psql). Also with an SQL DB, DB constraints help ensure data integrity (something that mongo, a nosql DB doesnt provide) and actually helps me iron out silly bugs. CochroachDB is something I may play with, because it to supports active-active in lieu of mongo.

In theory I could ditch the idea of an SQL DB and just use mongodb completely, which is also an option still at the moment.

Now that I have a working environment (it is currently exchanging BINKP mail with Hub 3, and EMSI mail with my old dos BBSes), I am ironing out the bugs. Al's test message the other day (from his point) wasnt handled correctly so that's next to fix.

When this is stable, I can support "legacy BBS" mailers and tossers (which is the current status quo).

With bugs sorted, I then have a base that I can spin up new ideas (protocols, packet formats, distrution models) fairly easy and quickly. Pulling mail out of an sql/nosql db is just a simple query.

My goals for "the new way" is security (which is where HTTPS may come in, or TLS in general I guess), improved authentication (HTTPS can help here), improved integrity (that a bundle comes from a known system), and effeciency (aka no bloat, lean and mean). (There's probably other ideas there too.) I think there are many advanced techniques (that didnt exist in 1990) that could be leveraged for the value that they provide.

You and tenser are probably much more clued up on secure, scalable...
etc.. do you think JSON is the way to go for stored / transmitted
messages?

No. One of my goals is effeciency - ie: I want to play with low bandwidth communication and so mail exchange between 2 systems needs to be as small as possible. Taking into account all the ideas of improved security and improved integrity, I'm going to be working at the bit level to squeeze out as many wasted bits as possible.

But, that said, if others create a JSON way to exchange mail, then I'll be able to adopt it too pretty easily (and happy to do so as well).

I actually dont think there is a single way forward and a new way of exchanging mail will only be one new way. I think the way forward is to support multiple distrubution techniques (until I guess there is mass adoption of one). So now that I can talk the old way, I'm up for creating new ways - and OK if there are more than one, and hopefully not break anything going forward.

I'm thinking if you're doing something and I'm doing something it'd be
good if those somethings could talk to each other :)

I'd like somebody to play with :) Playing alone is no fun at all :(


...ëîåï
--- SBBSecho 3.14-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

On 22 Sep 2021 at 02:07p, apam pondered and said...

I don't particularly care about mystic either (as you know), but don't want to lose those who seem to be tethered to it.

That's fair. I'm not suggesting leaving those people stranded,
but rather, providing an alternative mechanism for those so inclined.

and while building something on top of HTTPS would be fun, it's kind of pointless if no one uses it.

I got all excited by this idea a few days ago and started adding "json exporting" to postie (my mail tosser / scanner) and learning go to make a server/client, but the enthusiasm has fizzled a bit (mainly due to other stuff preoccupying my mind)

That's the fundamental problems: time and wondering who would use it?

Plus, I don't really know the best way to do the transmission, I was thinking just using POST with a node number and password and having the server respond with json messages in the response.

Well, I think the way to do it is a multiphase protocol:

1. Connect and authenticate. This would, presumably, mean POST'ing
credentials and getting back a session token of some kind.
2. Post to an "offer" resource, with a list of things to offer
the distant end. Note that the response to an HTTP POST
can itself contain data; presumably that would be a list of
dispositions for things things offered:
a. send + URI: send this now by PUT'ing to the given URI
b. reject: do not send and do not offer again
c. defer: do not send right now, but try again later
3. A sequence of PUT's to the URI's retrieved for "send"
responses from (2). The HTTP response to the PUT would
indicate successful receipt on the remote end, or failure
with a try-again-later, or whatever.

This takes care of the things that are offered to the distant end,
we now move onto a phase of retrieving from the remote side.
It's essentially the same protocol, just in reverse and with one
extra step.

1. Perform an HTTP GET on the "offer" resource; the result is
a list of resources and URIs offered by the remote end.
2. For each resource the local end is interested in retrieving,
issue an HTTP GET for that resource.
3. Once everything has been retrieved, we issue an HTTP POST
to a "finalize" resource with the disposition of the things
offered; either accept (meaning successfully accepted),
reject or defer (as before). You need the extra step in this
phase since you can't rely on HTTP response codes to indicate
the disposition of a requested resource.

That's basically it. Using HTTP pipelining, there aren't many
more "synchronization points" compared to binkp, one gets all of
the HTTP functionality (compression, encryption, authentication,
but also caching and proxying etc) for free, and you get streaming
in a way you don't get with binkp.

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 22 Sep 2021 at 05:47p, deon pondered and said...

So I'm probably going to go down this path - but I'll provide options.

IE: if you specify a packet version, your HTTP post will give you a
binary "bundle" of messages. If not, you get a json collection of
mesages. That way, "old" systems can get packets that can be used by
their old software, but something like wget could get their bundles. For "new" systems, it'll be a more

Whoa, time out here. This is conflating two things: the transport
protocol, and the thing being transported. This is a mistake that
the BBS people made and continue to make.

But HTTP has an answer for this: you add a `Content-Type:` header
to the HTTP request (or response) that can tell you exactly what
the message contains.

The thing to do here is define a small taxonomy of X- tokens
describing various BBS-centric formats and follow what the header
says.

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 22 Sep 2021 at 06:22p, apam pondered and said...

etc.. do you think JSON is the way to go for stored / transmitted messages?

I do, yeah. One can define a schema that describes basically the
union of BBS packet types and canonicalize into that, then recreate
a "packet" on the distant end if necessary.

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 22 Sep 2021 at 11:41a, Oli pondered and said...

IMHO:

1.) JSON sucks.

Why do you think so?

(No idea why I pitched the idea to use JSON instead of XML to the CouchDB guys)

Oh, so are you the guy to blame for that? :-) XML is heavyweight
and ugly; it's only really interesting property is preservation of
whitespace.

2.) It's especially stupid as a format for encoding mails. It sucks for 8-bit text that is not UTF-8. You have to escape everything and/or do charset translation.

This I disagree with; for BBS-style emails it's fine. It's
ubiquitous, libraries to handle it exist in just about every
language, it's extensible, self-describing, etc.

But I'm open to other ideas: what would you recommend instead?

3.) You cannot transport binary data without encoding it to base64 or something similar first.

That's fair, but BBS networks aren't moving enough traffic to
care.

Of course you can encode the header fields in JSON and get the message body as a binary blob via another HTTP request. Maybe just use a
variation of JMAP (https://jmap.io/spec-mail.html)?

Possibly. With Content-Type headers one could also just send
zip files or whatever.

I still don't see the appeal in using text based protocols and
interchange formats.

Extensibility, debugability, self-describing semantics, ease of
production and consumption, avoiding byte-ordering and fixed-length limitations; a whole host of things.

But I'm not wedded to the idea. Hell, if someone wants to define
a serialization using protocol buffers or similar, I'm game.

4.) JSON sucks for config files too.

Actual JSON, yes. HJSON and JSON5, I disagree. I wrote a passable
parser for JSON5 in ~100 lines of SML, and it makes a dandy config
file format: http://fat-dragon.org/post/json5/

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Re: Re: Is binkp/d's security model kaputt?
By: tenser to deon on Thu Sep 23 2021 02:06 am

On 22 Sep 2021 at 05:47p, deon pondered and said...

IE: if you specify a packet version, your HTTP post will give you a binary "bundle" of messages. If not, you get a json collection of mesages. That way, "old" systems can get packets that can be used by their old software, but something like wget could get their bundles. For "new" systems, it'll be a more

Whoa, time out here. This is conflating two things: the transport
protocol, and the thing being transported. This is a mistake that
the BBS people made and continue to make.

But HTTP has an answer for this: you add a `Content-Type:` header
to the HTTP request (or response) that can tell you exactly what
the message contains.

No timeout needed yet.

There are probably many ways to skin this cat. The Accept/Content-Type headers are but one and probably the way I'd be implementing it.

Since I'm not there yet, I'll happily watch and read on how others think about doing it.

The thing to do here is define a small taxonomy of X- tokens
describing various BBS-centric formats and follow what the header
says.

Sure, lets muse over that list here...


...ëîåï
--- SBBSecho 3.14-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

On 23 Sep 2021 at 08:04a, deon pondered and said...

No timeout needed yet.

My bad; that came across much snootier than I intended.

The thing to do here is define a small taxonomy of X- tokens
describing various BBS-centric formats and follow what the header
says.

Sure, lets muse over that list here...

Something like, `X-ftn/ftsXXX` for legacy formats
defined by Fidonet standards, and something like,
`X-json/x.y.z` for a JSON serialized version,
where `x.y.z` is a semantically versioned schema
identifier?

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

tenser wrote (2021-09-24):

On 23 Sep 2021 at 08:04a, deon pondered and said...

No timeout needed yet.

My bad; that came across much snootier than I intended.

The thing to do here is define a small taxonomy of X- tokens
describing various BBS-centric formats and follow what the header
says.

Sure, lets muse over that list here...

Something like, `X-ftn/ftsXXX` for legacy formats
defined by Fidonet standards, and something like,

There are no FTS-xxxx standards for packet formats in use ;). Only the legacy Type 2.0 packets (the one that doesn't support points) defined by FTS-0001.

`X-json/x.y.z` for a JSON serialized version,
where `x.y.z` is a semantically versioned schema
identifier?

Timeout!

This is just wrong. It's application/json or maybe application/x-something or message/x-whatever.

And don't forget:
https://www.rfc-editor.org/rfc/rfc6648

---
* Origin: 1995| Invention of the Cookie. The End. (21:3/102)

Re: Re: Is binkp/d's security model kaputt?
By: tenser to deon on Fri Sep 24 2021 01:04 am

Something like, `X-ftn/ftsXXX` for legacy formats
defined by Fidonet standards, and something like,
`X-json/x.y.z` for a JSON serialized version,
where `x.y.z` is a semantically versioned schema
identifier?

So I wasnt thinking of X-*. Nor referencing anything "Fidonet standards" in the value. If it ever becomes a standard, the standard will describe what is in use without naming itself.

I was thinking of the prefix "ftn/", eg ftn/2 for a v2 bundle (or it could be 2.e,2.2,2+, since that is what they are more commonly known as, etc), ftn/4 for a v4 bundle, etc. Maybe just ftn/json for a json bundle.

I guess "ftn" could be changed to "fido" - but keeping it short and suite.


...ëîåï
--- SBBSecho 3.14-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

On 24 Sep 2021 at 08:26a, deon pondered and said...

I guess "ftn" could be changed to "fido" - but keeping it short and
suite.

I'd build it with 'fsx' in mind :)

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 23 Sep 2021 at 04:15p, Oli pondered and said...

There are no FTS-xxxx standards for packet formats in use ;). Only the legacy Type 2.0 packets (the one that doesn't support points) defined by FTS-0001.

I could have sworn I found some fidonet standardish type document
that described packet formats in some detail. There were several;
oh, I guess I was looking at FSCs, which are not FTSs. Ok, so use
that as the content type....

Timeout!

This is just wrong. It's application/json or maybe
application/x-something or message/x-whatever.

It looks like RFC6838 backs you up there; I stand corrected. `application/x-foo` seems more appropriate.

And don't forget:
https://www.rfc-editor.org/rfc/rfc6648

Good point, but that's for new application protocols; we're
not talking about that, we're still using HTTP.

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Have a look in the stats echo for y/days report for 1/100 something weird going on there .. all nodes with files held for them showing 800+ days.. strange..

--- Mystic BBS v1.12 A47 2021/11/06 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 16 Nov 2021, 09:53a, Avon said the following...

Have a look in the stats echo for y/days report for 1/100 something
weird going on there .. all nodes with files held for them showing 800+ days.. strange..

If it's similar to the one that I'm using here, it's due to the file that you hatched out. It has a filedate of 2019, so it sees that as being the oldest file.


---

Black Panther(RCS)
aka Dan Richter
Castle Rock BBS
telnet://bbs.castlerockbbs.com
http://www.castlerockbbs.com
http://github.com/DRPanther
The sparrows are flying again...

... The dog ate my .REP packet

--- Mystic BBS v1.12 A47 2021/09/07 (Linux/64)
* Origin: Castle Rock BBS - bbs.castlerockbbs.com - (21:1/186)

Re: Re: Daily Stats 1/100
By: Avon to deon on Tue Nov 16 2021 09:53 am

Have a look in the stats echo for y/days report for 1/100 something weird going on there .. all nodes with files held for them showing 800+ days.. strange..

So have a look at the files for a node "ls -alt" (which will sort them by time) - I bet you have some files that are 800+ days old.

(The age shown is taken from the system call stat() - which gets the modified time of the file.)


...ëîåï
--- SBBSecho 3.14-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

On 15 Nov 2021 at 02:15p, Black Panther pondered and said...

If it's similar to the one that I'm using here, it's due to the file
that you hatched out. It has a filedate of 2019, so it sees that as
being the oldest file.

I did test re-hatch an image file from Agency the other day to see if I could do it in a way that was easier than using Htick and it was... but, now I see I have created another issue only in that the way the reporting software works... bummer.

--- Mystic BBS v1.12 A47 2021/11/06 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 16 Nov 2021 at 10:06a, deon pondered and said...

So have a look at the files for a node "ls -alt" (which will sort them
by time) - I bet you have some files that are 800+ days old.

(The age shown is taken from the system call stat() - which gets the modified time of the file.)

Aug 25 2019 ...is against the file I sent out (spscwp01.zip)

So there we go, bummer hummer... that's going to mess with the zen of the way this stuff is reported if I keep using this tool as I wanted to start re-hatching older files out to all nodes so new nodes could get them.

Hmmm

--- Mystic BBS v1.12 A47 2021/11/06 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Re: Re: Daily Stats 1/100
By: Avon to deon on Tue Nov 16 2021 03:56 pm

So there we go, bummer hummer... that's going to mess with the zen of the way this stuff is reported if I keep using this tool as I wanted to start re-hatching older files out to all nodes so new nodes could get them.

Only if you use fileboxes :(

I dont use fileboxes...

I think with the stats tool you dont need the fileboxes - because you can see what is waiting for a node and how old the oldest item is. You'll also save some disk space.

But for the game packets, fileboxes are good - because then you see how old the oldest game packet is :)


...ëîåï
--- SBBSecho 3.14-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

I'm going to chime in on an old thread here and haven't read the
followups yet. :)

are and won't change. Then that convo fizzles out. Sysops are just
happy
trading banter on a flawed/obsolete network because they made it just
work.

It could be said that we love BBSs *because* they are flawed/obsolete. :)

Personally, I think that our message networks *not* being accessible via
HTTP and *not* able to be scraped by companies looking to make a profit
from data collection and re-sale is a positive thing. And I'm not just
talking Facebook and Google, but companies like Shodan who scrape the web looking for vulnerabilities and then sell access to that info.

I know that historically FTNs have sometimes been exported to websites
(which I disagree with) but from what I've seen that's mostly Fidonet,
which nobody cares about any more.

We are specifically making a point to *not* be on the web, and I think
that's why these conversations fizzle out. And if something does
eventuate from it, the BBS world (small as it is) would be divided.
Refer: Fidonet.

Some other things to consider are that several people are running old
systems including 8bit systems, BBSs often have limits of 8 character
passwords and are stored in plain text, and to redo something that has
been worked on for decades by volunteers who are just doing this for fun
not profit is fairly unlikely to gain traction.

I remember years ago, one guy had the grand idea that we should be able
to have a phone app to connect to BBSs. And he wanted people to write the
code for him because he wasn't capable. That didn't get far either.

My personal feeling is that we should strengthen what we have, not throw
it out to start fresh.



--- Talisman v0.35-dev (Linux/x86_64)
* Origin: Lost Underground BBS (21:1/230)

We are specifically making a point to *not* be on the web, and I think

It could be said that we love BBSs *because* they are flawed/obsolete.

YES! That's a GREAT point. It's a retro tech scene, even with modern BBS software -- warts and all!

I remember years ago, one guy had the grand idea that we should be
able
to have a phone app to connect to BBSs. And he wanted people to write
the
code for him because he wasn't capable. That didn't get far either.

I use an SSH-based mobile app (Terminus) in a pinch. To me, it's just
another terminal, albeit at a very non-standard size :) Always thought
there *could* be a way to generate a better experience at a phone-size
using mobile telent/SSH, but the reality is -- BBSs were made for desktop computers. That's probably where they will stay, short of a wholly new
approach that would require BBS authors to create/adopt new screen
sizes AND new/better mobile apps to support them. Don't think that'll
happen.




|04a|12LPHA
|03Alpha Complex |15- |11alphacomplex.us:2323

--- Talisman v0.35-dev (Linux/x86_64)
* Origin: aLPHA cOMPLEX: You are in Error. No one is screaming. (21:4/158)

Re: Re: Is binkp/d's security model kaputt?
By: JoE DooM to Atreyu on Sun Dec 19 2021 07:45 am

are and won't change. Then that convo fizzles out. Sysops are just
happy
trading banter on a flawed/obsolete network because they made it just work.

My personal feeling is that we should strengthen what we have, not throw
it out to start fresh.

Firstly, replying to Nick on this topic is unlikely to get a supportive conversation..

I agree, I would like to "improve" what we have and innovate taking advantage in latest tehnology advancements, but keep the retroness of this hobby as it was.

There are probably two parts to this - the BBS part (the end node), and the Mailer part (the infrastructure).

I'm got a gazillion ideas of how to make the infrastructure easier, more secure, more effecient, etc and when I get in the mood, I work on something a bit more (the "Clearing Houz"). I may never get it done (I get distracted with life), but I've learnt a few things along the way so far (which was my motivation to get started).

My goal is based on enhancing the infrastructure part, but dont break any connectivity to the end nodes - given most of that software is old, the code or author have been lost and we like to reminisce with it :)


...ëîåï
--- SBBSecho 3.14-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

On 19 Dec 21 07:45:16, Joe Doom said the following to Atreyu:

My personal feeling is that we should strengthen what we have, not throw
it out to start fresh.

Your lengthly reply reiterates almost exactly how I feel, and I've said for a long time that if one really wants to attract newcomers to our hobby, we need
a seriously dumbed-down simple to use message client. We do not need new
packet or nodelist formats or storage formats for mail. Even the concept of modular deployments of a mailer, tosser, nodelist compiler etc just go over
the heads of everyone.

With many people now re-evaulating social media's place in their lives, it would be a perfect chance to turn these people to BBS'ing and message nets but the learning curve is just too much. Only "techie" people would care to jump through all kinds of hoops to get something running.

Atreyu

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (21:1/176)

On 18 Dec 2021 at 07:12p, Atreyu pondered and said...

With many people now re-evaulating social media's place in their lives,
it would be a perfect chance to turn these people to BBS'ing and
message nets but the learning curve is just too much. Only "techie"
people would care to jump through all kinds of hoops to get something running.

My concern is around how to build communications resilience. When we look back at the way POTS modems and calls over landlines worked, yep the time to get a message from A to B and a reply back was longer. But I wonder if the overall resilience of the communication was better?

Now that we rely on the Internet to be the bridge between nodes and the backbone of FTN style networks (and many other networks) I fear we have lost a lot of the means to be resilient should a bad actor(s) come along and hobble a city or country by taking down its Internet connectivity. :(

How best to get packets around a country or between countries without an Internet to carry them? <-- open question for anyone really...

Best, Paul

--- Mystic BBS v1.12 A47 2021/11/06 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

How best to get packets around a country or between countries without an Internet to carry them? <-- open question for anyone really...

First thing that comes to mind is packet radio. Hams have been using this protocol since 1980.

https://en.wikipedia.org/wiki/Packet_radio https://en.wikipedia.org/wiki/AMPRNet

Naturally, such a method of transmission would be severely rate-limited, on
the order of 10 kbit/s or less (less than 20% of the speed of ye olde 56k modem) even with good reception. Good luck watching YouTube on that!

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (21:4/135)

On 19 Dec 21 11:13:22, Deon said the following to Joe Doom:

Firstly, replying to Nick on this topic is unlikely to get a supportive conversation..

While Joe watches you attempt a penis-comparison contest, I'm content to demonstrate my supportiveness by developing software used by many Sysops worldwide and running infrastructure that hubs mail to many. That kinda puts me in the "results" catagory, not the "goals and a gazillion ideas" catagory.

If someone presents to me an idea that is logical and supportive of the average Sysop (that I engage with almost daily), then I'm all in. Not some unoriginal Internet "clearing house" thing 20 years too late that nobody
would use now. Sysops want users calling their boards... nets want new people posting. A dumbed-down message/BBS client is a fantastic idea I would support.

Atreyu

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (21:1/176)

On 19 Dec 21 14:49:45, Avon said the following to Atreyu:

Now that we rely on the Internet to be the bridge between nodes and the backbone of FTN style networks (and many other networks) I fear we have lost lot of the means to be resilient should a bad actor(s) come along and hobble city or country by taking down its Internet connectivity. :(

Its hard to answer. Its likely that if Internet connectivity becomes a serious problem, we all would have far greater things to worry about than not being able to trade silly banter on some net only a fraction of the world cares for.

Atreyu

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (21:1/176)

I agree, I would like to "improve" what we have and innovate taking advantage in latest tehnology advancements, but keep the retroness of
this hobby as it was.

In my experience, the only times that innovation happens is when someone
just pulls up their boot laces and develops it. Either fully working, or
a prototype, but something that others can look at and use and play with.

While discussing things is useful to a degree, I feel it's more useful
when there is something concrete to discuss. Otherwise, everyone has
different ideas on what they want, how they'd do it, etc.

OK I guess there's one other way to achieve something, and that's to
throw money at it. haha When you have no technical ability like Steve
Jobs and Elon Musk, you just pay people who *do* know what they're doing.

There were a lot of great ideas in the thread over the last couple
months, but as I say, until someone develops something, we'll just keep
the circular discussions going for another 20 years. :)

There are no shortage of people willing to play around with stuff once
it's been written. How many people run several BBSs to play with
different software, different' OSs, etc.. And then there's the X in fsX
:) Paul would be all over new toys to play with. :D haha


--- Talisman v0.35-dev (Linux/x86_64)
* Origin: Lost Underground BBS (21:1/230)

Your lengthly reply reiterates almost exactly how I feel, and I've
said for a long time that if one really wants to attract newcomers
to our hobby, we need
a seriously dumbed-down simple to use message client. We do not need

Yeah I agree to a point. I think that in all honesty, the type of people
that are attracted to BBSs are not the lowest common denomiator type of
people. Those people have Facebook (which for all intents and purposes is *literally* old school BBSs with new technology and seriously dumbed down message client)...

I know people who were into the BBSs in the 80s and 90s, which is where I
met them and we became lifelong friends. They have a nostalgia for the
boards, but have utterly zero interest in logging back into them. They
used the boards to socialise with local people back in the day.

They have Facebook for that now.

Even my ex of the last few years was a major local sysop. Even she
couldn't be arsed logging in to the board I set up. haha It was just too
much effort and it isn't how she wanted to communicate in the 21st
century.

I know there are multiple angles on how BBS "modernisation" should work,
and that's fine, but the reality is we're doing things the "old way" very intentionally.

BBSs went through a modernisation when the Internet came along. And hell,
even the online web based forums suffer now because everyone just wants
to use Facebook.

*shrug* I dunno. But as I said to deon in my last post, I honestly think
that if someone wants to change something, they will have to develop it
first and people will get onboard. Discussing grand ideas will naturally
result in people with different ideas not agreeing, or diluting the ideas
so much that nothing will get done.



--- Talisman v0.35-dev (Linux/x86_64)
* Origin: Lost Underground BBS (21:1/230)

How best to get packets around a country or between countries without
an Internet to carry them? <-- open question for anyone really...

The internet was designed to be resilient, and in a way it still is. When
you speak of cities being DDoS'd or cables being cut, and cities or
countries (usually only small ones) being taken offline, well, they're
only a twig on a tree.

The tree is still standing and if you can swing across and grab another
branch, you'll still be online. This might be an alternate route, such as
a satellite link as a fallback.

But what risk are you trying to mitigate? A satellite link from an
external vendor is a good fallback if your country is cut off using
regular connectivity like southern cross cable in NZ.

A secondary fibre circuit is a good fallback if you're mitigating "spade
fade".

A second ISP and modem is a good mitigation if your risk is your ISP
falling over.

Most networks, however, are not designed to be resilient in all cases
because it's too costly for low-risk scenarios. Just like buildings are
made to a code to withstand certain level of quakes because anything
higher is too costly for outlier risk. And quakes are an interesting one because we have different types of quakes that shake the ground in
different ways.

When an event happens that is outside the normal expected risk profile,
and things fall over (networks, buildings, nuclear reactors, roads,
whatever), then everyone jumps up and down demanding to know why the
thing wasn't perfectly able to withstand every single disaster scenario.

I'm sure nobody builds buildings to account for meteor strikes, but they
remain a possibility. Not likely, but certainly possible. :D

Not to mention vaccine efficacy percentages and the people who think that anything less than 100% is the same as 0%. haha

So what are you trying to build a network for? What risk(s) are you
trying to mitigate, and how much are you prepared to spend on diminishing
risk profiles?

The internet will always be there even if all the ISPs and telcos aren't. Because TCP/IP can be spun up by anyone on any computer over a variety of media, both terrestrial and non-terrestrial.

But you might need to get an alternate way to connect and change some IP addresses to make it happen. And that won't be automatic if your budget
is fish'n'chip money. :)



--- Talisman v0.35-dev (Linux/x86_64)
* Origin: Lost Underground BBS (21:1/230)

On 12-19-21 14:49, Avon wrote to Atreyu <=-

My concern is around how to build communications resilience. When we
look back at the way POTS modems and calls over landlines worked, yep
the time to get a message from A to B and a reply back was longer. But
I wonder if the overall resilience of the communication was better?

Not necessarily. The old systems were, by necessity, hierarchical, and had many built in SPOFs - hubs, etc. Rerouting was a manual operation that took a bit of coordinating over the phone. Today, redundant feeds and virtual networks are easy to spin up, and the software is (mostly) better at handling these new topologies.

Now that we rely on the Internet to be the bridge between nodes and the backbone of FTN style networks (and many other networks) I fear we have lost a lot of the means to be resilient should a bad actor(s) come
along and hobble a city or country by taking down its Internet connectivity. :(

For me, POTS is out (that uss the Internet too). Locally, a "community mesh network" using LoRa devices might be a possible solution. These have good range and the efficiency of BBS data transfers is ideally suited to this medium. But for longer distances, things get more challenging. If only we had a QO-100 like satellite over our side of the world.

How best to get packets around a country or between countries without
an Internet to carry them? <-- open question for anyone really...

Short distance LoRa mesh (Meshtastic and similar networks), longer distances - limited options (especially legal ones), the US DoD will go after us if we use their sats. :D



... A fool with a tool is a well-equipped fool
=== MultiMail/Win v0.52
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)

On 12-18-21 23:11, McDoob wrote to Avon <=-

How best to get packets around a country or between countries without an Internet to carry them? <-- open question for anyone really...

First thing that comes to mind is packet radio. Hams have been using
this protocol since 1980.

https://en.wikipedia.org/wiki/Packet_radio https://en.wikipedia.org/wiki/AMPRNet

Effective throughput on a good (uncongested) channel is < 600 bps. But on real networks, "hidden station" issues really kill performance. But IPv4 can run over packet.

Naturally, such a method of transmission would be severely
rate-limited, on the order of 10 kbit/s or less (less than 20% of the

Actually a LOT less. 9600bps links often don't perform a lot better than 1200bps, because at 9600, issues like linkm turnaround time really kill throughput. Running point to point full duplex links will definitely help this, along with large window sizes at the transport layer.

But for lonjg haul, you're down to KF, where you may get 100bps through on a GOOD day and it goes downhill from there. ;)


... It's a can of worms full of Pandora's boxes.
=== MultiMail/Win v0.52
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)

On 12-18-21 22:09, Atreyu wrote to Deon <=-

If someone presents to me an idea that is logical and supportive of the average Sysop (that I engage with almost daily), then I'm all in. Not
some unoriginal Internet "clearing house" thing 20 years too late that nobody would use now. Sysops want users calling their boards... nets
want new people posting. A dumbed-down message/BBS client is a
fantastic idea I would support.

I'd like to see a decent mobile client, but one that can work offline. Let's not assume the Internet is ever present (north of here it's frequently not present).


... IBM: It may be slow, but at least it's expensive.
=== MultiMail/Win v0.52
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)

On 12-19-21 20:20, JoE DooM wrote to Atreyu <=-

Yeah I agree to a point. I think that in all honesty, the type of
people that are attracted to BBSs are not the lowest common denomiator type of people. Those people have Facebook (which for all intents and purposes is *literally* old school BBSs with new technology and
seriously dumbed down message client)...

With some advances (such as multimedia capability, push notifications, etc), and some drawbacks (sucky clients, tightly bound to the network (adds lag to performance, slows reading, though the FB CDN helps a little, by shortening ping times and caching content on servers capable of delivering it faster).

I know there are multiple angles on how BBS "modernisation" should
work, and that's fine, but the reality is we're doing things the "old
way" very intentionally.

I feel opening things up too much to the masses could kill the goose that laid our golden egg. Look at how things went downhill with mass access to social media, yet there are still small, close knit groups on Facebook that are quite good, because they're kept small and curated.

BBSs went through a modernisation when the Internet came along. And
hell, even the online web based forums suffer now because everyone just wants to use Facebook.

Online web forums just suck, I never got into them, because of their poor performance and navigation.

*shrug* I dunno. But as I said to deon in my last post, I honestly
think that if someone wants to change something, they will have to
develop it first and people will get onboard. Discussing grand ideas
will naturally result in people with different ideas not agreeing, or diluting the ideas so much that nothing will get done.

For those who have that capability.

--- Talisman v0.35-dev (Linux/x86_64)
* Origin: Lost Underground BBS (21:1/230)

... You! What PLANET is this? McCoy, stardate 3134.0.
=== MultiMail/Win v0.52
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)

Re: Re: Is binkp/d's security model kaputt?
By: Atreyu to Deon on Sat Dec 18 2021 10:09 pm

Firstly, replying to Nick on this topic is unlikely to get a supportive conversation..

While Joe watches you attempt a penis-comparison contest, ...

Not some unoriginal Internet "clearing house" thing 20 years too late that nobody
would use now.

See, I wasnt wrong was I?


...ëîåï
--- SBBSecho 3.14-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

On 19 Dec 21 19:35:00, Vk3Jed said the following to Atreyu:

I'd like to see a decent mobile client, but one that can work offline. Let' not assume the Internet is ever present (north of here it's frequently not present).

Kindof like an off-line reader... for the board itself?

Atreyu

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (21:1/176)

On 19 Dec 21 20:20:07, Joe Doom said the following to Atreyu:

I know people who were into the BBSs in the 80s and 90s, which is where I met them and we became lifelong friends. They have a nostalgia for the boards, but have utterly zero interest in logging back into them. They
used the boards to socialise with local people back in the day.

Oh same here too... big time.

*shrug* I dunno. But as I said to deon in my last post, I honestly think that if someone wants to change something, they will have to develop it first and people will get onboard. Discussing grand ideas will naturally

The last great innovation for BBS'ing was BinkD, which simplified a part of
the transport layer / infrastructure of moving mail packets. Everyone adopted it as there was a need for it. That was 20 years ago. Since then... really nothing... maybe we can only go so far, the amps can only go to eleven, etc.

It could be argued that Mystic and Synchronet drove a recent new wave of BBS nostalgia/interest. I'm not really a fan of either software but totally respect that it gets someone excited to put a board up again.

Atreyu

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (21:1/176)

On 19 Dec 21 21:33:18, Deon said the following to Atreyu:

See, I wasnt wrong was I?

About what? That I want to see your idea actually working and less boasting?

Where can we download your software?

Atreyu

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (21:1/176)

Atreyu wrote to Joe Doom <=-

We do not need new packet or nodelist formats or storage formats for mail. Even the concept of modular deployments of a mailer, tosser, nodelist compiler etc just go over the heads of everyone.

Probably the last things we need.

With many people now re-evaulating social media's place in their lives,
it would be a perfect chance to turn these people to BBS'ing and
message nets but the learning curve is just too much. Only "techie"
people would care to jump through all kinds of hoops to get something running.

Aside from techie people, who know the risks of social media, who else is really re-evaluating? Most of the non-techie people I know who have issues with social media are re-evaluating because (1) they spend too much time on
it, and are giving it up, which means they really are not looking to
replace it, or because (2) they feel like social media has some sort of
bias towards their beliefs. I guess that second group might be a potential target but, not being techie, as you have suggested I think they would lose interest in something that didn't have a phone app and didn't allow them
share their beliefs with a larger group.

Most other people I know who are really into social media are not re-evaluating. Aside from being able to argue politics or air opinions on
some of the BBS networks, whatever else draws them to social media really does not exist, unless we want to set our boards up to include media sharing
(like tic-tok, instagram, or youtube) or some opportunity for them to make money (like onlyfans or patreon).

Honestly, I feel like most people who are really into social media are not
into it just for the communication, beyond using communication to draw attention to themselves. I am sure there are a few who maybe remember
using a BBS in the day, or that have some tech inclination that might be interested, but I just don't see most social media users taking an interest
in BBSing. The gratification is not instant enough.


... Her voice rings in his ears like the music of the spheres
--- MultiMail
* Origin: Possum Lodge South * possumso.fsxnet.nz:7636/SSH:2122 (21:4/134)

It could be argued that Mystic and Synchronet drove a recent new wave of BBS nostalgia/interest. I'm not really a fan of either software but totally respect that it gets someone excited to put a board up again.

That's pretty much why I'm here. Mystic and Synchro are basically "install
and run" BBSs. It would be orders of magnitude more difficult to get an older software to even run on my Pi, let alone fully configured and online.

Personally, I don't have the time nor patience to accept that challenge.

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (21:4/135)

On 19 Dec 21 14:38:19, Mcdoob said the following to Atreyu:

That's pretty much why I'm here. Mystic and Synchro are basically "install and run" BBSs. It would be orders of magnitude more difficult to get an olde software to even run on my Pi, let alone fully configured and online.

I assume the Pi can't run a DOS emulator properly?

Atreyu

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (21:1/176)

I assume the Pi can't run a DOS emulator properly?

Well, no. Most Pi images are based on Debian, and I think it requires at
least a Linux kernel on any image. So, it can run anything that runs in
Debian, as long as theres a 'armhf' build. I know from experience that DOSbox works in PiOS. I've learned QEmm also works, but I've been having trouble with it.

The main problem I have is that my Pi isn't connected to a screen or input, and doesn't have PiOS installed. I'm using an image called DietPi, which is
command line only, and interacting through SSH (mostly).

As the name implies, DietPi is about as stripped-down as a Pi image can get.
A fresh install is something like 1.5 GB, uses about 300 MB RAM at restart,
and has practically zero CPU overhead. Perfect for running a bunch of
different projects on a 3B+...The reason I'm running it headless is much simpler. I have only so many keyboards, mice, and monitors, and I don't have
a KVM switch.

And getting DOS to work is just the FIRST step! XD

Meanwhile, Mystic has a linux install, and was working in just a handful of hours. I brought it fully online in less than a week. It did help that I had stumbled upon Avon's tutorial videos. :)

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (21:4/135)

On 12-19-21 05:24, Atreyu wrote to Vk3Jed <=-

On 19 Dec 21 19:35:00, Vk3Jed said the following to Atreyu:

I'd like to see a decent mobile client, but one that can work offline.

et'

not assume the Internet is ever present (north of here it's frequently not present).

Kindof like an off-line reader... for the board itself?

Yeah, offline (even if updating in the background), and a touch screen friendly interface.


... Dachshund kennel ad: Get a long little doggie.
=== MultiMail/Win v0.52
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)

On 18 Dec 2021 at 11:11p, McDoob pondered and said...

How best to get packets around a country or between countries without Internet to carry them? <-- open question for anyone really...

First thing that comes to mind is packet radio. Hams have been using this protocol since 1980.
Naturally, such a method of transmission would be severely rate-limited, on the order of 10 kbit/s or less (less than 20% of the speed of ye olde 56k modem) even with good reception. Good luck watching YouTube on that!

Yes this is an area of interest and has been for some time. I have never actually taken steps to try to get such a thing working though. For some reason it always felt hard to do, probably much more so that it is. I'm a licensed amateur operator, not that active and where I am it's mostly VHF and UHF stuff... I have not done much with packet but yep, need to make some time to do so.

The other thing with this mode is it's rather limited to who can get on the air / use the frequencies and if done well is still probably limited to within a city or across a country using repeater networks... still that's better than nothing for sure :)

--- Mystic BBS v1.12 A47 2021/11/06 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 18 Dec 2021 at 11:08p, Atreyu pondered and said...

Now that we rely on the Internet to be the bridge between nodes and the backbone of FTN style networks (and many other networks) I fear we have lot of the means to be resilient should a bad actor(s) come along and h city or country by taking down its Internet connectivity. :(

Its hard to answer. Its likely that if Internet connectivity becomes a serious problem, we all would have far greater things to worry about
than not being able to trade silly banter on some net only a fraction of the world cares for.

I agree we may have far greater concerns but as for trading silly banter... if the poop hit the fan, having a means of getting helpful / serious communications between parties within or between countries would surely be welcomed by folks otherwise cut off.

Hopefully FTN can play a part in that. The store to forward bit is still just as robust, it's the how to forward bit that is my worry.

--- Mystic BBS v1.12 A47 2021/11/06 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Yes this is an area of interest and has been for some time. I have never actually taken steps to try to get such a thing working though. For some reason it always felt hard to do, probably much more so that it is. I'm
a licensed amateur operator, not that active and where I am it's mostly VHF and UHF stuff... I have not done much with packet but yep, need to make some time to do so.

Getting my ham license isn't very high on my priority list. But that only
means that I'm not allowed to build or use a transmitter (or transciever). Anyone can buy a good reciever and listen in...

I have a couple of RTL-SDRs I like to play with. One of them is occupied by
my PiAware (aircraft monitor) project, and the other is...usually tuned to my favorite local FM station, honestly...I am really thinking about buying
another one, since I need two for proper trunk decoding, and I want to have advanced notice, next time the police stop by...

The other thing with this mode is it's rather limited to who can get on the air / use the frequencies and if done well is still probably limited to within a city or across a country using repeater networks... still that's better than nothing for sure :)

Yep. Being unlicensed, even if I could get your downlink from here, which I doubt, I'm not allowed to uplink. But, one of the things packet radio was developed for is 'emergency use'...say, when the internet goes down over an entire country...

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (21:4/135)

On 21 Dec 2021, Avon said the following...

Yes this is an area of interest and has been for some time. I have never actually taken steps to try to get such a thing working though. For some reason it always felt hard to do, probably much more so that it is. I'm
a licensed amateur operator, not that active and where I am it's mostly VHF and UHF stuff...

The other thing with this mode is it's rather limited to who can get on the air / use the frequencies and if done well is still probably limited to within a city or across a country using repeater networks... still that's better than nothing for sure :)

As others have said, TCP/IP can still work, even if the internet is down. If you had someone within a few KMs of you, you could still use long range wifi to exchange packets. Linus Tech Tips has done a couple of videos about this subject:

5KM Wifi Link (August 2021):
https://www.youtube.com/watch?v=9T98VsMe3oo

12KM Wifi Link (May 2018):
https://www.youtube.com/watch?v=lYJFwXw1ZIc

Still limited to the same city/region, but at much higher speeds than would be available using packet radio.

The distance between Nick & myself is around 75KM as-the-crow-flies, so I doubt long range wifi would work for us.

If things got really bad connectivity wise, perhaps mailing USB sticks with mail between regions/countries and then propagate out via long range wifi could be a strategy? Either that or maybe Nick & I could train some carrier pigeons. ;)


Jay

... Success is being nothing but a quote.

--- Mystic BBS v1.12 A47 2021/12/13 (Raspberry Pi/32)
* Origin: Northern Realms (21:3/110)

On 21 Dec 21 11:20:08, Warpslide said the following to Avon:

If things got really bad connectivity wise, perhaps mailing USB sticks with mail between regions/countries and then propagate out via long range wifi could be a strategy? Either that or maybe Nick & I could train some carrier pigeons. ;)

I don't mind a road-trip to your place to trade USB sicks... Since you live in the armpit of Ontario, would you be wearing a hefty amount of Axe deodorant?

Atreyu

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (21:1/176)

On 19 Dec 2021, Vk3jed said the following...

Short distance LoRa mesh (Meshtastic and similar networks), longer distances - limited options (especially legal ones), the US DoD will go after us if we use their sats. :D

What would be considered short & long distances in terms of LoRa?

I just watched some YouTube videos on it and some people were getting 2-3km on a quick test walking the dog and others were boasting ~20KM. I see one video where someone got more than 100KM!

Just wondering if it would even be possible for someone like Nick and I to communicate using something like this ~75KM away (and across a stretch of Lake Ontario) while still getting decent data rates. (Assuming Nick would even want to try something like this).

(I would be using US902-928 here in Canada)


Jay

... RAM DISK is NOT an installation procedure!

--- Mystic BBS v1.12 A47 2021/12/13 (Raspberry Pi/32)
* Origin: Northern Realms (21:3/110)

On 21 Dec 2021, Atreyu said the following...

I don't mind a road-trip to your place to trade USB sicks... Since you live in the armpit of Ontario, would you be wearing a hefty amount of
Axe deodorant?

Axe deodorant doubles a bug repellent in the summer and replaces showering in the winter, so yes.


Jay

... This tagline's just for you.

--- Mystic BBS v1.12 A47 2021/12/13 (Raspberry Pi/32)
* Origin: Northern Realms (21:3/110)

Hello Warpslide!

** On Tuesday 21.12.21 - 11:20, Warpslide wrote to Avon:

5KM Wifi Link (August 2021):
https://www.youtube.com/watch?v=9T98VsMe3oo

Has he done any followup vids to this? It seems that there
would be constant fiddling with the alignment to keep things
operating at optimum.


--- OpenXP 5.0.50
* Origin: Ogg's WestCoast Point (21:4/106.21)

5KM Wifi Link (August 2021):

Has he done any followup vids to this? It seems that there
would be constant fiddling with the alignment to keep things
operating at optimum.

I'm a fan of Linus Media Group, and I haven't seen any follow up to this
video. But, once you have max signal, why would you have to change the alignment again? I mean, assuming that the dishes are tightly bolted
down, and don't get moved by external means (ie wind).

Weather can definitely have an effect on signal reception, but no amount of adjustment would improve on that.

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (21:4/135)

On 21 Dec 2021, Ogg said the following...

5KM Wifi Link (August 2021): https://www.youtube.com/watch?v=9T98VsMe3oo

Has he done any followup vids to this? It seems that there
would be constant fiddling with the alignment to keep things
operating at optimum.

I don't see a follow up, but in my experience these are pretty reliable.

In another life we installed a point-to-point wireless dishes on the top of two buildings to bridge two PBX systems. For the most part there were no issues, though I do remember having to send a tech out once after a bad storm to re-align the two dishes. So low maintenance for sure, but not no maintenance.


Jay

... An oyster is a fish built like a nut.

--- Mystic BBS v1.12 A47 2021/12/13 (Raspberry Pi/32)
* Origin: Northern Realms (21:3/110)

On 12-21-21 21:20, Warpslide wrote to Vk3jed <=-

On 19 Dec 2021, Vk3jed said the following...

Short distance LoRa mesh (Meshtastic and similar networks), longer distances - limited options (especially legal ones), the US DoD will go after us if we use their sats. :D

What would be considered short & long distances in terms of LoRa?

Good question! But given I'm 150km from Melbourne and with a mountain range in between, "long distance" options are important to me! And that distance is short by our standards. ;)

I just watched some YouTube videos on it and some people were getting 2-3km on a quick test walking the dog and others were boasting ~20KM.
I see one video where someone got more than 100KM!

The tech does seem capable of really good range, which is a point of interest for me. I'd like to see what the paths were like.

Just wondering if it would even be possible for someone like Nick and I
to communicate using something like this ~75KM away (and across a
stretch of Lake Ontario) while still getting decent data rates.
(Assuming Nick would even want to try something like this).

Sounds worth a shot.

(I would be using US902-928 here in Canada)

I think we only have 915-928 MHz on that ISM band here.



... Never believe anything until it has been officially denied.
=== MultiMail/Win v0.52
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)

On 12-21-21 11:20, Warpslide wrote to Avon <=-

On 21 Dec 2021, Avon said the following...

Yes this is an area of interest and has been for some time. I have never actually taken steps to try to get such a thing working though. For some reason it always felt hard to do, probably much more so that it is. I'm
a licensed amateur operator, not that active and where I am it's mostly VHF and UHF stuff...

I was on packet in the heyday of the mode (1991-1992 mainly). There's severe issues with things like the "Hidden transmitter problem", which can seriously harm throughput. However, I found the IP based protocols like FTP were the most robust, though you'd have to start a FTP session before going to bed and see what had arrived by the next morning. :)

The other thing with this mode is it's rather limited to who can get on the air / use the frequencies and if done well is still probably limited to within a city or across a country using repeater networks... still that's better than nothing for sure :)

Channel capacity, especially hidden stations dramatically cuts throughput. Might get better results with a duplex repeater, operating as a bit regenerator (demodulates the signal, cleans up the bitstream and retransmits). Using duplex would at least solve the hidden station problem. Probably have to just use bit regeneration (processing packets would add delays that could affect CSMA/CA performance).

As others have said, TCP/IP can still work, even if the internet is
down. If you had someone within a few KMs of you, you could still use long range wifi to exchange packets. Linus Tech Tips has done a couple
of videos about this subject:

IT would allow a diversity of network links - from wifi to packet, as appropriate. :)

If things got really bad connectivity wise, perhaps mailing USB sticks with mail between regions/countries and then propagate out via long
range wifi could be a strategy? Either that or maybe Nick & I could
train some carrier pigeons.
;)

Got you covered. :)
https://datatracker.ietf.org/doc/html/rfc2549



... Meteor shower tonight, bring your own soap!
=== MultiMail/Win v0.52
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)

On 12-21-21 21:51, McDoob wrote to Ogg <=-

Weather can definitely have an effect on signal reception, but no
amount of adjustment would improve on that.

True, but you can use diversity reception to get around that issue.


... Find a safe part and use it as an anchor
=== MultiMail/Win v0.52
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)

Vk3jed wrote (2021-12-19):

I feel opening things up too much to the masses could kill the goose that laid our golden egg. Look at how things went downhill with mass access
to social media,

You mean like Fidonet in the 90s? ;-)

(thank god it was killed by the stupid ones on the top and the Internet)

BBSs went through a modernisation when the Internet came along. And
hell, even the online web based forums suffer now because everyone
just wants to use Facebook.

Online web forums just suck, I never got into them, because of their poor performance and navigation.

Have you ever used a web forum that uses XenForo, Discourse, Flarum, NodeBB? Much better than any BBS, echomail, Facebook, reddit, ...

---
* Origin: Birds aren’t real (21:3/102)

Avon wrote (2021-12-21):

I agree we may have far greater concerns but as for trading silly
banter... if the poop hit the fan, having a means of getting helpful / serious communications between parties within or between countries would surely be welcomed by folks otherwise cut off.

Hopefully FTN can play a part in that. The store to forward bit is still just as robust,

I thought we are going to replace the robust part with a totally centralized system called the "infrastructure".

it's the how to forward bit that is my worry.

What threats do you worry about? Why would internet connectivity go down? Unreliable ISP? Cyber war? World wide catastrophe? Authoritarian regime that can shut down the (national) internet or a Great Firewall?

---
* Origin: Birds aren’t real (21:3/102)

On 22 Dec 2021, Vk3jed said the following...

Either that or maybe Nick & I could train some carrier pigeons.

Got you covered. :)
https://datatracker.ietf.org/doc/html/rfc2549

OMG, that's hilarious. I've not seen that one before! LOL


Jay

... The government solution to a problem is usually as bad as the problem.

--- Mystic BBS v1.12 A47 2021/12/13 (Raspberry Pi/32)
* Origin: Northern Realms (21:3/110)

On 12-22-21 10:19, Oli wrote to Vk3jed <=-

Vk3jed wrote (2021-12-19):

I feel opening things up too much to the masses could kill the goose that laid our golden egg. Look at how things went downhill with mass access
to social media,

You mean like Fidonet in the 90s? ;-)

Actually it was less the users that killed Fidonet, more those with some degree of power, methinks. ;) But personally, I had no issues on Fidonet, and hung out in some good echos. :)

(thank god it was killed by the stupid ones on the top and the
Internet)

:)

Online web forums just suck, I never got into them, because of their poor performance and navigation.

Have you ever used a web forum that uses XenForo, Discourse, Flarum, NodeBB? Much better than any BBS, echomail, Facebook, reddit, ...

Discourse, yep. But I find web forums unvariably feature clumsy navigation and sluggish performance.



... You don't have to be ashamed of using your own ideas
=== MultiMail/Win v0.52
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)

On 12-22-21 08:36, Warpslide wrote to Vk3jed <=-

On 22 Dec 2021, Vk3jed said the following...

Either that or maybe Nick & I could train some carrier pigeons.

Got you covered. :)
https://datatracker.ietf.org/doc/html/rfc2549

OMG, that's hilarious. I've not seen that one before! LOL

Yeah looks like an update, with QoS. ;)

Jay

... The government solution to a problem is usually as bad as the
problem.

These days, worse - or there wasn't a problem in the first place! :D


... Success is being nothing but a quote.
=== MultiMail/Win v0.52
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)

On 22 Dec 2021, Vk3jed said the following...

I just watched some YouTube videos on it and some people were getting 2-3km on a quick test walking the dog and others were boasting ~20KM.
I see one video where someone got more than 100KM!

The tech does seem capable of really good range, which is a point of interest for me. I'd like to see what the paths were like.

My father-in-law gave me some cash for xmas, so I just ordered two Adafruit RFM95W modules to play with:

https://www.adafruit.com/product/4074

Along with the 900MHz antenna kit:

https://www.adafruit.com/product/3340

They should arrive next week some time.

Looking forward to playing around with these. My father-in-law lives about 9.2km away (as the crow flies), so once I get more familiar with these modules I may try putting a Pi at his place and see if I can get them talking to each other.

There are several houses, forests, farmland & businesses in the path along with a big meat processing factory so I may have to raise the antennas up high to get the range. I'll play around with it at shorter distances before trying something that far away.


Jay

... Monday is a hard way to spend one-seventh of your life.

--- Mystic BBS v1.12 A47 2021/12/13 (Raspberry Pi/32)
* Origin: Northern Realms (21:3/110)

Hello Warpslide!

** On Friday 24.12.21 - 14:50, Warpslide wrote to All:

https://www.adafruit.com/product/4074
https://www.adafruit.com/product/3340

Looking forward to playing around with these. My father-
in-law lives about 9.2km away (as the crow flies), so once
I get more familiar with these modules I may try putting a
Pi at his place and see if I can get them talking to each
other.

The encryption part intrigues me. It sounds like it operateas
in the frequency range that 900Mhz phones used to have, but
with encryption permitted.



--- OpenXP 5.0.50
* Origin: Ogg's WestCoast Point (21:4/106.21)

On 12-24-21 14:50, Warpslide wrote to All <=-

My father-in-law gave me some cash for xmas, so I just ordered two Adafruit RFM95W modules to play with:

Let me know how you go with those. :) There's a local guy who I'd like to consult with on LoRa, as he's been playing around with them. Unfortunately, our schedules have been conflicting, especially now that the peak of the summer sports season is fast approaching. Also have to be careful here with 900 MHz stuff, to make sure it's compliant with our narrower band.


... Behind every great man is an amazed mother-in-law!
=== MultiMail/Win v0.52
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)

On 24 Dec 2021, Ogg said the following...

The encryption part intrigues me. It sounds like it operateas
in the frequency range that 900Mhz phones used to have, but
with encryption permitted.

There is another version of this module that uses 433MHz which is the 70cm amateur radio band. Presumably you wouldn't be able to encrypt using those frequencies. (And would need to be licensed to use).

https://www.adafruit.com/product/4075


Jay

... It is impossible to please the whole world and your mother-in-law.

--- Mystic BBS v1.12 A47 2021/12/24 (Raspberry Pi/32)
* Origin: Northern Realms (21:3/110)

Hello Warpslide!

** On Saturday 25.12.21 - 08:01, Warpslide wrote to Ogg:

The encryption part intrigues me. It sounds like it operateas
in the frequency range that 900Mhz phones used to have, but
with encryption permitted.

There is another version of this module that uses 433MHz which is the 70cm amateur radio band. Presumably you wouldn't be able to encrypt using
those frequencies. (And would need to be licensed to use).

I suppose that is similar in concept to ZigBee which Ontario
HydroOne uses for the smart meters? My meter sends its data to
the nearest neighbor's meter which then keeps forwarding the
data until it reaches its intended destination.


--- OpenXP 5.0.50
* Origin: Ogg's WestCoast Point (21:4/106.21)

On 12-25-21 08:01, Warpslide wrote to Ogg <=-

On 24 Dec 2021, Ogg said the following...

The encryption part intrigues me. It sounds like it operateas
in the frequency range that 900Mhz phones used to have, but
with encryption permitted.

There is another version of this module that uses 433MHz which is the
70cm amateur radio band. Presumably you wouldn't be able to encrypt
using those frequencies. (And would need to be licensed to use).

Depenmds where you are. In Australia, 433 MHz is covered by the LIPD class licence, so no dramas using them here.


... A problem can be found for almost every solution.
=== MultiMail/Win v0.52
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)

The encryption part intrigues me. It sounds like it operateas
in the frequency range that 900Mhz phones used to have, but
with encryption permitted.

There is another version of this module that uses 433MHz which is the 70cm amateur radio band. Presumably you wouldn't be able to encrypt using those frequencies. (And would need to be licensed to use).

Depenmds where you are. In Australia, 433 MHz is covered by the LIPD class licence, so no dramas using them here.

It's very different in North America. For the most part, encryption is not allowed on ham bands, even with a license to transmit.

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (21:4/135)

On 12-26-21 16:05, McDoob wrote to Vk3jed <=-

The encryption part intrigues me. It sounds like it operateas
in the frequency range that 900Mhz phones used to have, but
with encryption permitted.

There is another version of this module that uses 433MHz which is the 70cm amateur radio band. Presumably you wouldn't be able to encrypt using those frequencies. (And would need to be licensed to use).

Depenmds where you are. In Australia, 433 MHz is covered by the LIPD class licence, so no dramas using them here.

It's very different in North America. For the most part, encryption is
not allowed on ham bands, even with a license to transmit.

The point here is that these are not classed as ham devices, and not running under ham rules. 433 MHz has multiple spectrum users.


... I am NOT burned out - just singed a little!
=== MultiMail/Win v0.52
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)

What threats do you worry about? Why would internet connectivity go down? Unreliable ISP? Cyber war? World wide catastrophe? Authoritarian regime that can shut down the (national) internet or a Great Firewall?

You weren't asking me, but of these, Cyberwar is my largest concern. It can be as simple as a kind of domestic terrorism:

https://www.wired.com/2015/11/security-news-this-week-bay-area-fiber-optic-cab les-mysteriously-cut/

One plus side of being in the US is most of the essential Internet facilities I use (save the noble fsxNet hub in the antipodes, of course) are here in the US. An authoritarian regime cutting off its country's access doesn't impact me directly (my sympathy for those impacted by such a thing notwithstanding).

Packet radio has been around a long time and I have seen some YouTube demos of bulletin boards running on it; however, what is not clear is whether or not anyone has ever tried to use a repeater network to store-and-forward messages across oceans and over borders.

I would be less concerned about real time communications because that seems fraught with all manner of technical challenges, and more concerned with something like Fidonet in which local cities could store data, then send them via repeater networks out of their region and on to destinations, with routers at each point sorting and sending through the right networks. A lot of the repeaters around me are solar-powered, so this could be disaster-resistant, and ideally such a network should be able to send something other than (but in addition to) plain text, like maps, or images.

Does anyone who is more than a dabbler like me know if such a thing has been tried, or exists?

https://www.youtube.com/watch?v=8Hm6omrVaeE

This is a packet radio BBS. I have no idea how many of these exist or are in regular use. I have tried to find a list but the ones I can find are out of date and most indicate there are none near me in Tucson, Arizona.

https://f1zwt.files.wordpress.com/2010/09/world-bbs-listing-dec-2018.pdf

--- Mystic BBS v1.12 A47 2021/09/24 (Linux/64)
* Origin: Shipwrecks & Shibboleths [San Francisco, CA - USA] (21:1/227)

Re: Is binkp/d's security model kaputt?
By: apam to Oli on Sat Sep 18 2021 04:57 pm

I'm more interested in fixing the current software and standards.

Why? The "current" software is kind of unfixable, it would require people with access to the current software's code having a desire to fix it.

It would also require said people working together...

Look at fsxnet for example, an FTN network, now, I would say 90% of the network runs mystic software. Not some DOS bbs that saw it's last release
in 1995.

That last 10% probably run synchronet, some other software or a very very tiny few actually run software (that is connected to fsxnet) from eons
ago.

Even that software that hasn't seen an update since 1995 probably has message bases compatible with Squish or JAM.

So we could put lipstick on a pig so to say and keep FTN only. FSXnet
isn't fidonet, it doesn't need to be married to the technology - WWIVnet
and DOVEnet both use other systems, so one could create a new network technology, and have it working with BBSes.

I find the topic of a new messsage network technology interesting and have been following along here.

However, before anything "new" is proposed, I suggest a careful examination of what is wrong with the current technology (FTN). I've started my own list here:
http://wiki.synchro.net/wiki:user:digital_man#what_s_wrong_with_fidonet

For a long time, I've been innovating with QWK-based networking, because
1. it was more extensible (than FTN) while maintaining backward-compatibility 2. the networks (e.g. DOVE-Net) were more amenable to change

With Synchronet, I also supported PostLink networking (e.g. RIME) in the past and certainly have no love of FTN, but I think it'd be best to know what you're trying to fix before you try to replace it with something else. :-)
--
digital man (rob)

Rush quote #51:
Suddenly you were gone from all the lives you left your mark upon
Norco, CA WX: 57.8øF, 77.0% humidity, 7 mph WNW wind, 0.15 inches rain/24hrs --- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)

Digital Man wrote to apam <=-

With Synchronet, I also supported PostLink networking (e.g. RIME) in
the past and certainly have no love of FTN, but I think it'd be best to know what you're trying to fix before you try to replace it with
something else. :-) --

+1



... DalekDOS v(overflow): (I)Obey (V)ision impaired (E)xterminate
--- MultiMail
* Origin: Possum Lodge South * possumso.fsxnet.nz:7636/SSH:2122 (21:4/134)

I find the topic of a new messsage network technology interesting and
have been following along here.

It's interesting, I'm kind of a little bit fickle about the idea, I'm not really sure it's worth pursuing. I mean, from a development point of
view, making new things for the sake of making new things can be fun, but
who would use it?

However, before anything "new" is proposed, I suggest a careful
examination of what is wrong with the current technology (FTN). I've
started my own list here:

Yep, I agree, I read your list, and think it's pretty much spot on.

To be honest though, I think it's a kind of dead end. It's interesting to
talk about though I suppose.

Happy birthday by the way, not sure if it was today or yesterday..
facebook told me, but I don't know how that works with timezones :)

Andrew

--
|03Andrew Pamment |08(|11apam|08)
|13Happy|10Land |14v2.0|08!|07


--- Talisman v0.35-dev (Windows/x64)
* Origin: The Grinning Cat - telnet://gcat.talismanbbs.com:11823 (21:1/151)

Re: Is binkp/d's security model kaputt?
By: apam to Digital Man on Sat Jan 01 2022 02:55 pm

I find the topic of a new messsage network technology interesting and have been following along here.

It's interesting, I'm kind of a little bit fickle about the idea, I'm not really sure it's worth pursuing. I mean, from a development point of
view, making new things for the sake of making new things can be fun, but who would use it?

It's always possible that a network could be formed (or switch to) a non-FTN technoloy. And that could then be a new technology. But so far, I haven't found any limitation or issue with QWK that I couldn't address, so that's where I tend to focus my message-networking-innovation. I appreciate your adopting (and testing the interoperability) of some of my QWKnet extensions too.

However, before anything "new" is proposed, I suggest a careful examination of what is wrong with the current technology (FTN). I've started my own list here:

Yep, I agree, I read your list, and think it's pretty much spot on.

To be honest though, I think it's a kind of dead end. It's interesting to talk about though I suppose.

Yeah, probably a dead end. There's the occasional discussion of the same subject on FidoNet proper (e.g. Future4fido echo), but I don't think it's ever going to amount to much because of the compatiblity issue.

Happy birthday by the way, not sure if it was today or yesterday..
facebook told me, but I don't know how that works with timezones :)

Thanks. It's still the 31st here in California, so still my birthday (the Unix epoch, for this timezone anyway). :-)
--
digital man (rob)

Breaking Bad quote #4:
Tagging trees is a lot better than chasing monsters. - Hank
Norco, CA WX: 47.0øF, 90.0% humidity, 0 mph ESE wind, 0.01 inches rain/24hrs --- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)

It's always possible that a network could be formed (or switch to) a
non-FTN technoloy. And that could then be a new technology. But so
far,

Yes, it would have to offer something FTN doesn't though I think, even if
it was technically superior, FTN does work and I suspect unless both
Synchronet and Mystic supported it natively, very few would be bothered
to set it up.

I haven't found any limitation or issue with QWK that I couldn't
address, so that's where I tend to focus my
message-networking-innovation. I appreciate your adopting (and testing
the interoperability) of some of my QWKnet extensions too.

That's cool, I mainly just wanted messages from talisman to be a bit more seemless for those viewing on synchronet (so people didn't get mad lol)
but I'm glad it was helpful to test things.

Thanks. It's still the 31st here in California, so still my birthday
(the Unix epoch, for this timezone anyway). :-)

Ah, ok. That's interesting. So facebook must tell me it's peoples
birthdays in my own timezone not theirs.

Sorry, I don't mean to be a bit of a downer regarding message nets - I'm
not sure if it's coming across that way.

Andrew

--
|03Andrew Pamment |08(|11apam|08)
|13Happy|10Land |14v2.0|08!|07


--- Talisman v0.35-dev (Windows/x64)
* Origin: The Grinning Cat - telnet://gcat.talismanbbs.com:11823 (21:1/151)

Yes this is an area of interest and has been for some time. I have never actually taken steps to try to get such a thing working though. For some reason it always felt hard to do, probably much more so that it is. I'm
a licensed amateur operator, not that active and where I am it's mostly VHF and UHF stuff... I have not done much with packet but yep, need to make some time to do so.

Oh that would be cool for sure!

-Karl

... My reality check just bounced

--- Mystic BBS v1.12 A47 2021/09/29 (Raspberry Pi/32)
* Origin: The Digital Abyss | Tampa, Florida USA (21:3/156)