| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 27 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 38:06:00 |
| Calls: | 631 |
| Calls today: | 2 |
| Files: | 1,187 |
| D/L today: |
22 files (29,767K bytes) |
| Messages: | 173,683 |
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.
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.
AIUI, NNTP relies on always-on, always-same network connections.
UUCP functions with mostly-off, manually configured connections. That
seems like dialup.
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.
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.
On Fri, 04 Apr 2025 10:13:46 -0300snips
Ethan Carter <ec1828@somewhere.edu> wrote:
bp@www.zefox.net writes:
Ethan Carter <ec1828@gmail.com> wrote:
Toaster <toaster@dne3.net> writes:
My original idea was to leverage wifi's characteristics to propagate
articles in a flooding manner. It bypasses all of the complexity of
ad-hoc wifi peering and uses all of the strengths of a radio based
broadcast medium. It'd be anonymous and virtually uncensorable. (and
free transport with no configuration or centralized anything)
Using the internet, I'd just use NNTP. UUCP would work for serial links
or the like, but NNTP already exists, so why not use it?
But don't stop there, imo NNTPchan should have leveraged the existing
usenet network instead of having another separate network of
incompatible servers. Just make a top level hierarchy and use that for
the service data, or under alt, who cares.
I think the problem is going to be getting people to use it, as it
stands alot of people like having control over their own little
communities. Bad news is good data can just disappear forever. So many
lost geocities pages full of content gone. :(
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.
I've mentioned before that NNCP is to UUCP what rsh is to telnet.
I don't think it required unique hostnames, though they were preferred,I'd like to experiment around with uucp and nncp. looking at nncp
since the bang paths generally were different for different hosts even
if the had the same name. In a sense the bang path was the identity of
any given host.
UUCP died out because DNS and ICANN made TCP/IP much easier to administer
and was incomparably faster. With with some thought it might be useful
again.
Thanks for reading,
bob prohaska
On 4/4/2025 7:54 PM, bp@www.zefox.net wrote:
snip
I don't think it required unique hostnames, though they were preferred,I'd like to experiment around with uucp and nncp. looking at nncp
since the bang paths generally were different for different hosts even
if the had the same name. In a sense the bang path was the identity of
any given host.
UUCP died out because DNS and ICANN made TCP/IP much easier to administer
and was incomparably faster. With with some thought it might be useful
again.
Thanks for reading,
bob prohaska
protocol currently.
My router can see about a dozen WAPs, each of them can likely see
more than a dozen each. If I could peer with just a few of them and
we all agreed to share some fraction of our bandwidth back to our
ISP and other peers it would make for a rather dense mesh.
My router can see about a dozen WAPs, each of them can likely see
more than a dozen each. If I could peer with just a few of them and
we all agreed to share some fraction of our bandwidth back to our
ISP and other peers it would make for a rather dense mesh.
https://freifunk.net/en/
Toaster <news@dne3.net> wrote:
On 4/4/2025 7:54 PM, bp@www.zefox.net wrote:
snip
I don't think it required unique hostnames, though they wereI'd like to experiment around with uucp and nncp. looking at nncp
preferred, since the bang paths generally were different for
different hosts even if the had the same name. In a sense the bang
path was the identity of any given host.
UUCP died out because DNS and ICANN made TCP/IP much easier to
administer and was incomparably faster. With with some thought it
might be useful again.
Thanks for reading,
bob prohaska
protocol currently.
Are you thinking of using WiFi LANs as the transport layer?
My router can see about a dozen WAPs, each of them can likely see
more than a dozen each. If I could peer with just a few of them and
we all agreed to share some fraction of our bandwidth back to our
ISP and other peers it would make for a rather dense mesh.
bob prohaska
On Mon, 7 Apr 2025 19:23:35 -0000 (UTC)
bp@www.zefox.net wrote:
Toaster <news@dne3.net> wrote:
On 4/4/2025 7:54 PM, bp@www.zefox.net wrote:
snip
I don't think it required unique hostnames, though they wereI'd like to experiment around with uucp and nncp. looking at nncp
preferred, since the bang paths generally were different for
different hosts even if the had the same name. In a sense the bang
path was the identity of any given host.
UUCP died out because DNS and ICANN made TCP/IP much easier to
administer and was incomparably faster. With with some thought it
might be useful again.
Thanks for reading,
bob prohaska
protocol currently.
Are you thinking of using WiFi LANs as the transport layer?
My router can see about a dozen WAPs, each of them can likely see
more than a dozen each. If I could peer with just a few of them and
we all agreed to share some fraction of our bandwidth back to our
ISP and other peers it would make for a rather dense mesh.
bob prohaska
Yes, that's the idea. I'm also looking into yggdrasil network. Zero configuration, end to end encrypted. The idea would be everyone peers together via wifi, directional links or omni-directional. Directional
is more scalable. Then you share resources with people you know
(internet access, files, etc) via public key. I.e. my friend and I
trust each other, we both share our internet access to each other and
allow default routing out.
If enough people do this then it would be a good auxilliary to standard internet access, good for low to mid bandwidth localized traffic. Right
now most traffic on the internet goes to a few centralized sites, but
does that have to be the case?
In a peer to peer network, you just install an application that
communicates directly with the person you are trying to reach, no
server needed. All it would take is a small shift in which applications
are used.
Another idea is to ditch IP communication altogether and just use the
mesh as a news network. Articles bounce around the mesh like they do on usenet. That's a tough sell, can't do much other than post like we do
here on usenet.
Zero infrastructure cost, run by volunteers = free communications.
I could see using it for out-of-band access to home servers, private sms, zero infrastructure chat applications. I'd put a news server and irc on
it, make a phone app and dress it up nice and pretty for my friends
that aren't technical. Could even support voip to your landline/hotspot.
The dream is the ability to connect your phone to this free net, and
talk to your friends in your community directly instead of trusting
some far off thing. Battery powered nodes would work when nothing else
would (i.e. tornado took out most of everything, enough nodes remain
and the network persists). All this needs is enough buy in from people
to make a minimal network. I'd even pay for the units because im weird
like that.
Toaster <news@dne3.net> wrote:
On 4/4/2025 7:54 PM, bp@www.zefox.net wrote:
snip
I don't think it required unique hostnames, though they wereI'd like to experiment around with uucp and nncp. looking at nncp
preferred, since the bang paths generally were different for
different hosts even if the had the same name. In a sense the bang
path was the identity of any given host.
UUCP died out because DNS and ICANN made TCP/IP much easier to
administer and was incomparably faster. With with some thought it
might be useful again.
Thanks for reading,
bob prohaska
protocol currently.
Are you thinking of using WiFi LANs as the transport layer?
My router can see about a dozen WAPs, each of them can likely see
more than a dozen each. If I could peer with just a few of them and
we all agreed to share some fraction of our bandwidth back to our
ISP and other peers it would make for a rather dense mesh.
bob prohaska
<snip>
Perhaps some of that can be automated.
These comments aren't meant to be _very_ discouraging, just
realistic. Some may find them very discouraging anyway.
Thanks for writing,
bob prohaska