Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.misc > #25420 > unrolled thread

If you were to design a netnews protocol today...

Back to article view | Back to comp.misc

Contents

  If you were to design a netnews protocol today... George Musk <grgmusk@skiff.com> - 2024-08-07 14:32 +0000
    Re: If you were to design a netnews protocol today... Michael Bäuerle <michael.baeuerle@stz-e.de> - 2024-08-07 18:03 +0200
      Re: If you were to design a netnews protocol today... Anton Shepelev <anton.txt@g{oogle}mail.com> - 2024-08-28 16:41 +0300
        Re: If you were to design a netnews protocol today... Michael Bäuerle <michael.baeuerle@stz-e.de> - 2024-08-28 17:04 +0200
    Re: If you were to design a netnews protocol today... D <noreply@mixmin.net> - 2024-08-07 17:23 +0100
    Re: If you were to design a netnews protocol today... not@telling.you.invalid (Computer Nerd Kev) - 2024-08-08 08:49 +1000
    Re: If you were to design a netnews protocol today... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-08 01:29 +0000
      Re: If you were to design a netnews protocol today... Grant Taylor <gtaylor@tnetconsulting.net> - 2024-08-07 21:52 -0500
        Re: If you were to design a netnews protocol today... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-08 07:32 +0000
          Re: If you were to design a netnews protocol today... D <noreply@mixmin.net> - 2024-08-08 13:41 +0100
            Re: If you were to design a netnews protocol today... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-08 23:54 +0000
          Re: If you were to design a netnews protocol today... Grant Taylor <gtaylor@tnetconsulting.net> - 2024-08-14 22:05 -0500
            Re: If you were to design a netnews protocol today... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-15 07:20 +0000
              Usenet as social media [was:Re: If you were to design a netnews protocol today...] Anton Shepelev <anton.txt@g{oogle}mail.com> - 2024-08-15 13:37 +0300
                Re: Usenet as social media [was:Re: If you were to design a netnews protocol today...] "Kerr-Mudd, John" <admin@127.0.0.1> - 2024-08-15 16:30 +0100
                  Re: Usenet as social media [was:Re: If you were to design a netnews protocol today...] Anton Shepelev <anton.txt@g{oogle}mail.com> - 2024-08-15 18:48 +0300
                    Re: Usenet as social media [was:Re: If you were to design a netnews protocol today...] D <remailer@domain.invalid> - 2024-08-15 13:15 -0400
                    Re: Usenet as social media [was:Re: If you were to design a netnews protocol today...] D <nospam@example.net> - 2024-08-15 23:30 +0200
                      Re: Usenet as social media [was:Re: If you were to design a netnews protocol today...] snipeco.2@gmail.com (Sn!pe) - 2024-08-15 23:03 +0100
                        Re: Usenet as social media [was:Re: If you were to design a netnews protocol today...] D <nospam@example.net> - 2024-08-16 09:41 +0200
                      Re: Usenet as social media [was:Re: If you were to design a netnews protocol today...] yeti <yeti@tilde.institute> - 2024-08-15 23:35 +0042
                        Re: Usenet as social media [was:Re: If you were to design a netnews protocol today...] D <nospam@example.net> - 2024-08-16 09:44 +0200
                          Re: Usenet as social media [was:Re: If you were to design a netnews protocol today...] Johanne Fairchild <jfairchild@tudado.org> - 2024-08-27 19:51 -0300
                            Re: Usenet as social media [was:Re: If you were to design a netnews protocol today...] D <nospam@example.net> - 2024-08-28 10:45 +0200
                    Re: Usenet as social media [was:Re: If you were to design a netnews protocol today...] Johanne Fairchild <jfairchild@tudado.org> - 2024-08-27 19:49 -0300
                      Re: Usenet as social media [was:Re: If you were to design a netnews protocol today...] kludge@panix.com (Scott Dorsey) - 2024-09-04 11:40 +0000
            Re: If you were to design a netnews protocol today... steveo@panix.com (Steven M. O'Neill) - 2024-08-15 14:11 +0000
              Re: If you were to design a netnews protocol today... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-16 02:07 +0000
                Re: If you were to design a netnews protocol today... The Real Bev <bashley101@gmail.com> - 2024-08-17 11:18 -0700
                  Re: If you were to design a netnews protocol today... D <nospam@example.net> - 2024-08-17 21:45 +0200
                    Re: If you were to design a netnews protocol today... The Real Bev <bashley101@gmail.com> - 2024-08-17 13:04 -0700
                      Re: If you were to design a netnews protocol today... Rich <rich@example.invalid> - 2024-08-17 20:31 +0000
                        Re: If you were to design a netnews protocol today... The Real Bev <bashley101@gmail.com> - 2024-08-17 15:41 -0700
                      Re: If you were to design a netnews protocol today... The Real Bev <bashley101@gmail.com> - 2024-08-17 15:35 -0700
                      Re: If you were to design a netnews protocol today... D <nospam@example.net> - 2024-08-18 11:04 +0200
                        Re: If you were to design a netnews protocol today... The Real Bev <bashley101@gmail.com> - 2024-08-18 08:25 -0700
                          Re: If you were to design a netnews protocol today... "Kerr-Mudd, John" <admin@127.0.0.1> - 2024-08-21 10:50 +0100
                            Re: If you were to design a netnews protocol today... D <nospam@example.net> - 2024-08-21 16:08 +0200
                        Re: If you were to design a netnews protocol today... Rich <rich@example.invalid> - 2024-08-18 17:11 +0000
                          Re: If you were to design a netnews protocol today... The Real Bev <bashley101@gmail.com> - 2024-08-18 10:37 -0700
                          Re: If you were to design a netnews protocol today... D <nospam@example.net> - 2024-08-19 00:02 +0200
                          Re: If you were to design a netnews protocol today... kludge@panix.com (Scott Dorsey) - 2024-08-20 22:07 +0000
                            Re: If you were to design a netnews protocol today... "Kerr-Mudd, John" <admin@127.0.0.1> - 2024-08-21 10:52 +0100
                    Re: If you were to design a netnews protocol today... Richard Kettlewell <invalid@invalid.invalid> - 2024-08-18 10:18 +0100
                      Re: If you were to design a netnews protocol today... D <nospam@example.net> - 2024-08-19 00:00 +0200
                  Re: If you were to design a netnews protocol today... Johanne Fairchild <jfairchild@tudado.org> - 2024-08-27 19:53 -0300
                    Re: If you were to design a netnews protocol today... The Real Bev <bashley101@gmail.com> - 2024-08-27 19:51 -0700
                      Re: If you were to design a netnews protocol today... Johanne Fairchild <jfairchild@tudado.org> - 2024-08-28 21:34 -0300
                        Re: If you were to design a netnews protocol today... yeti <yeti@tilde.institute> - 2024-08-29 01:42 +0042
                          Re: If you were to design a netnews protocol today... D <nospam@example.net> - 2024-08-29 10:21 +0200
                            Re: If you were to design a netnews protocol today... Rich <rich@example.invalid> - 2024-08-29 13:57 +0000
                              Re: If you were to design a netnews protocol today... yeti <yeti@tilde.institute> - 2024-08-29 16:56 +0042
                                Re: If you were to design a netnews protocol today... Rich <rich@example.invalid> - 2024-08-29 17:07 +0000
                                  Re: If you were to design a netnews protocol today... Anton Shepelev <anton.txt@g{oogle}mail.com> - 2024-08-30 11:58 +0300
                                    Re: If you were to design a netnews protocol today... D <nospam@example.net> - 2024-08-30 22:53 +0200
                          Re: If you were to design a netnews protocol today... Johanne Fairchild <jfairchild@tudado.org> - 2024-08-30 18:51 -0300
                            Re: If you were to design a netnews protocol today... yeti <yeti@tilde.institute> - 2024-08-30 22:50 +0042
                        Re: If you were to design a netnews protocol today... D <nospam@example.net> - 2024-08-29 10:18 +0200
                          Re: If you were to design a netnews protocol today... yeti <yeti@tilde.institute> - 2024-08-29 09:22 +0042
                            Re: If you were to design a netnews protocol today... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-09-05 01:28 +0000
                              Re: If you were to design a netnews protocol today... candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2024-09-05 15:10 +0000
                          Re: If you were to design a netnews protocol today... Johanne Fairchild <jfairchild@tudado.org> - 2024-08-30 18:53 -0300
                            Re: If you were to design a netnews protocol today... Johanne Fairchild <jfairchild@tudado.org> - 2024-09-01 22:47 -0300
                              Re: If you were to design a netnews protocol today... yeti <yeti@tilde.institute> - 2024-09-02 06:56 +0042
                        Re: If you were to design a netnews protocol today... Anton Shepelev <anton.txt@g{oogle}mail.com> - 2024-08-29 13:30 +0300
                          Re: If you were to design a netnews protocol today... Johanne Fairchild <jfairchild@tudado.org> - 2024-08-30 18:55 -0300
                  Re: If you were to design a netnews protocol today... snipeco.2@gmail.com (Sn!pe) - 2024-08-28 00:53 +0100
                    Re: If you were to design a netnews protocol today... yeti <yeti@tilde.institute> - 2024-08-28 01:59 +0042
                      Re: If you were to design a netnews protocol today... snipeco.2@gmail.com (Sn!pe) - 2024-08-28 03:07 +0100
                        Re: If you were to design a netnews protocol today... yeti <yeti@tilde.institute> - 2024-08-28 03:08 +0042
                          Re: If you were to design a netnews protocol today... candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2024-08-28 17:50 +0000
                        Re: If you were to design a netnews protocol today... Anton Shepelev <anton.txt@g{oogle}mail.com> - 2024-08-28 19:41 +0300
                          Re: If you were to design a netnews protocol today... snipeco.2@gmail.com (Sn!pe) - 2024-08-28 18:52 +0100
                            Re: If you were to design a netnews protocol today... "Kerr-Mudd, John" <admin@127.0.0.1> - 2024-08-28 19:34 +0100
                              Re: If you were to design a netnews protocol today... snipeco.2@gmail.com (Sn!pe) - 2024-08-28 19:58 +0100
                                Re: If you were to design a netnews protocol today... "Kerr-Mudd, John" <admin@127.0.0.1> - 2024-08-28 21:16 +0100
                          Re: If you were to design a netnews protocol today... Mike Spencer <mds@bogus.nodomain.nowhere> - 2024-08-28 17:55 -0300
                            Re: If you were to design a netnews protocol today... snipeco.2@gmail.com (Sn!pe) - 2024-08-28 22:04 +0100
                              Re: If you were to design a netnews protocol today... candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2024-08-28 22:40 +0000
                            Re: If you were to design a netnews protocol today... Anton Shepelev <anton.txt@g{oogle}mail.com> - 2024-08-29 13:12 +0300
                            Re: If you were to design a netnews protocol today... kludge@panix.com (Scott Dorsey) - 2024-08-31 23:47 +0000
                            Re: If you were to design a netnews protocol today... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-09-05 01:34 +0000
                      Re: If you were to design a netnews protocol today... D <nospam@example.net> - 2024-08-28 10:46 +0200
                        Re: If you were to design a netnews protocol today... yeti <yeti@tilde.institute> - 2024-08-28 15:09 +0042
                    Re: If you were to design a netnews protocol today... scott@alfter.diespammersdie.us (Scott Alfter) - 2024-08-28 18:11 +0000
                      Re: If you were to design a netnews protocol today... snipeco.2@gmail.com (Sn!pe) - 2024-08-28 19:58 +0100
        Re: If you were to design a netnews protocol today... Dan Purgert <dan@djph.net> - 2024-08-08 09:39 +0000
          Re: If you were to design a netnews protocol today... D <noreply@mixmin.net> - 2024-08-08 14:16 +0100
      Re: If you were to design a netnews protocol today... D <noreply@mixmin.net> - 2024-08-08 04:31 +0100
    Re: If you were to design a netnews protocol today... Richard Kettlewell <invalid@invalid.invalid> - 2024-08-09 08:23 +0100
      Re: If you were to design a netnews protocol today... Richard Kettlewell <invalid@invalid.invalid> - 2024-08-09 17:34 +0100
        Re: If you were to design a netnews protocol today... Richard Kettlewell <invalid@invalid.invalid> - 2024-08-09 19:13 +0100
          Re: If you were to design a netnews protocol today... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-10 00:25 +0000
            Re: If you were to design a netnews protocol today... Richard Kettlewell <invalid@invalid.invalid> - 2024-08-10 09:14 +0100
              Re: If you were to design a netnews protocol today... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-10 08:17 +0000
              Re: If you were to design a netnews protocol today... Rich <rich@example.invalid> - 2024-08-10 15:05 +0000
                Re: If you were to design a netnews protocol today... Bob Eager <news0009@eager.cx> - 2024-08-10 16:51 +0000
                Re: If you were to design a netnews protocol today... D <nospam@example.net> - 2024-08-10 23:41 +0200
                  Re: If you were to design a netnews protocol today... bks@panix.com (Bradley K. Sherman) - 2024-08-10 22:10 +0000
                    Re: If you were to design a netnews protocol today... William Stickers <bill.stickers@innocent.com> - 2024-08-12 10:23 +0100
                      Re: If you were to design a netnews protocol today... snipeco.2@gmail.com (Sn!pe) - 2024-08-12 11:21 +0100
                        Re: If you were to design a netnews protocol today... William Stickers <bill.stickers@innocent.com> - 2024-08-12 21:41 +0100
      Re: If you were to design a netnews protocol today... D <nospam@example.net> - 2024-08-09 22:25 +0200
      Re: If you were to design a netnews protocol today... D <nospam@example.net> - 2024-08-09 22:27 +0200
      Re: If you were to design a netnews protocol today... yeti <yeti@tilde.institute> - 2024-08-09 21:38 +0042
      Re: If you were to design a netnews protocol today... Johanne Fairchild <jfairchild@tudado.org> - 2024-08-13 22:34 -0300
        Re: If you were to design a netnews protocol today... Rich <rich@example.invalid> - 2024-08-14 03:44 +0000
          Re: If you were to design a netnews protocol today... Johanne Fairchild <jfairchild@tudado.org> - 2024-08-14 13:33 -0300
            Re: If you were to design a netnews protocol today... not@telling.you.invalid (Computer Nerd Kev) - 2024-08-15 08:16 +1000
              Re: If you were to design a netnews protocol today... Anton Shepelev <anton.txt@g{oogle}mail.com> - 2024-08-15 19:50 +0300
                Re: If you were to design a netnews protocol today... not@telling.you.invalid (Computer Nerd Kev) - 2024-08-16 08:30 +1000
        Re: If you were to design a netnews protocol today... Richard Kettlewell <invalid@invalid.invalid> - 2024-08-14 18:36 +0100
    Re: If you were to design a netnews protocol today... "Andy K." <andy.k466@gmail.com> - 2024-08-17 16:49 +0200
      Re: If you were to design a netnews protocol today... D <nospam@example.net> - 2024-08-17 21:43 +0200
        Re: If you were to design a netnews protocol today... "Andy K." <andy.k466@gmail.com> - 2024-08-19 13:07 +0200
          Re: If you were to design a netnews protocol today... D <nospam@example.net> - 2024-08-19 19:36 +0200
            Re: If you were to design a netnews protocol today... yeti <yeti@tilde.institute> - 2024-08-19 18:35 +0042
              Re: If you were to design a netnews protocol today... D <nospam@example.net> - 2024-08-19 22:40 +0200
                Re: If you were to design a netnews protocol today... yeti <yeti@tilde.institute> - 2024-08-19 22:20 +0042
                  Re: If you were to design a netnews protocol today... D <nospam@example.net> - 2024-08-20 10:01 +0200
                    Re: If you were to design a netnews protocol today... yeti <yeti@tilde.institute> - 2024-08-20 17:07 +0042
                      Re: If you were to design a netnews protocol today... D <nospam@example.net> - 2024-08-20 20:00 +0200
                Re: If you were to design a netnews protocol today... kludge@panix.com (Scott Dorsey) - 2024-08-20 22:10 +0000
                  Re: If you were to design a netnews protocol today... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-21 07:28 +0000
            Re: If you were to design a netnews protocol today... anthk <anthk@openbsd.home> - 2025-05-12 06:24 +0000

Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7  Next page →

#25480

William Stickers <bill.stickers@innocent.com> wrote:

> Bradley K. Sherman wrote:
> > 
> > A more perfect netnews:
> >  o Automatic rejection of top-posted articles.
> >  o Severe penalties for exceeding 72 characters.
> >  o Automatic elision of "LOL", "ROTFL", "LMAO" etc.
> >  o Life-time ban for using an emoji.
> > 
> >     --bks
> 
[> PMSL!] 
    ^
    |
    |
[automatic elision]

-- 
^Ï^.       Sn!pe, PTB, FIBS      -      Professional Crastinator 

My pet rock Gordon just is.

[toc] | [prev] | [next] | [standalone]

#25493

Sn!pe wrote:
> 
> William Stickers <bill.stickers@innocent.com> wrote:
> 
> > Bradley K. Sherman wrote:
> > > 
> > > A more perfect netnews:
> > >  o Automatic rejection of top-posted articles.
> > >  o Severe penalties for exceeding 72 characters.
> > >  o Automatic elision of "LOL", "ROTFL", "LMAO" etc.
> > >  o Life-time ban for using an emoji.
> > > 
> > >     --bks
> > 
> [> PMSL!] 
>     ^
>     |
>     |
> [automatic elision]

:'-(

Fine, I'm going back to loitering, erm, I mean lurking. <sniff>.

[toc] | [prev] | [next] | [standalone]

#25452

[Multipart message — attachments visible in raw view] — view raw

On Fri, 9 Aug 2024, Stefan Ram wrote:

> Richard Kettlewell <invalid@invalid.invalid> wrote or quoted:
>> * Binary serialization rather than the complex text-based structures we
>>  have in NNTP and the Usenet article format.
>
>  When I read through all this stuff, it seems like every change
>  has just as many pros as cons. Take the point above, for instance.
>  If I think my newsreader is acting up today or isn't showing a
>  certain feature (like grabbing stuff via Message-ID), I can just
>  hop on telnet to the news server and see what's really coming
>  from the server or call up the missing feature directly. With a
>  binary format, that wouldn’t be as straightforward!
>

Amen! The power of text!

[toc] | [prev] | [next] | [standalone]

#25453

On Fri, 9 Aug 2024, Stefan Ram wrote:

> Richard Kettlewell <invalid@invalid.invalid> wrote or quoted:
>> * Machine-readable format specification to reduce ambiguity.
>
>  Wikipedia:
>
> |The "second-system effect" or "second-system syndrome" is the
> |tendency of small, elegant, and successful systems to be
> |succeeded by over-engineered, bloated systems, due to
> |inflated expectations and overconfidence.
>
>  , see also:
>
> "Things You Should Never Do, Part I". (April 6, 2000) - Joel Spolsky
>
>  .

Interesting. I read on an encryption mailinglist some critique of crypto 
developers. They love to develop new things all the time, instead of 
perfecting and learning how to use what we do have.

The argument was to not tinker, and learn how to use, instead of tinkering 
and introducing new bugs and stuff.

Right or wrong, it was a nice discussion.

[toc] | [prev] | [next] | [standalone]

#25456

ram@zedat.fu-berlin.de (Stefan Ram) writes:

>   If I think my newsreader is acting up today or isn't showing a
>   certain feature (like grabbing stuff via Message-ID), I can just
>   hop on telnet to the news server and see what's really coming
>   from the server or call up the missing feature directly. With a
>   binary format, that wouldn’t be as straightforward!

\o/ ____( rlwrap nc newsserver 119 )

-- 
I do not bite, I just want to play.

[toc] | [prev] | [next] | [standalone]

#25503

Richard Kettlewell <invalid@invalid.invalid> writes:

>> Just a thought experiment:
>> if you could/had to make something like a NNTP 2.0 (with no need for  
>> backwards compatibility) and server and client software for it today, what 
>> would it be like?
>> In terms of specifications, technologies used, user interface, etc.

[...]

>   * All messages signed by author and originating server (supporting
>     reputation management)

Can you elaborate on this?  You'd like to bind each message to the
author-public-key and his NNTP server?  So that everyone who he is and
which server he used?  (Can you give an example of how you'd do that?)

[toc] | [prev] | [next] | [standalone]

#25507

In comp.misc Johanne Fairchild <jfairchild@tudado.org> wrote:
> Richard Kettlewell <invalid@invalid.invalid> writes:
> 
>>> Just a thought experiment:
>>> if you could/had to make something like a NNTP 2.0 (with no need for  
>>> backwards compatibility) and server and client software for it today, what 
>>> would it be like?
>>> In terms of specifications, technologies used, user interface, etc.
> 
> [...]
> 
>>   * All messages signed by author and originating server (supporting
>>     reputation management)
> 
> Can you elaborate on this?  You'd like to bind each message to the
> author-public-key and his NNTP server?  So that everyone who he is and
> which server he used?  (Can you give an example of how you'd do that?)

One possibility (which would inherit most if not all of the pgp/gpg 
'key' distribution problem):

1) each user generates a gpg key pair they use for 'usenet2' posts.

2) user uploads public key to some "central source" for others to 
   retreive from [1] for 'validation' purposes.

3) user installs private half of key in their client software

4) for each post, user's client software 'signs' the message using the 
private key, inserting the 'signature' into appropriate message 
'headers' (note, there's a lot left unstated here, I'm spitballing, not 
protocol designing).

5) each server also performs step 1 but there may not need to be a step 
2 for a server /if/ the collective set of servers are the 'central' 
storage of keys and the protocol has a way to supply a public key for 
'server/user X' on demand.

6) for each post, from any user of serverX, serverX further signs the 
message using the serverX private key and inserts the appropriate 
message headers containing the "server signature" (note that here one 
most likely wants this server sig.  to cover [and thus authenticate] 
the user signature headers of the message).

The result, is that a recipient, should they choose to do so, can 
verify that any given message was signed by serverX using the serverX 
public key, and can further verify that the messge was signed by userX 
of serverX via the userX of serverX public key.


[1] Do note that the 'central source' could be the collective set of 
'usenet2' servers, provided there was a way to request the 'key' of 
user 'X' from server 'Y'.  In which case #2 is "uploads public key to 
their 'usenet2' server.

[toc] | [prev] | [next] | [standalone]

#25510

Rich <rich@example.invalid> writes:

> In comp.misc Johanne Fairchild <jfairchild@tudado.org> wrote:
>> Richard Kettlewell <invalid@invalid.invalid> writes:
>> 
>>>> Just a thought experiment:
>>>> if you could/had to make something like a NNTP 2.0 (with no need for  
>>>> backwards compatibility) and server and client software for it today, what 
>>>> would it be like?
>>>> In terms of specifications, technologies used, user interface, etc.
>> 
>> [...]
>> 
>>>   * All messages signed by author and originating server (supporting
>>>     reputation management)
>> 
>> Can you elaborate on this?  You'd like to bind each message to the
>> author-public-key and his NNTP server?  So that everyone who he is and
>> which server he used?  (Can you give an example of how you'd do that?)
>
> One possibility (which would inherit most if not all of the pgp/gpg 
> 'key' distribution problem):
>
> 1) each user generates a gpg key pair they use for 'usenet2' posts.
>
> 2) user uploads public key to some "central source" for others to 
>    retreive from [1] for 'validation' purposes.
>
> 3) user installs private half of key in their client software
>
> 4) for each post, user's client software 'signs' the message using the 
> private key, inserting the 'signature' into appropriate message 
> 'headers' (note, there's a lot left unstated here, I'm spitballing, not 
> protocol designing).
>
> 5) each server also performs step 1 but there may not need to be a step 
> 2 for a server /if/ the collective set of servers are the 'central' 
> storage of keys and the protocol has a way to supply a public key for 
> 'server/user X' on demand.
>
> 6) for each post, from any user of serverX, serverX further signs the 
> message using the serverX private key and inserts the appropriate 
> message headers containing the "server signature" (note that here one 
> most likely wants this server sig.  to cover [and thus authenticate] 
> the user signature headers of the message).
>
> The result, is that a recipient, should they choose to do so, can 
> verify that any given message was signed by serverX using the serverX 
> public key, and can further verify that the messge was signed by userX 
> of serverX via the userX of serverX public key.
>
>
> [1] Do note that the 'central source' could be the collective set of 
> 'usenet2' servers, provided there was a way to request the 'key' of 
> user 'X' from server 'Y'.  In which case #2 is "uploads public key to 
> their 'usenet2' server.

Thanks.

I have not thought even five minutes on this, but it seems complicated.
A large NNTP server should be time-resilient, so, for example, to
eternally be able to verify signatures, we need to keep all used public
keys always available.  Archiving, as we know, is not an easy task.

When I think of a user's network, I think of a kind of mailing lists via
NNTP, but not like Gmane.  I subscribe myself to a group in a server by
getting an authorization from the server (for that group specifically).
I register that authorization in my client.  Now I can post to that
group.  Without an authorization, I'd only be able to read it.  Other
servers can easily host that group for reading.  Servers connected to
these other servers could not post to that group---only read it.  If a
client is external (that is, connected to these other servers) would
ever like to post, the author would write his post and the client would
directly connect to the group's original server, authenticate itself,
and then post.

In other words, let's not share responsibility.  Each server controls
its groups---and lets others easily read it, archive it, disseminate
it.  This way experts can have their own turf, let the world see their
discussion without disturbing them.

How is membership controlled in the Linux kernel mailing list (for
example)?  I don't know.  I'd think someone must approve new members.
I'd like to keep an eye on those discussions via NNTP, but it seems I
cannot easily do that.  Surely someone is archiving that in an NNTP
server somewhere.  I'm on Eternal September.  It should be an easy
matter for me; if it is not, then I think that's an opportunity for new
work.

[toc] | [prev] | [next] | [standalone]

#25514

In comp.misc Johanne Fairchild <jfairchild@tudado.org> wrote:
> When I think of a user's network, I think of a kind of mailing lists via
> NNTP, but not like Gmane.  I subscribe myself to a group in a server by
> getting an authorization from the server (for that group specifically).
> I register that authorization in my client.  Now I can post to that
> group.  Without an authorization, I'd only be able to read it.  Other
> servers can easily host that group for reading.  Servers connected to
> these other servers could not post to that group---only read it.  If a
> client is external (that is, connected to these other servers) would
> ever like to post, the author would write his post and the client would
> directly connect to the group's original server, authenticate itself,
> and then post.
> 
> In other words, let's not share responsibility.  Each server controls
> its groups---and lets others easily read it, archive it, disseminate
> it.  This way experts can have their own turf, let the world see their
> discussion without disturbing them.

It seems to me that much the same could be done with moderated
groups already, but I guess it's a matter of preference whether
this should be a part of the NNTP standard.

> How is membership controlled in the Linux kernel mailing list (for
> example)?  I don't know.  I'd think someone must approve new members.
> I'd like to keep an eye on those discussions via NNTP, but it seems I
> cannot easily do that.  Surely someone is archiving that in an NNTP
> server somewhere.  I'm on Eternal September.  It should be an easy
> matter for me; if it is not, then I think that's an opportunity for new
> work.

A read-only NNTP server for the lore.kernel.org mailing lists is
here:
nntp.lore.kernel.org

It doesn't seem to be properly maintained though, mailing lists
move and apparantly their new groups aren't included, or maybe
they've actually been moved off that server and can't be included
easily. I've never looked into it that closely, but it might be
something you could follow up on.

-- 
__          __
#_ < |\| |< _#

[toc] | [prev] | [next] | [standalone]

#25521

Computer Nerd Kev to Johanne Fairchild:

> > How is membership controlled in the Linux kernel mailing
> > list (for example)?  I don't know.  I'd think someone
> > must approve new members.  I'd like to keep an eye on
> > those discussions via NNTP, but it seems I cannot easily
> > do that.  Surely someone is archiving that in an NNTP
> > server somewhere.  I'm on Eternal September.  It should
> > be an easy matter for me; if it is not, then I think
> > that's an opportunity for new work.
>
> A read-only NNTP server for the lore.kernel.org mailing
> lists is here:
> nntp.lore.kernel.org

Many if not all Linux kernel mailing lists are available for
both reading and posting via NNTP on Gmane.  For a complete
list, type "kernel.org" in the list search box here:

                   https://admin.gmane.io/

and hit Enter.  The Gmane NNTP server is: news.gmane.io .

-- 
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments

[toc] | [prev] | [next] | [standalone]

#25525

In comp.misc Anton Shepelev <anton.txt@g{oogle}mail.com> wrote:
> Computer Nerd Kev to Johanne Fairchild:
> 
>> > How is membership controlled in the Linux kernel mailing
>> > list (for example)?  I don't know.  I'd think someone
>> > must approve new members.  I'd like to keep an eye on
>> > those discussions via NNTP, but it seems I cannot easily
>> > do that.  Surely someone is archiving that in an NNTP
>> > server somewhere.  I'm on Eternal September.  It should
>> > be an easy matter for me; if it is not, then I think
>> > that's an opportunity for new work.
>>
>> A read-only NNTP server for the lore.kernel.org mailing
>> lists is here:
>> nntp.lore.kernel.org
> 
> Many if not all Linux kernel mailing lists are available for
> both reading and posting via NNTP on Gmane.

Sure, but they already mentioned Gmane in the post I was responding
to, so obviously they have some problem with that. Or perhaps what
they were saying is that they can't be bothered connecting to
another NNTP server besides Eternal September, in which case that's
their problem.

-- 
__          __
#_ < |\| |< _#

[toc] | [prev] | [next] | [standalone]

#25512

Johanne Fairchild <jfairchild@tudado.org> writes:
> Richard Kettlewell <invalid@invalid.invalid> writes:
>>> Just a thought experiment:
>>> if you could/had to make something like a NNTP 2.0 (with no need for  
>>> backwards compatibility) and server and client software for it today, what 
>>> would it be like?
>>> In terms of specifications, technologies used, user interface, etc.
>
> [...]
>
>>   * All messages signed by author and originating server (supporting
>>     reputation management)
>
> Can you elaborate on this?  You'd like to bind each message to the
> author-public-key and his NNTP server?  So that everyone who he is and
> which server he used?  (Can you give an example of how you'd do that?)

User signatures:

The client software automatically generates a key pair; signs every
message under it; and distributes the public key with each message.

The high-level effect is to create the option for users to maintain a
persistent identity (denoted by their public key) between their
postings.

It’s useful several things:
- forgery prevention
- reputation management (up-scoring, filtering, etc)
- access control (groups with restricted posting rules of some sort)
- canceling/superseding their their own posts (comparable to
  existing cancel lock functionality)
- authentication of destination public keys for encrypted messages
  across netnews, allowing encrypted groups (necessarily with limited
  membership) or secure user-to-user messaging

A hypothetical netnews replacement might not include all these things,
but it does mean they are options.

It doesn’t _force_ a persistent identity; there’s nothing stopping a
user from generating a fresh key for every posting, for example in an
attempt to frustrate filtering. But no matter: you can filter out
previously unattested identities, if you’re trying to defend yourself
against a troll problem.

In a wider context, it also creates the option of cryptographically
relating users to other cryptographically managed identities, for
example PKIX, OpenPGP, or national identity schemes.

Originating server signatures:

The situation is similar but here there is a key pair per server, which
signs all messages originated on that server. Again public keys are
distributed with messages.

The first effect is to identify who has administrative responsibility
for posts through the server. If a user starts to use a particular
server for abuse of some kind, such as spam, then it gives the server
operator the option of issuing cancels (or perhaps more complex kinds of
policy statement, be creative l-) for the abusive messages.

A second use case would be to authenticate institutional affilation,
e.g. if the server is owned by a university, business, etc. (This might
involve signing the user keys rather than signing the posts - I’ve not
thought this through.)

Logistics:

Key pairs above may actually be hierarchies of key pairs, e.g. with
well-protected root keys delegating to limited-scope operational keys.

Originating server keys could be rolled over relatively frequently
without losing much value.

Under current trends we’d expect to use (at least) a post-quantum
signature scheme, which means large signatures. Even with ML-DSA-44 two
signatures and two public keys adds about 6Kbyte to every message. That
could be reduced a bit by separating key distribution from message
distribution, but on modern networks the overhead isn’t actually that
much, so it might be better to just accept the cost.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#25537

On Wed, 7 Aug 2024 14:32:01 -0000 (UTC)
George Musk wrote:

> Just a thought experiment:
> if you could/had to make something like a NNTP 2.0 (with no need for  
> backwards compatibility) and server and client software for it today, what 
> would it be like?
> In terms of specifications, technologies used, user interface, etc.

Not for nothing, but Secure Scuttlebutt is a pretty cool "next gen
NNTP" option.

https://en.wikipedia.org/wiki/Secure_Scuttlebutt

-- 
AndyK

[toc] | [prev] | [next] | [standalone]

#25540

On Sat, 17 Aug 2024, Andy K. wrote:

> On Wed, 7 Aug 2024 14:32:01 -0000 (UTC)
> George Musk wrote:
>
>> Just a thought experiment:
>> if you could/had to make something like a NNTP 2.0 (with no need for
>> backwards compatibility) and server and client software for it today, what
>> would it be like?
>> In terms of specifications, technologies used, user interface, etc.
>
> Not for nothing, but Secure Scuttlebutt is a pretty cool "next gen
> NNTP" option.
>
> https://en.wikipedia.org/wiki/Secure_Scuttlebutt
>

Long time since I heard about it, but doesn't it have scaling problems?

[toc] | [prev] | [next] | [standalone]

#25564

On Sat, 17 Aug 2024 21:43:50 +0200
D wrote:

> On Sat, 17 Aug 2024, Andy K. wrote:
> 
> > On Wed, 7 Aug 2024 14:32:01 -0000 (UTC)
> > George Musk wrote:
> >  
> >> Just a thought experiment:
> >> if you could/had to make something like a NNTP 2.0 (with no need for
> >> backwards compatibility) and server and client software for it today, what
> >> would it be like?
> >> In terms of specifications, technologies used, user interface, etc.  
> >
> > Not for nothing, but Secure Scuttlebutt is a pretty cool "next gen
> > NNTP" option.
> >
> > https://en.wikipedia.org/wiki/Secure_Scuttlebutt
> >  
> 
> Long time since I heard about it, but doesn't it have scaling problems?

Maybe, but mainly it has discoverability problem. Unless you already
know a community you want to join, it's these days almost impossible
to find some public server/group/whatever.

It doesn't help that there are two concepts now - servers (old) and
rooms (new), and there seems to be a different invite/join process for
each.

I love SSB conceptually, since it's basically like Usenet in its UUCP
beginnings (nodes syncing among each other periodically), but it has
teething problems.

-- 
AndyK

[toc] | [prev] | [next] | [standalone]

#25570

On Mon, 19 Aug 2024, Andy K. wrote:

> On Sat, 17 Aug 2024 21:43:50 +0200
> D wrote:
>
>> On Sat, 17 Aug 2024, Andy K. wrote:
>>
>>> On Wed, 7 Aug 2024 14:32:01 -0000 (UTC)
>>> George Musk wrote:
>>>
>>>> Just a thought experiment:
>>>> if you could/had to make something like a NNTP 2.0 (with no need for
>>>> backwards compatibility) and server and client software for it today, what
>>>> would it be like?
>>>> In terms of specifications, technologies used, user interface, etc.
>>>
>>> Not for nothing, but Secure Scuttlebutt is a pretty cool "next gen
>>> NNTP" option.
>>>
>>> https://en.wikipedia.org/wiki/Secure_Scuttlebutt
>>>
>>
>> Long time since I heard about it, but doesn't it have scaling problems?
>
> Maybe, but mainly it has discoverability problem. Unless you already
> know a community you want to join, it's these days almost impossible
> to find some public server/group/whatever.
>
> It doesn't help that there are two concepts now - servers (old) and
> rooms (new), and there seems to be a different invite/join process for
> each.
>
> I love SSB conceptually, since it's basically like Usenet in its UUCP
> beginnings (nodes syncing among each other periodically), but it has
> teething problems.
>

Ahh got it. Maybe time to bring those improvisational UUCP networks back 
to life then? Why opt for the copy, when you can get the original! ;)

[toc] | [prev] | [next] | [standalone]

#25572

D <nospam@example.net> writes:

> Ahh got it. Maybe time to bring those improvisational UUCP networks
> back to life then? Why opt for the copy, when you can get the
> original! ;)

\o/

I'd join that game.

-- 
I do not bite, I just want to play.

[toc] | [prev] | [next] | [standalone]

#25574

On Mon, 19 Aug 2024, yeti wrote:

> D <nospam@example.net> writes:
>
>> Ahh got it. Maybe time to bring those improvisational UUCP networks
>> back to life then? Why opt for the copy, when you can get the
>> original! ;)
>
> \o/
>
> I'd join that game.
>

Out of curiousity, how did they do discovery in those ancient times? Was 
it word of mouth, or did they have something more sophisticated?

[toc] | [prev] | [next] | [standalone]

#25575

D <nospam@example.net> writes:

> Out of curiousity, how did they do discovery in those ancient times?
> Was it word of mouth, or did they have something more sophisticated?

<https://tldp.org/LDP/nag/node192.html>

I've no idea how uptodate this information still is.

My UUCP (over port 540 over Tor) experiments only connected some own
guinea pigs and I wired every neighbour into the config of every other
one.  So a full graph.  That sure won't fit "playing" with lots of
neighbours well.

When nobody wanted to join and(!) because of the config complexity, I
switched to playing with SMTP directly over Tor, but that turned out to
be as lonely as my previous UUCP experiments.

UUCP can use a phonebook like file and route mail based on that.  I
think we would need that if we want to connect more than a minuscule
amount of neighbours.


When UUCP is mentioned 3 times in a thread, typically someone else will
show up and paste a standard text snippet about NNCP into the thread.

Maybe NNCP really has some tricks UUCP now should learn, but I don't use
Go, so I was not in the mood for a closer look yet.

-- 
xkcd - The blag of the webcomic - Randall 2019-08-26
Chapter 19: How to Send a File
<https://blog.xkcd.com/2019/08/26/how-to-send-a-file/>

[toc] | [prev] | [next] | [standalone]

#25578

On Mon, 19 Aug 2024, yeti wrote:

> D <nospam@example.net> writes:
>
>> Out of curiousity, how did they do discovery in those ancient times?
>> Was it word of mouth, or did they have something more sophisticated?
>
> <https://tldp.org/LDP/nag/node192.html>
>
> I've no idea how uptodate this information still is.
>
> My UUCP (over port 540 over Tor) experiments only connected some own
> guinea pigs and I wired every neighbour into the config of every other
> one.  So a full graph.  That sure won't fit "playing" with lots of
> neighbours well.
>
> When nobody wanted to join and(!) because of the config complexity, I
> switched to playing with SMTP directly over Tor, but that turned out to
> be as lonely as my previous UUCP experiments.
>
> UUCP can use a phonebook like file and route mail based on that.  I
> think we would need that if we want to connect more than a minuscule
> amount of neighbours.
>
>
> When UUCP is mentioned 3 times in a thread, typically someone else will
> show up and paste a standard text snippet about NNCP into the thread.
>
> Maybe NNCP really has some tricks UUCP now should learn, but I don't use
> Go, so I was not in the mood for a closer look yet.
>

Interesting! Thank you very much for the information. With todays compute 
power, I wouldn't discount the phone book method entirely. I think it 
scales better than one might think. On the other hand, keeping it up to 
date and distributing it might be more of a challenge perhaps.

[toc] | [prev] | [next] | [standalone]

Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7  Next page →

Back to top | Article view | comp.misc

csiph-web