DTN

[Bruce Perens]

Delay/Disruption-Tolertant Network is software designed for interplanetary communications that can also handle the timing issues of Amateur Radio store-and-forward. Stuart was considering UUCP, but this might be better. The software is here: https://github.com/ibrdtn/ibrdtn

A tutorial paper is here: https://www.nasa.gov/wp-content/uploads/2023/09/dtn-tutorial-v3.2-0.pdf-----

Bruce Perens K6BP

[Bruce Perens]

This one is under current development: https://github.com/nasa-jpl/ION-DTN

--

Bruce Perens K6BP

[Bruce Perens]

Videos to get up to speed on DTN:

https://www.youtube.com/watch?v=nWtRTzXJvtI&t=228s

https://www.youtube.com/watch?v=7xwJEZyL_Ns

https://www.youtube.com/watch?v=2RHzIxbBJgo&t=3s

--

Bruce Perens K6BP

[Greg Troxel]

I worked on a project that did DTN and the bundle protocol over ad hoc
radio in 2008. I agree that DTN-like concepts are useful, but how to
steer across layers is really not obvious.

Back then, the gaping hole in DTN (Bundle Protocol) was that there was
no real story about routing. On one hand there was flooding, and on the
other there was explicit knowledge about how the system would operate
and essentially hand-written routes. I have not since had the
impression that this has really changed.

It's also important in constrained networks to use an application-layer
protocol that is frugal in bits. "users" who don't understand will
otherwise want to send multi-MB images and 20MB presentations. Agreed
that this doesn't directly bear on DTN/BP.)

Email can be sort of viewed as layer 7 DTN, except that there aren't
handoffs to random nodes.

Overall, I feel that the plan of which messages are handed to which
other nodes at contact time is tha hard issue, and that BP vs L7
exchange doesn't really matter. I am not convinced that adding the
RFC5050 ball of wax is a net win.

Another thing to look at is Briar. While focused on avoiding traffic
analysis and confidentiality, it's a mostly-worked example of L7 DTN
across devices.
https://briarproject.org/

There's also Delta Chat, which lacks the DTN aspect but now allows
multiple SMTP relays so that messages get through if A can reach any of
their servers and one of those can reach a server for B that B can
reach. Which is multipath routing not DTN.


Looking at winlink, my impression is that there is a firm division into
"clients", which admit Free implementation like pat, and "servers",
which appear to need the official/proprietary code and adminstrative
agreements to be part of the club. There seems to be an assumption that
all/most servers have Internet connectivity. It's not clear to mehow
that works under massive Internet disrupion. Contrary facts
etc. welcome - I read winlink.org somewhat and didn't come to understand
more.


I'm left thinking that a reasonable approach is for nodes to have some
metric about how well connected they are (to some core notion, waves
hands) and to have that increase over links, and to use DTN-like
forwarding of message objects downhill in metric space, with some
controlled amount of replication, with acks that then delete the
duplicate messages (and are stored for a while to suppress any arriving
copies). A conceptual design like that might well lead to a decision to
re-use BP.

That raises the issue of whether messages from a node are intended for
another specific node, ham callsign or some kind of hierarchical
tactical callsign, or are intended as email gateway. The former case is
straight DTN.

The email case is almost DTN except the last hop is email,
but logically it's part of the routing, as until an MX for the recipient
domain acks the message, it's still in flight. So a node that thinks
it is internet connected -- or one which is at the time mostly internet
connected -- cannot generate an e2e ack. Here, I'm using e2e to mean
from the node originating the email to the recipient MX.



Reading your goals document, I think interop with email is not a goal.
But I don't want to conclude that.

[Bruce Perens]

Greg, you are obviously up-to-speed on things I just heard of for the first time yesterday. I think email is permissible as an end route to people without the system, but we should strongly insist on message-delivery-notification equipped mailers, and digest the MDN messages.

What do you suggest as the next step? I could have the AI hack Briar for ham radio purposes - removing encryption and adding our flavor of address, and then run a big simulation.

As we write this, the AI is turning the ICS-100 course into an engaging story. with timed repetition of questions, rather than the dry thing that FEMA puts out. It will probably ingest all of the ICS courses overnight. Except that I can't find ICS-800 online while FEMA is down.

    Thanks

    Bruce

    Thanks

    Bruce

--

Bruce Perens K6BP

[Stuart Longland]

On 13/3/26 23:38, Greg Troxel wrote:
> I worked on a project that did DTN and the bundle protocol over ad hoc
> radio in 2008. I agree that DTN-like concepts are useful, but how to
> steer across layers is really not obvious.
>
> Back then, the gaping hole in DTN (Bundle Protocol) was that there was
> no real story about routing. On one hand there was flooding, and on the
> other there was explicit knowledge about how the system would operate
> and essentially hand-written routes. I have not since had the
> impression that this has really changed.

Just reading through their documentation, I'm getting a sense of that.

I'll admit UUCP would seem foreign to most people today. My first
encounter with it was a project with Aurizon: back in the mid-90s they
(back then known as Queensland Rail) had approached my workplace for a
weighbridge tracking system, so they lashed together SCO OpenServer 5
boxes with UUCP and MacroView SCADA, with 1200-baud dial-up links (even
in modern times… central Queensland telephone lines are not great)
shunting data around.

20 years later, those wheezing servers were still going and they wanted
a replacement so I got a baptism of fire with getting SCO UUCP talking
to Taylor UUCP on Ubuntu 14.04.

I came to appreciate the old protocol though, and actually managed to
get it somewhat working over SSH links, did have a go at making it talk
to a packet TNC, but it didn't seem to like the line echo.

Now, AX.25 routing itself behaves a lot like UUCP: it is source-routed.
Email however and TCP/IP is the opposite: they are destination-routed.

I haven't yet figured out which way around ION-DTN is.

I can see a benefit in it being source-routed like UUCP and AX.25
because the latter requires either static route configuration or
frequent-enough contact to maintain dynamic routes, however having
dynamic routing does make life a lot easier for the end user: They just
say "send this to base" and it figures out where "base" is and how to
get it there. There's minimal pre-configuration needed.

In the packet radio world, one solution to this that was developed was
Net/ROM. That provided some (admittedly basic) destination-route
capability over AX.25 networks, and is implemented in the Linux kernel
AX.25 stack and in BPQ32.

Two things I see that ION-DTN provides over these solutions is I see
ION-DTN has an authenticity/confidentiality layer, and it can operate
with nodes that are only temporarily online.

So destination-routing could probably be achieved at a higher layer by
observing the routing table that a lower-level stack (like Net/ROM)
builds up, storing that, and using that to build up a higher-layer route
to pass to something like UUCP or ION-DTN: and having that protocol
manage the actual data transfer.

Another prospect I thought was to use something like APRS to "ping" the
node, discover a route, then use that to feed UUCP. Crude, but for
always-on nodes, it'd work okay I think. For permanent infrastructure
we'd need something smarter.

> It's also important in constrained networks to use an application-layer
> protocol that is frugal in bits. "users" who don't understand will
> otherwise want to send multi-MB images and 20MB presentations. Agreed
> that this doesn't directly bear on DTN/BP.)

Indeed, this is where user expectations are going to meet the hard
reality of constrained narrowband modems. Best I've seen there were
some GE radio modems that a gold mine bought that offered ~40kbps over a
standard 2.5kHz UHF radio link, and probably had an eyewatering price
tag. Especially the generation born this century: who have never
experienced a modem handshake (or the frustration of a dropped link in
the middle of a download). We think nothing of 20MB today, but 30 years
ago, that was a hour's Internet download time.

Protocols like CoAP (RFC 7252) are written around small packet sizes:
IEEE 802.15.4 only has a MTU of about 128 bytes and so you have to
seriously penny-pinch every byte in the payload. Rather than JSON, the
CBOR (RFC 8949) payload format is quite popular for transferring data.
There's also EXI (W3C standard) and the venerable ASN.1 format.

I have thought about whether to adapt CoAP over AX.25… but for now it's
a silly idea with no real application in mind.

Sending a 512kB file over CoAP is doable through block-wise transfer
(RFC 7959), and if you've got a good well-behaved Thread (6LoWPAN)
network, the transfer can be done in about 2-3 minutes, but if it's bad
comms (e.g. trying to push 22dBm of 2.4GHz radio signal through a garage
door or fire-rated reinforced concrete floors), it can take hours or days.

If we interface to email, most SMTP servers can configure a maximum file
size limit (Postfix defaults to 10MB) so it bounces at the first hop. I
think the HERMES system leant on using data compression and transcoding
to get payloads down in size so that ARDOP modems could send things in a
sensible time period, but tempering user expectations will be a big step
in the right direction here.

Regards,
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.

--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.

[Stuart Longland]

On 14/3/26 13:14, Bruce Perens wrote:
> Greg, you are obviously up-to-speed on things I just heard of for the first
> time yesterday. I think email is permissible as an end route to people
> without the system, but we should strongly insist on

> message-delivery-notification equipped mailers, and digest the MDN messages..

>
> What do you suggest as the next step? I could have the AI hack Briar for
> ham radio purposes - removing encryption and adding our flavor of address,
> and then run a big simulation.
>
> As we write this, the AI is turning the ICS-100 course into an engaging
> story. with timed repetition of questions, rather than the dry thing that
> FEMA puts out. It will probably ingest all of the ICS courses overnight.
> Except that I can't find ICS-800 online while FEMA is down.

This is probably a good time for me to declare my position on "AI".
I'll admit my opinion is not that of a trained lawyer familiar with
things like copyright law, but as a software developer where some basic
understanding of legal issues is still required.

I have very strong ethical and legal concerns with the use of large
language models for the purpose of generating copyrighted content. I
personally reject such code in my own personal projects and I have a
strong preference for avoiding tools and dependencies that incorporate
LLM-generated content.

(I recognise this puts my use of Linux, and my choice of Python for many
of my projects as being somewhat problematic.)

Part of this is down to the manner and method in which these
large-language models have been "trained" and developed: the vast
majority of the training content used is "scraped" off the information
superhighway with minimal regard to authorship, licensing or quality;
all of which has to then be categorised and labelled by human reviewers
(often whom are not domain-experts in any given field). It's then
computed into model weights at extreme computational cost.

As such, the output is not so much "intelligent" output, but rather is a
"statistical mean" of all of the variations of the input observed. It
seems "intelligent" to us because "we" have not seen anything like it,
but somewhere, there will be something like it.

If "past recorded intelligence" counts as genuine intelligence, then my
JVC JL-A1 counts as an "intelligent" machine: a somewhat crass one too
if my Austen Tayshus record happens to be playing.

In areas where there is little source material, we're more likely to see
duplication of content. I've seen something similar to this play out
once before: https://github.com/ocaml/ocaml/pull/14369 -- there it was
in the OCaml field, and it managed to regurgitate copyrighted code from
an opposition project.

There's not that many amateur radio projects in circulation, it would
appear the probability of this happening is higher here. In the case of
AX.25 stacks, there aren't that many open-source ones out there: Linux
kernel, BPQ32, Direwolf, and aioax25 are the ones I know of personally.

Even if it doesn't, we want to very carefully label "generated" content,
lest the entire work be declared "generated": the US supreme court
recently ruled that copyright does not apply to machine-generated works,
only human generated works.

https://www.heise.de/en/news/Copyright-dispute-over-AI-generated-art-US-Supreme-Court-dismisses-case-11196323.html

The last thing we want in this project, is to find ourselves on the
receiving end of a copyright infringement dispute, or to have our work
declared "public domain".

Furthermore, as a goal is to introduce this work to government
organisations, likely we will need to explain how the system works in
great detail. Wilbur Wright pointed out the better way to learn to ride
a horse was to get on the animal's back and give it a go. I'm not
certain sticking a robot on the metaphorical horse's back is going to
teach us what we need to know to sufficiently explain it to another human.

[Stuart Longland]

On 14/3/26 17:21, 'Stuart Longland' via emergency_communications wrote:
> I have very strong ethical and legal concerns with the use of large
> language models for the purpose of generating copyrighted content.  I
> personally reject such code in my own personal projects and I have a
> strong preference for avoiding tools and dependencies that incorporate
> LLM-generated content.
>
> (I recognise this puts my use of Linux, and my choice of Python for many
> of my projects as being somewhat problematic.)

Out of interest I had a close look at ION-DTN on this front: the use
there is limited to a couple of small commits, one is adding read-only
access to a process on a Github action, but the more intriguing one is this:

https://github.com/nasa-jpl/ION-DTN/commit/f7783d03812f41cf5ba8acfd631ed97d0cb30c8d

Now, no copyright infringement is happening there from what I can see.
On that front, things are safe, but this exposes another insidious thing
with these tools: plausible but still wrong outputs. The change "seems
plausible", but I'm not sure it does what it says on the tin.

ici/test/smrbtsh.c is listed in full here:
https://github.com/nasa-jpl/ION-DTN/blob/979687f885b73013537f2e4154dfdc26a24b8202/ici/test/smrbtsh.c#L66-L77

`PsmAddress` is a `typedef` for a `uaddr`:
https://github.com/nasa-jpl/ION-DTN/blob/integration/ici/include/psm.h#L49

and a `uaddr` is a `typedef` for either a `unsigned long` or a `unsigned
long long`, depending on the platform:
https://github.com/nasa-jpl/ION-DTN/blob/integration/ici/include/platform.h

(I'll leave aside my loathing of the `long` and `long long` data types
here for their cross-platform vagueness, I'm guessing they have their
reasons for ignoring `stdint.h`.)

Casting it to a `unsigned long` in `smrbtsh.c` seems dodgy to me.
Even more problematic, is casting the `void *dataBuffer` to a `unsigned
long`: I hope for their sake the data is word-aligned because I know for
a fact that ARM does not like unaligned word access.

Now, the code the bot changed actually did much the same thing, and
probably re-wrote that to be a little more "readable", but it didn't
fundamentally fix the "Uncontrolled data in arithmetic expression" it
claimed, and nor have the subsequent fixes as it still exists on their
"integration" branch today.

I wouldn't cast ION-DTN aside over this alone, their use of this tool is
limited:

stuartl@rikishi ~/projects/emcomm-wg/ION-DTN $ git log --format="%h %s
%(trailers:key=Co-authored-by)" | grep -i copilot
f7783d038 Potential fix for code scanning alert no. 73: Uncontrolled
data in arithmetic expression Co-authored-by: Copilot Autofix powered by
AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
41e0e1f7d Potential fix for code scanning alert no. 138: Workflow does
not contain permissions Co-authored-by: Copilot Autofix powered by AI
<62310815+github-advanced-security[bot]@users.noreply.github.com>

… but it does underscore the point about putting too much trust in these
tools and what they produce.

[Greg Troxel]

Bruce Perens <br...@perens.com> writes:

> Greg, you are obviously up-to-speed on things I just heard of for the first
> time yesterday. I think email is permissible as an end route to people
> without the system, but we should strongly insist on
> message-delivery-notification equipped mailers, and digest the MDN messages.
>
> What do you suggest as the next step? I could have the AI hack Briar for
> ham radio purposes - removing encryption and adding our flavor of address,
> and then run a big simulation.

I think it is vastly premature to be thinking about code. The big issue
is being clear on what are and are not requirements, and then thinking
about system architecture. Routing is hard and once you move beyond
multi-hub/spoke and assuming the hubs can all intercommunicate reliably,
you're into ad hoc routing which is very hard, with low bitrate links,
unreliable links, or mobility and especially hard with multiple of
those. Decisions about naming and routing are going to have huge
long-term effects on the system.

I would then want to see a protocol spec, or something at least mostly
like that, as the system should admit mulitple independent interoperable
implementations, at least eventually.

It seems obvious that modular design in architecture is a goal, with
narrow waists to allow different parts to be thought about separately.

For requirements, architecture, and protocol design I do not see LLMs as
being helpful.



The current Policy file is a mix of requirements and architecture
decisions. I would suggest a requirements section and separating things
that are our statement of what is to be accomplished from thoughts about
how to go about it. Things that are there or have been mentioned plus
things that come to mind as I type:

system architecture and protocol must be entirely open, with documents
downloadable anonymously. Anyone must be able to implement, deploy,
sell implementations, etc. without needing a patent license.

purpose of the system is to transport ICS messages
- secondarily there should be the ability to transport other kinds of
messages, TBD

system must create and store an audit trail

system must have an interface for creating, reading and acknowledging
ICS messages, suitable for normie ICS types
- perhaps, must support concept of a message to someone who reads
it on paper and acks it with the ack coming back to bits

something about acks/delivery-receipts. Is this part of ICS?
something that's part of this system?

TBD: While unicast messages (perhaps including multiple recipients) is
an obvious requirement, is there a requirement for some kind of
multicast/broadcast message, such as might be used to carry ARRL
bulletins, IPAWS messages, or general orders from IC to all resources
under that IC's command? What does this look like in ICS now? What
should be provided? (Routing gets even harder with multicast, and
"reliable multicast" causes ad hoc routing experts to get worried.
But the question here is what is required,)

system must not assume stable connectivity on any link

system must be able to deliver messages when 1-hop connectivity from
source to destination never happens

system should be able to utilize links which mostly work over time but
with relatively low to near zero channel occupancy during periods of
no traffic.

It is not a requirement to have rapid/near-real-time functionality for
highly mobile nodes. Mobility is defined mostly as changes in
topology; if you can close the same link while you phys-move you are
not really topo-moving.

system must be able to utilize multiple kinds of links
- hf modem
- v/uhf modem
- LoRa like links (e.g. "meshtastic hardware")
- BLE
- local internet (including wifi)
- distant internet

one of the link types is a movable node, where someone carries
computer from one place to another (and perhaps back)

TBD: one of the link types is a portable storage device
(e.g. flashdrive), as opposed to a movable node.

TBD: is there a requirement for Data Origin Authentication?

TBD: is there a requirement to be able to support Confidentiality as a
service, even understanding that this will preclude use of Amateur
Radio for those messages?

TBD: What is the total scale of the system? 10^k, for k 2, 6, 9?

TBD: What are the forms of naming for entities that send and receive
messages? Is this defined already?

TBD: Is there a sense of "address" separate from "name" within ICS?

TBD: Can we require geographically hierarchical names?

TBD: Can we assume that we have geo coords for our station and that
this can be used locally and exchanged, or can we not assume that?
What are the OPSEC and privacy concerns?
- Straw proposal: In most cases, latitude and longitude to 2 decimal
places is acceptable, but each node can be configured for
off/0places/1place/2places. System must function for nodes with
reduced or off, but it is acceptable for costs to increase. 3
decimal places is 100m and is unacceptably precise. Or perhaps
also skip 2 places, leaving 1 place as 10 km (ish) squares (not
really, but not the point).

TBD: Are there any "radio silence" or similar concerns?

Because these requirements are incompatible with "just use WinLink",
full compatibility with WinLink is not a requirement. Same for APRS.

TBD: Gateway to Internet email is or is not a requirement. How are
ICS messages back to people in offices handled? Do they have to have
a local node for the new system?

TBD: Is it or is it not a requirement for people in the field to be
able to send and receive normal emails to random places, separately
from ICS messages to/from ICS names/addresses?

[Greg Troxel]

"'Stuart Longland' via emergency_communications"

<emergency_co...@perens.com> writes:

> This is probably a good time for me to declare my position on
> "AI". I'll admit my opinion is not that of a trained lawyer familiar
> with things like copyright law, but as a software developer where some
> basic understanding of legal issues is still required.

I am in the same boat mostly. I see non-consensual use of content for
training as a moral offense, and I see AI scrapers as a DDOS against web
sites. I also see LLM output as a derived work of the training data,
and it's always missing attribution and license compliance.

I recently had occasion to look over a vibe-coded PR and found it quite
low quality in terms of the commit message and explanation, and the code
content was also off.

Separately from those concerns, I think Stuart is right about the thin
amount of training data for most of what's needed.

[Greg Troxel]

I used UUCP for email from the 70s to the 90s, so I understand where
you're coming from. UUCP was intermittent, but from the viewpoint of
routing was stable. When system A had a relationship with B and a
message, it just got sent, on schedule, or dial on demand. There was no
"PSTN is messed up and A<>B calls fail but A<>C and C<>B work and the
system is expected to figure this out."


All good points about protocols, but I think the real issues are going
to be naming/addressing/routing. How messages are represented and how
they are exchanged between nodes when routing says they should be will
matter, but that isn't what will make or break the system.


Your discussion about user expectations and larger messages makes me
think about if there needs to be an authorization system to send images,
so that only those which are worth it get sent. The kids these days
just never used 300 baud modems or RK05s and they have no idea.

[Stuart Longland]

On 15/3/26 00:59, Greg Troxel wrote:
> I used UUCP for email from the 70s to the 90s, so I understand where
> you're coming from. UUCP was intermittent, but from the viewpoint
> of routing was stable. When system A had a relationship with B and
> a message, it just got sent, on schedule, or dial on demand. There
> was no "PSTN is messed up and A<>B calls fail but A<>C and C<>B work
> and the system is expected to figure this out."

The hardest bit here I think are the cases when:

- Node X was there an hour ago, but isn't reachable now, will it come
back, is it being moved, or is it gone for good?
and
- Node Y is unknown, where does it fit in to the connectivity graph?

Sleepy end devices in Thread didn't handle the latter case at all, but
they handled the former by first "attaching" themselves to a parent
router node, then informing the parent that they were going to sleep for
X seconds. The parent would then store messages for the child and pass
them on when the child woke up.

https://openthread.io/guides/thread-primer/node-roles-and-types#minimal_thread_device

The simplification here is that "end devices" do no routing in Thread.

In contrast, in this system we expect the offline node to pick up a
message when it returns, and then forward it on when it is able to. I
feel like an automatic routing system should preference online nodes
over offline ones in the interests of keeping things moving, and only
failing back to offline nodes if there is no other choice or the user
really insists on it.

Even harder is when a node operates rogue. The last thing you want is a
node that "ACKs" your message with a promise to forward it on, and
intentionally drops it in the bit bucket.

I think NASA's ION-DTN system seemed to wait until it received an ACK
from a hop beyond, which unless you had a lot of rogue nodes in the
chain, could theoretically fall back to a different route and retry in
that situation.

In this case, we'd also need some check that the forwarded ACK was
authentic, something like the COSE (RFC 8152) Sign and Sign1 objects,
lest the ACK was forged.

I'm wondering if we maybe should use a hybrid system: dynamic routing
for quick registration of new and mobile nodes with a timed expiry, and
the option of static routes on select nodes which allow for those
"special cases" to be configured?

Possibly also a "trust" concept too, so signed "certificates" that allow
preferring of trusted nodes over untrusted ones?

> The kids these days just never used 300 baud modems or RK05s and
> they have no idea.

I'll admit to being one of the kids that has never used a 300 baud modem
or RK05… slowest I've dealt with was 1200 baud (the aforementioned UUCP
system, it'd answer at 1200 baud because it only needed to know who was
calling then it'd hang up and dial back, possibly faster).

You get into the habit of checking commands over *before* you sent them
real quick because a modern Linux system has decent-size buffers and
you'll wait a long time after hitting ^C for them to empty and a shell
prompt to re-appear.

RK05 I think was the DEC removable disk drive: that was more than a
decade before my time. It's amusing enough when a work colleague
innocently asks: "what's a floppy disk?" (A question that prompted
specimens of 8", 5¼" and 3½" variants to appear on said colleagues desk
the very next day.)

[Bruce Perens]

Greg, you have your undisputed areas of expertise. For decades I've been an expert witness and intellectual property specialist working for lawyers and corporations.

The AI copyright infringement battle is completely lost.

This is not how I would have liked it to happen, and I agree that all AI training is copying, and all AI output is copying. Unfortunately, legislators and courts are not on that side of the argument, and the horse is out of the barn and can't be put back. My expressed opinion in this article in The Register was similar: https://www.theregister.com/2026/03/06/ai_kills_software_licensing/

It is true that you might not be able to defend your AI created work against the "infringement" of others. However for your work to be found infringing seems a remote prospect at the moment. The cases have simply not been won, and present copyright law is based upon two factors: 1. Direct textual copying, 2. non-literal copying as defined in Judge Walker's finding in Computer Associates v. Altai ( https://en.wikipedia.org/wiki/Computer_Associates_International,_Inc._v._Altai,_Inc. ). Neither of these is the way that the AI produces output, and there seems to be little possibility that the law will now be amended to incorporate the AI method of mixing multiple sources as infringement. 

We also have a really big opportunity to code working code quickly. Regarding getting it to meet your standards, see my rather large framework to constrain the AI athttps://github.com/BrucePerens/hams_community . This is not only about 100 pages in the standard prompt, but a programmatic framework to catch the AI's foibles. The only thing not in there is commenting the code for humans (due to token bandwidth considerations), but the AI will do that pretty well if you ask it. 

 For example, over a couple of days, I had the program code a system to digest the ICS courses and render them into stories, with character arcs and Pixar's 7-stage story spine method of writing compelling stories. It works. The stories are actually pretty good, and teach ICS better than the dry powerpoint presentations of FEMA. I have attached the ICS-100 story in raw CSV form, it's easy enough to read. This is taught with interactive questions and explanation if you get it wrong, which are also pretty good, but not attached.

    Thanks

    Bruce

--
You received this message because you are subscribed to the Google Groups "emergency_communications" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emergency_communic...@perens.com.
To view this discussion visit https://groups.google.com/a/perens.com/d/msgid/emergency_communications/rmieclmpilu.fsf%40s1.lexort.com.

--

Bruce Perens K6BP

[Greg Troxel]

"'Stuart Longland' via emergency_communications"
<emergency_co...@perens.com> writes:

> The hardest bit here I think are the cases when:
>
> - Node X was there an hour ago, but isn't reachable now, will it come
> back, is it being moved, or is it gone for good?
> and
> - Node Y is unknown, where does it fit in to the connectivity graph?

The first case is hard. The second, I think is easy: you don't know
anything, so it's unreachable. But you're saying "node", which is a
network address, vs a name that is the recipient of a message, and
getting clarity about names and addresses is the first step in thinking
about this.

> Sleepy end devices in Thread didn't handle the latter case at all, but
> they handled the former by first "attaching" themselves to a parent
> router node, then informing the parent that they were going to sleep
> for X seconds. The parent would then store messages for the child and
> pass them on when the child woke up.
>
> https://openthread.io/guides/thread-primer/node-roles-and-types#minimal_thread_device
>
> The simplification here is that "end devices" do no routing in Thread.

I think that is too limiting an assumption here. It makes sense in a
mostly online Thread world. How well do Thread systems deliver messages
when the power fails and the controller is on UPS but most of the
nodes-that-route are down? My guess is quite badly and nobody worries
about that.

> In contrast, in this system we expect the offline node to pick up a
> message when it returns, and then forward it on when it is able to. I
> feel like an automatic routing system should preference online nodes
> over offline ones in the interests of keeping things moving, and only
> failing back to offline nodes if there is no other choice or the user
> really insists on it.

Fair points, but online/offline are shades of grey when you have nodes
that are long-term up but which disconnect/reconnect on schedule. Once
you admit DTN concepts (keeping concept and protocol separate), you are
ok with things that come and go if you think it will lead to timely
enough delivery, and there's lots of caveats there!

> Even harder is when a node operates rogue. The last thing you want is
> a node that "ACKs" your message with a promise to forward it on, and
> intentionally drops it in the bit bucket.

The usual approaches are

have a set of authorized nodes, with that enforced by some kind of
PKI, group key, etc., combined with some form of validation and a
revocation mechanism

"byzantine-resilient protocols", almost entirely theoretical (but a
significan sub-area of computer science).

> I think NASA's ION-DTN system seemed to wait until it received an ACK
> from a hop beyond, which unless you had a lot of rogue nodes in the
> chain, could theoretically fall back to a different route and retry in
> that situation.

interesting partial approach to detect one bad node assuming the rest
are ok (not a crazy part of the space to carve out)

> In this case, we'd also need some check that the forwarded ACK was
> authentic, something like the COSE (RFC 8152) Sign and Sign1 objects,
> lest the ACK was forged.

Once you start down this path you need signatures, which cost compute
time, energy to computer, and take up bits in messages.

I see no rules problem with signatures in Amateur Radio.

> I'm wondering if we maybe should use a hybrid system: dynamic routing
> for quick registration of new and mobile nodes with a timed expiry,
> and the option of static routes on select nodes which allow for those
> "special cases" to be configured?
>
> Possibly also a "trust" concept too, so signed "certificates" that
> allow preferring of trusted nodes over untrusted ones?

Interesting thoughts. I would lean to estimating probabilities that
nodes will return based on the past, and trying to co-evolve routing
schemes and operational practice.


In writing proposals to the government, this would end up with writing
requirements and then writing a story about how the system is used,
labeled "concept of operations". Do people operate mostly powered
down, turn on a radio and expect to connect quickly and send messages,
and get messages intended for them? Or do they expect to set up a relay
node semi-long term and have it operate over several hours to days?

How people with phones/laptops connect to the node to inject/pickup
messages is separate; this is sort of "how does the SMTP server
operate", not "how does your MUA connect to your server". That
statement has assumptions about naming backed in, that you are using a
name that belongs to the server you are with.

[Greg Troxel]

I will respect your judgement that the likelihood will find the copying
done by LLMs to be infringing is near zero. (I see that as capture of
the political system by large companies, demanding the opposite of what
they used to demand in prosecuting small-scale copiers.)

That doesn't change my moral judgement, and I am not inclined to
participate in that part.


Separately from any legal/moral issues, I see the questions of
naming/addressing/requirements as critical steps that are not amenable
to LLM-based solution. Getting the system architecture right enough
will be key to building something that can adapt and have long-term
usefulness. I tried to list things with a lot of TBD recently.

I am at this point unclear on your larger scale plan.