2 Punkte von GN⁺ 2025-05-09 | 1 Kommentare | Auf WhatsApp teilen
  • Mycoria ist ein offenes, sicheres Overlay-Netzwerk, das alle Teilnehmenden gleichberechtigt verbinden will und sich am offenen, experimentierfreudigen Charakter des frühen Internets orientiert
  • Für die Teilnahme gibt es keine bürokratischen Verfahren, und alle Verbindungen setzen Authentifizierung und Verschlüsselung standardmäßig voraus
  • Es kann über das Internet verbunden oder zu einem eigenen Mesh-Netzwerk ausgebaut werden, um die Hürden für die Netzwerkteilnahme zu senken
  • Das Design konzentriert sich auf eine kleine, einfache Struktur, Kompatibilität mit bestehender Infrastruktur wie DNS sowie grundlegende Sicherheit und Privatsphäre
  • Es bietet automatische Ende-zu-Ende-Verschlüsselung, skalierbares Routing, ein Dashboard, .myco-DNS-Auflösung und Service Discovery; einige Funktionen für Privatsphäre und automatische Optimierung befinden sich noch im WIP-Status

Die von Mycoria angestrebte Form der Verbindung

  • Mycoria ist ein offenes, sicheres Overlay-Netzwerk, das alle Teilnehmenden miteinander verbindet
  • Es folgt dem neugierigen und abenteuerlichen Geist des frühen Internets und betrachtet die Freiheit der Verbindung als zentralen Wert
  • Die Kernprinzipien sind wie folgt
    • Everyone is equal: Verbindung ist für alle leicht möglich
    • Everyone is welcome: ein offenes Netzwerk, dem man ohne bürokratische Verfahren beitreten kann
    • No spooking: alle Verbindungen werden authentifiziert
    • No surveillance: alle Verbindungen sind verschlüsselt und umfassen Private Addresses
    • No barriers: Verbindung über das Internet oder Erweiterung von Mycoria als eigenes Mesh möglich

Designziele und aktuelle Funktionen

  • Ziel ist es, die Struktur klein und einfach zu halten
  • Die Kompatibilität mit bestehender Infrastruktur wie DNS wird berücksichtigt
  • Sicherheit ist standardmäßig integriert, während grundlegende Privatsphäre weiterhin WIP ist
  • Derzeit werden folgende Funktionen bereitgestellt
    • automatische Ende-zu-Ende-Verschlüsselung
    • moderne Kryptografie
    • intelligentes und skalierbares Routing
    • Dashboard
    • .myco-DNS-Auflösung
      • erfordert OS-Konfiguration
    • einfache Service Discovery
    • automatische Netzwerkoptimierung und -wiederherstellung für Internet-Overlay
      • Status: WIP
    • rotierende private addresses
      • Status: WIP

1 Kommentare

 
GN⁺ 2025-05-09
Meinungen auf Hacker News
  • Ich bin der Autor. Bei Safing habe ich in den letzten acht Jahren als Mitgründer/CTO Privacy-Technologie entwickelt; die größte technische Errungenschaft war SPN (früher Port17/Gate17).
    SPN war ein Privacy-Netzwerk in der Nische zwischen VPN und Tor, also ein Layer-5-Proxy. Es ließ keine Fehlkonfiguration zu, war recht schnell und bot durch Onion-Verschlüsselung sowie die Trennung von Authentifizierung und Autorisierung deutlich besseren Datenschutz als ein VPN.
    Interessanterweise wurde diese Form der getrennten Authentifizierung später auch in Apple Private Relay und Google One VPN implementiert.
    SPN funktionierte im Großen und Ganzen gut, ließ sich aber schwer skalieren. Weil wir es als Layer-5-Proxy gebaut hatten, um Metadaten zu reduzieren und die Privatsphäre zu erhöhen, mussten wir auch Traffic Control und Congestion Control neu implementieren. Das war nicht einfach und verursacht bis heute Probleme.
    In der Zwischenzeit habe ich cjdns und Yggdrasil gelesen und verfolgt und fand die Networking-Ideen spannend. Etwa im November 2023 fragte ich mich, wie weit man mit der bisherigen Erfahrung und dem Wissen ein skalierbares Layer-3-Mesh-Netzwerk bauen könnte, das einen Teil der Privatsphäre und vollständige Sicherheit bewahrt.
    Ich habe mehrere Monate lang die meisten Abende daran gearbeitet, und es lief besser als gedacht. Nachdem es ein brauchbares MVP gab und ein Freund es erstmals in einer kleinen Produktion eingesetzt hatte, hatte ich jedoch keine Zeit mehr, weiter daran zu arbeiten.
    Jetzt starte ich ein neues Projekt und werde es dort gut einsetzen, daher dürfte die Entwicklung in den nächsten Jahren noch deutlich vorangehen. Mycoria funktioniert derzeit zumindest im kleinen Maßstab, ist aber im Wesentlichen noch eher ein MVP.

    • Mycoria sieht vielversprechend aus und erinnert an die frühen Peer-to-Peer-Systeme aus den Zeiten von Napster und Gnutella.
      Ich frage mich, ob es einen besonderen Grund gibt, warum ihr nicht standardbasiertes Segment Routing, das sich auf Layer 3 einsetzen ließe, für Source-Routing-Support verwendet, sondern einen eigenen Layer-4-Transport gebaut habt.
      Außerdem frage ich mich, ob ihr für die Sicherheitsanalyse BAN-Logik und das Verifikationstool ProVerif verwendet habt.
      https://en.wikipedia.org/wiki/Gnutella
      https://en.wikipedia.org/wiki/Segment_routing
      https://en.wikipedia.org/wiki/Burrows%E2%80%93Abadi%E2%80%93...
      https://en.wikipedia.org/wiki/ProVerif
    • Ich würde statt friend einen Begriff wie peer vorschlagen. Das ist keine kleinliche Haarspalterei; Beziehungssemantik, die im Bereich des User Agent nicht abgeschlossen ist, sollte man besser nicht in der Infrastrukturschicht verwenden.
      Auch mein Laptop-Server ist mein User Agent, und die Instanz auf meinem Telefon ebenso; die beiden sind also Peers.
      Anwendungen, die auf dieser Grundlage entstehen, werden größtenteils die sozialen Beziehungen der Nutzer behandeln, und Begriffe wie friend werden auf dieser Ebene nützlich sein.
    • Mir scheint, dass ähnliche Lösungen gemeinsam die kommerzielle Seite ignorieren. Ich weiß nicht, ob eine breite Akzeptanz angestrebt ist, vermute aber, dass die Privacy- und Anonymitätseigenschaften besser werden, je mehr Menschen es nutzen.
      Falls ja, frage ich mich, ob ihr Anreize zur Teilnahme — monetäre oder nicht monetäre — in Betracht gezogen habt. Die zentrale Herausforderung in diesem Bereich scheint mir darin zu liegen, standardisierte anonyme Zahlungen für Anbieter von Infrastrukturservices des Netzwerks zu lösen.
    • Aus der Dokumentation wurde es mir nicht klar: Wenn die IPv6-ähnliche Adresse eines Routers ein Fingerprint des öffentlichen Schlüssels ist, codiert sie dann auch geografische Präfixe und Distanzen?
      Theoretisch scheint das möglich zu sein; falls ihr diesen Ansatz verfolgt, würde ich gern wissen, wie. Oder enthalten Router-Adressen keine Metadaten und nur Endnutzer-Adressen werden auf diese Weise codiert?
    • Als ich noch Windows nutzte, waren Portmaster und SPN großartig. Ich wünschte, es gäbe so etwas auch für macOS.
      Es gibt zwar Private Relay, aber es funktioniert nur in einigen Apple-Apps wie Safari, man erkennt schwer, ob es aktiv ist, und man kann den Traffic nicht zwingend ausschließlich darüber leiten.
  • Technisch finde ich solche Dinge wirklich großartig. Man stellt sich eine ferne Zukunft vor, in der coole Nerds und Geeks allen Widrigkeiten zum Trotz nur mit grundlegender Infrastruktur ihre eigenen Community-Netzwerke aufbauen.
    Aber letztlich ist die Teilnahme an üblichen dezentralen Projekten unbequem und schreckt mich ab, weil ich das Gefühl habe, damit das Teilen und Verbreiten von Material über sexuellen Kindesmissbrauch zu unterstützen.
    Tailscale bleibt zumindest im privaten Rahmen, aber das hier fühlt sich an, als würde man Teil eines größeren Netzwerks. Ich frage mich, ob mein Node dafür genutzt wird, solchen Traffic zu routen.

    • Tatsächlich ist die größere und realistischere Gefahr Tyrannei. Tyrannen sind in der Regel auch Missbrauchstäter.
    • Das würde auf die Schlussfolgerung hinauslaufen, jegliche Privatsphäre im Internet abzuschaffen, aber selbst damit würde man Material über sexuellen Kindesmissbrauch nicht verhindern.
      Viel Glück, Herr Big Brother.
    • Was immer man baut, es wird am Ende für illegale Dinge genutzt werden.
      Hätte man dann auch das Internet nicht erfinden sollen? Dasselbe würde für Briefe, Facebook, Autos, Waffen, Messer und Landwirtschaft gelten.
  • Es ist klar zu sehen, wo die Erkenntnisse aus cjdns und Yggdrasil eingeflossen sind, und das Projekt ist wirklich sehr cool.
    Da es vielversprechend wirkt und auch ein neues Projekt spannend ist, möchte ich nur auf ein kleines Detail hinweisen. Laut FAQ haben Router-IPs eine Struktur, und abgesehen von Präfixen für besondere Zwecke liegen die meisten innerhalb von geografischen Präfixen. Jedes Land und jeder US-Bundesstaat hat in Mycoria ein eigenes Präfix; Router im selben Land teilen sich auf globaler Ebene dasselbe Präfix, und nahe beieinanderliegende Länder haben meist auch ähnliche Präfixe.
    Innerhalb eines Länderpräfixes verwendet Mycoria Adressdistanz-Routing und sendet Pakete an den unter den bekannten anderen Routern adressmäßig nächstgelegenen. Das ist nicht das effizienteste Routing, funktioniert aber insbesondere dann ziemlich gut, wenn man es wie bei Mycoria auf kleinere geografische Bereiche beschränkt und ein paar zusätzliche Maßnahmen ergreift.
    Eine der unglücklichen Lehren aus dem IPv4-Internet, der Art, wie IANA-IPs von den einzelnen RIRs verwaltet wurden, und der Weise, wie IPv4-Blöcken Geoinformationen zugeordnet wurden, ist, dass politische Entscheidungsträger sehr gern Policy auf geografische Tags aufsetzen. Zum Beispiel: Wenn Maxmind eine Adresse als in Pakistan befindlich meldet und nach pakistanischem Recht Inhalte, die eine andere Adresse anbietet, verboten sind, wird sie blockiert.
    Wenn geografische Erkennung in Netzwerkpräfixe eingebaut ist, kann das auf eine Weise missbraucht werden, die Nutzer nicht wollen. Natürlich kann das ein akzeptabler Kompromiss sein, und man kann sich leicht Szenarien vorstellen, in denen Nutzer genug Vorteile aus geografischen Präfixen ziehen, um die Nachteile in Kauf zu nehmen.
    Falls Ersteres zutrifft, wäre es erwägenswert, statt geografischer Präfixe – also „innerhalb von X Meilen zu anderen Personen in dieser Jurisdiktion“ – zu latenzbewussten Präfixen überzugehen, also „innerhalb von X ms zu anderen Personen in diesem Präfix“.
    Wenn ich meine eigene Empfehlung allerdings selbst widerlege: Wer Policy auf Layer 8 über geografischen Präfixen implementieren will, könnte latenzbewusste Präfixe absichtlich als nah genug missverstehen, und dann wäre viel Aufwand vergeblich.

    • Danke, dass du dir Zeit für dieses Feedback genommen hast. Ich möchte dieses Problem mit privaten Adressen lösen.
      Private Adressen haben keine geografische Kennzeichnung und werden nicht geroutet. Sie werden zum Beispiel zufällig generiert und lassen sich nicht ohne Weiteres einem geografischen Standort zuordnen.
  • Die Dokumentation ist gut gemacht und sieht interessant aus. Ich muss es selbst ausprobieren, aber meine erste Frage ist, ob Mycoria innerhalb des Netzwerks den gesamten Node offenlegt, sodass man für Port-Zugriffsbeschränkungen usw. eine Firewall braucht.
    Ich frage, weil das bei Yggdrasil nötig ist: https://yggdrasil-network.github.io/faq.html#will-my-machine...

    • Mycoria ist standardmäßig sicher und erfordert fast keine Konfiguration.
      Standardmäßig kann niemand auf dein Gerät zugreifen. Du musst das im Abschnitt services der Konfiguration aktiv erlauben.
  • Ich frage mich, wie es im Vergleich zu Veilid (https://veilid.com/) abschneidet.

  • Ich frage mich, ob du Reticulum[0] gesehen hast. Außerdem würde ich gern wissen, wie stark es sich mit der Netzwerkschicht von Mycoria überschneidet.
    [0]: https://github.com/markqvist/Reticulum

  • Vielleicht habe ich etwas komplett übersehen, aber versucht Mycoria zu verhindern, dass Netzwerkteilnehmer die öffentliche Internet-IP-Adresse herausfinden, die einer Mycoria-Router-ID entspricht?
    Das Feld iana in der Konfiguration lässt es so aussehen, als sei das nicht das Ziel; dann wirkt dieses System eher wie Tailscale mit IPv6 und globalem Namensraum. In diesem Fall können sich fast alle Internet-Hosts über NAT-Traversal-Techniken wie bei BitTorrent direkt gegenseitig erreichen, daher verstehe ich nicht ganz, warum „Routing“ so betont wird.
    Wenn es darum geht, wie bei Tor Hidden Services die öffentliche Internet-IP-Adresse zu verbergen, ergibt die Routing-Methode für mich ebenfalls nicht viel Sinn. Denn vermutlich möchte man nicht, dass durch die Wahl von Pfaden mit einer deterministischen oder latenzabhängigen Strategie Informationen durchsickern.

    • Mycoria wurde für Resilienz gebaut und verlässt sich nicht darauf, dass das heutige Internet-Backbone perfekt funktioniert.
      Selbst wenn das heutige Internet „normal“ funktioniert, haben viele Nutzer ähnlicher Netzwerke berichtet, dass sie durch Overlay-Network-Routing eine bessere Konnektivität erhalten haben. Das Routing im IANA-Internet wird nämlich stark beeinflusst.
      Wenn Mycoria die Konfiguration erzeugt, werden die aktuellen öffentlichen Interfaces des Geräts aufgenommen; das gilt also nur für Server. Mycoria ist nicht von IANA-Adressen abhängig, nutzt sie aber, um die Netzwerkstruktur automatisch zu verbessern. Das heißt, es findet bessere Pfade zwischen Routern über das IANA-Internet.
  • Es könnte nützlicher sein, zu bereits existierenden Netzwerken wie i2p beizutragen.

    • Nicht nur i2p, sondern fast identische bestehende Projekte sind bereits etabliert.
      Die meisten davon sind gescheitert, weil sie keine ausreichende Verbreitung erreicht haben – ein Hauptgrund ist, dass sie nicht anerkennen, dass über 90 % des Desktop-Computer-Markts weder Linux noch BSD nutzen.
      Einige unterstützen Windows-Clients nur halbherzig, und macOS, das etwa 20–30 % des Desktop-Markts ausmacht, wird kaum unterstützt.
  • Ich frage mich, wie es im Vergleich zu zrok (https://zrok.io/) abschneidet. Ich würde es gern selbst ausprobieren, bin aber etwas besorgt, weil es so klingt, als sei es standardmäßig nicht privat.

    • Für die von Zrok genannten Anwendungsfälle ist Mycoria sehr ähnlich.
      Standardmäßig kann nichts auf dein Gerät zugreifen. Du musst Dienste definieren und friends, also deine anderen Geräte, hinzufügen, um Zugriff zu erlauben.