Subj : Re: Is binkp/d's security model kaputt?
To   : deon
From : Avon
Date : Sat Sep 04 2021 08:16 pm

On 02 Sep 2021 at 09:41p, deon pondered and said...
 
 de> So I too, would love to see many improvements - that sees this retro
 de> hobby still function (with the retro software), but at the core, it
 de> leverages modern technologies for the benefits that they bring (improved
 de> security, improved authentication, improved authorisation, alternative
 de> 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).

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

 de> I have a few things to sort out with my new mailer, and then I'd be in a 
 de> position to proto type something new - but I guess that's only useful if
 de> there is something else that uses it too. It would be nice to know that
 de> 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)

.