public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed
* Automatic routing: Thoughts, Questions, and Designs
@ 2023-10-12 16:54 John Goerzen
2023-10-31 8:43 ` Sergey Matveev
0 siblings, 1 reply; 2+ messages in thread
From: John Goerzen @ 2023-10-12 16:54 UTC (permalink / raw)
To: nncp-devel
Hi,
I am making up some plans for developing an automatic routing system for
larger-than-personal NNCP systems.
The basic idea is that nodes can use nncp-exec to automatically
distribute updates about the immediate peers they know of, and what
nodes those peers can route for, to their peers. This would let any
given node compute the single next step for a packet (one entry in
-via), or, alternatively, the entire path to a destination (-via with
many items).
I hope to code this up before long and test it locally.
The ultimate idea is that NNCP users should be able to send email to
username@NODEID•nncp without having to have previous knowledge of it or
direct knowledge of how to route a packet there. This is helped by the
current ability of NNCP to let you either specify an entire end-to-end
path in -via, or to specify a partial path (eg, just to the next hop,
and that hop calculates further hops).
Already without changes in NNCP, I can, therefore, support automatic
routing where the destination is known to us, even if many of the
intermediaries are not (subject to a caveat about route calculation
below).
Question: if a destination is not given in nncp.hjson, but its -via step
is, can we send a packet to it simply by giving its full node ID as the
destination? That is, if the node ID is the public key, that should
theoretically work, right?
Now in order for this all to really work, at least in the "receive mail
from strangers" sense, there are two missing pieces. The first is being
able to receive packets from unknown nodes. Maybe a catch-all default
in the "neigh" section? (This would be similar to the support that
already exists in the multicast area setup).
I almost wonder if we could work around this if everyone has the same
multicast area defined, with an empty subs, and then could run commands
like this:
nncp-file -via smarthost,desthost file.txt gloablarea:file.txt
The idea here is that nothing realizes it's an area packet except the
desthost. I'm not sure if this actually works this way though.
The second missing piece is sort of an optional nice-to-have. Having
this bolt-on tool is easy enough to use when generating a nncp-exec or
nncp-file command line. Because we could just use -via to the first hop
and trust that hop to figure out the rest of the path, no mods to
nncp.hjson would be necessary on the originating node.
But at the next hop, there's the problem of there being no easy way to
drop in a custom routing decision. We'd have to generate and maintain
many, many entries in nncp.hjson.
The workaround is to distribute deep pictures of the network from each
node to its peers, so the originating node would generate the entire
-via path, end to end. That works, but is significantly less efficient
at a large scale. But I could certainly prototype something along these
lines.
In short, there's a lot I can do within NNCP's existing system. The
goal would be to expand on what I'm doing with quux, to make it more
distributed and replicable to other hub nodes -- maybe even publish a
Docker container or something for those that want to easily stand up a
NNCP public peer somewhere.
- John
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Automatic routing: Thoughts, Questions, and Designs
2023-10-12 16:54 Automatic routing: Thoughts, Questions, and Designs John Goerzen
@ 2023-10-31 8:43 ` Sergey Matveev
0 siblings, 0 replies; 2+ messages in thread
From: Sergey Matveev @ 2023-10-31 8:43 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 2209 bytes --]
Greetings!
Unfortunately I can not answer any of that right now. I have never ever
thought about routing automatisation/easiness. NNCP was never intended
to do that kind of things. Being friend-to-friend in my opinion means
that no "automagic" routes/neighbours distribution occurs -- human has
to explicitly make all required decisions. I mean I am not against that
kind of things, but at first glance do not sympathise that features,
ignorant to them.
>The ultimate idea is that NNCP users should be able to send email to
>username@NODEID•nncp without having to have previous knowledge of it or
>direct knowledge of how to route a packet there.
In my opinion that is exactly what (completely) distributed networks do,
peer-to-peer ones with automatic peer discovery. And in my views that
some kind of opposes friend-to-friend network, where you have to
explicitly set authentication/trust/knowledge about each peer. NNCP was
not designed with such things in mind. I do not want to say that it is
impossible with current design decisions, but personally I would not try
to implement distributed network with peer's (routing) autodiscovery on
top of existing implementation, but would redesign it from scratch
probably.
>Question: if a destination is not given in nncp.hjson, but its -via step
>is, can we send a packet to it simply by giving its full node ID as the
>destination? That is, if the node ID is the public key, that should
>theoretically work, right?
No, because node's ID is a hash of node's signing public key. Even if it
was (actually they have got the same length) the signing public key
itself, each node also has "exchpub" key (curve25519 public key that is
used in Diffie-Hellman key agreement to derive shared encryption key for
packet encryption). Using of hash(signpub) instead of signpub is not
necessary step, just used to more uniformly distribute ID's value at
256-bit value space. If node's ID will be concatenated 512-bit
"exchpub"+"signpub", then it could be used to immediately create
outgoing packet to that node indeed.
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2023-10-31 8:44 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-12 16:54 Automatic routing: Thoughts, Questions, and Designs John Goerzen
2023-10-31 8:43 ` Sergey Matveev