Subj : Re: Is binkp/d's security model kaputt?
To   : tenser
From : deon
Date : Thu Sep 09 2021 12:32 pm

  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)

.