Russ Allbery wrote:

> Subject: 6.14. Find external feeds and set up peering

After the discussion in group news.admin.peering, it became clear
that chapter 6.14 of the INN 2.x FAQ need to be updated with the
following conditions:

* administrator must have an account on "reliable email service" [1];
* administrator should assist the third party in achieving
commercial interests [2].

It probably makes sense to write a definition of "reliable email
service" and list them.

References:
1. Message-ID: <tamep7$2r8ph$1@news.mixmin.net>
2. Message-ID: <tamtot$12n$1@txtcon.i2p>
--
Miner

Miner <invalid@invalid.invalid> writes:

> After the discussion in group news.admin.peering, it became clear that
> chapter 6.14 of the INN 2.x FAQ need to be updated with the following
> conditions:

> * administrator must have an account on "reliable email service" [1];
> * administrator should assist the third party in achieving
> commercial interests [2].

> It probably makes sense to write a definition of "reliable email
> service" and list them.

Some people may have those requirements, some people may not. I don't
think the INN FAQ is the place to get into specifics about what peering
policies other people may have.

I certainly completely disagree with the second point and that is not part
of any peering policy that I have (if anything, the exact opposite; I
generally don't peer with commercial sites).

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

On 7/14/22 05:38, Miner wrote:

<snip>

It appears you may be interested in Bitmessage. It is similar to having
usenet and mixmaster rolled into one.

https://bitmessage.org

Bitmessage is a anonymous, peer-to-peer messaging protocol that allows
for public and private chans and direct private messages. Chans are
similar to newsgroups. It is completely decentralized and totally
uncensorable. It has support for Tor and Tor hidden services built-in.

Additionally, Bitmessage supports broadcasts and decentralized mailing
lists.

Messages are encrypted and signed with the algorithms used by Bitcoin.
It also employs dandelion mix routing for privacy. A QT interface is
available with the standard reference implementation.

--

G.K.

On 7/14/22 8:45 AM, Russ Allbery wrote:
> Some people may have those requirements, some people may not.

I'll copy & paste a comment I made about this in the news.admin.peering
newsgroup.

I consider the desire ~> requirement for valid email address as one of
network operations. As in server administrators need a reliable way to
get a hold of each other to communicate about repairing the network when
the network is down. Or out of bands if you will.

> I don't think the INN FAQ is the place to get into specifics about
> what peering policies other people may have.

I think that it's probably worth while for one of the INN documents, if
not the FAQ, to mention what is likely needed to establish peering
connections.

Lest we end up with documentation on how to stand up a server that's an
island with no information on how to build bridges to / from that island.

I think /not/ having /some/ information on this is a disservice to new
news masters.

> I certainly completely disagree with the second point and that is
> not part of any peering policy that I have (if anything, the exact
> opposite; I generally don't peer with commercial sites).

I wonder if that's old verbiage meant to discourage de-peering with a
peer in the event that a previously non-commercial peer tries to turn
commercial. I feel like the spirit of RFC "SHOULD" / "SHOULDN'T" vs
"MUST" / "CAN'T" comes to mind.

--
Grant. . . .
unix || die

Grant Taylor <gtaylor@tnetconsulting.net> writes:

> I think that it's probably worth while for one of the INN documents, if
> not the FAQ, to mention what is likely needed to establish peering
> connections.

I think this would fall into a similar category as the separate hierarchy
administration FAQ that I maintain (badly, or at least slowly). It's a
bit outside the scope of INN as a piece of software, which is perfectly
happy to be used to exchange news among a private set of peers who
communicate only via carrier pigeon.

The nice thing about a general FAQ on being a good public Usenet news
admin is that anyone can write it and maintain it and it doesn't need to
be tied to a specific piece of news software. :)

> I think /not/ having /some/ information on this is a disservice to new
> news masters.

I would be happy to review and offer suggestions on any document you chose
to start!

I get the impression that the original message was mostly a continuation
of some argument in news.admin.peering by other means, though, which to me
is another reason for the INN FAQ to stay out of it.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

G.K. wrote:

> On 7/14/22 05:38, Miner wrote:
>
> <snip>
>
> It appears you may be interested in Bitmessage. It is similar
> to having usenet and mixmaster rolled into one.

Bitmessage causes an little justified load on CPU. Gretta Tunberg
probably denounces this. :-)

--
Miner

Get new additions to the FAQ.

Before asking for a peering:
* administrator must register the domain and probably should pay
for it [3];
* administrator should set up and run the MTA [4];

References:
3. Message-ID: <taq3dh$34539$1@news.mixmin.net>
4. Message-ID: <tapl1i$3369a$1@news.mixmin.net>

Miner wrote:

> Russ Allbery wrote:
>
> > Subject: 6.14. Find external feeds and set up peering
>
> After the discussion in group news.admin.peering, it became clear
> that chapter 6.14 of the INN 2.x FAQ need to be updated with the
> following conditions:
>
> * administrator must have an account on "reliable email service" [1];
> * administrator should assist the third party in achieving
> commercial interests [2].
>
> It probably makes sense to write a definition of "reliable email
> service" and list them.
>
> References:
> 1. Message-ID: <tamep7$2r8ph$1@news.mixmin.net>
> 2. Message-ID: <tamtot$12n$1@txtcon.i2p>
> --
> Miner
>

--
Miner

Thus spake Russ Allbery <eagle@eyrie.org>
> I get the impression that the original message was mostly a continuation
> of some argument in news.admin.peering by other means, though, which to me
> is another reason for the INN FAQ to stay out of it.

+1

--
Too many ingredients in the soup, no room for a spoon
http://www.eternal-september.org

On Fri, 15 Jul 2022 13:06:00 +0200, Ray Banana <rayban@raybanana.net> wrote:
> Thus spake Russ Allbery <eagle@eyrie.org>
>
>> I get the impression that the original message was mostly a continuation
>> of some argument in news.admin.peering by other means, though, which to me
>> is another reason for the INN FAQ to stay out of it.
>
> +1

I agree. Also, many things are implied by common logic and it would be waste of everybody's time to include. e.g.

- to contact other people, one should have some common agreed medium for contact.
These days e-mail is usually implied, in times past it was postal adress, in a century it might be facebook account
or some other horrible distopian stuff.
- in order to peer over network, one needs functional network connectivity of some kind
- to edit config files, one should know how to use some available editor, etc.

There is absolutely no need to specify those in *INN* FAQ. Perhaps is some "computing 101" FAQ...

--
Opinions above are GNU-copylefted.

Matija Nalis wrote:

> On Fri, 15 Jul 2022 13:06:00 +0200, Ray Banana <rayban@raybanana.net> wrote:
> > Thus spake Russ Allbery <eagle@eyrie.org>
> >
> >> I get the impression that the original message was mostly a
> >> continuation of some argument in news.admin.peering by other
> >> means, though, which to me is another reason for the INN FAQ
> >> to stay out of it.
> >
> > +1
>
> I agree. Also, many things are implied by common logic and it
> would be waste of everybody's time to include. e.g.

Administrator must have comprehensive information before setting
up the service. Lack of information turns into wasted time.

--
Miner

On 7/15/22 5:23 AM, Matija Nalis wrote:
> I agree. Also, many things are implied by common logic and it would
> be waste of everybody's time to include.

I disagree.

1st "common logic" is both regionally and chronologically dependent. It
used to be common logic that smoking on a plane was okay.

2nd given the above, I find it's better to clarify things, even if
believed to be common logic, so that people that are in a different
region or different time (years later) have a frame of reference from
the document that no longer exists for them.

Perhaps some of these things don't need to be /in/ the INN FAQ itself.
But I do think it would be good to have a pointer in the INN FAQ
referencing some of these things. E.g.

Q: What do I do now that my INN server is up and running?
A: See the Peering FAQ document for more details.

--
Grant. . . .
unix || die

On 7/15/22 12:02 AM, Miner wrote:
> Before asking for a peering:
> * administrator must register the domain and probably should pay for it
> [3];

I can't support "/must/ register a domain name". I see zero problems
with using a hostname in an existing domain name.

I can support "/must/ use a /registered/ domain name".

The difference to me has to do with if a new news master needs to
register a new domain for their own use or not.

> * administrator should set up and run the MTA [4];

I question if the news master really /should/ set up and run an MTA. I
completely agree that an email address MUST be serviceable. But why
does there need to be an MTA on news.example.net when example.net
already has a fully functional MTA stack? What's more is why can't
news.example.net use news-example-net@<$FREE_EMAIL_PROVIDER>?

I agree that using an email address in the same (parent) domain is
preferred. But I don't think that preference even qualifies as a SHOULD.

--
Grant. . . .
unix || die

Grant Taylor <gtaylor@tnetconsulting.net> writes:

> I can't support "/must/ register a domain name". I see zero problems with
> using a hostname in an existing domain name.

> I can support "/must/ use a /registered/ domain name".

> The difference to me has to do with if a new news master needs to register
> a new domain for their own use or not.

I feel like this thread is assuming the very specific and narrow context
of wanting to peer with other random people one doesn't already know, on
the public Internet or on some privacy-preserving overlay of it, carrying
generally-distributed Usenet groups. In other words, that's a
news.admin.peering FAQ addressing the specific social context of that
group, but not really taking into account the broader news.software.nntp
world.

Nothing wrong with that! But this is why I don't think the INN FAQ is the
place for it apart from a pointer (which I'd be happy to add once such a
document existed).

Just to say this for the record: none of INN nor news.software.nntp nor
netnews are limited to this configuration. It works with IP addresses
with no DNS. It works on private networks. INN can provide stand-alone
service for entirely private groups. Netnews as a protocol is a much
bigger world than public peering of Usenet groups.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

On 7/15/22 12:25 PM, Russ Allbery wrote:
> ...

ACKs all around and well said Russ.

--
Grant. . . .
unix || die

Grant Taylor wrote:

> On 7/15/22 12:02 AM, Miner wrote:
> > Before asking for a peering:
> > * administrator must register the domain and probably should pay for it
> > [3];
>
> The difference to me
No difference for me. I have no domain.

> > * administrator should set up and run the MTA [4];
> But why
Discuss details with Ishmel.

--
Miner

On 7/15/22 2:12 PM, Miner wrote:
> Discuss details with Ishmel.

Who and where?

I don't see Ishmel listed as a sender in this thread.

--
Grant. . . .
unix || die

On 7/15/22 13:04, Grant Taylor wrote:
> It used to be common logic that smoking on a plane was okay.

Prude.

--

Ishmel Rowe Dent

Russ Allbery wrote:

> In other words, that's a news.admin.peering FAQ addressing the
> specific social context of that group, but not really taking
> into account the broader news.software.nntp world.

Just the facts.
1. News.admin.peering FAQ does not exist or hasn't been posted in
the past few months.
2. INN 2.x FAQ does not cover an important aspect of usage. The
lack of complete information caused a waste of time.

Therefore, the inaction of the author of the INN 2.x FAQ from now
on can be regarded as disinformation. Probably with the aim of
making attractive a little popular software product or, in other
words, fossil of ancient times.

> INN can provide stand-alone service for entirely private
> groups.

I have never seen usage in this way. Companies and organizations
prefer other solutions.
Norton Commander also provide something. However, no one is using
it.

--
Miner

Grant Taylor wrote:

> On 7/15/22 2:12 PM, Miner wrote:
> > Discuss details with Ishmel.
>
> Who and where?
> I don't see Ishmel listed as a sender in this thread.

I noticed you're abusing [skip] often. There was references on
Message-ID.

--
Miner

On 7/16/22 06:40, Miner wrote:
> Russ Allbery wrote:

<snip>

>> INN can provide stand-alone service for entirely private
>> groups.
>
> I have never seen usage in this way. Companies and organizations
> prefer other solutions.

YGBSM. You can't seem to set up a peering without a mountain of friction
and now you're pretending to be an expert on Usenet software proliferation.

I am subscribed to several private NNTP servers that don't peer with
Usenet. There are thousands of private NNTP servers in active use
world-wide. Nobody acts as toxic as you on any of the servers I
subscribe to, and many of them are using opsec to hide their identities.
If they want to peer, they know that email and domain name is standard.

There are many such servers. There are also special-purpose NNTP feed
forwarding servers such as gmane.io and gwene.io that don't peer with
the larger Usenet hierarchies. You're just a crank troll and you've
proven it repeatedly. I smell rodent.

STFU and peer with someone by giving them a email address and domain
name, or just go away and run a private server and be happy in your
anonymous pedo-pirate-carder-tweaker-opsec bubble. I think you are a
crank and your wank disgusts me.

Really dude, it's time to stop this nonsense and grow up. Your trolling
smells of Kerman the German wank.

--

Ishmel Rowe Dent

Ishmel Rowe Dent wrote:

> On 7/16/22 06:40, Miner wrote:
> > Russ Allbery wrote:
>
> <snip>
>
> > > INN can provide stand-alone service for entirely private
> > > groups.
> >
> > I have never seen usage in this way. Companies and
> > organizations prefer other solutions.
>
> YGBSM. You can't seem to set up a peering without a mountain of
> friction and now you're pretending to be an expert on Usenet
> software proliferation.

Instead of commenting the facts, you generate unclaimed thoughts
in abundance.

As it became known, the peering requires many conditions. The
conditions remained unknown at the stage of setting up the
service. This was the result of misinformation (or is it better
to say disinformation?) in the FAQ. Now let me improve FAQ. No
thanks needed.

> I am subscribed to several private NNTP servers that don't peer
> with Usenet. There are thousands of private NNTP servers in
> active use world-wide. Nobody acts as toxic as you on any of
> the servers I subscribe to, and many of them

I announced the InterNetNews to potential users. They called the
InterNetNews "petrified shit of mammoth". For the common good
ongoing testing of its toxicity. :-)

--
Miner

Miner <invalid@invalid.invalid> writes:

> Just the facts.
> 1. News.admin.peering FAQ does not exist or hasn't been posted in
> the past few months.
> 2. INN 2.x FAQ does not cover an important aspect of usage. The
> lack of complete information caused a waste of time.

> Therefore, the inaction of the author of the INN 2.x FAQ from now
> on can be regarded as disinformation. Probably with the aim of
> making attractive a little popular software product or, in other
> words, fossil of ancient times.

Oh, you're adorable. It's been about twenty years since this sort of
thing has worked on me, but nice try! A very honest attempt to capture
the spirit of 1990s Usenet.

This fossil of ancient times has learned one of the lessons that fossils
learn, which is that if you're doing something as a hobby, you should do
it however makes you happy and not care too much about what anyone else
thinks about what you're doing. Life is too short to argue about your
hobbies. If someone doesn't like what you're doing, they can go do
something else.

>> INN can provide stand-alone service for entirely private groups.

> I have never seen usage in this way.

Yes, I'm not surprised. Nonetheless, if you pay attention, people talk
about it from time to time in this very group.

Like all uses of INN and Usenet in general, it's gone down over time as
people have mostly switched to other protocols and other software stacks.

> Companies and organizations prefer other solutions. Norton Commander
> also provide something. However, no one is using it.

I hate to break this to you, but "no one is using it" is true about Usenet
and netnews *in general*. We are a very small backwater with a very
obscure hobby.

And not only is that fine, it's often a nice place to be. We're part of
the world's diversity. It would be boring and oppressive if everyone was
using the popular thing.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

Russ Allbery wrote:

> Miner <invalid@invalid.invalid> writes:
>
> > Just the facts.
> > 1. News.admin.peering FAQ does not exist or hasn't been
> > posted in the past few months.
> > 2. INN 2.x FAQ does not cover an important aspect of usage.
> > The lack of complete information caused a waste of time.
>
> > Therefore, the inaction of the author of the INN 2.x FAQ from
> > now on can be regarded as disinformation. Probably with the
> > aim of making attractive a little popular software product
> > or, in other words, fossil of ancient times.
>
> This fossil of ancient times has learned one of the lessons
> that fossils learn, which is that if you're doing something as
> a hobby, you should do it however makes you happy and not care
> too much about what anyone else thinks about what you're doing.
> Life is too short to argue about your hobbies. If someone
> doesn't like what you're doing, they can go do something else.

I can't be happy when the result of my efforts is very different
from the expected. My expectations were based on the content of
the FAQ.

> >> INN can provide stand-alone service for entirely private groups.
>
> > I have never seen usage in this way.
>
> Yes, I'm not surprised. Nonetheless, if you pay attention,
> people talk about it from time to time in this very group.
>
> Like all uses of INN and Usenet in general, it's gone down over
> time as people have mostly switched to other protocols and
> other software stacks.

There is reason to think about the cause of this phenomenon. The
conceptual advantages of the Usenet are undeniable.

> > Companies and organizations prefer other solutions. Norton
> > Commander also provide something. However, no one is using
> > it.
>
> I hate to break this to you, but "no one is using it" is true
> about Usenet and netnews *in general*. We are a very small
> backwater with a very obscure hobby.

Degradation is often the result of error. It remains to find the
error and fix before it's too late.

--
Miner

Miner <invalid@invalid.invalid> writes:

> I can't be happy when the result of my efforts is very different from
> the expected. My expectations were based on the content of the FAQ.

You've got a point that the answer to that question expressed rather more
certainty about getting a feed than may be warranted. I've reworded it a
bit:

One way to find peers is to ask for an external feed in the
news.admin.peering newsgroup. Some news administrators read that
group and may be willing to peer. It's common for news administrators
to have different criteria for peering (specific hierarchies,
geographic or network proximity, spam filtering, no binaries,
binaries, specific network protocols; the variation is endless), so
finding someone with matching goals may require some patience and
possibly some configuration changes. And why not keep subscribed to
this newsgroup to help others find a news feed once you get yours?

> There is reason to think about the cause of this phenomenon. The
> conceptual advantages of the Usenet are undeniable.

Usenet has an incredibly clunky, awkward, and insecure mechanism for
moderation, which is a fatal flaw at any level of popularity much higher
than its current level and which (combined with the constant problem of
finding enough people to do the moderation) is a lot of the reason why
Usenet only has its current level of popularity. General-distribution
newsgroups only survive the lack of moderation tools because this is a
niche hobby with a tiny community, which means it's relatively rare that
someone will actively try to break it for everyone else.

Back when it was far more popular, other people routinely tried to break
it for everyone else and, due to the inherent insecurities in the
protocol, mostly succeeded.

Even with that small community, there is absolutely no way that I would
legally risk running a Usenet server that accepted binaries given the
utter lack of tools or support for keeping child sexual abuse material off
of Usenet. Other people obviously make different decisions and, well,
good luck to them, I guess.

> Degradation is often the result of error. It remains to find the error
> and fix before it's too late.

Have fun! I'm just going to be over here doing my thing. :)

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

Hi Russ,

> You've got a point that the answer to that question expressed rather more
> certainty about getting a feed than may be warranted.

Yup, agreed, my mistake. Re-reading the previous wording, I indeed was
too much optimistic; of course nothing is ever guaranteed.

> I've reworded it a bit

You did well, thanks.
You proved not to be a fossil :-)

Both you and Grant have always proven to be reliable, pro-active and
helpful to others!

--
Julien ÉLIE

« C'est comme chercher une aiguille dans du foin en bottes ! »
(Jolitorax)