Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Ethan Carter <ec1828@somewhere.edu>
Newsgroups: news.software.nntp
Subject: Re: ad-hoc wifi news transport
Date: Fri, 04 Apr 2025 10:13:46 -0300
Organization: A noiseless patient Spider
Lines: 78
Message-ID: <x87plhsax2t.fsf@somewhere.edu>
References: <20250320204547.0000274b@dne3.net> <874izak212.fsf@gmail.com>
	<vshbnj$3nh1s$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Fri, 04 Apr 2025 20:42:12 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="73bc28e5e9b55780aa914f2f2af497dd";
	logging-data="206446"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/OYkETc+KXhsbTI6w9ZdbC/l/YkxLkKRg="
Cancel-Lock: sha1:/RpKclNHIo3O4TFNqmWc574TxYk=
	sha1:qjXmt7SCe9DehYM5ql+XKla4OHU=
Bytes: 4748

bp@www.zefox.net writes:

> Ethan Carter <ec1828@gmail.com> wrote:
>> Toaster <toaster@dne3.net> writes:
>> 
>>> Posting this here (was on comp.misc)
>>>
>>> I was researching NNTP and came across this project:
>>>
>>> https://github.com/nntpchan/nntpchan/
>>>
>>> Using NNTP as a base protocol for other services. Personally, I think
>>> it's a great idea, and it got me thinking.
>>>
>>> Wireless ad-hoc mesh networks are an interest of mine. Normally the
>>> purpose of the network is to route traditional TCP/IP protocol stacks
>>> on top of whatever routing technology (like babel). But for radios,
>>> they broadcast out naturally, it seems like a service like news/store
>>> and forward message sending would be a natural fit.
>>>
>>> The idea is to use a smart flooding algorithm, like uflood
>>> (https://pdos.csail.mit.edu/~jaya/uflood_thesis.pdf) and skip all the 
>>> routing/high speed packet delivery problems and just flood news
>>> articles over it. I think it would be a good fit.
>>>
>>> Usenet is already decentralized, decentralizing the infrastructure seems
>>> like a cool idea. If I were going to do it, I'd add some kind of
>>> proof-of-work scheme to prevent spamming the network. Bandwidth would
>>> be low due to the air-time of a large mesh network being saturated, but
>>> I see that as a plus, prevents abuse (spamming binaries on the net).
>>>
>>> It's half baked, but I wanted to put my thoughts out there and see if
>>> other work has already been done on something like this.
>> 
>> Everything in your post looks interesting, but I'm reading it all for
>> the first time.  I would have liked a slower presentation of everything.
>> For instance, nntpchan.net is down.  I'm asking for help on their IRC
>> channel at Rizon.  It's not clear what it aims to achieve, but it looks
>> interesting.
>> 
>> What I'm working on right now is an NNTP server for a small community.
>> So far the server is not able to peer itself with another one.  Where am
>> I going?  I see a lot of websites hosting forums.  That's the wrong
>> thing to do.  These forums should have an interface-independent storage
>> that provides the data for a web interface as well as others such as
>> NNTP itself.
>> 
>> I'm beginning the work with the NNTP protocol because it allows us to
>> use the system right away with all the NNTP clients out there.  But I
>> plan to build an HTTP API with which people can build their web
>> preferred web interface and then power their communities.
>> 
>> But I'm aware you're talking about something considerably lower level
>> here---which is also interesting.  Perhaps I could keep the idea in mind
>> while I work on this project.
>
> To a degree, ad-hoc wifi bears some resemblance to the dialup connections
> used in the days of UUCP. I wonder if a UUCP-like approach, at some level
> in the stack, might be useful. 

A UUCP approach sounds nice for peering.  Now, typically servers would
peer by plain TCP, so the server should plan for a UUCP-type of exchange
ahead of time.  I am not there yet, but I'll keep that in mind.  I
believe a UUCP-type of exchange might be too much for a first release
with peering support.  I also think we should take advantage of what's
available.  I think TCP plus NNTP is what the most popular servers do.

> AIUI, NNTP relies on always-on, always-same network connections.

I think a server can come online, fetch all articles their peers want to
deliver and then disconnect.  But, yes, I think peers register their
peers and communicate with the same ones always.  I don't think we
should go towards a discovery of peers, say.

> UUCP functions with mostly-off, manually configured connections. That
> seems like dialup.

That makes sense.