On 3/15/22 7:04 PM, meff wrote:
> Yes from my understanding, this should be fairly trivial with UUCP
> as well. You can always pipe UUCP payloads to a verifier which drops
> unverified payloads.

Yep.

uux makes it even easier. STDOUT of the sending side into uux which
will send that into the STDIN of gpg on the receiving side. :-D

--
Grant. . . .
unix || die

In article <t0r6vv$8rv$1@tncsrv09.home.tnetconsulting.net>,
Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>On 3/14/22 8:24 AM, Dan Cross wrote:
>> Good. Then could we please stop discussing the suitability of FTN
>> for this kind of thing?
>
>Okay.
>
>> IP is literally a store and forward networking protocol, though
>> it could be configured to communicate only with directly
>> connected hosts (ie, with no routing).
>
>IP is not a store and forward networking protocol.

This is simply incorrect.

>There is no persistent storage for IP.

First, whether or not there is "persistent storage" for IP
datagrams transiting a network is an implementation detail.

Second, there is no persistent storage requirement for some
network to be based on store-and-forward techniques.

Store-and-forward simply means that a logical "packet" of data
is completely received via some intermediate node in the network
before being forwarded to the next hop en route to the eventual
destination.

>Buffers, which /may/ be used for a very
>short period of time are transient at best.
>
>IP functions as a transport mechanism between two endpoints that may or
>may not be directly connected to each other. The nature of how IP works
>requires that all of the necessary routing segments be online and
>operational between two IP endpoints /at/ /the/ /same/ time.

That's not true at all, either in theory or in practice.

Segments go down all the time, and datagrams may be routed
across any number of paths between two nodes. Further, the
network may be completely partitioned for some period of time;
IP could care less. If a path between nodes is re-established
before some higher-level protocol times out, it doesn't matter.
TCP connections have been known to remain in the "established"
state for _days_ in the face of a partition.

>Conversely UUCP can easily exchange files without there ever being
>end-to-end connectivity at the same time. UUCP only requires that each
>pair of nodes be able to communicate and exchange files. A & B can
>exchange files while B can't talk to C. B & C can exchange files while
>B can't talk to A. A & C never have the ability to perform end-to-end
>communications. This works perfectly fine with UUCP. IP will never
>suffice without something (like UUCP / FTN / MQueue / ftp / etc.) on top
>of it to exchange files.

You seem to be conflating two related, but separate, things: the
physical transport used in some network, and the protocols that
use that transport. Here, one could usefully compare UUCP with
SMTP and HTTP or something similar, and IP versus a data stream
over a telephone line via e.g. a modem.

>B in this example could be a notebook / files on a flash drive / cd-rom
>/ etc that is physically transported between A's location and C's location.

Perhaps I naively assumed it was obvious from context, but the
whole point of providing IP connectivity in this sort of
scenario would be to support higher-level protocols like those
mentioned above.

>[snip]
>> What would this hypothetical network be used for, otherwise?
>
>non-real-time communications; email, file transfer, etc.
>
>Technically you could request web pages through it. Though the latency
>would be ... painful. This would work through multiple out and back
>cycles and / or out, package, and back cycle where the packaging deduces
>the necessary supporting files (image, CSS, etc.) in support of the
>requested file / page.

You misunderstand me. What would be the point of this network?

If I may be blunt, you're fixating on specific technologies and
their hypothetical potential to "communicate" without
considering why people might want to use them or how they'd like
to communicate. That's not terribly useful.

>> So does UUCP/FTN/whatever else. For that matter, so does the PSTN.
>> Those cell towers and copper pairs connect to something.
>
>The crux is that IP needs all the elements of the path to be up at the
>same time for end-to-end communications. Conversely UUCP only needs the
>path elements between adjacent nodes. (See the A - B - C example above.)

See above.

>> One generally needs digipeating for coverage, even in a geographically
>> isolated area.
>
>Maybe. Probably.
>
>What if instead of digipeating the repeater node actually received the
>files a la. UUCP, stored them, and then forwarded them on to the next
>node. You end up breaking the A - B - C /multi-hop/ communications path
>into two /single-hop/ communications paths that don't need to be
>available at the same time.
>
>This single vs multi hop becomes more of an issue as you integrate more
>hops.

This seems very confused.

With modem-based communications of any kind, you need the
receiving end to actually answer the phone. Since telephony
systems are circuit-switched, that means that both ends and all
intermediate steps within the phone system have to be online in
order to establish a connection to exchange data. That those
systems can then independently exchange data with other systems
is irrelevant.

Incidentally, this is also how AX.25 mailers pretty much already
work. Here, you're simply avoiding the reliance on exiting
infrastructure.

>> AX.25 mailers can already do this.
>
>Fair enough.
>
>Substitute AX.25 in place of UUCP. Well save for the fact that AX.25
>equipment is more specialized than UUCP equipment.

A $35 HT you can buy on Amazon and a rasperry pi is hardly
"specialized". The software is trivial to install on the Linux
distribution of your choice. In contrast, good luck finding a
modem if you want to use a landline, and one hopes those burner
phones have modems built in.

>> So is a telephone exchange, which you have been arguing for pretty
>> strenuously. This argument is not self-consistent with your earlier
>> arguments.
>
>It depends on the scope of view and if things are mobile or not. The
>town that I'm from had three separate telephone exchanges. If any one
>of them became unavailable, it was not impossible to travel across town
>to another location serviced by a separate telephone exchange.

Unless you get shot at doing so.

>If you want to consider the telephone exchange to be a link in A - B - C
>and expand it as such A - (eA)(eB) - B - (eB)(eC) - C.
>
>If A & B are on the same exchange and the exchange itself is down, then
>they are going to have a hard time using the phone to connect to each
>other. Fortunately there are other ways to get UUCP to communicate.

....such as?

>If A & B are on different exchanges, then perhaps the one on a dead
>exchange can move to a different exchange and be able to communicate
>with the other.
>
>Aside: Fortunately UUCP is not dependent on the source {address,phone
>number, port} /by/ /default/. As such, if A or B can move to other
>exchanges, they can quite likely connect and exchange files.

....and now you're back to this discovery issue. Phone numbers
are tied to exchanges. If you wish to send data to B, and the
exchange that B is connected to goes down, then B's number must
change. How does A know what the new number is?

>Further aside: digipeating will have similar dependencies in that you
>will be reliant on A's transceiver, both of B's transceivers, and C's
>transceiver all (four) being operational at the same time. Things only
>get worse as you add more hops.

What you are ignoring here is that radio is inherently a
broadcast medium. As such, any station that can hear A can
repeat to C.

As a technical aside, in the case of digipeating, since AX.25 is
based on packet switching, which is store-and-forward, B only
needs one transceiver.

>> Besides, with IP connectivity, one could start to do things like have
>> that VPS accessible via a VPN, or TOR, or....
>
>IP introduces more complexity and more vulnerability.

You'll have to back that up with specifics.

>> I'd love to hear examples of such BBSes that participate in FTN
>> networks.
>
>I believe the contemporary Synchronet and / or Citadel are effectively
>standard Unix / Linux packages that may gateway to FTN. I feel like
>there's another another major package that's effectively an FTN counter
>part to uucico, but I can't think of the name at the moment.

Yes, but the context (which was removed) is that these do not do
GPG.

>I find ftnapps/FTNd / ftncico on GitHub, but that's not what I'm trying
>to remember.

>> ...are you referring to my digipeater thing here?
>
>Not specifically a digipeater per se. Just any small computer being
>used for whatever small computers are used for. Either system B being
>physically carried between A and C in the example above, or the node
>connected to the B transceiver to receive, store, and forward files via
>UUCP, or anything else you want.

In article <BwVXJ.184493$SeK9.24445@fx97.iad>, meff <email@example.com> wrote:
>On 2022-03-13, Eric Pozharski <whynot@pozharski.name> wrote:
>> gtaylor@, please stop beating this dead horse. It becomes painful
>> (horse doesn't mind, it's already dead).
>
>I was too young during the BBS days to use a BBS, but I generally hold
>the opinion that those who are ignorant of history are doomed to
>repeat it. I think documenting FTN would be a good exercise if
>anything to help ambitious folks not recreate some of its foibiles in
>modern IP networks.

Well, there's http://ftsc.org/, which archives most of the
standards.

- Dan C.

On 3/16/22 9:03 AM, Dan Cross wrote:
> This is simply incorrect.

Please name one implementation of the IP protocol (v4 or v6) that will
store a packet, for at least multiple days, waiting for the next router
or endpoint to be serviceable again.

I'm explicitly talking about the IP protocol, not something that runs on
top of it that will retry subsequent connections when the previous
connection fails.

> First, whether or not there is "persistent storage" for IP datagrams
> transiting a network is an implementation detail.

It is extremely germane detail.

How is an IP system going to hold a packet for 14 days waiting on the
next router or remote system becomes available? Especially without
persistent storage and / or system reboots.

What you are suggesting is that an IP router (B) will hold an IP packet
from a different system (A) on it's way to yet another different system (C).

> Second, there is no persistent storage requirement for some network
> to be based on store-and-forward techniques.
>
> Store-and-forward simply means that a logical "packet" of data is
> completely received via some intermediate node in the network before
> being forwarded to the next hop en route to the eventual destination.

How is a router going to store an IP packet for one or more weeks?

> That's not true at all, either in theory or in practice.

I disagree.

Consider the following scenario: End systems A and E want to
communicate and the only physical and logical route is through the
intermediary routers B, C, and D.

[A]---[B]---[C]---[D]---[E]

A and E can not establish end-to-end communications with each other
without B and C and D being online and serviceable all at the same time
that A and E want to communicate.

With true store-and-forward, A and E can send messages / files to each
other as long as the following happens.

A generates messages / files to E

[A]---[B] [C] [D] [E] A sends messages / files to B

[A] [B]---[C] [D] [E] B sends messages / files to C

[A] [B] [C]---[D] [E] C sends messages / files to D

[A] [B] [C] [D]---[E] D sends messages / files to E

E processes messages / files from A

E generates messages / files to A

[A] [B] [C] [D]---[E] E sends messages / files to D

[A] [B] [C]---[D] [E] D sends messages / files to C

[A] [B]---[C] [D] [E] C sends messages / files to B

[A]---[B] [C] [D] [E] B sends messages / files to A

A processes messages / files from E

Notice how the only communications link that needs to be up at any given
time -- all be it in successive sequences -- are the two communicating
nodes.

A is able to send a message to E and E is able to send a reply back to A
over eight different cycles.

Note how A and E have zero hope of ever establishing an IP connection
with each other because there is no end-to-end connectivity between them.

> Segments go down all the time, and datagrams may be routed across
> any number of paths between two nodes.

That is predicated on their being alternate routes. As established
elsewhere in this thread, not all networks are flexible enough to allow
the re-routing.

> Further, the network may be completely partitioned for some period of
> time;

Yes.

> IP could care less.

IP cares greatly if there is only one path A/B/C/D/E and some part of
that path is always broken.

> If a path between nodes is re-established before some higher-level
> protocol times out, it doesn't matter.

That is a really big if. The risk of said if becomes exponentially more
risky as the number of digits in the number of seconds of the outage
duration goes up.

6 seconds, probably not a problem.
60 seconds, may or may not be a problem.
600 seconds, probably gong to be a problem.
6000 seconds, almost certainly going to be a problem.
60000 seconds, good luck

> TCP connections have been known to remain in the "established" state
> for _days_ in the face of a partition.

That "established" state is extremely fragile. If either end tries to
send one single byte, or even a heartbeat for a keep alive, while the
end-to-end connectivity is lost, its a matter of time before the
connection comes crashing down. Where the matter of time is a double,
or at best triple, digit number of seconds.

> You seem to be conflating two related, but separate, things: the
> physical transport used in some network, and the protocols that use
> that transport. Here, one could usefully compare UUCP with SMTP
> and HTTP or something similar, and IP versus a data stream over a
> telephone line via e.g. a modem.

I don't think so.

SMTP and HTTP rely on underlying protocols, namely IP.

UUCP provides it's own protocol and does not rely on any underlying
protocols.

Since both SMTP+IP and UUCP will require some physical link between
systems A & B, I'm ignoring the particulars about it for the moment.

Conceptually, at the 1,000 foot view, yes, UUCP / SMTP / HTTP move units
of information. But we are discussing things at the 100 foot if not 10
foot view. As such the differences between them are particularly important.

> Perhaps I naively assumed it was obvious from context, but the whole
> point of providing IP connectivity in this sort of scenario would be
> to support higher-level protocols like those mentioned above.

I figured that's what you were striving for.

I have naively assumed that A and E -- re-using my examples -- would be
the SMTP / HTTP client & server and B, C, and D would be IP routers.

Re-using my example, are you meaning that B, C, D, and E are SMTP / HTTP
clients & servers too? Thus meaning that B, C, and D are actually not
functioning as IP routers?

> You misunderstand me. What would be the point of this network?

To exchange information.

> If I may be blunt, you're fixating on specific technologies and
> their hypothetical potential to "communicate" without considering
> why people might want to use them or how they'd like to communicate.
> That's not terribly useful.

No, I'm not fixated on specific technologies. I'm fixated on specific
features / capabilities. I have gravitated towards specific
technologies that provide said features / capabilities.

The ability to exchange messages is the fundamental goal. I believe
that doing so is quite useful.

> See above.

Indeed, see above. How are A and E going to communicate when there is
no alternate path and the path between them always has at least one
segment down.

> This seems very confused.

I hope what I've outlined above with A, B, C, D, and E helps explain.

> With modem-based communications of any kind, you need the receiving
> end to actually answer the phone. Since telephony systems are
> circuit-switched, that means that both ends and all intermediate steps
> within the phone system have to be online in order to establish a
> connection to exchange data. That those systems can then independently
> exchange data with other systems is irrelevant.
>
> Incidentally, this is also how AX.25 mailers pretty much already work.
> Here, you're simply avoiding the reliance on exiting infrastructure.

AX.25, as I understand it, would probably be a good comparison to what
I'm describing with UUCP.

The down side is that (historically) far fewer people had access to
equipment necessary for AX.25 than did for UUCP.

> A $35 HT you can buy on Amazon and a rasperry pi is hardly
> "specialized". The software is trivial to install on the Linux
> distribution of your choice. In contrast, good luck finding a modem
> if you want to use a landline, and one hopes those burner phones have
> modems built in.

Perhaps you touch on a point that relates to my (historically) comment
above.

Yes, an inexpensive HT and a mobile computer may be easier to order open
market /today/. However I suspect that ordering something open market
is antithetical to the environment that we're talking about.

I still think that it's far more likely to find more modems in the
environment that we're talking about than it is HTs.

But as stated above, AX.25 and UUCP are mostly interchangeable in this
scenario. If anything, chances are good that the inexpensive HTs that
you're describing are going to be 2m / 440 or other relatively short
distance communications, maybe across town. As such, you are going to
be dependent one or more intermediate nodes.

> Unless you get shot at doing so.

I consider the possibility of getting shot at to mean that you are too
close to the active fighting.

> ...such as?

AX.25, null modem / IrDA if physically close enough, LoRA, sneaker net.

> ...and now you're back to this discovery issue. Phone numbers are
> tied to exchanges. If you wish to send data to B, and the exchange
> that B is connected to goes down, then B's number must change.

In article <t0tmeg$ut1$1@tncsrv09.home.tnetconsulting.net>,
Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>On 3/16/22 9:03 AM, Dan Cross wrote:
>> This is simply incorrect.
>
>Please name one implementation of the IP protocol (v4 or v6) that will
>store a packet, for at least multiple days, waiting for the next router
>or endpoint to be serviceable again.
>
>I'm explicitly talking about the IP protocol, not something that runs on
>top of it that will retry subsequent connections when the previous
>connection fails.

That's irrelevant. You are factually incorrect about the
definition of a store-and-forward protocol.

>> First, whether or not there is "persistent storage" for IP datagrams
>> transiting a network is an implementation detail.
>
>It is extremely germane detail.
>
>How is an IP system going to hold a packet for 14 days waiting on the
>next router or remote system becomes available? Especially without
>persistent storage and / or system reboots.
>
>What you are suggesting is that an IP router (B) will hold an IP packet
>from a different system (A) on it's way to yet another different system (C).

No, that is not at all what I am suggesting.

You have, bluntly, subscribed to a definition of what
"store-and-forward" means that is just wrong.

The rest of what you wrote, based on your incorrect assumptions,
is irrelevant.

>> Second, there is no persistent storage requirement for some network
>> to be based on store-and-forward techniques.
>>
>> Store-and-forward simply means that a logical "packet" of data is
>> completely received via some intermediate node in the network before
>> being forwarded to the next hop en route to the eventual destination.
>
>How is a router going to store an IP packet for one or more weeks?

Irrelevant based on incorrect assumptions.

>> That's not true at all, either in theory or in practice.
>
>I disagree.

You can disagree all you want, but that doesn't change reality.

>[deleted a bunch of hypotheticals based on false assumptions]
>
>Note how A and E have zero hope of ever establishing an IP connection

IP is not connection-oriented.

>[deleted more incorrect stuff]
>
>> If a path between nodes is re-established before some higher-level
>> protocol times out, it doesn't matter.
>
>That is a really big if.

This happens all the time, every day. It's one of the
foundational design principles of the Internet.

>[deleted more incorrect stuff]
>> You seem to be conflating two related, but separate, things: the
>> physical transport used in some network, and the protocols that use
>> that transport. Here, one could usefully compare UUCP with SMTP
>> and HTTP or something similar, and IP versus a data stream over a
>> telephone line via e.g. a modem.
>
>I don't think so.

Again, you can disagree, but that doesn't make you right.

>SMTP and HTTP rely on underlying protocols, namely IP.

Yes. And usually TCP.

>UUCP provides it's own protocol and does not rely on any underlying
>protocols.

This is trivially incorrect. UUCP relies on some kind of
transport: either TCP/IP if transiting over the Internet, or
some kind of data stream provided by a modem or similar device
(or any number of other potential transports, but let's make it
easy on ourselves). That data stream runs over something like
an analog phone line.

How do you suppose those work, if not being based on
"underlying protocols"?

>Since both SMTP+IP and UUCP will require some physical link between
>systems A & B, I'm ignoring the particulars about it for the moment.

Which is why your arguments throughout this thread fall have not
held.

>[snip]
>Re-using my example, are you meaning that B, C, D, and E are SMTP / HTTP
>clients & servers too? Thus meaning that B, C, and D are actually not
>functioning as IP routers?

If two nodes in an internetwork want to exchange data, they
first agree on some protocol to do so; let's assume HTTP as an
example. Further, let's assume its usual configuration of
sending that data via TCP/IP. To send data via HTTP, one first
creates a TCP connection, which is a logical abstraction, which
relies on transferring IP datagrams between the two nodes.

Those datagrams can be routed by a number of intermediate
routers along any available path between those two nodes. At
each such "hop", the datagram is read and buffered (stored),
examined for errors, and then (usually) forwarded towards the
intended destination by that router according to its internal
routing tables: this is what "store-and-forward" means.

Note that it has nothing inherently to do with persistent
storage.

Once the connection is established (standard SYN, SYN-ACK, ACK
"three-way handshake"), the higher-level protocol transfers
data in accordance with its semantics. The TCP will break up
the data stream produced by HTTP into "segments" that are
transferred via IP datagrams; again, these can be routed along
any viable path between the nodes. Once the two endpoints are
done with the exchange, they (usually) tear down the underlying
TCP connection. The implication is that the connection is
resillient in the face of intermediate failures while the
connection is established, given a sufficiently robust
underlying networkd, and the endpoints are oblivious of
intermediate failures while not actively exchanging data.

In the case of the Internet, we generally have a very robust
underlying network. In a conflict sort of scenario, the
challenge would be to provide that robust substrate. This can
be done by any number of means; for instance, one could even
layer IP on top of AX.25 (this is commonly done in the amateur
radio community), or use more robust protocols like ARNGLL
(https://github.com/arngll/) over RF (note: we're still working
on ARNGLL).

Note that the establishment of the TCP connection is
conceptually similar to the establishment of a circuit in a
switched network, like the PSTN: mostly these days, that means
a protocol like SS7 once you get past the copper loop to the
end DCE (for, e.g., a landline "POTS" telephone). Transfer of
data using a higher level protocol, like any number of UUCP
protocols (g-, f-, t-; whatever) are much more conceptually
closer to HTTP.

Unlike with IP, the ability to build ad-hoc telephony networks
is rather more limited, since they are much more specialized.
It's unclear why one would prefer something like that to IP
anyway.

>> You misunderstand me. What would be the point of this network?
>
>To exchange information.

To what end? This is critical. See below.

>> If I may be blunt, you're fixating on specific technologies and
>> their hypothetical potential to "communicate" without considering
>> why people might want to use them or how they'd like to communicate.
>> That's not terribly useful.
>
>No, I'm not fixated on specific technologies. I'm fixated on specific
>features / capabilities. I have gravitated towards specific
>technologies that provide said features / capabilities.
>
>The ability to exchange messages is the fundamental goal. I believe
>that doing so is quite useful.

Yes, but you haven't articulated the parameters around which you
would like this to be used. The ability to communicate is
useful only insofar as the participants in the communication
actually have useful data to exchange. Two people coming up
with some elaborate protocol to drive to coffee shops and dial
up different phone numbers with netbook computers could just
talk on the phone, or meet in a park. Or do SLIP or PPP over
that dialup connection.

>> See above.
>
>Indeed, see above. How are A and E going to communicate when there is
>no alternate path and the path between them always has at least one
>segment down.

They're obviously not; the same as with any communications
mechanism. The same would be true of telephony switching, or
jammed (or just out of range) RF, or for message couriers if all
the physical routes beteen A and E were destroyed or impractical
to use.

So you've constructed a strawman to prove a non-sequitur. But
so what?

>> This seems very confused.
>
>I hope what I've outlined above with A, B, C, D, and E helps explain.

No sorry; if anything, that seemed to be based on some pretty
fundamental misunderstandings of the underlying technology.

>> With modem-based communications of any kind, you need the receiving
>> end to actually answer the phone. Since telephony systems are
>> circuit-switched, that means that both ends and all intermediate steps
>> within the phone system have to be online in order to establish a
>> connection to exchange data. That those systems can then independently
>> exchange data with other systems is irrelevant.
>>
>> Incidentally, this is also how AX.25 mailers pretty much already work.
>> Here, you're simply avoiding the reliance on exiting infrastructure.
>
>AX.25, as I understand it, would probably be a good comparison to what
>I'm describing with UUCP.
>
>The down side is that (historically) far fewer people had access to
>equipment necessary for AX.25 than did for UUCP.

*CUT*

Guys, this isn't healty. Consider redoing all this ping-pong in OSI
model.

--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

with <t0r75v$8rv$2@tncsrv09.home.tnetconsulting.net> Grant Taylor wrote:
> On 3/12/22 5:57 AM, Eric Pozharski wrote:

>> You two are avoiding one significant point of the puzzle. UUCP is
>> fine to move articles and files around. It doesn't handle
>> subscription.
> Please elaborate on what you mean by "subscriptions" in this context.

(Well, seems like you can't stop beating this dead hosrse.) Anyway, The
Apeal is about experience. Here how it looks like, most elaborate
example.

Wanabe Sysop (aka a Point, aka FTN-Compatible Sysop) sends netmail to
their Boss (aka Sysop) with To set to special AreaFix nick (nicks are
arbitrary, routing is concerned with addresses) with a line '%AVAIL'.
Then waits.

Meanwhile, AreaFix (at the Boss) sends '%AVAIL' requests to AreaFix'es
to all its peers. Then waits.

Eventually, replies from peers are somehow pressed into something that
roughly may be interpreted as a reply.

Then the Point receives more or less (mostly more) copious list of
echos. Now comes most exciting part. The Point goes through couple of
thousands of malformed lines. And they must be careful what they pick
-- there are echos sources from different networks, regions, and zones
(potential to cause fatal drama (potentianlly, international); such
drama will be fatal to the Point, because noone gives a fsck about
points), unreachable (physically) flea markets, and echos some bosses
keep to deal with their points. When desired echos are picked, then
list is sent to the AreaFix again. Then Point waits.

Now the Areafix sends subscription requests to its peers, and then
waits.

Then, eventually, a message comes through this creates echo locally thus
enabling the Point to achieve The Conversion Experience. However,
sometimes initiating message never comes (like I can see FTN traffic in
Usenet, subscription succeeds (I can verify, I'm subscribed), and
nothing happens).

If you don't see experience, then I don't know what experience is.

Something alike is FileEcho's (different robot -- 'FileFix', and
somewhat different mechanics). However, I hadn't no ability then
reasons then chance to use it (for many different reasons), thus I
can't describe it myself.

> I believe that something like news server exchanging things via UUCP
> would provide /a/ subscription type model. What I'm not sure of is if
> it would match what you mean by subscriptions in this context.

Well, looking how this thread is developing I'll better abstain.

--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

On 2022-03-17, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> Let me be clear about what I've been saying in this thread, as
> it appears to have been muddled:
>
> * IP is a good protocol on which to base a clandestine
> communications network in an occupied or active conflict
> situation.
> * The PSTN, and telephony in general, is not a viable
> alternative to IP networks in this context.
> * BBSes and FTN are poorly suited and best avoided.
> * UUCP is acceptable, but has limitations related to the
> underlying transport; this transport issue cannot be ignored.
> * Packet radio using e.g. AX.25 or APRS is probably the simplest
> and most robust mechanism for establishing a communications
> channel. Noteably, one can use TCP/IP over AX.25.
> * Unattended, cheap, throw-away digipeaters can be used to
> extend range and coverage.
> * In this sort of scenario, it is important to focus not so much
> on the technology but on the use cases and environment. The
> details, and getting them right, is critical to effective and
> useful communications.

Indeed and now that I think about it, offering PPP over a link and
then sending your message to a mailserver over SMTP/IP is a very
simple thing to do in the hypothetical situation both of you have been
discussing. That way you can still use your Raspberry Pi or laptop's
MUA to send mail and then have the MTA deal with the long-term storage
and forwarding.

On 3/17/22 8:50 AM, Dan Cross wrote:
> That's irrelevant. You are factually incorrect about the
> definition of a store-and-forward protocol.

Why don't you share the definition that you're using for store-and-forward.

I'm using the following definition for store-and-forward networking:
Something receives a message from a sender, stores it for some (possibly
indeterminate) amount of time, and then sends it to the next system in
the path at some point in the future.

> IP is not connection-oriented.

Pick any higher transport layer protocol that want and it will still
fail to establish communications when there is not an end to end path
for IP to take.

> This happens all the time, every day. It's one of the
> foundational design principles of the Internet.

There are many connections that fail to establish or die on a daily
basis too.

> This is trivially incorrect. UUCP relies on some kind of
> transport: either TCP/IP if transiting over the Internet, or
> some kind of data stream provided by a modem or similar device
> (or any number of other potential transports, but let's make it
> easy on ourselves).

UUCP provides it's own protocol that rides on the underlying physical
serial port transport; be it null modem cable or modem or IrDA. There
is nothing that interposes itself between UUCP and what UUCP sees as the
physical hardware.

> That data stream runs over something like an analog phone line.
>
> How do you suppose those work, if not being based on
> "underlying protocols"?

Both UUCP and IP are going to have the same requirement for some
physical connection and the associated physical signaling. Ergo the
same variables can be eliminated from both sides of the equation.

> Those datagrams can be routed by a number of intermediate
> routers along any available path between those two nodes. At
> each such "hop", the datagram is read and buffered (stored),
> examined for errors, and then (usually) forwarded towards the
> intended destination by that router according to its internal
> routing tables: this is what "store-and-forward" means.
>
> Note that it has nothing inherently to do with persistent
> storage.

And what does the router do with the packets if the next hop is offline
for an extended period of time (> 300 seconds)? It drops them.

> Once the connection is established (standard SYN, SYN-ACK, ACK
> "three-way handshake"), the higher-level protocol transfers
> data in accordance with its semantics.

And what happens when there is no end-to-end path for the end systems to
establish a connection?

> The implication is that the connection is resillient in
> the face of intermediate failures while the connection is established,
> given a sufficiently robust underlying networkd, and the endpoints are
> oblivious of intermediate failures while not actively exchanging data.

That is predicated on a robust underlying layer. Which I've explicitly
stated does not exist in the examples that I've provided.

> In the case of the Internet, we generally have a very robust
> underlying network. In a conflict sort of scenario, the
> challenge would be to provide that robust substrate. This can
> be done by any number of means; for instance, one could even
> layer IP on top of AX.25 (this is commonly done in the amateur
> radio community), or use more robust protocols like ARNGLL
> (https://github.com/arngll/) over RF (note: we're still working
> on ARNGLL).

This too is predicated on the ability to establish multiple paths. (See
my prior statement.)

> Note that the establishment of the TCP connection is
> conceptually similar to the establishment of a circuit in a
> switched network, like the PSTN:

TCP, like the PSTN, is dependent on a path from end system (A) and the
destination system (E). If any one (or more) of the links is down the
TCP connection / PSTN switched circuit can't be established.

> Yes, but you haven't articulated the parameters around which you
> would like this to be used. The ability to communicate is
> useful only insofar as the participants in the communication
> actually have useful data to exchange. Two people coming up
> with some elaborate protocol to drive to coffee shops and dial
> up different phone numbers with netbook computers could just
> talk on the phone, or meet in a park. Or do SLIP or PPP over
> that dialup connection.

Talking, be it on the phone or in person, is a poor communications
medium, especially if you need to exchange many pieces of information.
This is compounded by the desire / need to exchange other types of data,
images, programs, audio recordings, etc. which are in electronic
formats. UUCP, SLIP, or PPP are much better at that.

SLIP or PPP can be used ad-hoc as you suggest. However that will not
provide end-to-end connectivity between A and E. SLIP and PPP will be
much more akin to the node to node to node connection that UUCP will
provide.

> No sorry; if anything, that seemed to be based on some pretty
> fundamental misunderstandings of the underlying technology.

Please elaborate.

> The Russian army is literally running around with cheap HTs of
> the kind I'm suggesting buying off of Amazon.

What does what the Russian army is using have to do with what citizens
will be able to get their hands on? Or are you suggesting that they get
them from the Russian army?

> But you're advocating burner phones and notebooks using UUCP.
> In the sort of environment we're talking about, where do you
> suppose you're going to find those?

I expect that there are (or were) many such burner phones in region already.

I'm able to buy burner phones or SIM cards from most gas stations. As
such, I'm expecting that there are (or were) many similarly available in
the area.

With this in mind, I suspect that burner phones or SIM cars are much
easier to come by than HTs.

> How, precisely, do you think that cell phones work?

Voice and modem calls will view the cell phone the same. They will also
view the PSTN the same way.

In short, the cell will be a short distance link to the PSTN for a
longer distance connection.

HTs won't have the benefit of the PSTN to make a longer distance connection.

I'm ignoring auto-patches for the time being.

> Then what is this communications network you are proposing to be
> used for?

To get information into and out of the larger area.

What are communications in an ARES emergency net for?

> Why not just throw WiFi in the loop and use TCP/IP and call it a
> day?

If you are in proximity and can do that, then do so.

PSTN and even AX.25 will probably be able to go further than consumer WiFi.

> Interestingly, these are all protocols that would also support
> IP.

See above comment about ad-hoc IP networks.

> Furthermore, they're all protocols; something you said above was not
> needed for UUCP because UUCP has its own protocols.

AX.25, null modem / IrDA, LoRA, and sneaker net form the physical layer
to connect two systems. -- I acknowledged that a physical connection
of some sort was needed.

> But that's the central technical challenge _you_ need to solve
> if these hypotheticals you've been throwing around are to
> actually be useful.

Just about any form of communications can be boiled down to files to be
exchanged. Size of files really translates to amount of storage needed
on the transmitting & receiving systems and duration of transmission.

> But the numbers are changing all the time.

I had been presuming that a phone number would change no more frequently
than every three days.

If you want to use a different line in the sand for discussion, so be
it. Please suggest such a time.

> Suppose A's number changed at the same time as B's.

Valid concern.

> Suppose B doesn't have access to an exchange at all. Suppose A isn't
> in the coffee shop with the modem ready to answer when B tries to call.
> Suppose....

The intention is that B will re-try the call at a later point in time
when hopefully A is at $LOCATION and ready to answer.

> These are _all_ problems you _have_ to solve to realize any sort
> of useful communications network.
>
> You keep focusing on linear paths between stations and
> constructing hypotheticals around that. Once you get over this
> fixation on "paths", and you can start thinking about creating
> other, more robust topologies.

More robust typologies are far superior. But in my experience, it's
best to plan for the worst and hope for the best.

> You're taking a statement too literally. Perhaps I should have
> written, "can potentially repeat to...". I naively assumed that
> was clear from context.

In a discussion about when various systems are online and offline at the
same time, I think that's a fairly big assumption.

On 3/17/22 3:53 PM, meff wrote:
> Indeed and now that I think about it, offering PPP over a link and
> then sending your message to a mailserver over SMTP/IP is a very
> simple thing to do in the hypothetical situation both of you have been
> discussing. That way you can still use your Raspberry Pi or laptop's
> MUA to send mail and then have the MTA deal with the long-term storage
> and forwarding.

Yes, having an SMTP server (or comparable functionality) on each side of
a physical link (SLIP / PPP / UUCP / AX.25 / IrDA / etc.) is a viable
option.

The SMTP server actively receives the message, take responsibility for
it, and will ((RFC) SHOULD persistently) store the message until it can
pass the message to the next system in the link.

Node A can use SMTP to send a message to node B. Where in node B will
hold onto the message until some point in the future when node C is
available at which point node B will send the message to node C. Thus
node A has communicated with node C even though they were never online
at the same time.

--
Grant. . . .
unix || die

On 3/17/22 11:11 AM, Eric Pozharski wrote:
> Wanabe Sysop (aka a Point, aka FTN-Compatible Sysop) sends netmail to
> their Boss (aka Sysop) with To set to special AreaFix nick (nicks are
> arbitrary, routing is concerned with addresses) with a line '%AVAIL'.
> Then waits.
>
> Meanwhile, AreaFix (at the Boss) sends '%AVAIL' requests to AreaFix'es
> to all its peers. Then waits.

Okay. It sounds like '%AVAIL' propagates out multiple degrees; 1st
point to node; 2nd node to nodes.

How many degrees out does the '%AVAIL' go? Is there a limit? Or is it
until it floods to all nodes in the FTN in question?

> Eventually, replies from peers are somehow pressed into something
> that roughly may be interpreted as a reply.

ACK

> Then the Point receives more or less (mostly more) copious list
> of echos.

If the point receives a reply from each remote node that responds to the
'%AVAIL', I can see how that can be a lot of responses.

> Now comes most exciting part. The Point goes through couple of
> thousands of malformed lines.

I'll believe it.

> And they must be careful what they pick -- there are echos sources from
> different networks, regions, and zones (potential to cause fatal drama
> (potentianlly, international); such drama will be fatal to the Point,
> because noone gives a fsck about points), unreachable (physically)
> flea markets, and echos some bosses keep to deal with their points.

I can see how a point has a potential to cause ... problems by
requesting something that disrupts the network.

> When desired echos are picked, then list is sent to the AreaFix again.
> Then Point waits.

ACK

> Now the Areafix sends subscription requests to its peers, and then
> waits.

ACK

> Then, eventually, a message comes through this creates echo locally
> thus enabling the Point to achieve The Conversion Experience. However,
> sometimes initiating message never comes (like I can see FTN traffic
> in Usenet, subscription succeeds (I can verify, I'm subscribed),
> and nothing happens).

Okay.

> If you don't see experience, then I don't know what experience is.

;-)

> Something alike is FileEcho's (different robot -- 'FileFix', and
> somewhat different mechanics). However, I hadn't no ability then
> reasons then chance to use it (for many different reasons), thus I
> can't describe it myself.

Fair enough.

> Well, looking how this thread is developing I'll better abstain.

It seems to me like AreaFix / FileFix automate the process of what I
consider to be newsgroup subscription management. What's more is that
it seems like an off system (point) can initiate an automated change on
a parent (point's upstream node) and maybe even remotes (parent's peer
node(s)).

I'm not aware of any automated subscription management on news servers /
Usenet. In news servers / Usenet, this amounts to an email to the peer
news master(s) asking them to alter the feed.

--
Grant. . . .
unix || die

On 2022-03-04, Oregonian Haruspex <no_email@invalid.invalid> wrote:
>
> Looks like we’re going back to the Kremvax days.
>

I2pd it's an interesting alternative to avoid that.

They have several Russian servers on the IRC proxied
servers (two), but one of the two it's almost Russian
language based.

They have an NNTP server, too. Setting up i2pd is not
dark magic, I can write a guide if anyone wants.

On 2022-03-05, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
> On 3/4/22 5:51 PM, meff wrote:
>> How does this affect Usenet?
>
> It depends.
>
>> Have any prominent providers stopped allowing access from Russian
>> IPs or ASNs?
>
> What do you consider "prominent providers" to be.
>
> Cogent, a major backbone / connectivity provider is de-peering Russian
> clients. So there is a good chance that Internet connectivity between
> parts of Russia and other parts of the world will be less reliable if
> not out & out broken (if more providers follow suit).
>
> Other big names in tech, particularly social media, are blocking Russian
> clients.
>
> We are witnessing what may be the first steps of a significant fracture
> of the Internet, and thus in many ways, Usenet. The coming days / weeks
> will show ho significant the fracture will be.
>
>
>

I2Pd has news servers accesible from any client (Pan, XNews, SLRN).
It's just a matter of setting up a tunnel and configuring the news
client to that localhost listening port.

On 2022-03-05, Scott Dorsey <kludge@panix.com> wrote:
> Retrograde <fungus@amongus.com.invalid> wrote:
>>
>>How do you know Usenet isn't accessible in Russia? Not doubting you,
>>just trying to figure out if it's true.
>
> Usenet is hardly accessible at all anywhere. Used to be every ISP had
> a fast local server, now basically everyone is on a handful of big servers
> and that kind of defeats the whole purpose.
> --scott

That newsgroup it's perfectly accesible via I2P/i2Pd by setting
up a custom config for any NNTP client pointing to a localhost
proxy config. Setting up an NNTP tunnel on i2pd it's almost cloning
the IRC one and chaging down the server URL and the
source/dest ports.

RetroBBS and friends provide an I2P address on Rslight or
whatever is called, can't remember it now well, but
I can tell that Russians won't get isolated.

Grant Taylor <gtaylor@tnetconsulting.net> wrote:
> On 3/17/22 8:50 AM, Dan Cross wrote:
>> That's irrelevant. You are factually incorrect about the
>> definition of a store-and-forward protocol.
>
> Why don't you share the definition that you're using for store-and-forward.
>
> I'm using the following definition for store-and-forward networking:
> Something receives a message from a sender, stores it for some (possibly
> indeterminate) amount of time, and then sends it to the next system in
> the path at some point in the future.

It appears that you two are talking past one another.

Dan is conflating store and forward packet switching with store and
forward networking and believing that both mean the same thing and then
arguing that IP is a store-and-forward system (without any qualifiers
to indicate what subset he is referencing).

While some IP switches/routers can operate in a store-and-forward mode
(whole IP packet is first received into memory before the header is
analyzed to determine which link to transmit the IP packet, then the
packet is transmitted (or dropped) depending upon the header analysis)
this is not a requirement of IP networking. It is also possible, and
many very high performance switches/routers do, for the switch/router
to analyze the headers as they are received off the line, decide where
to send the packet, and begin transmitting the packet on the outbound
link while the remainder of it is still being received on the inbound
link.

Dan has conflated an invisible (to IP) implementation detail of
router/switch hardware with a requirement of the protocol itself (as in
SMTP protocol which explicitly requires that it operate in a store and
forward networking mode) and is therefore arguing that IP is "store and
forward". But IP does not require switches/routers operate in store
and forward mode. Whether they do, or not, is invisible to, and
unspecified by, IP.

And even those routers/switches that /do/ operate in a store and
forward like mode for IP, they do not 'store' said packet any longer
than necessary to make their routing decision. If their header
analysis indicates they do not know where to forward the packet, they
drop it and move along. This is the critical distinction that Dan
appears unaware of that differentates packet store and forward systems
from what the rest of us term store and forward networking (i.e., SMTP
like store and forward operation).

In article <q5OYJ.208079$aT3.84251@fx09.iad>, meff <email@example.com> wrote:
>On 2022-03-17, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> Let me be clear about what I've been saying in this thread, as
>> it appears to have been muddled:
>>
>> * IP is a good protocol on which to base a clandestine
>> communications network in an occupied or active conflict
>> situation.
>> * The PSTN, and telephony in general, is not a viable
>> alternative to IP networks in this context.
>> * BBSes and FTN are poorly suited and best avoided.
>> * UUCP is acceptable, but has limitations related to the
>> underlying transport; this transport issue cannot be ignored.
>> * Packet radio using e.g. AX.25 or APRS is probably the simplest
>> and most robust mechanism for establishing a communications
>> channel. Noteably, one can use TCP/IP over AX.25.
>> * Unattended, cheap, throw-away digipeaters can be used to
>> extend range and coverage.
>> * In this sort of scenario, it is important to focus not so much
>> on the technology but on the use cases and environment. The
>> details, and getting them right, is critical to effective and
>> useful communications.
>
>Indeed and now that I think about it, offering PPP over a link and
>then sending your message to a mailserver over SMTP/IP is a very
>simple thing to do in the hypothetical situation both of you have been
>discussing. That way you can still use your Raspberry Pi or laptop's
>MUA to send mail and then have the MTA deal with the long-term storage
>and forwarding.

Yup. It's the obvious solution; all of these shenanigans around
UUCP and Fidonet and the like seem like mostly an academic
exercise.

- Dan C.

In article <t10der$k4a$1@tncsrv09.home.tnetconsulting.net>,
Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>On 3/17/22 8:50 AM, Dan Cross wrote:
>> That's irrelevant. You are factually incorrect about the
>> definition of a store-and-forward protocol.
>
>Why don't you share the definition that you're using for store-and-forward.

I have. Several times.

>I'm using the following definition for store-and-forward networking:
>Something receives a message from a sender, stores it for some (possibly
>indeterminate) amount of time, and then sends it to the next system in
>the path at some point in the future.

Sure. But you also seem to be imposing additional requirements
on top of this, in particular adding some kind of transactional
persistence layer.

>> IP is not connection-oriented.
>
>Pick any higher transport layer protocol that want and it will still
>fail to establish communications when there is not an end to end path
>for IP to take.

So what? Continually throughout this thread, you've been
conflating the transport with the applications running over that
transport. I have tried to make this distinction clear, but you
don't seen notice and continue with the confusion. Suffice it
to say, these things are not synonymous.

Similarly, you seem to assert that protocols like UUCP are
immune to the problems you highlight with paths in e.g., IP
networks, while not acknowledging that the PSTN or similar links
you seem to be asserting can be used in lieu of an IP network
suffer from the exact same problems. When this is pointed out,
you move the goalposts by changing the parameters of the
problem; this has happened so often it's no longer clear what
you're arguing for.

My conclusion is that you don't have a great grasp on the
fundamental parameters of the problem, and ignore externalities
that don't support your presuppositions. You seem to be more
interested in being "right" in some pedantic sense than in
building an actually useful communications solution. As such,
I don't see further responses being particularly fruitful.

I started writing a response to the rest of this post, but it
was becoming a lot snarkier than I wanted, so I'm not going to
do that.

I'll just conclude by saying that I'm a former military
communicator who actually has some experience communicating in a
combat environment, including under fire. Most of what you've
written, frankly, just isn't realistic.

- Dan C.

On 3/18/22 7:06 AM, Rich wrote:
> It appears that you two are talking past one another.

Ya.... :-/

> Dan is conflating store and forward packet switching with store
> and forward networking and believing that both mean the same thing
> and then arguing that IP is a store-and-forward system (without any
> qualifiers to indicate what subset he is referencing).

I've gotten the same impression. But I didn't see any value in digging
deeper into that. -- In some ways, store-and-forward terminology can
be applied at different layers. Switches can use store-and-forward via
a non-persistent buffer (OSI) L2. UUCP & mail servers /are/
store-and-forward at the application layer (OSI) L7.

> While some IP switches/routers can operate in a store-and-forward mode
> (whole IP packet is first received into memory before the header is
> analyzed to determine which link to transmit the IP packet, then the
> packet is transmitted (or dropped) depending upon the header analysis)

Agreed.

> this is not a requirement of IP networking. It is also possible, and
> many very high performance switches/routers do, for the switch/router
> to analyze the headers as they are received off the line, decide
> where to send the packet, and begin transmitting the packet on the
> outbound link while the remainder of it is still being received on
> the inbound link.

I believe this has been referred to as "cut-through" in the past.

> Dan has conflated an invisible (to IP) implementation detail of
> router/switch hardware with a requirement of the protocol itself
> (as in SMTP protocol which explicitly requires that it operate in a
> store and forward networking mode) and is therefore arguing that IP is
> "store and forward". But IP does not require switches/routers operate
> in store and forward mode. Whether they do, or not, is invisible to,
> and unspecified by, IP.

Agreed.

> And even those routers/switches that /do/ operate in a store and
> forward like mode for IP, they do not 'store' said packet any longer
> than necessary to make their routing decision.

Hence my comments about the amount of time that they store the packet
alluding to the fact that they won't store them for O(days) at a time.

> If their header analysis indicates they do not know where to forward
> the packet, they drop it and move along.

Even if such a switch / router does know where to forward the packet,
there is no guarantee that the destination system is still online. E.g.
the MAC address for an IP, be it the target / End System or a next hop
router / Intermediate System, is still valid in the ARP / neighbor cache
but is now offline for any reason; shutdown, crash, power fail, someone
tripping over the network cable.

> This is the critical distinction that Dan appears unaware of that
> differentates packet store and forward systems from what the rest
> of us term store and forward networking (i.e., SMTP like store and
> forward operation).

Agreed.

--
Grant. . . .
unix || die

On 2022-03-18, bozo@dev.null <bozo@dev.null> wrote:
> On 2022-03-04, Oregonian Haruspex <no_email@invalid.invalid> wrote:
>>
>> Looks like we’re going back to the Kremvax days.
>>
>
> I2pd it's an interesting alternative to avoid that.
>
> They have several Russian servers on the IRC proxied
> servers (two), but one of the two it's almost Russian
> language based.
>
> They have an NNTP server, too. Setting up i2pd is not
> dark magic, I can write a guide if anyone wants.

I'm curious if you have thoughts on why I2P instead of Tor, or
vice-versa (or neither). Just safer to not have to deal with the
concept of an exit node?

>>>>> On 2022-03-05 01:43:34 -0000, Retrograde wrote:
>>>>> On 2022-03-04, Oregonian Haruspex wrote:

>> Looks like we’re going back to the Kremvax days.

> I saw they're banning foreign reporters and cutting access to
> Facebook and Twitter. Was just looking to see if they're cutting
> port 80

Sure you don't mean 443?

> but Usenet is still an option.

> How do you know Usenet isn't accessible in Russia? Not doubting
> you, just trying to figure out if it's true.

I can confirm that so far, at least access to Aioe is /not/
blocked in Russia.

Given, however, that Tor /is/ blocked (mostly) since December,
I'm not willing to bet that the situation won't change at some
point in future. Such ban is certainly feasible from the
technical standpoint.

> alt.russian.z1 is a Russian speaking newsgroup with a lot of
> activity. Seems to have recent posts as of 4 March.

That may very well be the case, but note that '.z1' in the
group name refers to http://en.wikipedia.org/wiki/World_Zone_1 ;
which is to say, it's a newsgroup created for Russian speakers
in North America.

--
FSF associate member #7257 http://am-1.org/~ivan/

Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>On 3/12/22 8:47 AM, Dan Cross wrote:
>> Sadly, that doesn't make it any less true.
>
>Please elaborate on why the Internet is required when a group of people
>make dial up connections to each other using FTN and / or UUCP.

Because much of the FTN and pretty much all of UUCP is now carried over IP.
IP connectivity is so cheap and ubiquitous that if you are picking up the
phone and making a long distance call, it's likely being carried over a VoIP
circuit. If you are using an ATM with an X.25 connection to a host bank...
it is almost certainly X.25 tunnelled over IP on the public internet.

You can order a contact closure "telegraph" circuit from the telco here...
but secretly under the hood it's IP.

All of that legacy physical infrastructure is long gone. It looks like it's
there from up top because the functionality remains, but when you look under
the hood you will find that functionality is provided by IP now.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

In article <BwVXJ.184493$SeK9.24445@fx97.iad>, meff <email@example.com> wrote:
>
>I was too young during the BBS days to use a BBS, but I generally hold
>the opinion that those who are ignorant of history are doomed to
>repeat it. I think documenting FTN would be a good exercise if
>anything to help ambitious folks not recreate some of its foibiles in
>modern IP networks.

Few things are as well documented as the FTN. There are miles upon miles
of Bell operating manuals.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Javier <invalid@invalid.invalid> wrote:
>
>UUCPNET in the 80s was a cooperative network of universities and
>companies and all admins on it were well behaved and cooperated.
>Everything was unencrypted, and yet nobody was spoofing emails,
>nor doing crapflooding. I guess that the reasons for cooperation were
>
>a) the zeitgeist of the 80s encouraged technological cooperation.
>b) everybody's identity was public and most of them were academics
> who valued their prestige.
>c) barriers of entry (in terms of economical cost and the requirement
> of technical knowledge of hardware and software).

People were spoofing emails and crapflooding (at least I was). The thing
is, though, that the people who ran the infrastructure were few, and they
took their job of policing it seriously. If someone posted something that
was problematic, you could get on the phone to the poor admin at Penn State
and let him know what was going on and he would take care of it.

I think it was 1993 when I called up an admin about an abusive user and I
was told that there was nothing they could do about it. That's when it was
clear to me that things were changing. For the life of me I can't remember
the name of that ISP though.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

In article <t1205g$qhs$1@dont-email.me>, Rich <rich@example.invalid> wrote:
>
>Dan is conflating store and forward packet switching with store and
>forward networking and believing that both mean the same thing and then
>arguing that IP is a store-and-forward system (without any qualifiers
>to indicate what subset he is referencing).

This is likely because that terminology was used in some of the original
RFCs for TCP/IP.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 2022-03-18, meff <email@example.com> wrote:
> On 2022-03-18, bozo@dev.null <bozo@dev.null> wrote:
>> On 2022-03-04, Oregonian Haruspex <no_email@invalid.invalid> wrote:
>>>
>>> Looks like we’re going back to the Kremvax days.
>>>
>>
>> I2pd it's an interesting alternative to avoid that.
>>
>> They have several Russian servers on the IRC proxied
>> servers (two), but one of the two it's almost Russian
>> language based.
>>
>> They have an NNTP server, too. Setting up i2pd is not
>> dark magic, I can write a guide if anyone wants.
>
> I'm curious if you have thoughts on why I2P instead of Tor, or
> vice-versa (or neither). Just safer to not have to deal with the
> concept of an exit node?

That and instant yggdrasil suppport.