Subj : Is binkp/d's security model kaputt?
To   : deon
From : Oli
Date : Sat Sep 04 2021 12:18 pm

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.

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

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

 d> It could be trimmed a bit more if the "src" was taken
 d> from the calling system, saving another 8 chars. Using the packet name
 d> itself could reduce the header by a further 8 chars or so - and I'm
 d> 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.

 d> 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)

.