info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Konzeption webbasierter Usenet Client
5 views
Skip to first unread message
Sebastian Loncar
Dec 18, 2023, 8:15:00 AM12/18/23
to
Aufgrund der Problematik, dass Google Groups abgeschaltet wird, ziehe
ich ernsthaft, aber noch nicht endgültig, in Erwägung, einen
webbasierten Usenet-Client zu entwickeln.
In diesem Thread möchte ich gerne die wichtigsten Do's und Dont's
sammeln, sowie die grundlegende Konzeption (Brainstorming)
Milestone 1:
1) Nutzung einer bereits vorhandenen Client-Library. Es gibt einige zur
Verfügung, sodass das NNTP-Protokoll nicht selbst neu implementiert
werden muss.
2) Nachrichten werden über Eternal September geladen und in einer
SQLite-Datenbank gespeichert. Pro Gruppe gibt es eine eigene Datei.
3) Anzeige der Nachrichten in einem Webfrontend
Milestone 2:
4) Zum Versenden wird ebenfalls Eternal September verwendet, jedoch mit
den Zugangsdaten des Users, d.h. er trägt seine Zugangsdaten dort ein.
Um mit dem Passwort sicher umzugehen, gibt es mehrere Möglichkeiten,
z.B. Eingabe bei jedem Versenden. Ggf. sollten wir hier Rücksprache mit
dem Betreiber halten.
Für Punkt 4 wäre theoretisch noch kein User-Account seitens des neuen
Web-Usenet-Clients notwendig, lediglich der Eternal September Account.
Milestone 3:
5) Account-Verwaltung, Gruppen-Favoriten
Milestone 4:
6) Suchfunktion. Ich würde hier Elasticsearch vorschlagen.
Das ganze würde opensource auf GitHub gehostet sein.
Nun, da gibt es Rocksolid Light (rslight), welches genau das schon alles
kann. Wäre es nicht klüger, das aufzusetzen? Es wurde erwähnt, dass das
bereits einige machen - aber wer und wo? Und gibt es auch Hostings,
welche (fast) alle Hierarchien registriert haben?
In anderen Worten, wenn es bereits rslight gibt und das schon mehrfach
gehostet wird, dann wäre die oben genannte Idee prinzipiell vergebene
Liebesmüh.
ich ernsthaft, aber noch nicht endgültig, in Erwägung, einen
webbasierten Usenet-Client zu entwickeln.
In diesem Thread möchte ich gerne die wichtigsten Do's und Dont's
sammeln, sowie die grundlegende Konzeption (Brainstorming)
Milestone 1:
1) Nutzung einer bereits vorhandenen Client-Library. Es gibt einige zur
Verfügung, sodass das NNTP-Protokoll nicht selbst neu implementiert
werden muss.
2) Nachrichten werden über Eternal September geladen und in einer
SQLite-Datenbank gespeichert. Pro Gruppe gibt es eine eigene Datei.
3) Anzeige der Nachrichten in einem Webfrontend
Milestone 2:
4) Zum Versenden wird ebenfalls Eternal September verwendet, jedoch mit
den Zugangsdaten des Users, d.h. er trägt seine Zugangsdaten dort ein.
Um mit dem Passwort sicher umzugehen, gibt es mehrere Möglichkeiten,
z.B. Eingabe bei jedem Versenden. Ggf. sollten wir hier Rücksprache mit
dem Betreiber halten.
Für Punkt 4 wäre theoretisch noch kein User-Account seitens des neuen
Web-Usenet-Clients notwendig, lediglich der Eternal September Account.
Milestone 3:
5) Account-Verwaltung, Gruppen-Favoriten
Milestone 4:
6) Suchfunktion. Ich würde hier Elasticsearch vorschlagen.
Das ganze würde opensource auf GitHub gehostet sein.
Nun, da gibt es Rocksolid Light (rslight), welches genau das schon alles
kann. Wäre es nicht klüger, das aufzusetzen? Es wurde erwähnt, dass das
bereits einige machen - aber wer und wo? Und gibt es auch Hostings,
welche (fast) alle Hierarchien registriert haben?
In anderen Worten, wenn es bereits rslight gibt und das schon mehrfach
gehostet wird, dann wäre die oben genannte Idee prinzipiell vergebene
Liebesmüh.
Marco Moock
Dec 18, 2023, 8:32:41 AM12/18/23
to
Am 18.12.2023 um 14:14:56 Uhr schrieb Sebastian Loncar:
> Aufgrund der Problematik, dass Google Groups abgeschaltet wird, ziehe
> ich ernsthaft, aber noch nicht endgültig, in Erwägung, einen
> webbasierten Usenet-Client zu entwickeln.
>
>
> In diesem Thread möchte ich gerne die wichtigsten Do's und Dont's
> sammeln, sowie die grundlegende Konzeption (Brainstorming)
>
> Milestone 1:
>
> 1) Nutzung einer bereits vorhandenen Client-Library. Es gibt einige
> zur Verfügung, sodass das NNTP-Protokoll nicht selbst neu
> implementiert werden muss.
>
> 2) Nachrichten werden über Eternal September geladen und in einer
> SQLite-Datenbank gespeichert. Pro Gruppe gibt es eine eigene Datei.
>
> 3) Anzeige der Nachrichten in einem Webfrontend
RS-Light kann das ja, damit spiele ich gerade rum.
> Aufgrund der Problematik, dass Google Groups abgeschaltet wird, ziehe
> ich ernsthaft, aber noch nicht endgültig, in Erwägung, einen
> webbasierten Usenet-Client zu entwickeln.
>
>
> In diesem Thread möchte ich gerne die wichtigsten Do's und Dont's
> sammeln, sowie die grundlegende Konzeption (Brainstorming)
>
> Milestone 1:
>
> 1) Nutzung einer bereits vorhandenen Client-Library. Es gibt einige
> zur Verfügung, sodass das NNTP-Protokoll nicht selbst neu
> implementiert werden muss.
>
> 2) Nachrichten werden über Eternal September geladen und in einer
> SQLite-Datenbank gespeichert. Pro Gruppe gibt es eine eigene Datei.
>
> 3) Anzeige der Nachrichten in einem Webfrontend
> Milestone 2:
>
> 4) Zum Versenden wird ebenfalls Eternal September verwendet, jedoch
> mit den Zugangsdaten des Users, d.h. er trägt seine Zugangsdaten dort
> ein. Um mit dem Passwort sicher umzugehen, gibt es mehrere
> Möglichkeiten, z.B. Eingabe bei jedem Versenden. Ggf. sollten wir
> hier Rücksprache mit dem Betreiber halten.
sich erst bei E-S registrieren müssen und den Zusammenhang müssen die
erstmal verstehen.
Was spricht dagegen, dafür einen eigenen Server zu betreiben, der ggf.
gar keine Artikel von anderen annimmt, sondern nur welche zu anderen
Peers raushaut?
Wenn man so weit ist kann man aber eh eigentlich nen eigenen
NNTP-Server komplett betreiben.
> 6) Suchfunktion. Ich würde hier Elasticsearch vorschlagen.
kann damit durchsucht werden. Wenn man die Header anzeigen kann im
Web-Frontend müsste man die eigentlich auch per Google finden können.
> Nun, da gibt es Rocksolid Light (rslight), welches genau das schon
> alles kann. Wäre es nicht klüger, das aufzusetzen? Es wurde erwähnt,
> dass das bereits einige machen - aber wer und wo?
https://157.230.63.125/
https://rocksolid.sybershock.com/rocksolid/index.php
www.rocksolidbbs.com
> Und gibt es auch Hostings, welche (fast) alle Hierarchien registriert
> haben?
> In anderen Worten, wenn es bereits rslight gibt und das schon
> mehrfach gehostet wird, dann wäre die oben genannte Idee prinzipiell
> vergebene Liebesmüh.
Aber auch die anderen Hierarchien scheinen nicht vollständig im
Webinterface verfügbar zu sein bei den von mir getesteten Servern.
Stefan Froehlich
Dec 18, 2023, 9:16:26 AM12/18/23
to
On Mon, 18 Dec 2023 14:32:39 Marco Moock wrote:
> Am 18.12.2023 um 14:14:56 Uhr schrieb Sebastian Loncar:
>> 4) Zum Versenden wird ebenfalls Eternal September verwendet,
>> jedoch mit den Zugangsdaten des Users, d.h. er trägt seine
>> Zugangsdaten dort ein. Um mit dem Passwort sicher umzugehen, gibt
>> es mehrere Möglichkeiten, z.B. Eingabe bei jedem Versenden. Ggf.
>> sollten wir hier Rücksprache mit dem Betreiber halten.
> Dürfte Leute, denen Usenet unbekannt ist, vom Posten abhalten,
> weil die sich erst bei E-S registrieren müssen und den
> Zusammenhang müssen die erstmal verstehen.
Es wird auch die meisten anderen davon abhalten und ist zudem
> Am 18.12.2023 um 14:14:56 Uhr schrieb Sebastian Loncar:
>> 4) Zum Versenden wird ebenfalls Eternal September verwendet,
>> jedoch mit den Zugangsdaten des Users, d.h. er trägt seine
>> Zugangsdaten dort ein. Um mit dem Passwort sicher umzugehen, gibt
>> es mehrere Möglichkeiten, z.B. Eingabe bei jedem Versenden. Ggf.
>> sollten wir hier Rücksprache mit dem Betreiber halten.
> Dürfte Leute, denen Usenet unbekannt ist, vom Posten abhalten,
> weil die sich erst bei E-S registrieren müssen und den
> Zusammenhang müssen die erstmal verstehen.
maximal unbequem für den Benutzer.
Auch serverseitig sehe ich wenig Vorteile von Polling (via suck)
gegenüber ein paar ausgewählten Feeds.
> Was spricht dagegen, dafür einen eigenen Server zu betreiben, der
> ggf. gar keine Artikel von anderen annimmt, sondern nur welche zu
> anderen Peers raushaut?
überlegen, womöglich irgendwelche Passörter fremder Kunden fremder
Services bei sich zu speichern. Wenn man das Senden via inn
erledigt, kann man das Empfangen auch gleich damit abfackeln - und
die Datenbank über einen eigenen, lokalen Feed befüllen.
> Wenn man so weit ist kann man aber eh eigentlich nen eigenen
> NNTP-Server komplett betreiben.
einen einzelnen, lokalen Benutzer verwendet wird.
>> 6) Suchfunktion. Ich würde hier Elasticsearch vorschlagen.
> Vorteil des Webinterface: Der Kram wird von Google & Co. indexiert
> und kann damit durchsucht werden. Wenn man die Header anzeigen
> kann im Web-Frontend müsste man die eigentlich auch per Google
> finden können.
Aber viel wichtiger bei der Suche: Was (an Hierarchie und Zeitraum)
soll die denn abdecken? Für die typische Haltezeit eines Servers
braucht man keine Suche, da navigiert man einfach in der passenden
Gruppe. Für unendliche Haltezeit sollte man sich hingegen vorab
Gedanken über den Platzbedarf machen.
> Es fehlt halt einer, der de.*, ger.* usw. hostet.
> Aber auch die anderen Hierarchien scheinen nicht vollständig im
> Webinterface verfügbar zu sein bei den von mir getesteten Servern.
bei mir am Server, allerdings bislang keine Möglichkeit für
schreibenden Zugriff geplant.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
Stefan - die gefälligste Überraschung des Seins!
(Sloganizer)
Sebastian Loncar
Dec 22, 2023, 3:02:58 PM12/22/23
to
Also, ich hab' hier mal was vorbereitet:
- Eine NNTP-Client-Verbindung zum Eternal September herstellen
- Alle Gruppennamen laden (in eine "global.db" SQLite-Datei)
- Für jede Gruppe alle (partiellen) Header laden -> damit kann man
bereits die Baumstruktur aufbauen. Gespeichert in einer jeweiligen
<group-name>.db SQLite-Datei.
- Anschließend für jeden Header die korrekten Header+Body laden.
Um Speicherplatz zu sparen:
- Bekannte/häufig verwendete Header-Namen werden abgekürzt
- Die gesamte Nachricht wird komprimiert (XZ-Kompression bzw. LZMA) -
falls die Kompression jedoch größer als das Original ist, wird das
Original verwendet.
- Die Nachrichten werden als Append-only nacheinander in einer riesigen
Binärdatei gespeichert. Pro Nachricht werden ein paar Flags (z.B.
Kompression ja/nein), Datenlänge, Datenprüfsumme und eine Referenz zum
partiellen Header gespeichert.
- Der Offset in der Binärdatei und die Datei-"Id" werden pro Header in
der SQLite <group-name>.db abgelegt.
Die Idee besteht darin, dass das Ganze als Langzeit-Archiv möglichst
wenig Speicherplatz benötigt und die Nachrichten dennoch schnell
einlesbar sind.
Grafisches Webfrontend folgt später.
Das Projekt ist öffentlich auf GitHub verfügbar und definitiv ein Work
in Progress (Prototyp, nur gucken, nicht anfassen :-) ):
https://github.com/unflow-group/unflow
Mithilfe ist gern erwünscht - und sei es nur in Feedback, Meinungen und
vor allem Antworten auf Fragestellungen:
1) Google Groups hat scheinbar keine NNTP-Server, d.h. man kann den
Inhalt anscheinend nur online scrapen - leider wohl auch ohne die
originalen Header. Erschwerend finde ich nicht mal eine MessageId (also
die originale), sodass ich später auch keine Beständigkeit von original
Archiven deduplizieren kann.
2) Angeblich soll man Google Groups auch nach der Abschaltung zumindest
noch lesen können?
3) Gibt es einen Bulk-Download Befehl im NNTP-Protokoll? Ich lade
derzeit alle Artikel einzeln herunter über den Befehl "ARTICLE
<message-id>|<article number>".
4) Die Message-ID, bleibt diese immer gleich? Gehen wir mal davon aus,
es gibt verschiedene NNTP-Provider mit überschneidenden Gruppen (was ja
im Sinne des Erfinders ist), ist garantiert, dass die Message-ID
konstant über alle Provider ist? Alternativ könnte man einen Fingerprint
über die Header+Body abbilden und damit ein Matching machen - Glaskugel
lässt grüßen...
Natürlich würde ich mich auch auf Coding-Support freuen, träumen darf
man ja... :_)
- Eine NNTP-Client-Verbindung zum Eternal September herstellen
- Alle Gruppennamen laden (in eine "global.db" SQLite-Datei)
- Für jede Gruppe alle (partiellen) Header laden -> damit kann man
bereits die Baumstruktur aufbauen. Gespeichert in einer jeweiligen
<group-name>.db SQLite-Datei.
- Anschließend für jeden Header die korrekten Header+Body laden.
Um Speicherplatz zu sparen:
- Bekannte/häufig verwendete Header-Namen werden abgekürzt
- Die gesamte Nachricht wird komprimiert (XZ-Kompression bzw. LZMA) -
falls die Kompression jedoch größer als das Original ist, wird das
Original verwendet.
- Die Nachrichten werden als Append-only nacheinander in einer riesigen
Binärdatei gespeichert. Pro Nachricht werden ein paar Flags (z.B.
Kompression ja/nein), Datenlänge, Datenprüfsumme und eine Referenz zum
partiellen Header gespeichert.
- Der Offset in der Binärdatei und die Datei-"Id" werden pro Header in
der SQLite <group-name>.db abgelegt.
Die Idee besteht darin, dass das Ganze als Langzeit-Archiv möglichst
wenig Speicherplatz benötigt und die Nachrichten dennoch schnell
einlesbar sind.
Grafisches Webfrontend folgt später.
Das Projekt ist öffentlich auf GitHub verfügbar und definitiv ein Work
in Progress (Prototyp, nur gucken, nicht anfassen :-) ):
https://github.com/unflow-group/unflow
Mithilfe ist gern erwünscht - und sei es nur in Feedback, Meinungen und
vor allem Antworten auf Fragestellungen:
1) Google Groups hat scheinbar keine NNTP-Server, d.h. man kann den
Inhalt anscheinend nur online scrapen - leider wohl auch ohne die
originalen Header. Erschwerend finde ich nicht mal eine MessageId (also
die originale), sodass ich später auch keine Beständigkeit von original
Archiven deduplizieren kann.
2) Angeblich soll man Google Groups auch nach der Abschaltung zumindest
noch lesen können?
3) Gibt es einen Bulk-Download Befehl im NNTP-Protokoll? Ich lade
derzeit alle Artikel einzeln herunter über den Befehl "ARTICLE
<message-id>|<article number>".
4) Die Message-ID, bleibt diese immer gleich? Gehen wir mal davon aus,
es gibt verschiedene NNTP-Provider mit überschneidenden Gruppen (was ja
im Sinne des Erfinders ist), ist garantiert, dass die Message-ID
konstant über alle Provider ist? Alternativ könnte man einen Fingerprint
über die Header+Body abbilden und damit ein Matching machen - Glaskugel
lässt grüßen...
Natürlich würde ich mich auch auf Coding-Support freuen, träumen darf
man ja... :_)
Kay Martinen
Dec 22, 2023, 4:00:03 PM12/22/23
to
Am 18.12.23 um 15:16 schrieb Stefan Froehlich:
gewesen? Genau was Spammer wollen, oder?
> Nichts; es ist für die User angenehmer, und man braucht auch nicht
Technisch vielleicht nicht. Aber menschlich hätte ich zweifel.
>> Wenn man so weit ist kann man aber eh eigentlich nen eigenen
>> NNTP-Server komplett betreiben.
weil gg aufhört. Wo ist da der Vorteil bei dem die Leute sagen könnten
"Cool, darum will ich das"?
Stellt sich niemand die Frage ob es überhaupt Sinn macht einen Ersatz zu
schaffen für etwas das von so vielen eher als Übel angesehen wird?
Es geht hier vielleicht (noch) nicht um's Geld verdienen, aber Kosten
werden wohl anfallen. Und irgendwer muß die tragen.
Einer, der jederzeit sagen kann "war'n Spaß. Ich stampf es ein".
Oder viele, die dann mit irgend einer Art Nutzervereinbarung beteiligt
werden? So eine Art "individual Network" Plus?
Müsste man das; und die Sinnfrage; nicht erst mal klären?
Ｂｙｅ／
／Ｋａｙ
--
"Kann ein Wurstbrot die Welt retten?" :-)
> On Mon, 18 Dec 2023 14:32:39 Marco Moock wrote:
>> Am 18.12.2023 um 14:14:56 Uhr schrieb Sebastian Loncar:
>> Was spricht dagegen, dafür einen eigenen Server zu betreiben, der
>> ggf. gar keine Artikel von anderen annimmt, sondern nur welche zu
>> anderen Peers raushaut?
Ist "Send-Only" nicht genau einer der Kritikpunkte bei google groups
>> Am 18.12.2023 um 14:14:56 Uhr schrieb Sebastian Loncar:
>> Was spricht dagegen, dafür einen eigenen Server zu betreiben, der
>> ggf. gar keine Artikel von anderen annimmt, sondern nur welche zu
>> anderen Peers raushaut?
gewesen? Genau was Spammer wollen, oder?
> Nichts; es ist für die User angenehmer, und man braucht auch nicht
>> Wenn man so weit ist kann man aber eh eigentlich nen eigenen
>> NNTP-Server komplett betreiben.
>> Vorteil des Webinterface: Der Kram wird von Google & Co. indexiert
>> und kann damit durchsucht werden.
>> und kann damit durchsucht werden.
> Ich weiss nicht, ob man das überhaupt haben möchte.
Ich auch nicht. Klingt erst mal so als ob man gg nachbauen wollte nur
weil gg aufhört. Wo ist da der Vorteil bei dem die Leute sagen könnten
"Cool, darum will ich das"?
Stellt sich niemand die Frage ob es überhaupt Sinn macht einen Ersatz zu
schaffen für etwas das von so vielen eher als Übel angesehen wird?
Es geht hier vielleicht (noch) nicht um's Geld verdienen, aber Kosten
werden wohl anfallen. Und irgendwer muß die tragen.
Einer, der jederzeit sagen kann "war'n Spaß. Ich stampf es ein".
Oder viele, die dann mit irgend einer Art Nutzervereinbarung beteiligt
werden? So eine Art "individual Network" Plus?
Müsste man das; und die Sinnfrage; nicht erst mal klären?
Ｂｙｅ／
／Ｋａｙ
--
"Kann ein Wurstbrot die Welt retten?" :-)
Jörg Tewes
Dec 22, 2023, 6:30:25 PM12/22/23
to
Sebastian Loncar schrieb:
--
Bye Jörg
Religionskriege sind Konflikte zwischen erwachsenen Menschen, bei
denen es darum geht, wer den cooleren, imaginären Freund hat. Wenn
Jesus gevierteilt worden wäre, hätten wir heute dann Mobiles über der
Tür hängen?
> 4) Die Message-ID, bleibt diese immer gleich?
Nein, eher das Gegenteil. Eine M-ID soll (muß?) einmalig sein.
--
Bye Jörg
Religionskriege sind Konflikte zwischen erwachsenen Menschen, bei
denen es darum geht, wer den cooleren, imaginären Freund hat. Wenn
Jesus gevierteilt worden wäre, hätten wir heute dann Mobiles über der
Tür hängen?
Peter J. Holzer
Dec 22, 2023, 7:09:08 PM12/22/23
to
On 2023-12-22 20:02, Sebastian Loncar <sebastia...@gmail.com> wrote:
> 4) Die Message-ID, bleibt diese immer gleich? Gehen wir mal davon aus,
> es gibt verschiedene NNTP-Provider mit überschneidenden Gruppen (was ja
> im Sinne des Erfinders ist), ist garantiert, dass die Message-ID
> konstant über alle Provider ist?
Ja. Jeder Artikel wird eineindeutig durch eine Message-Id identifiziert.
> 4) Die Message-ID, bleibt diese immer gleich? Gehen wir mal davon aus,
> es gibt verschiedene NNTP-Provider mit überschneidenden Gruppen (was ja
> im Sinne des Erfinders ist), ist garantiert, dass die Message-ID
> konstant über alle Provider ist?
hp
Sebastian Loncar
Dec 22, 2023, 8:03:27 PM12/22/23
to
On 12/23/23 00:30, Jörg Tewes wrote:
> Sebastian Loncar schrieb:
>> 4) Die Message-ID, bleibt diese immer gleich?
>
> Nein, eher das Gegenteil. Eine M-ID soll (muß?) einmalig sein.
Dass die Message-ID pro Nachricht eindeutig ist, ist klar. Die Frage ist
> Sebastian Loncar schrieb:
>> 4) Die Message-ID, bleibt diese immer gleich?
>
> Nein, eher das Gegenteil. Eine M-ID soll (muß?) einmalig sein.
jedoch, ob sie auch providerübergreifend gleich bleibt. Sprich, wenn man
mehrere überschneidende Quellen (Newssserver) zusammenführt, kann man
sicher sein, dass die Message-ID übergreifend stets gleich ist (pro
Nachricht)? Andernfalls hätte man plötzlich keine Vereinigungsmenge
mehr, sondern Duplikate.
Thomas Hochstein
Dec 23, 2023, 1:45:04 AM12/23/23
to
Sebastian Loncar schrieb:
> Dass die Message-ID pro Nachricht eindeutig ist, ist klar. Die Frage ist
> jedoch, ob sie auch providerübergreifend gleich bleibt.
Natürlich. Das ist entscheidend für das Protokoll. Ein Newsserver lehnt
Artikel mit Message-IDs, die bereits kennt, ab; wird eine Message-ID also
zweimal verwendet, kommt ein Artikel nicht an. Kennt er die Message-ID
noch nicht, nimmt er den Artikel an; würde sie sich also ändern, würde das
zu Duplikaten führen.
> Sprich, wenn man
> mehrere überschneidende Quellen (Newssserver) zusammenführt, kann man
> sicher sein, dass die Message-ID übergreifend stets gleich ist (pro
> Nachricht)?
Ja, natürlich.
-thh
> Dass die Message-ID pro Nachricht eindeutig ist, ist klar. Die Frage ist
> jedoch, ob sie auch providerübergreifend gleich bleibt.
Artikel mit Message-IDs, die bereits kennt, ab; wird eine Message-ID also
zweimal verwendet, kommt ein Artikel nicht an. Kennt er die Message-ID
noch nicht, nimmt er den Artikel an; würde sie sich also ändern, würde das
zu Duplikaten führen.
> Sprich, wenn man
> mehrere überschneidende Quellen (Newssserver) zusammenführt, kann man
> sicher sein, dass die Message-ID übergreifend stets gleich ist (pro
> Nachricht)?
-thh
Ray Banana
Dec 23, 2023, 2:21:38 AM12/23/23
to
Also sprach Sebastian Loncar <sebastia...@gmail.com>
> - Eine NNTP-Client-Verbindung zum Eternal September herstellen
> - Alle Gruppennamen laden (in eine "global.db" SQLite-Datei)
> - Für jede Gruppe alle (partiellen) Header laden -> damit kann man
> bereits die Baumstruktur aufbauen. Gespeichert in einer jeweiligen
> <group-name>.db SQLite-Datei.
> - Anschließend für jeden Header die korrekten Header+Body laden.
Du solltest dabei auch die Nutzungsbedingungen des Newsservers
berücksichtigen:
,---------------------------------------------------------------------
| Systemsicherheit und Ressourcenschonung
| Jegliche Beeinträchtigung der Systemsicherheit und Gefährdung des
| laufenden Betriebs sind untersagt. Mit den Ressourcen des Newsservers
| news.eternal-september.org (Bandbreite, Rechenzeit u.ä.) ist
| verantwortungsvoll und schonend umzugehen.
`----------------------------------------------------------------------
https://www.eternal-september.org/index.php?showpage=terms
https://www.eternal-september.org/stats/news-notice.2023.12.22-04.00.01.html#nnrpd_groups
und den Umstand, dass zur Zeit viele Leute auf dieselbe Idee kommen.
Dein Ansatz ist mit Abstand die ressourcenintensivste (auf den Server
bezogen), die mir in den Sinn kommen könnte. Die sauberste Lösung wäre
mit Sicherheit ein eigener Newsserver mit Peers, ein Leafnode wurde wohl
reichen für deine Zwecke. Leafnode hätte auch den Vorteil, dass du
darüber mehrere Quellserver integrieren kannst.
Alternativ könnte man über UUCP-Batches nachdenken oder eine Lösung mit
suck, bei der über eine eigene .newsrc sichergestellt wird, dass nur
neue Artikel abgeholt werden.
--
Пу́тін — хуйло́
https://www.eternal-september.org
> - Eine NNTP-Client-Verbindung zum Eternal September herstellen
> - Alle Gruppennamen laden (in eine "global.db" SQLite-Datei)
> - Für jede Gruppe alle (partiellen) Header laden -> damit kann man
> bereits die Baumstruktur aufbauen. Gespeichert in einer jeweiligen
> <group-name>.db SQLite-Datei.
> - Anschließend für jeden Header die korrekten Header+Body laden.
berücksichtigen:
,---------------------------------------------------------------------
| Systemsicherheit und Ressourcenschonung
| Jegliche Beeinträchtigung der Systemsicherheit und Gefährdung des
| laufenden Betriebs sind untersagt. Mit den Ressourcen des Newsservers
| news.eternal-september.org (Bandbreite, Rechenzeit u.ä.) ist
| verantwortungsvoll und schonend umzugehen.
`----------------------------------------------------------------------
https://www.eternal-september.org/index.php?showpage=terms
https://www.eternal-september.org/stats/news-notice.2023.12.22-04.00.01.html#nnrpd_groups
und den Umstand, dass zur Zeit viele Leute auf dieselbe Idee kommen.
Dein Ansatz ist mit Abstand die ressourcenintensivste (auf den Server
bezogen), die mir in den Sinn kommen könnte. Die sauberste Lösung wäre
mit Sicherheit ein eigener Newsserver mit Peers, ein Leafnode wurde wohl
reichen für deine Zwecke. Leafnode hätte auch den Vorteil, dass du
darüber mehrere Quellserver integrieren kannst.
Alternativ könnte man über UUCP-Batches nachdenken oder eine Lösung mit
suck, bei der über eine eigene .newsrc sichergestellt wird, dass nur
neue Artikel abgeholt werden.
--
Пу́тін — хуйло́
https://www.eternal-september.org
Marco Moock
Dec 23, 2023, 4:55:21 AM12/23/23
to
Am 22.12.2023 um 21:56:52 Uhr schrieb Kay Martinen:
> Am 18.12.23 um 15:16 schrieb Stefan Froehlich:
> > On Mon, 18 Dec 2023 14:32:39 Marco Moock wrote:
> >> Am 18.12.2023 um 14:14:56 Uhr schrieb Sebastian Loncar:
>
> >> Was spricht dagegen, dafür einen eigenen Server zu betreiben, der
> >> ggf. gar keine Artikel von anderen annimmt, sondern nur welche zu
> >> anderen Peers raushaut?
>
> Ist "Send-Only" nicht genau einer der Kritikpunkte bei google groups
> gewesen? Genau was Spammer wollen, oder?
Wie willst du sowas technisch effektiv verhindern?
> Am 18.12.23 um 15:16 schrieb Stefan Froehlich:
> > On Mon, 18 Dec 2023 14:32:39 Marco Moock wrote:
> >> Am 18.12.2023 um 14:14:56 Uhr schrieb Sebastian Loncar:
>
> >> Was spricht dagegen, dafür einen eigenen Server zu betreiben, der
> >> ggf. gar keine Artikel von anderen annimmt, sondern nur welche zu
> >> anderen Peers raushaut?
>
> Ist "Send-Only" nicht genau einer der Kritikpunkte bei google groups
> gewesen? Genau was Spammer wollen, oder?
Die Spammer würden dann einfach vorher Artikel abholen, wenn erst
danach Posten freigeschaltet wird.
Das Problem bei Google ist, dass Google gar nicht gegen die Spammer
vorgehen WILL.
> > Nichts; es ist für die User angenehmer, und man braucht auch nicht
>
> Technisch vielleicht nicht. Aber menschlich hätte ich zweifel.
>
> >> Wenn man so weit ist kann man aber eh eigentlich nen eigenen
> >> NNTP-Server komplett betreiben.
>
> >> Vorteil des Webinterface: Der Kram wird von Google & Co. indexiert
> >> und kann damit durchsucht werden.
>
> > Ich weiss nicht, ob man das überhaupt haben möchte.
>
> Ich auch nicht. Klingt erst mal so als ob man gg nachbauen wollte nur
> weil gg aufhört. Wo ist da der Vorteil bei dem die Leute sagen
> könnten "Cool, darum will ich das"?
>
> Stellt sich niemand die Frage ob es überhaupt Sinn macht einen Ersatz
> zu schaffen für etwas das von so vielen eher als Übel angesehen wird?
eher, weil Google darüber Spam in großem Umfang zulässt?
rocksolid light bietet ja sowas für andere Hierarchien bereits, bisher
ist da kein Hass, zumindest sehe ich noch keinen.
E-S hatte den Vorgänger Newsportal früher auch.
Stefan Froehlich
Dec 23, 2023, 5:04:11 AM12/23/23
to
On Sat, 23 Dec 2023 10:55:19 Marco Moock wrote:
> Am 22.12.2023 um 21:56:52 Uhr schrieb Kay Martinen:
>> Am 18.12.23 um 15:16 schrieb Stefan Froehlich:
>> > On Mon, 18 Dec 2023 14:32:39 Marco Moock wrote:
>> >> Was spricht dagegen, dafür einen eigenen Server zu betreiben,
>> >> der ggf. gar keine Artikel von anderen annimmt, sondern nur
>> >> welche zu anderen Peers raushaut?
>> Ist "Send-Only" nicht genau einer der Kritikpunkte bei google
>> groups gewesen? Genau was Spammer wollen, oder?
> Wie willst du sowas technisch effektiv verhindern?
> Die Spammer würden dann einfach vorher Artikel abholen, wenn erst
> danach Posten freigeschaltet wird.
Möglicherweise wird der Energieaufwand, den Spammer zu betreiben
> Am 22.12.2023 um 21:56:52 Uhr schrieb Kay Martinen:
>> Am 18.12.23 um 15:16 schrieb Stefan Froehlich:
>> > On Mon, 18 Dec 2023 14:32:39 Marco Moock wrote:
>> >> Was spricht dagegen, dafür einen eigenen Server zu betreiben,
>> >> der ggf. gar keine Artikel von anderen annimmt, sondern nur
>> >> welche zu anderen Peers raushaut?
>> Ist "Send-Only" nicht genau einer der Kritikpunkte bei google
>> groups gewesen? Genau was Spammer wollen, oder?
> Wie willst du sowas technisch effektiv verhindern?
> Die Spammer würden dann einfach vorher Artikel abholen, wenn erst
> danach Posten freigeschaltet wird.
bereit sind, auch deutlich überschätzt (was Usenet betrifft). Ich
glaube nicht, dass es sich jemand zum Ziel setzt, uns mit Werbung zu
fluten, dafür sind wir viel zu wenige und viel zu unbekannt - es
wird wohl eher Kollateralschaden sein.
>> >> Vorteil des Webinterface: Der Kram wird von Google & Co.
>> >> indexiert und kann damit durchsucht werden.
>> > Ich weiss nicht, ob man das überhaupt haben möchte.
>> Ich auch nicht. Klingt erst mal so als ob man gg nachbauen wollte
>> nur weil gg aufhört. Wo ist da der Vorteil bei dem die Leute
>> sagen könnten "Cool, darum will ich das"?
>> Stellt sich niemand die Frage ob es überhaupt Sinn macht einen
>> Ersatz zu schaffen für etwas das von so vielen eher als Übel
>> angesehen wird?
> Wird GG als Übel angesehen, weil es ein öffentliches Archiv bietet
Die Meinungen darüber werden geteilt sein. Nachdem ich selber ein
(kleines) Archiv betreibe liegt nahe, dass ich die Existenz von
Archiven per se nicht als negativ empfinde - ganz im Gegenteil. Die
Frage ist für mich eher: Weshalb wollte ich das von Google & Co
indexiert haben? Ich möchte ja nicht der Welt einen Gefallen tun (so
dass denn überhaupt der Fall wäre), sondern mir selbst plus ein paar
anderen Menschen, die sich vage an einen alten Artikel erinnern und
den gerne noch einmal gelesen hätten.
Sollte Google mein Archiv indexieren, würde das primär Mehrkosten
durch den Traffic und höhere Serverbelastung bedeuten -
möglicherweise sogar mehr durch das Indexieren, als durch die darauf
folgende Nutzung über Suchergebnisse.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
(Sloganizer)
Stefan Froehlich
Dec 23, 2023, 5:11:03 AM12/23/23
to
(warum auch immer, auch damals war es nicht besonders schwierig,
ewige Eindeutigkeit sicherzustellen). Das wäre für aktuelle
Haltezeiten schon ein echtes Problem.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
(Sloganizer)
Marco Moock
Dec 23, 2023, 5:25:21 AM12/23/23
to
Am 22.12.2023 um 21:02:53 Uhr schrieb Sebastian Loncar:
> Um Speicherplatz zu sparen:
> - Bekannte/häufig verwendete Header-Namen werden abgekürzt
Warum das?
> Um Speicherplatz zu sparen:
> - Bekannte/häufig verwendete Header-Namen werden abgekürzt
Bedenke bitte, dass diese Header dann beim Anzeigen wieder vollständig
sein sollen.
> Mithilfe ist gern erwünscht - und sei es nur in Feedback, Meinungen
> und vor allem Antworten auf Fragestellungen:
> 1) Google Groups hat scheinbar keine NNTP-Server, d.h. man kann den
> Inhalt anscheinend nur online scrapen - leider wohl auch ohne die
> originalen Header.
im Newsreader nutzt).
Frage da am besten aber mal die Peers, z.B. die Freie Uni Berlin.
> Erschwerend finde ich nicht mal eine MessageId
> (also die originale), sodass ich später auch keine Beständigkeit von
> original Archiven deduplizieren kann.
> 2) Angeblich soll man Google Groups auch nach der Abschaltung
> zumindest noch lesen können?
> 4) Die Message-ID, bleibt diese immer gleich?
> Gehen wir mal davon aus, es gibt verschiedene NNTP-Provider mit
> überschneidenden Gruppen (was ja im Sinne des Erfinders ist), ist
> garantiert, dass die Message-ID konstant über alle Provider ist?
(NNTP-Server, den der Nutzer benutzt) generiert und darf von anderen
Servern nicht geändert werden.
Natürlich ist es möglich, absichtlich Nachrichten mit gleicher
Message-ID zu generieren und z.B. über verschiedene Server
einzuspielen, um Blödsinn zu machen.
> Alternativ könnte man einen Fingerprint über die Header+Body abbilden
> und damit ein Matching machen - Glaskugel lässt grüßen...
lange.
Marco Moock
Dec 23, 2023, 5:30:13 AM12/23/23
to
Am 23.12.2023 um 10:04:08 Uhr schrieb Stefan Froehlich:
> On Sat, 23 Dec 2023 10:55:19 Marco Moock wrote:
> > Am 22.12.2023 um 21:56:52 Uhr schrieb Kay Martinen:
> >> Am 18.12.23 um 15:16 schrieb Stefan Froehlich:
> >> > On Mon, 18 Dec 2023 14:32:39 Marco Moock wrote:
> >> >> Was spricht dagegen, dafür einen eigenen Server zu betreiben,
> >> >> der ggf. gar keine Artikel von anderen annimmt, sondern nur
> >> >> welche zu anderen Peers raushaut?
>
> >> Ist "Send-Only" nicht genau einer der Kritikpunkte bei google
> >> groups gewesen? Genau was Spammer wollen, oder?
>
> > Wie willst du sowas technisch effektiv verhindern?
> > Die Spammer würden dann einfach vorher Artikel abholen, wenn erst
> > danach Posten freigeschaltet wird.
>
> Möglicherweise wird der Energieaufwand, den Spammer zu betreiben
> bereit sind, auch deutlich überschätzt (was Usenet betrifft). Ich
> glaube nicht, dass es sich jemand zum Ziel setzt, uns mit Werbung zu
> fluten, dafür sind wir viel zu wenige und viel zu unbekannt - es
> wird wohl eher Kollateralschaden sein.
Ich vermute, dass es da nur um Web geht und Usenet genommen wird, weil
> On Sat, 23 Dec 2023 10:55:19 Marco Moock wrote:
> > Am 22.12.2023 um 21:56:52 Uhr schrieb Kay Martinen:
> >> Am 18.12.23 um 15:16 schrieb Stefan Froehlich:
> >> > On Mon, 18 Dec 2023 14:32:39 Marco Moock wrote:
> >> >> Was spricht dagegen, dafür einen eigenen Server zu betreiben,
> >> >> der ggf. gar keine Artikel von anderen annimmt, sondern nur
> >> >> welche zu anderen Peers raushaut?
>
> >> Ist "Send-Only" nicht genau einer der Kritikpunkte bei google
> >> groups gewesen? Genau was Spammer wollen, oder?
>
> > Wie willst du sowas technisch effektiv verhindern?
> > Die Spammer würden dann einfach vorher Artikel abholen, wenn erst
> > danach Posten freigeschaltet wird.
>
> Möglicherweise wird der Energieaufwand, den Spammer zu betreiben
> bereit sind, auch deutlich überschätzt (was Usenet betrifft). Ich
> glaube nicht, dass es sich jemand zum Ziel setzt, uns mit Werbung zu
> fluten, dafür sind wir viel zu wenige und viel zu unbekannt - es
> wird wohl eher Kollateralschaden sein.
es Google Groups gibt und da alles an Spam auch blieb.
> >> >> Vorteil des Webinterface: Der Kram wird von Google & Co.
> >> >> indexiert und kann damit durchsucht werden.
>
> >> > Ich weiss nicht, ob man das überhaupt haben möchte.
>
> >> Ich auch nicht. Klingt erst mal so als ob man gg nachbauen wollte
> >> nur weil gg aufhört. Wo ist da der Vorteil bei dem die Leute
> >> sagen könnten "Cool, darum will ich das"?
>
> >> Stellt sich niemand die Frage ob es überhaupt Sinn macht einen
> >> Ersatz zu schaffen für etwas das von so vielen eher als Übel
> >> angesehen wird?
>
> > Wird GG als Übel angesehen, weil es ein öffentliches Archiv bietet
> > [...]
>
> Die Meinungen darüber werden geteilt sein. Nachdem ich selber ein
> (kleines) Archiv betreibe liegt nahe, dass ich die Existenz von
> Archiven per se nicht als negativ empfinde - ganz im Gegenteil. Die
> Frage ist für mich eher: Weshalb wollte ich das von Google & Co
> indexiert haben?
Threads (Foren, Usenet) von vor 20 Jahren, die heute noch relevant sind.
> Ich möchte ja nicht der Welt einen Gefallen tun (so dass denn
> überhaupt der Fall wäre), sondern mir selbst plus ein paar anderen
> Menschen, die sich vage an einen alten Artikel erinnern und den gerne
> noch einmal gelesen hätten.
Leute, die diese Artikel nie gelesen haben, werden sich auch nicht
erinnern können, sind aber ggf. trotzdem interessiert.
Deshalb werden in Foren ja die Thread auch nicht nach nem Jahr einfach
gelöscht.
Der Grund für die Haltezeiten bei den Newsservern dürfte zumindest
früher hauptsächlich der Speicherplatz gewesen sein.
> Sollte Google mein Archiv indexieren, würde das primär Mehrkosten
> durch den Traffic und höhere Serverbelastung bedeuten -
> möglicherweise sogar mehr durch das Indexieren, als durch die darauf
> folgende Nutzung über Suchergebnisse.
einmal lädt?
Wenn man die Statistiken von E-S & Co anschaut, sind das pro Tag
weniger als 1 GB - das ist bei heutigen Internetanschlüssen Popelkram
gegenüber Spiele-Downloads.
Peter J. Holzer
Dec 23, 2023, 6:57:59 AM12/23/23
to
On 2023-12-23 10:30, Marco Moock <mm+s...@dorfdsl.de> wrote:
> Am 23.12.2023 um 10:04:08 Uhr schrieb Stefan Froehlich:
>> Möglicherweise wird der Energieaufwand, den Spammer zu betreiben
>> bereit sind, auch deutlich überschätzt (was Usenet betrifft). Ich
>> glaube nicht, dass es sich jemand zum Ziel setzt, uns mit Werbung zu
>> fluten, dafür sind wir viel zu wenige und viel zu unbekannt - es
>> wird wohl eher Kollateralschaden sein.
>
> Ich vermute, dass es da nur um Web geht und Usenet genommen wird, weil
> es Google Groups gibt und da alles an Spam auch blieb.
Ich glaube "Usenet" wird (von den GG-Spammern) gar nicht genommen. Die
> Am 23.12.2023 um 10:04:08 Uhr schrieb Stefan Froehlich:
>> Möglicherweise wird der Energieaufwand, den Spammer zu betreiben
>> bereit sind, auch deutlich überschätzt (was Usenet betrifft). Ich
>> glaube nicht, dass es sich jemand zum Ziel setzt, uns mit Werbung zu
>> fluten, dafür sind wir viel zu wenige und viel zu unbekannt - es
>> wird wohl eher Kollateralschaden sein.
>
> Ich vermute, dass es da nur um Web geht und Usenet genommen wird, weil
> es Google Groups gibt und da alles an Spam auch blieb.
wollen Google Groups bespammen, und dass ein Teil davon auch ins Usenet
schwappt, ist bestenfalls ein angenehmer Nebeneffekt.
>> Sollte Google mein Archiv indexieren, würde das primär Mehrkosten
>> durch den Traffic und höhere Serverbelastung bedeuten -
>> möglicherweise sogar mehr durch das Indexieren, als durch die darauf
>> folgende Nutzung über Suchergebnisse.
>
> Wie groß ist das Archiv und wie groß wäre das Problem, wenn Google das
> einmal lädt?
Wenn man eine Site mit vielen Seiten und wenigen Besuchern hat, dann
besteht der Traffic fast ausschließlich aus Bots. Ich habe auf meiner
Website ein RFC-Archiv (stammt noch aus der Zeit, als die IETF-Site
wirklich schlecht war, wird aber automatisch aktuell gehalten und auch
von echten Menschen genutzt), einen (sehr unvollständigen und seit
Jahrzehnten nicht mehr gepflegten) Katalog von Planeten aus der
Perry-Rhodan-Serie und einige Foto-Sammlungen auf meiner Website.
Insgesamt wohl ca. 20000 Seiten, und die grast jede Suchmaschine
regelmäßig (nicht unbedingt täglich, aber recht oft) ab, um zu schauen,
ob sich was geändert hat. Das ist jetzt traffic-mäßig kein Problem aber
geschätzt 1 bis 2 Größenordnungen über dem Traffic, den menschliche
Leser verursachen.
Bei einem Usenet-Archiv wäre das entsprechend mehr.
hp
Stefan Froehlich
Dec 23, 2023, 11:37:36 AM12/23/23
to
On Sat, 23 Dec 2023 11:30:11 Marco Moock wrote:
> Am 23.12.2023 um 10:04:08 Uhr schrieb Stefan Froehlich:
>> On Sat, 23 Dec 2023 10:55:19 Marco Moock wrote:
>> > Am 22.12.2023 um 21:56:52 Uhr schrieb Kay Martinen:
>> >> Am 18.12.23 um 15:16 schrieb Stefan Froehlich:
>> >> > On Mon, 18 Dec 2023 14:32:39 Marco Moock wrote:
>> >> >> Vorteil des Webinterface: Der Kram wird von Google & Co.
>> >> >> indexiert und kann damit durchsucht werden.
>> >> > Ich weiss nicht, ob man das überhaupt haben möchte.
> Am 23.12.2023 um 10:04:08 Uhr schrieb Stefan Froehlich:
>> On Sat, 23 Dec 2023 10:55:19 Marco Moock wrote:
>> > Am 22.12.2023 um 21:56:52 Uhr schrieb Kay Martinen:
>> >> Am 18.12.23 um 15:16 schrieb Stefan Froehlich:
>> >> > On Mon, 18 Dec 2023 14:32:39 Marco Moock wrote:
>> >> >> Vorteil des Webinterface: Der Kram wird von Google & Co.
>> >> >> indexiert und kann damit durchsucht werden.
>> >> > Ich weiss nicht, ob man das überhaupt haben möchte.
>> Die Meinungen darüber werden geteilt sein. Nachdem ich selber ein
>> (kleines) Archiv betreibe liegt nahe, dass ich die Existenz von
>> Archiven per se nicht als negativ empfinde - ganz im Gegenteil.
>> Die Frage ist für mich eher: Weshalb wollte ich das von Google &
>> Co indexiert haben?
> Damit andere das finden können.
Ganz platt gesagt: Weshalb sollten mich andere interessieren?
>> (kleines) Archiv betreibe liegt nahe, dass ich die Existenz von
>> Archiven per se nicht als negativ empfinde - ganz im Gegenteil.
>> Die Frage ist für mich eher: Weshalb wollte ich das von Google &
>> Co indexiert haben?
> Damit andere das finden können.
Mitleser im Usenet gehören irgendwie zur gleichen Art, daher finde
ich es ok, für diese Gemeinde auf eigene Zeit und Kosten ein (eh
sehr überschaubares) Service zur Verfügung zu stellen.
Alles, was darüber hinausgeht müsste schon ein wenigstens
ausgeglichen bilanzierendes Geschäftsmodell sein, und das ist für so
ein Archiv vollkommen abwegig.
>> Ich möchte ja nicht der Welt einen Gefallen tun (so dass denn
>> überhaupt der Fall wäre), sondern mir selbst plus ein paar
>> anderen Menschen, die sich vage an einen alten Artikel erinnern
>> und den gerne noch einmal gelesen hätten.
> Und genau das ist das Problem: Dran erinnern.
> Leute, die diese Artikel nie gelesen haben, werden sich auch nicht
> erinnern können, sind aber ggf. trotzdem interessiert.
nur gewarnt: sie ist wirklich sehr, sehr langsam).
>> Sollte Google mein Archiv indexieren, würde das primär Mehrkosten
>> durch den Traffic und höhere Serverbelastung bedeuten -
>> möglicherweise sogar mehr durch das Indexieren, als durch die
>> darauf folgende Nutzung über Suchergebnisse.
> Wie groß ist das Archiv und wie groß wäre das Problem, wenn Google
> das einmal lädt?
(wenn jemand ältere Bestände hat, bitte einfach vorbeischicken),
das sind derzeit 44 Mio. Postings.
Google würde die regelmäßig durchackern, insbesondere aber auch über
die Querverweise in den References und über die Thread-Ansicht. Wäre
vermutlich verkraftbar, aber ohne irgendwelche Vorteile binde ich
mir das nicht ans Bein.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
(Sloganizer)
Christian Garbs
Dec 25, 2023, 4:34:31 AM12/25/23
to
Mahlzeit!
Sebastian Loncar <sebastia...@gmail.com> wrote:
> 1) Google Groups hat scheinbar keine NNTP-Server, d.h. man kann den
> Inhalt anscheinend nur online scrapen - leider wohl auch ohne die
> originalen Header. Erschwerend finde ich nicht mal eine MessageId (also
> die originale), sodass ich später auch keine Beständigkeit von original
> Archiven deduplizieren kann.
Uff, wann haben die denn das sabotiert? Im Hamburger-Menü an einem
Artikel ist der Menüpunkt "Show original message" weiterhin vorhanden,
da gab es früher den Artikel in Rohform mitsamt Headern. Das ist
jetzt aber grundsätzlich ausgegraut mit der Meldung, dass die "view
member email adresses"-Berechtigung fehlt. Dieses Rechtekonstrukt
macht aber nur für "selbstgebaute" Google-Groups Sinn, nicht für
öffentliche Usenet-Gruppen.
> 3) Gibt es einen Bulk-Download Befehl im NNTP-Protokoll? Ich lade
> derzeit alle Artikel einzeln herunter über den Befehl "ARTICLE
> <message-id>|<article number>".
Um Dein Projekt zum Laufen zu bekommen und zu testen, würde ich nicht
versuchen, alte Artikel auszubuddeln, sondern mich stattdessen an
einen (oder mehrere) aktiven Newsfeed¹ hängen, so dass alle
zukünftigen Artikel bei Dir aufschlagen.
Ob Dein Archiv nun heute startet oder auf dem Stand von vor 4 Wochen
(oder wie hoch halt die Vorhaltezeit von eternal-november ist), macht
in zwei Jahren keinen Unterschied mehr.
Und falls das so gedacht ist, dass sich mehrere Leute die
Archivsoftware lokal installieren, wäre es sehr fies gegenüber dem
Newsserver, wenn jede Installation erstmal den gesamten Newsspool
runterlädt.
Gruß
Christian
¹ Ich würde zumindest ausgehend mit Dir peeren, wobei ich allerdings
kurz vor der Abkündigung von Google Groups noch die GG-Server
rausgefiltert habe ;-) Den Spam kriegtest Du also schon nicht mehr.
--
....Christian.Garbs....................................https://www.cgarbs.de
Am 1.1.2000 sollen alle Computer abstürzen.
Für Windows-Benutzer bleibt alles beim alten.
Sebastian Loncar <sebastia...@gmail.com> wrote:
> 1) Google Groups hat scheinbar keine NNTP-Server, d.h. man kann den
> Inhalt anscheinend nur online scrapen - leider wohl auch ohne die
> originalen Header. Erschwerend finde ich nicht mal eine MessageId (also
> die originale), sodass ich später auch keine Beständigkeit von original
> Archiven deduplizieren kann.
Artikel ist der Menüpunkt "Show original message" weiterhin vorhanden,
da gab es früher den Artikel in Rohform mitsamt Headern. Das ist
jetzt aber grundsätzlich ausgegraut mit der Meldung, dass die "view
member email adresses"-Berechtigung fehlt. Dieses Rechtekonstrukt
macht aber nur für "selbstgebaute" Google-Groups Sinn, nicht für
öffentliche Usenet-Gruppen.
> 3) Gibt es einen Bulk-Download Befehl im NNTP-Protokoll? Ich lade
> derzeit alle Artikel einzeln herunter über den Befehl "ARTICLE
> <message-id>|<article number>".
versuchen, alte Artikel auszubuddeln, sondern mich stattdessen an
einen (oder mehrere) aktiven Newsfeed¹ hängen, so dass alle
zukünftigen Artikel bei Dir aufschlagen.
Ob Dein Archiv nun heute startet oder auf dem Stand von vor 4 Wochen
(oder wie hoch halt die Vorhaltezeit von eternal-november ist), macht
in zwei Jahren keinen Unterschied mehr.
Und falls das so gedacht ist, dass sich mehrere Leute die
Archivsoftware lokal installieren, wäre es sehr fies gegenüber dem
Newsserver, wenn jede Installation erstmal den gesamten Newsspool
runterlädt.
Gruß
Christian
¹ Ich würde zumindest ausgehend mit Dir peeren, wobei ich allerdings
kurz vor der Abkündigung von Google Groups noch die GG-Server
rausgefiltert habe ;-) Den Spam kriegtest Du also schon nicht mehr.
--
....Christian.Garbs....................................https://www.cgarbs.de
Am 1.1.2000 sollen alle Computer abstürzen.
Für Windows-Benutzer bleibt alles beim alten.
Thomas Hochstein
Dec 28, 2023, 5:45:03 PM12/28/23
to
Christian Garbs schrieb:
> Uff, wann haben die denn das sabotiert?
Paar Jahre her, einen genauen Zeitraum habe ich mir nicht gemerkt.
> Im Hamburger-Menü an einem
> Artikel ist der Menüpunkt "Show original message" weiterhin vorhanden,
> da gab es früher den Artikel in Rohform mitsamt Headern. Das ist
> jetzt aber grundsätzlich ausgegraut mit der Meldung, dass die "view
> member email adresses"-Berechtigung fehlt. Dieses Rechtekonstrukt
> macht aber nur für "selbstgebaute" Google-Groups Sinn, nicht für
> öffentliche Usenet-Gruppen.
Jo.
-thh
> Uff, wann haben die denn das sabotiert?
> Im Hamburger-Menü an einem
> Artikel ist der Menüpunkt "Show original message" weiterhin vorhanden,
> da gab es früher den Artikel in Rohform mitsamt Headern. Das ist
> jetzt aber grundsätzlich ausgegraut mit der Meldung, dass die "view
> member email adresses"-Berechtigung fehlt. Dieses Rechtekonstrukt
> macht aber nur für "selbstgebaute" Google-Groups Sinn, nicht für
> öffentliche Usenet-Gruppen.
-thh
Fritz
Dec 31, 2023, 4:58:12 AM12/31/23
to
On 18.12.23 near 14:14, Sebastian Loncar suggested:
Und dann auf diesen über das WEB Interface zugreifen.
<https://stackoverflow.com/questions/10086945/how-does-the-nntp-peering-protocol-works>
--
Fritz
Freunde begrüßen! 👋😊
Trolle, Crackpots, Sockenpuppen, Spinner werden kaum bis gar nicht gelesen!
> 2) Nachrichten werden über Eternal September geladen und in einer
> SQLite-Datenbank gespeichert. Pro Gruppe gibt es eine eigene Datei.
Grundvoraussetzung - eigenen NNTP Server aufsetzten, diesen peeren.
> SQLite-Datenbank gespeichert. Pro Gruppe gibt es eine eigene Datei.
Und dann auf diesen über das WEB Interface zugreifen.
<https://stackoverflow.com/questions/10086945/how-does-the-nntp-peering-protocol-works>
--
Fritz
Freunde begrüßen! 👋😊
Trolle, Crackpots, Sockenpuppen, Spinner werden kaum bis gar nicht gelesen!
Juergen Helbing
Jan 19, 2024, 10:24:12 AMJan 19
to
Sebastian Loncar <sebastia...@gmail.com> wrote:
>Aufgrund der Problematik, dass Google Groups abgeschaltet wird, ziehe
>ich ernsthaft, aber noch nicht endgültig, in Erwägung, einen
>webbasierten Usenet-Client zu entwickeln.
>[...]
>Aufgrund der Problematik, dass Google Groups abgeschaltet wird, ziehe
>ich ernsthaft, aber noch nicht endgültig, in Erwägung, einen
>webbasierten Usenet-Client zu entwickeln.
Hat sich denn in deinem Umfeld unterdessen heraus kristallisiert, ob
das sinnvoll und/oder wünschenswert wäre ?
>Nun, da gibt es Rocksolid Light (rslight), welches genau das schon alles
>kann. Wäre es nicht klüger, das aufzusetzen? Es wurde erwähnt, dass das
>bereits einige machen - aber wer und wo? Und gibt es auch Hostings,
>welche (fast) alle Hierarchien registriert haben?
>
>In anderen Worten, wenn es bereits rslight gibt und das schon mehrfach
>gehostet wird, dann wäre die oben genannte Idee prinzipiell vergebene
>Liebesmüh.
arbeitet ?
Schade, dass dein Thread so eingeschlafen ist.
Dass Google Groups schliesst, könnte ja durchaus eine Initialzündung,
für etwas besseres sein.
--
Juergen
(Mynews)
Marco Moock
Jan 19, 2024, 11:26:52 AMJan 19
to
Am 19.01.2024 um 15:23:59 Uhr schrieb Juergen Helbing:
> Hast du unterdessen einen Userkreis gefunden, der mit Rocksolid
> arbeitet ?
Den gibt es laut dem Betreiber von novabbs bereits.
> Hast du unterdessen einen Userkreis gefunden, der mit Rocksolid
> arbeitet ?
Da der aber aktuell kein de.* anbietet, sondern nur einen Teil von
Big-8, wirst du im deutschen Usenet erstmal niemanden finden.
X-Rslight* wird da als Header genutzt. Anhand dessen kannst du einen
Newsspool danach durchsuchen. Kannst ja mal mit misc.test ausprobieren.
Juergen Helbing
Jan 22, 2024, 3:11:26 AMJan 22
to
Marco Moock <mm+s...@dorfdsl.de> wrote:
>Am 19.01.2024 um 15:23:59 Uhr schrieb Juergen Helbing:
>
>> Hast du unterdessen einen Userkreis gefunden, der mit Rocksolid
>> arbeitet ?
>
>Den gibt es laut dem Betreiber von novabbs bereits.
> [...]
>Am 19.01.2024 um 15:23:59 Uhr schrieb Juergen Helbing:
>
>> Hast du unterdessen einen Userkreis gefunden, der mit Rocksolid
>> arbeitet ?
>
>Den gibt es laut dem Betreiber von novabbs bereits.
Danke für die Info.
Das ist ja genau was ursprünglich gesucht war.
Jetzt braucht es nur noch jemanden, der das für DE.* anbietet.
So long.
Juergen.
Marco Moock
Jan 22, 2024, 3:22:53 AMJan 22
to
Am 22.01.2024 um 08:11:09 Uhr schrieb Juergen Helbing:
> Jetzt braucht es nur noch jemanden, der das für DE.* anbietet.
Das teste ich gerade, aber Posten ist deaktiviert und wird auch vorerst
> Jetzt braucht es nur noch jemanden, der das für DE.* anbietet.
deaktiviert bleiben.
0 new messages