Gnutella: Das Protokoll, das länger überlebte als die Welt, die es erschuf

 (rickcarlino.com)
1 Punkte von GN⁺ 10 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Gnutella ist heute fast ein vergessenes Filesharing-Protokoll, war aber ein reales Beispiel dafür, wie Millionen Nutzer ohne jedes Bewusstsein für Dezentralisierung ein Problem beim MP3-Download lösten
  • 2000–2001 erreichte die Internetverbreitung in den USA 50 %, MP3-Player wurden günstiger, Streaming hatte klare Grenzen, und die Kultur der direkten Dateiverwaltung förderte die Verbreitung
  • Dank einer serverlosen Architektur und dem Fehlen eines Single Point of Failure war das System nach der Einstellung durch AOL kaum noch zurückzudrehen und lief trotz jahrelanger Abschaltversuche weiter
  • Die Grundstruktur ist eine Kombination aus HTTP-Dateiübertragung und einem TCP-Gossip-Protokoll; PING/PONG, QUERY/QUERYHIT und PUSH übernehmen Suche, Antwort und Firewall-Umgehung
  • Aus dem Mainstream verschwand es nicht wegen eines unmittelbaren technischen Scheiterns, sondern weil das damalige Nutzerumfeld verschwand; das Netzwerk selbst existiert in kleinerem Maßstab weiter

Warum Gnutella so lange überlebt hat

  • Gnutella ist ein Filesharing-Protokoll, das viele vergessen haben, aber ein Beispiel dafür, wie Millionen ganz normaler Nutzer ein reales Problem lösen wollten, ohne sich überhaupt für Dezentralisierung zu interessieren
  • Die Nutzer beteiligten sich nicht wegen Motiven wie steigenden Token-Werten am Gnutella-Netzwerk, sondern wegen MP3-Downloads; das Netzwerk wuchs explosionsartig, blieb danach fast ein Jahrzehnt in einer stabilen Phase und hielt anschließend mit geringerer Nutzung einen langen Nachlauf
  • Gnutella war die zugrunde liegende Technologie unter sichtbareren Projekten wie LimeWire, und durch das Modell der Walled Gardens moderner Plattformen gibt es heute sogar Internetnutzer, die sich kaum noch an das Dateisystem selbst erinnern
  • Das Gnutella-Projekt begann, als eine von AOL eingestellte interne Demo öffentlich durchsickerte; wegen des serverlosen, dezentralen Designs ließ sich das nach der Veröffentlichung kaum noch rückgängig machen
  • Gnutella lief trotz Abschaltversuchen über Jahre weiter, und selbst Kopien des ursprünglichen Gnutella.exe sind noch auf archive.org zu finden
  • Warum es schwerfällt, Gnutella als gescheitertes Protokoll zu betrachten, ist klar
    • Es skalierte auf Millionen gleichzeitig aktiver Nutzer und florierte rund 10 Jahre lang als Mainstream-Anwendungsfall
    • Aus dem Mainstream verschwand es nicht wegen eines unmittelbaren Scheiterns des Protokolls selbst, sondern weil das Nutzerumfeld, in dem Gnutella entstand, verschwand
    • Es läuft bis heute in kleinerem Maßstab weiter

Historische Bedingungen für die Verbreitung

  • Um 2000–2001 erreichte die Internetverbreitung unter US-Verbrauchern 50 %, und das Internet wandelte sich gerade von einem Werkzeug für Enthusiasten zu einer alltäglichen Infrastruktur
  • Dass Musikdateien so häufig geteilt wurden, lag an mehreren gleichzeitig wirkenden Bedingungen
    • Die Musikindustrie konnte sich nicht an veränderte Verbraucherpräferenzen anpassen
    • MP3-Player und Solid-State-Speicher wurden billiger und breiter verfügbar
    • Über langsame Einwahlverbindungen war Musik-Streaming nicht praktikabel
    • Speicherplatz, Verzeichnisse, Backups und heruntergeladene Dateien selbst zu verwalten, war damals selbst für normale Computernutzer akzeptabel
  • Diese Bedingungen schufen ein goldenes Zeitalter des Filesharings, das bis in die frühen 2010er Jahre anhielt, und LimeWire blieb als repräsentativer Name dieser Erfahrung in Erinnerung
  • Gnutella war schwer abzuschalten, weil es keinen Single Point of Failure gab, und das Basisprotokoll war zwar einfach, ließ sich aber dank optionaler Erweiterungen in der Spezifikation leicht ausbauen

Grundlegender Charakter des Protokolls

  • Für die meisten Nutzer war Gnutella ein Werkzeug zur Dateiübertragung, im Kern war es aber eher eine P2P-Suchmaschine für Blobs
  • Prinzipiell hätte es auch für ein einfaches DNS, eine globale Key/Value-Metadaten-Abfragetabelle oder einen Matchmaking-Dienst für Unreal-Tournament-Ligen dienen können, historisch blieb es aber als Download von Dateien passend zu Suchbegriffen in Erinnerung, insbesondere für MP3-Downloads
  • Der Entwurf der Gnutella-0.6-Spezifikation erklärt, dass gemeinsam genutzte Ressourcen alles Mögliche sein können: Zuordnungen zu anderen Ressourcen, kryptografische Schlüssel, Dateien aller Art oder Metadaten zu Ressourcen, die per Schlüssel adressiert werden können
  • Ein typischer Nutzungsablauf sah so aus
    • Man startete einen Gnutella-Client wie LimeWire, BearShare oder GTK-Gnutella
    • Der Client verband sich mit einigen Peers irgendwo im Internet
    • Der Nutzer gab einen Suchbegriff wie LinkinPark.mp3.exe ein
    • Die Anfrage verbreitete sich von Peer zu Peer nach außen durch das Netzwerk
    • Nach und nach kamen Ergebnisse von beliebigen Rechnern auf der ganzen Welt zurück
    • Anhand der Dateinamen schätzte der Nutzer ab, ob es sich um Fälschungen handelte, verglich Verbindungsgeschwindigkeiten und hoffte, keinen Virus zu erwischen
    • Wählte man eine Datei aus, lud der Client Stücke davon direkt per HTTP von den Rechnern anderer Nutzer herunter
  • Man konnte beim Herunterladen falscher Dateien zufällig neue Inhalte entdecken oder sich Malware einfangen; dieses erkundende Sammeln verschwand mit dem Aufkommen von Empfehlungsmaschinen
  • Clients boten üblicherweise vier Hauptfunktionen
    • Query Manager: Behandelte Suchanfragen, die sich langsam über Tausende Peers ausbreiteten
    • Dateimanager: Legte Verzeichnisse oder Pfade zum Teilen sowie den Speicherort für Downloads fest
    • Transfer Manager: Übernahm Wiederaufnahme, Aufteilung und Verwaltung bidirektionaler Dateiübertragungen
    • Zusatzfunktionen: Dazu gehörten IRC-Chat, Foren, Monitoring von Suchanfragen oder das Erkunden bestimmter Hosts, vieles davon war aber nicht Teil des eigentlichen Protokolls
  • Im Gnutella-Ökosystem gab es Marktführer wie LimeWire, aber mehrere Clients existierten nebeneinander, und unabhängige Entwickler konnten auch eigene Clients von Grund auf neu schreiben
  • Bei der Implementierung des Gnutella Bun Client zeigte sich, dass vieles nicht in der Spezifikation stand, Funktionen undokumentiert waren oder auf zusätzliche Spezifikationen verteilt vorlagen; das Protokoll entwickelte sich organisch weiter

Die Kombination aus HTTP und Gossip-Protokoll

  • Auf den ersten Blick scheint Filesharing möglich, wenn man auf einem privaten Rechner einen HTTP-Server startet und die IP-Adresse bekanntgibt, doch heute ist es durch NAT, Firewalls und Richtlinien von Heim-ISPs schwer, eingehende TCP-Ports offenzulegen
  • Vor 20 Jahren war es deutlich üblicher, auf dem lokalen Rechner einen kleinen HTTP-Server zu betreiben und ihn über eine öffentliche IP erreichbar zu machen
  • Gnutella nutzte dieses Umfeld, damit jeder Teilnehmer innerhalb eines Meshs aus miteinander gossipenden Peers Dateien hosten konnte
  • Die eigentliche Übertragungsphase beim Herunterladen über LimeWire ähnelte dem Abruf einer Datei mit curl oder wget
  • Nur mit einem HTTP-Server entsteht aber noch kein P2P-Filesharing-Netzwerk
    • Schon damals boten ISPs oft keine stabilen statischen IP-Adressen an
    • Eine heute geteilte IP-Adresse konnte morgen schon eine andere sein
    • Eine zufällige URL wie http://74.6.231.21:4000 war wahrscheinlich in keiner Suchmaschine indexiert und wurde offline, sobald man den Laptop zuklappte
  • Deshalb betrieben Gnutella-Clients neben dem HTTP-Server auch ein TCP-basiertes Gossip-Protokoll
    • So machten sie in einem Mesh aus Peers, die ihre gemeinsamen Verzeichnisse per HTTP bereitstellten, auf ihre Existenz aufmerksam
    • Informationen wie Peer-Adressen, Bandbreite, Latenz und Suchanfragen wanderten durch dieses Mesh
    • Es gab Werkzeuge für den Umgang mit Firewalls, doch zur Lösung moderner NAT-Probleme waren später Erweiterungen nötig
  • Die Grundrolle eines Gnutella-Knotens bestand aus drei Teilen
    • Über einen lokalen HTTP-Server Dateien an Interessierte übertragen
    • Verfügbare Dateien über Gossip-Nachrichten suchen und bekanntmachen
    • Gegebenenfalls Techniken zur Umgehung von Firewalls einsetzen
  • Da Gnutella keinen zentralen Einstiegspunkt und kein Benutzerregister hat, entdeckt man nach dem Eintritt ins Mesh neue Peers, eingehende Suchanfragen und sonstigen Netzwerkverkehr von selbst

Bootstrapping

  • Bootstrapping ist der Prozess, zunächst einige Start-Peers zu finden, um in ein P2P-Mesh hineinzukommen, zu dem man weder eingeladen wurde noch dessen Eingangstür sichtbar ist
  • Das globale Gnutella-Netzwerk ist eine Mischung aus IP-Adressen von Teilnehmern; schon die Verbindung zu einem einzigen verlässlichen Peer im Hauptnetz reicht aus, um den Netzwerkverkehr einer großen Nutzermenge zu sehen
  • Mit der Zeit entdeckt man über PONG-Nachrichten weitere Peers, und die Peerliste wird zur späteren Wiederverbindung auf Festplatte gespeichert
  • Wegen wechselnder IP-Adressen oder Offline-Zeiten fällt ein Teil dieser gespeicherten Peers mit der Zeit aus, und der Client probiert die Liste durch, bis er wieder gültige Peers findet
  • Wer das Netzwerk zum ersten Mal betritt oder nach längerer Abwesenheit zurückkehrt, kommt mit einer alten Liste unter Umständen nicht weit, daher ist Bootstrapping nötig
  • Die häufigste Methode dafür ist der Gnutella Web Cache (GWebCache)
    • Ein Verbund unabhängig betriebener Webserver von Freiwilligen, meist kleine Webanwendungen in Form von CGI- oder PHP-Skripten
    • Sie protokollieren die IP-Adressen von Gnutella-Teilnehmern, die ihre Informationen freiwillig bereitstellen
    • Sie speichern IPs oder Domains anderer GWebCache-Server für den Fall, dass der aktuelle Server ausfällt
    • Sie liefern Listen alternativer GWebCache-Server
    • Sie liefern Listen aktuell bekannter IP-Adressen von Teilnehmern im Gnutella-Netzwerk
  • Manche Gnutella-Clients sprechen Cache-Server automatisch an, bei anderen muss man die IPs in eine Konfigurationsdatei oder in das Einstellungsmenü kopieren
  • Sobald man mit Start-Peers verbunden ist, sammelt man über Netzwerknachrichten indirekt weitere Peers ein, wodurch die Abhängigkeit vom Cache sinkt
  • GWebCache ist kein zentraler Flaschenhals
    • Es existieren mehrere voneinander unabhängige GWebCache-Server
    • Es gibt mehrere Möglichkeiten, einen Client auch ohne GWebCache zu bootstrappen
    • Selbst ohne GWebCache könnte Gnutella in weniger komfortabler Form weiterbestehen
  • Ein Beispiel für eine Anfrage nach einer Bootstrap-Liste
    • Hängt man ?get=1&client=TEST&version=1 an das Ende der URL an, kann man eine Liste abrufen, wird bei zu vielen Anfragen aber schnell rate-limitiert
http://cache.jayl.de/g2/gwc.php
http://gweb.4octets.co.uk/skulls.php
http://midian.jayl.de/g2/bazooka.php
http://p2p.findclan.net/skulls.php
http://skulls.gwc.dyslexicfish.net/skulls.php
  • Die Ausgabe sieht zum Beispiel so aus
H|106.107.193.27:23459|88579
H|182.233.59.26:23464|88581
U|http://bj.ddns.net/skulls/skulls.php|208999
U|http://scissors.gwc.dyslexicfish.net:3709/|341201
  • Einträge, die mit H beginnen, sind Peers; Einträge mit U sind redundante Cache-Server, die später genutzt werden können

Zentrale Nachrichtentypen

  • Gnutella ist ein TCP-basiertes Protokoll, und wenn man sich mit einem Peer verbindet, der eingehende Verbindungen akzeptiert, erfolgt zuerst ein Handshake
  • Der Client sendet GNUTELLA CONNECT/0.4 oder GNUTELLA CONNECT/0.6; antwortet die Gegenstelle positiv, ist die Verbindung hergestellt und binäre Gnutella-Nachrichten beginnen zu fließen
  • Alle binären Nachrichten beginnen mit einem 23-Byte-Header
    • Der Header enthält Nachrichten-ID, Payload-Typ, TTL, Hop-Anzahl und Payload-Länge
    • TTL ist die verbleibende Lebensdauer der Nachricht, die Hop-Anzahl die bereits zurückgelegte Strecke
    • TTL + Hops steht für die ursprünglich beabsichtigte Reichweite der Nachricht
  • Im Kern gibt es praktisch fünf Nachrichtentypen
    • PING: Erkennt lebende Peers, Payload-Typ 0x00
    • PONG: Antwort auf PING mit IP-Adresse, Port und Freigabestatistiken, Payload-Typ 0x01
    • QUERY: Vom Nutzer oder einem nahegelegenen Peer gestartete Suchanfrage, Payload-Typ 0x80
    • QUERYHIT: Positive Antwort auf QUERY mit Dateiergebnissen und Verbindungsinformationen für den Download, Payload-Typ 0x81
    • PUSH: Umgehungslösung für Uploader hinter Firewalls; fordert den Dateibesitzer auf, eine Rückverbindung zum Downloader aufzubauen, Payload-Typ 0x40
  • Es gibt auch eine BYE-Nachricht, sie ist aber nicht zwingend erforderlich
  • Protokollnachrichten unterstützen Erweiterungsdatenfelder, sodass Clients Funktionen ergänzen können, ohne das gesamte Netzwerk zu stören
  • GTK-Gnutella unterstützt Funktionen wie TLS, IPv6 und UDP, die im kleinen Kernprotokoll ursprünglich nicht enthalten waren

Protokollerweiterungen

  • Wahrscheinlich ließe sich ein funktionierender Gnutella-Client bauen, wenn man nur die fünf Nachrichtentypen implementiert, aber die Spezifikation ist fast 30 Jahre alt und das Ökosystem ist nicht stehengeblieben
  • Gnutella ließ Raum, neue Ideen in alte Pakete einzubauen
  • GGEP (Gnutella Generic Extension Protocol) bietet einen allgemeinen Bereich für Erweiterungsdaten innerhalb normaler Nachrichten
  • HUGE (Hash/URN Gnutella Extensions) ermöglicht es Clients, Dateien per SHA-Hash zu identifizieren, statt nur anhand des Dateinamens zu suchen
  • Es gibt Berichte über Unterstützung für XML-Erweiterungs-Payloads, doch die Spezifikation behandelt dies in der Vergangenheitsform, und im heutigen Netzwerkverkehr wurde es nicht beobachtet
  • Das ursprüngliche Design war klein, aber flexibel genug, um weiterzuwachsen

Wie Suche und Übertragung funktionieren

  • PING/PONG-Nachrichten fungieren als Herzschlag zwischen Knoten
    • PING hat außer dem normalen 23-Byte-Header keine Pflicht-Payload, kann aber optionale GGEP-Erweiterungsdaten enthalten
    • PONG enthält den Port, die IPv4-Adresse, die Anzahl der freigegebenen Dateien und die Anzahl der freigegebenen Kilobyte des antwortenden Servent
    • Knoten sammeln die an PONG angehängten IP-/Port-Informationen, werden dadurch besser verbundene Mitglieder des Meshs und speichern diese Daten für spätere Sitzungen
  • QUERY/QUERYHIT funktionieren ähnlich wie PING/PONG, tragen aber statt Peer-Werbung den Suchverkehr
    • QUERY enthält ein Feld für die Mindestgeschwindigkeit bzw. Übertragungsbandbreite, gefolgt von einem NUL-terminierten Suchstring
    • Beispiel: beethoven.mp3
    • QUERY-Nachrichten breiten sich flutartig vom Absender nach außen aus, und QUERYHIT-Nachrichten kehren mit Ergebnissen wieder in Richtung des Absenders zurück
    • QUERYHIT enthält IP-Adresse, Port, Geschwindigkeit und Ergebnismenge des Antwortenden
    • Jedes Ergebnis enthält Dateindex, Dateigröße, Dateiname sowie optionale Metadaten oder Erweiterungen
    • Der Dateindex wird später verwendet, wenn die Datei per HTTP angefordert wird
  • Wegen des Flood-Routing bei Gnutella trafen Ergebnisse nur langsam ein, und bis zur Vollständigkeit konnten Minuten vergehen
  • Die Ingenieure von LimeWire entwickelten dynamisches Query Routing, um das besser skalierbar zu machen
    • Sie nutzten Bloom-Filter und eine clevere Netzwerktopologie
    • Diese fortgeschrittene Konfiguration ermöglichte die Skalierung auf Millionen Nutzer, ohne an Flood-Routing zu scheitern
    • Bis heute implementieren die meisten Mainstream-Clients dieses System

PUSH und Firewalls

  • PUSH-Nachrichten sind eine Umgehungslösung, damit manche HTTP-Server Firewalls überwinden können, lösen aber nicht alle Fälle
  • Statt wie bei normalem HTTP den Client mit dem Server verbinden zu lassen, nähert sich das Modell eher einer Aufforderung an den Server, seinerseits den Client zu kontaktieren
  • Eine PUSH-Nachricht enthält die Servent-ID und weitere Kennungen, die der Uploader benötigt, um den Downloader zu finden
  • Weil der Client keine direkte Verbindung herstellen kann, bittet er die Gegenseite um eine Rückverbindung und die Dateiübertragung
  • Details finden sich in der Gnutella-Spezifikation
  • Moderne Clients verwenden zusätzliche Techniken und UDP-Erweiterungen, um solche Probleme eleganter zu behandeln

Verbleibende Bedeutung und Referenzen

  • Dank eines guten frühen Designs skalierte Gnutella auf Millionen gleichzeitige Nutzer, entging Blockierungsversuchen und blieb über Jahrzehnte ohne externe Hilfe online
  • Dass es sich nicht um ein Netzwerk handelte, das beim ersten echten Traffic zusammenbrach, sondern um ein Netzwerk, das als Teil der Y2K-Kultur entstand und noch immer nicht verschwunden ist, zeigt die Robustheit des Designs
  • Der naheliegende Schluss ist, dass Gnutella vor allem deshalb verblasste, weil es länger überlebte als die Welt, die es hervorgebracht hatte
  • Das Netzwerk selbst überlebte länger als viele Websites, die Materialien zum Protokoll hosteten

  • Weiterführende Links

    • GTK-Gnutella GitHub - Ein Client, den man verwenden kann, wenn man Gnutella in den 2020er Jahren tatsächlich nutzen möchte; der leitende Maintainer war an der Ausarbeitung der Gnutella-0.6-Spezifikation beteiligt und ist weiterhin aktiv
    • Gnutella Bun Client GitHub - Eine als Hobbyprojekt entstandene Gnutella-Client-Implementierung in TypeScript/Bun, die tatsächlich funktioniert und weitgehend mit GTK-Gnutella kompatibel ist, aber nicht vollständig
    • Gnutella Terminology Glossary - Ein Glossar zu Gnutella-Begriffen und verwandten Konzepten wie QRP, GGEP und GIV
    • Gnutella Forums - Ein altes Forum für Gnutella-Clients, Fehlersuche und Netzwerkdiskussionen, das Stand 2026 nicht mehr besonders aktiv ist
    • Cap’n Bry’s Gnutella Site - Eine alte Gnutella-Fanseite
    • Annotated Gnutella Protocol Specification v0.4 - Die ursprüngliche und kommentierte Gnutella-0.4-Protokollspezifikation
    • Gnutella Protocol 0.6 Draft - Der spätere Entwurf der Gnutella-0.6-Protokollspezifikation
    • Query Routing Protocol Spec - Die Spezifikation von QRP, dem Gnutella-Query-Routing-System zur Verringerung ineffizienten Floodings; die Diagramme sind verschwunden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 10 시간 전
Lobste.rs-Kommentare

  • Ich erinnere mich an Gnutella vor allem als etwas, mit dem man passend zu Suchbegriffen ganz leicht viele Dateien herunterladen konnte, meist MP3s, aber da war auch noch dieses „andere Zeug“
    Schön, dass das nostalgische Gefühle weckt, und schade, dass das heutige Web zu einem Monster geworden ist
    Mitte der 2000er war das Studentenwohnheim-Netz ein flaches Netzwerk, und iTunes war extrem populär; damit konnte man Musik mit jeder Person im Netzwerk teilen
    Ich hatte meinen neuen 64-Bit-HP-Laptop von Circuit City innerhalb einer Woche mit Evanescence und Green Day gefüllt, und es fühlte sich an, als bräuchte ich den Columbia House CD Club nicht mehr

    • Im Wohnheim gab es ein Filesharing-Netzwerk, und die IT-Abteilung wusste inoffiziell natürlich davon, tat offiziell aber so, als wüsste sie von nichts
      Ein paar Jahre nach meinem Abschluss sprach dann jemand vor der falschen Person darüber, wodurch die IT offiziell davon erfuhr, und am Ende musste es abgeschaltet werden
    • War es vielleicht Dtella? Ich habe gute Erinnerungen daran, kurz im Release-Team eines inoffiziellen, nicht von der IT genehmigten Dtella-Netzwerks an der Uni mitgearbeitet zu haben, und es war meine erste Gelegenheit, einigermaßen eng mit den Technikleuten zusammenzuarbeiten
      Später habe ich verstanden, dass mit dem „flachen Netzwerk“ nicht ein auf dem Uni-Netz aufgebautes Filesharing-Knotennetz gemeint war, sondern dass das Netzwerk selbst flach war
      Trotzdem war die Uni-Zeit genau die richtige Phase für solchen Spaß

  • Soulseek lebt immer noch ziemlich und funktioniert gut

  • Das Lustigste an Gnutella ist, dass es überhaupt nichts mit dem GNU-Projekt zu tun hat, sondern der Name nur gewählt wurde, weil GNU cool klang

  • Ich frage mich oft, wie viel von Gnutellas Kerngedanken man für neuere Small-Web- oder Gemini-artige Content-Discovery wiederverwenden könnte
    Zu sagen, es sei „gescheitert“, ist unvollständig. Dinge scheitern oder gelingen im Allgemeinen nicht einfach so, sondern nur in Bezug auf ein bestimmtes Ziel
    Dass es keine Gnutella-Nutzer mehr gibt, hat im Wesentlichen zwei Gründe, und beide kann man als Scheitern sehen
    Erstens haben Gnutella und die verschiedenen Programme den Schutz der Privatsphäre der Nutzer nicht ausreichend gewährleistet und sie dadurch realen oder wahrgenommenen Risiken ausgesetzt
    Zweitens war es als System zur Verteilung von Mediendateien zwar sehr gut, bot aber nicht die richtige Balance aus Qualität und Preis, um die meisten Nutzer zufriedenzustellen. Es gab den unbegrenzten Zugang, den die Nutzer wollten, aber keine Garantie für echten Content, während Spotify beides bot
    In diesem Sinne gibt es Gnutella-Nutzer immer noch, sie verwenden heute nur etwas anderes

    • Falls jemand etwas in Richtung Gemini + Gnutella zusammen machen möchte, kann er sich gern melden. Ich hatte eine ähnliche Idee
      Ich dachte an ein Archiv von *.gmi-Dateien, die sich über eine Gnutella-Erweiterung durchsuchen lassen, sowie an ein Pointer-System, mit dem Leute Gemtext-Dokumente signieren und veröffentlichen können
      Die Idee selbst ist nicht neu, aber die Kombination aus Gemtext + Gnutella-Verteilung wirkt neu: https://github.com/RickCarlino/gnutella-bun-client/…
      Dieser Text ist das Ergebnis eines Brainstormings im Austausch mit GPT-5.4 und wurde nur für später abgelegt; eigentlich hatte ich nicht vor, ihn schon zu teilen, also bitte mit Vorsicht lesen
      Ich würde gern hören, welche Gedanken es im Bereich Gemini + Gnutella dazu gibt; man findet mich leicht auf Linkedin, Reddit, im Fediverse usw., und auf meinem Blog stehen auch Kontaktinfos

  • OnionShare ist auch ziemlich interessant: https://onionshare.org/
    Könnte Teil des DaRkWeB sein

    • Ich frage mich, ob das ein Such-Overlay bereitstellt oder nur Übertragungsfunktionen bietet
      Den Docs nach wirkt es eher wie ein Tool für direkte Dateiübertragung per Verbindung

  • Ich glaube, ein Punkt dafür, dass Gnutella unter den damaligen Bedingungen so lange überlebt hat, fehlt: Es gab kaum einen echten Anreiz, P2P-Suchspam zu betreiben
    Später kam P2P-Suchspam dann tatsächlich auf

    • Gnutella hatte im Vergleich zu späteren P2P-Systemen ein höheres Vertrauensniveau, wodurch Spam leichter einzuschleusen war, aber heute dürfte der Anreiz gering sein, weil es wahrscheinlich nur noch ein paar Tausend Nutzer gibt
      Dass es in IRC heute fast keinen Spam mehr gibt, scheint einen ähnlichen Grund zu haben
      Interessant ist, wie viele Teile des Protokolls dem Client vertrauen
      GUIDs sollen zufällig sein, stehen aber unter Kontrolle der Nutzer, also könnten theoretisch alle ihre GUID auf 0000 setzen. Würde man Gnutella heute neu bauen, würde man wahrscheinlich ein komplexes Schlüsselaustauschsystem und auf ED25519-Schlüsseln basierende Identitäten einbauen
      Auch Dinge wie die Zahl der angebotenen Dateien oder die Bandbreite beruhen im Grunde darauf, dass Nutzer die Wahrheit sagen. Ein komplizierteres Protokoll hätte vielleicht versucht, solche Angaben tatsächlich zu verifizieren
      Mit vielen Schlüsselsignaturen oder Reputationsmechanismen wäre die Implementierung womöglich zu komplex geworden, und vielleicht war gerade diese Einfachheit ein Grund für den Erfolg. Einen Gnutella-Client kann man tatsächlich bauen
      Ich finde, viele moderne P2P-Projekte übersehen genau das. Selbst bei meinem Lieblingsprojekt Secure Scuttlebutt wirkt es so, als habe man versucht, etwas nahezu Perfektes zu bauen, das alle möglichen Fehler- und Missbrauchsfälle berücksichtigt, und am Ende entstand ein Ökosystem mit nur einem funktionierenden Client, nämlich dem der Spezifikationsautoren
      Dasselbe Beispiel gilt auch für gemini://. Es ist kein P2P-, sondern ein föderiertes Protokoll, aber obwohl die Spezifikation viele Probleme und Lücken hat, haben die Leute am Ende tatsächlich Clients gebaut, und trotz aller Probleme gibt es im Ökosystem eine recht große Vielfalt an Implementierungen

  • Für Gnutellas Aufstieg zu diesem Zeitpunkt waren Gene Kan und Spencer Kimball als Mitglieder von Berkeley XCF sehr wichtig
    Spencer hat später bei Google viel hervorragende technische Arbeit geleistet und ist heute CEO des Datenbankunternehmens Cockroach Labs
    Gene hatte früh Erfolg, als er seine Suchfirma an Sun verkaufte, verstarb aber tragischerweise 2002 in viel zu jungem Alter