Initial project structure: documentation, server concept, agents instructions
This commit is contained in:
@@ -0,0 +1,140 @@
|
||||
# Architektur
|
||||
|
||||
Von unten (Physik) nach oben (Inhalte). Der AKI-Node ist das Herzstück —
|
||||
eine kleine Box im Wohnungsregal, die zu Hause sitzt und das Viertel verbindet.
|
||||
|
||||
## Übersicht
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
subgraph HausA[Haus A]
|
||||
GA[Geräte A] --> NA[AKI-Node A]
|
||||
end
|
||||
subgraph HausB[Haus B]
|
||||
GB[Geräte B] --> NB[AKI-Node B]
|
||||
end
|
||||
subgraph HausC[Haus C]
|
||||
GC[Geräte C] --> NC[AKI-Node C]
|
||||
end
|
||||
NA <-->|"Glasfaser (bzw. Funk-Fallback)"| NB
|
||||
NB <-->|"Glasfaser"| NC
|
||||
NA -->|"ISP-Uplink A"| WA((Internet))
|
||||
NB -->|"ISP-Uplink B"| WA
|
||||
NC -->|"ISP-Uplink C"| WA
|
||||
```
|
||||
|
||||
Entscheidend: **jeder Haushalt behält seinen eigenen Uplink**. Es gibt keinen
|
||||
zentralen Exit (anders als klassische Community-Meshes mit einem Supernode),
|
||||
sondern viele — das verteilt nicht nur Last, sondern auch Risiko und Zensur-
|
||||
Angriffsfläche.
|
||||
|
||||
## Schicht 0 — Physik (Nachbarschaftsglasfaser)
|
||||
|
||||
- **Bevorzugt:** Glasfaser Haus-zu-Haus (z. B. 2-Faser-Duplex G.657A2, LC-
|
||||
Stecker), Medienwandler bzw. SFP-Port direkt im Node. Innenrohr entlang
|
||||
der Fassade, kurze Gräben im Garten, Kabelkanal.
|
||||
- **Pragmatisch für den Start:** was da ist — existierendes LAN-Kabel im
|
||||
Mehrfamilienhaus (bis 100 m), Richtfunk 60-GHz-PTP (5–15 Gbit/s,
|
||||
Sichtlinie nötig) als Überbrückung.
|
||||
- **Topologie:** anfangs Stern/Ring (2–5 Häuser), später vermascht. Jede
|
||||
Faser ist ein separates Link; Redundanz schlägt Eleganz.
|
||||
|
||||
## Schicht 1 — Routing (Overlay über alle Haushalte)
|
||||
|
||||
Kandidaten (Auswahl offen, Kriterium: simpel, wartbar, verschlüsselt):
|
||||
|
||||
| Kandidat | Pro | Con |
|
||||
|---|---|---|
|
||||
| **Yggdrasil** | Out-of-the-box e2e-verschlüsseltes IPv6-Overlay, null Konfiguration, self-contained | experimentell, Performance über wenige Gbit/s hinaus |
|
||||
| Babel + WireGuard | bewährt (Althea-Ansatz), Router-Hardware tauglich | mehr Konfigurationsaufwand |
|
||||
| cjdns | Battle-tested in Hyperboria | ältere Codebasis |
|
||||
|
||||
Empfehlung für den PoC: **Yggdrasil**. Jeder AKI-Node peert über die
|
||||
Glasfaser-Links mit seinen Nachbarn; Geräte der Haushalte hängen per NAT/
|
||||
Firewall getrennt dahinter (Home-LAN ≠ Mesh-LAN).
|
||||
|
||||
## Schicht 2 — Bandbreiten-Pooling (der eigentliche Kern)
|
||||
|
||||
### Exit-Pool
|
||||
|
||||
Jeder Haushalt bietet seinem Node an, wie viel Uplink er "spendiert"
|
||||
(Kontingent, standardmäßig fair-share). Der Exit-Pool ist die aggregierte
|
||||
Kapazität. Exit ist **opt-in pro Haushalt und jederzeit widerruflich**.
|
||||
|
||||
### Segmentierter Multi-Exit-Download (`aki-fetch`)
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant User
|
||||
participant Node (HAUS)
|
||||
participant Exits (alle Haushalte)
|
||||
participant Origin (Origin-Server)
|
||||
|
||||
User->>Node: GET bigfile.iso
|
||||
Node->>Node: Plan (Dateigröße, Range-Splits, Exit-Kontingente)
|
||||
par parallel über alle Exits
|
||||
Node->>Exits: Range 0–25%
|
||||
Node->>Exits: Range 25–50%
|
||||
Node->>Exits: Range 50–75%
|
||||
Node->>Exits: Range 75–100%
|
||||
end
|
||||
Exits->>Origin: (je ein GET mit Range)
|
||||
Origin-->>Exits: Daten
|
||||
Exits-->>Node: Segmente (verschlüsselt über Mesh)
|
||||
Node-->>User: Datei (Hash-verifiziert, reassembliert)
|
||||
```
|
||||
|
||||
- HTTP Range Splits + Shadow-Verifizierung (Content-Hash)
|
||||
- Fallback: entfällt ein Exit, übernimmt ein anderer das Segment
|
||||
- Für nicht-rangefähige Quellen: klassische Proxy-Rotation
|
||||
|
||||
### Generischer Traffic (alles andere)
|
||||
|
||||
VPN-artiges Overlay: pro Gerät ein verschlüsselter Tunnel zu *einem*
|
||||
gewählten Exit, Exit-Wahl rotiert; Browsing/Video-Calls laufen über einen
|
||||
Exit, große Transfers über alle. Video-Calls werden explizit auf einen
|
||||
Exit gepinnt (kein Splitting).
|
||||
|
||||
### Fairness-Scheduler (`aki-fair`)
|
||||
|
||||
- Max-min Fairness über alle aktiven Nutzer:innen des Netzes
|
||||
- Exit-Kontingente (Volumenlimit, Wartungszeit) werden respektiert
|
||||
- Karma statt Bezahlung: wer dauerhaft deutlich mehr zieht als er gibt,
|
||||
wird fair angesprochen (Drosselung als letztes Mittel, nie als Strafe
|
||||
für Berechtigte mit Bedarf)
|
||||
|
||||
### Nachbarschafts-Cache (`aki-cache`)
|
||||
|
||||
- Transparenter Shared-Cache (lancache-Prinzip): große, popluläre Objekte
|
||||
(Steam, Konsolen-Updates, OS-Images, Software-Pakete) kommen aus dem
|
||||
Viertel statt aus dem Internet
|
||||
- DNS-basiert, pro Haushalt kleine Cache-Slots; gemeinsam sind sie groß
|
||||
|
||||
## Schicht 3 — Inhalte & Apps (Freenet)
|
||||
|
||||
- `freenet-core` (Rust, AGPL-3.0) läuft als Sidecar auf ausgewählten Nodes
|
||||
und stellt verteilte Inhalte/Apps im Viertel bereit: Nachbarschafts-Wiki,
|
||||
Microblogging, lokale Services — ohne zentralen Server, auch offline
|
||||
erreichbar.
|
||||
- Freenet ist **keine Anonymitätslösung** (siehe FAQ) und wird auch nicht
|
||||
als solche beworben.
|
||||
- Unsere Software nutzt Freenet über `freenet-stdlib` bzw. die
|
||||
WebSocket-API (nicht-derivativ), unsere eigene Codebasis bleibt AGPL-3.0.
|
||||
|
||||
## Sicherheit und Vertrauen
|
||||
|
||||
- Nodes authentifizieren sich gegenseitig per Keypair; Onboarding im
|
||||
persönlichen Gespräch (Nachbar:innen sind der Trust-Anchor, nicht PKI).
|
||||
- Strikte Netz-Trennung: Mesh-LAN hat keinen Zugriff auf Home-LAN der
|
||||
Teilnehmer (Client-Isolation).
|
||||
- Kill-Switch: jeder Haushalt kann seine Faser physisch/softwareseitig
|
||||
abklemmen; der Node fällt auf "nur eigener Anschluss" zurück.
|
||||
- Minimale Logs (DSGVO, siehe [recht.md](recht.md)).
|
||||
|
||||
## Offene Fragen
|
||||
|
||||
- DSLite/Carrier-NAT-Haushalte: Synchrone Exits gehen, aber
|
||||
Konfigurationsaufwand pro Router-Modell prüfen.
|
||||
- ISP-AGB: Weitergabe an "Dritte" kann verboten sein (per ISP prüfen,
|
||||
siehe recht.md).
|
||||
- Wie viel Cache lohnt sich real bei 3–10 Haushalten? (Messung in Phase 2)
|
||||
@@ -0,0 +1,76 @@
|
||||
# Die Kernidee — und ein ehrlicher Realitätscheck
|
||||
|
||||
## Ursprungsidee
|
||||
|
||||
> Man spannt Glasfaser von Haus zu Haus und baut ein lokales Netz auf. Wenn
|
||||
> man über das Internet etwas nachfragt, läuft die Anfrage nicht (nur) über
|
||||
> den eigenen Anschluss, sondern die Last wird aufs gesamte Netz verteilt.
|
||||
> Jede:r nutzt die Gesamtkapazität der Nachbarschaft, ohne dass es mehr
|
||||
> kostet. Schwache Haushalte werden gestärkt. Nebenbei wird Traffic verteilt
|
||||
> und ist für Außenstehende schwerer zuzuordnen (Privacy).
|
||||
|
||||
Diese Idee ist gut — und sie ist nicht abstrakt: NYC Mesh läuft genau so
|
||||
("members share their internet"), Freifunk und guifi.net zeigen es in
|
||||
großem Maßstab. Was hier neu gedacht ist, ist der **konsequente Exit-Jede**
|
||||
statt Exit-Nirgends: Jeder Haushalt bleibt bei seinem ISP, aber Anfragen
|
||||
verlassen das Viertel an *allen* Punkten gleichzeitig.
|
||||
|
||||
## Was technisch funktioniert
|
||||
|
||||
1. **Segmentierte Downloads über mehrere Exits.** Große Dateien werden in
|
||||
Byte-Bereiche gesplittet (HTTP Range Requests) und parallel über die
|
||||
Glasfaseranschlüsse mehrerer Haushalte geladen. Das ist Multi-WAN-
|
||||
Aggregation, nur verteilt über das Viertel. Ein DSL-50000-Haushalt kann
|
||||
damit realistisch 5× herunterladen, wenn 4 Nachbarn mitspielen.
|
||||
2. **Fair-Share-Scheduling.** Wer gerade nichts lädt, gibt seinen Anteil
|
||||
automatisch. Ein einzelner Stream profitiert von fremder Kapazität,
|
||||
mehrere Lade gleichzeitig bekommen faire Anteile.
|
||||
3. **Nachbarschafts-Cache.** Beliebte Inhalte (Updates, Games, Videos,
|
||||
Software-Pakete) liegen im Viertel. Das entlastet die Uplinks stärker
|
||||
als jedes Pooling — siehe [lancache](https://lancache.net/).
|
||||
4. **Privacy durch Verteilung.** Der ISP sieht pro Haushalt nur einen
|
||||
Bruchteil des ursprünglichen Traffics; Zuordnung "IP → Person" wird
|
||||
deutlich schwächer. Backtracking von außen muss die Frage lösen:
|
||||
"Welcher der 12 Anschlüsse im Viertel hat das eigentlich gezogen?"
|
||||
5. **Resilienz.** Fällt ein Anschluss aus, laufen die anderen weiter — auch
|
||||
lokaler Traffic funktioniert ohne Internet komplett (Ethos §7).
|
||||
|
||||
## Was nicht so einfach ist
|
||||
|
||||
1. **Ein einzelner TCP-Stream kennt kein Pooling.** Ohne Segmentierung oder
|
||||
Multipath bleibt ein einzelner Download auf der Geschwindigkeit *eines*
|
||||
Uplinks. Der Gewinn kommt aus unserer Download-Software, nicht aus dem
|
||||
Kabel — deshalb bauen wir `server/`.
|
||||
2. **Alltagstraffic braucht eine Exit-Wahl.** Video-Calls, Banking etc.
|
||||
können nicht sinnvoll gesplittet werden. Für generischen Traffic braucht
|
||||
es ein VPN-Overlay mit Load-Balancing (mehrerer Exits gleichzeitig),
|
||||
damit z. B. Web-Browsing über "die Nachbarschaft" läuft statt über die
|
||||
eigene Leitung.
|
||||
3. **Physik ist der eigentliche Engpass.** Glasfaser spannen heißt: Genehmigungen,
|
||||
Vermieter, Grundstücke, Arbeit. Realistisch beginnt man mit dem, was da
|
||||
ist (Kabel im Mehrfamilienhaus, Garten, kurze Richtfunkstrecken), und
|
||||
baut Glasfaser dort, wo ohnehin gegraben wird (siehe Recht).
|
||||
4. **Volumen-/Drosseltarife.** Wer ein Volumenlimit hat, zahlt mit Volumen,
|
||||
wenn Nachbarn über seinen Exit laden. Lösung: Exits haben harte Kontingente
|
||||
und der Scheduler respektiert sie ("Exit-Karenz"), plus Karma.
|
||||
5. **Privacy ist ein Nebenprodukt, keine Anonymität.** Freenet sagt es
|
||||
selbst (FAQ): keine Anonymität wie Tor/I2P. Metadaten bleiben. Wer echte
|
||||
Anonymität will, legt Tor/I2P über das Netz. Wir verkaufen deshalb
|
||||
Privacy-by-Design, nicht Anonymität.
|
||||
6. **Recht.** Abmahnungen landen zuerst beim Anschlussinhaber, egal wer
|
||||
geladen hat; bewusstes Ermöglichen von Rechtsbrüchen kann eigene Haftung
|
||||
erzeugen. Details und Gegenmaßnahmen: [recht.md](recht.md).
|
||||
|
||||
## Der technische Kern (warum es Software braucht)
|
||||
|
||||
Das Netz ohne Software ist "nur" ein LAN. Die Mehrwerte entstehen durch
|
||||
einen **AKI-Node** pro Haushalt, der folgendes macht:
|
||||
|
||||
- Overlay-Routing über alle Haushalte (Kandidat: Yggdrasil)
|
||||
- Exit-Pool verwalten: Wer darf über wen raus, mit welchem Kontingent
|
||||
- Segmentierten Multi-Exit-Downloader (API + CLI + Browser-Integration)
|
||||
- Fairness-Scheduler über alle Haushalte
|
||||
- Transparenten Nachbarschafts-Cache
|
||||
- (Später) Freenet als Inhalts- und App-Ebene im Viertel
|
||||
|
||||
Siehe [architektur.md](architektur.md) und [server/README.md](../../server/README.md).
|
||||
@@ -0,0 +1,93 @@
|
||||
# Rechtslage (Deutschland)
|
||||
|
||||
> ⚠️ Keine Rechtsberatung. Stand: September 2026, aus öffentlich zugänglichen
|
||||
> Quellen zusammengestellt. Für den Ernstfall: Anwält:in für Urheberrecht/
|
||||
> Telekommunikationsrecht fragen — im Kollektiv, nicht alleine.
|
||||
|
||||
## 1. Urheberrecht / Filesharing — das größte Risiko
|
||||
|
||||
### Wie die Rechtsprechung heute funktioniert
|
||||
|
||||
- Wer im Netz einer IP-Adresse etwas rechtswidrig bereitstellt, führt zur
|
||||
**Täterschaftsvermutung** gegen den Anschlussinhaber (BGH, 12.05.2010,
|
||||
I ZR 121/08). Diese Vermutung kann erschüttert werden, indem man darlegt,
|
||||
dass **andere selbstständigen Zugang** zum Anschluss hatten ("sekundäre
|
||||
Darlegungslast") — man muss nicht den Täter benennen (LG Frankenthal,
|
||||
06.08.2019, 6 O 398/17; AG Bochum, 16.04.2014, 67 C 57/14 — WG-Fall).
|
||||
- **Störerhaftung** des Zugangsvermittlers für Unterlassung/Schadensersatz
|
||||
wurde 2017 weitgehend abgeschafft (§ 8 Abs. 1 S. 2 TMG a.F., heute in
|
||||
DDG/DSA weitergeführt; BGH "Dead Island", I ZR 64/17). Es bleibt ein
|
||||
**Sperranspruch** (§ 7 Abs. 4 TMG a.F.): Rechteinhaber können verlangen,
|
||||
dass der Anschlussinhaber konkrete rechtsverletzende Inhalte sperrt,
|
||||
wenn es ihm zumutbar ist (Verbraucherzentrale: das kann Registrierung,
|
||||
Passwortzwang bis hin zur vollständigen Zugangssperre bedeuten).
|
||||
- **Abmahnungen landen trotzdem zuerst beim Anschlussinhaber** — Rechteinhaber
|
||||
wissen nicht, wer wirklich geladen hat; die Ermittlung läuft über die
|
||||
zentrale IP-Adresse (Verbraucherzentrale Berlin).
|
||||
- Wer **Kenntnis** von einer Rechtsverletzung über seinen Anschluss hat und
|
||||
nicht einschreitet, kann haften (Störerhaftung bei konkretem Hinweis).
|
||||
- Wer **bewusst und gezielt** Infrastruktur bereitstellt, um Rechtsbrüche
|
||||
zu ermöglichen, kann als Teilnehmer/Beihelfer behandelt werden
|
||||
(Analogie: BGH zu Tor-Exit-Betreibern mit Vorbelastung).
|
||||
|
||||
### Was das für das AKI-Netz bedeutet
|
||||
|
||||
1. **Exit-Haushalt = Verantwortung bleibt beim Exit-Haushalt.** Wenn
|
||||
fremder Traffic über meinen Anschluss ins Internet geht, gilt:
|
||||
- Ich muss darlegen können, dass andere Zugang hatten → das Netz
|
||||
dokumentiert (lokal, nicht zentral!) die Teilnehmerschaft.
|
||||
- Bei Kenntnis einer konkreten Verletzung muss ich handeln können →
|
||||
deshalb braucht der AKI-Node technische Wege, einzelne Nutzer/Segmente
|
||||
zu sperren, ohne das ganze Netz zu killen.
|
||||
2. **Kein "Das ist ja verteilt, also legal."** Wer lädt, bleibt Täter —
|
||||
unabhängig davon, über welchen Exit. Verteilung ändert die Ermittlungs-
|
||||
lage (schwerere Zuordnung), nicht die Haftung des wirklich Tätigen.
|
||||
3. **Piraterie ist kein Feature.** Ethos §5: Das Netz wird als
|
||||
Infrastrukturprojekt betrieben. Downloads großteils über Overlays
|
||||
(Freenet/I2P/Tor) zu leiten ist ein technischer Schutz für *alle*
|
||||
— aber die Werbung dazu gehört nicht auf die Projekt-Homepage.
|
||||
4. **Sekundäre Darlegungslast brauchen wir als Feature:** Der Node führt
|
||||
(lokal, minimal, DSGVO-konform) eine Teilnehmerliste, die im Ernstfall
|
||||
belegt: "Auf meinem Anschluss hatten N Personen unabhängigen Zugang."
|
||||
|
||||
## 2. ISP-AGB / Vertragslage
|
||||
|
||||
- Viele deutsche Provider verbieten in AGB die **Weitergabe an Dritte**.
|
||||
Konsequenz: pro ISP prüfen, ggf. Tarif wählen, der das erlaubt, oder
|
||||
Formulierung als "privates WLAN-Netz im eigenen Haushaltsverbund"
|
||||
(Nachbarn ≠ Gäste ist eine Grauzone). Offenlegen, nicht verstecken.
|
||||
- Netzneutralität: Pooling ist kein Problem, solange wir nicht nach
|
||||
Inhalten filtern oder drosseln.
|
||||
|
||||
## 3. Physik: Kabel verlegen
|
||||
|
||||
- **Mehr-/Eigentumsfamilienhäuser:** einfachste Route — Innenausbau mit
|
||||
Zustimmung Eigentümer:in.
|
||||
- **Kabel über fremde Grundstücke:** braucht Zustimmung (Dienstbarkeit/
|
||||
Gestattungsvertrag). § 918 BGB (Notwegrecht) greift nicht automatisch
|
||||
für Leitungen über fremdes Grund; sauberer Weg ist Zustimmung durch
|
||||
Vertrag.
|
||||
- **Unterirdische Verlegung in öffentlichen Flächen/Straßen:** Bauanfrage
|
||||
bei der Gemeinde, ggf. Tiefbauamt — das ist der reguläre Weg für
|
||||
Nachbarschafts-Fiber-Projekte (guifi.net und Community-Fiber-Initiativen
|
||||
in Deutschland machen es vor).
|
||||
- **Richtfunk als Alternative:** keine Grabungsrechte nötig, nur
|
||||
Sichtlinie und ggf. Denkmalschutz am Gebäude.
|
||||
|
||||
## 4. Datenschutz
|
||||
|
||||
- Nodes loggen minimal (nur Betriebsmetriken, keine Inhalts-/Nutzungs-
|
||||
profiles).Logs bleiben lokal, nichts geht zentral ab.
|
||||
- Teilnehmerdaten (Namen, Adressen) bleiben **außerhalb des Repos** und
|
||||
außerhalb der Nodes, wo es nicht nötig ist.
|
||||
|
||||
## 5. Zusammengefasste Regeln für die Software
|
||||
|
||||
Damit Agents und Developer das im Code umsetzen:
|
||||
|
||||
1. Exit ist opt-in, dokumentiert und jederzeit widerrufbar.
|
||||
2. Node kann einzelne Teilnehmer/Segmente sperren (Sperrpflicht-Umsetzung).
|
||||
3. Logs: minimal, lokal, keine Inhaltslogs.
|
||||
4. Keine Funktion, deren alleiniger Zweck das Verstecken von Rechtsbrüchen ist.
|
||||
5. Heavy-Traffic-Default: Freenet/Overlay bevorzugen, wo sinnvoll.
|
||||
6. Datenschutz by default; keine zentrale Datensammlung.
|
||||
@@ -0,0 +1,56 @@
|
||||
# Roadmap
|
||||
|
||||
Kleine Schritte, alles muss für sich allein funktionieren. Jede Phase
|
||||
endet mit etwas, das man benutzen kann.
|
||||
|
||||
## Phase 0 — Grundlagen (jetzt)
|
||||
|
||||
- [x] Doku-Grundstruktur (Ethos, Idee, Architektur, Recht, Roadmap)
|
||||
- [x] AGENTS.md mit Projektregeln
|
||||
- [x] Gitea-Repo + initialer Push
|
||||
- [ ] Prior Art vertiefen: Freifunk-Community in der Nähe kontaktieren
|
||||
- [ ] ISP-AGB-Check für die Teilnehmer-Haushalte
|
||||
|
||||
## Phase 1 — Pilot (2–3 Haushalte)
|
||||
|
||||
Ziel: Beweis, dass Pooling über zwei Anschlüsse real funktioniert.
|
||||
|
||||
- [ ] AKI-Node auf Mini-PC (Raspberry Pi / N100-Box), Yggdrasil-Overlay
|
||||
zwischen 2 Haushalten (Kabel oder kurzstrecke WLAN/60-GHz)
|
||||
- [ ] `aki-fetch` PoC: segmentierter Download (HTTP-Range-Splitting) über
|
||||
2 Exits, plus Baseline-Messung (1-Exit vs. 2-Exit, gleiche Datei)
|
||||
- [ ] Fair-Share-Scheduler v0: zwei gleichzeitige Downloads, faire Aufteilung
|
||||
- [ ] Doku: Messwerte, Erkenntnisse, Stolpersteine → hier in das Repo
|
||||
|
||||
## Phase 2 — MVP-Software
|
||||
|
||||
Ziel: ein Paket, das 3–10 Haushalte installieren können.
|
||||
|
||||
- [ ] `aki-node` Daemon: Discovery, Peering, Metriken (per-Exit Bandbreite/
|
||||
Latenz), Onboarding-Flow (QR/Knopfdruck)
|
||||
- [ ] Exit-Pool: Kontingente, opt-in/opt-out, Kill-Switch
|
||||
- [ ] `aki-fetch`: API + CLI + einfache Browser-Integration
|
||||
- [ ] `aki-cache`: lancache-artiger transparenter Cache (DNS-basiert)
|
||||
- [ ] Fairness-Scheduler v1 (max-min, Exit-Kontingente, Karma)
|
||||
- [ ] Telemetrie: keine zentrale Sammlung; lokale Metriken im Node
|
||||
|
||||
## Phase 3 — Nachbarschafts-Rollout
|
||||
|
||||
- [ ] Onboarding-Doku für Nachbarn (Hardware-Einkaufsliste, Schritt-für-Schritt)
|
||||
- [ ] Physische Ausbaupläne pro Häuserblock (Glasfaser wo gegraben wird,
|
||||
Richtfunk als Standard-Alternative)
|
||||
- [ ] Gemeinschafts-Verträge: Gestattungsverträge für Kabel über Grundstücke,
|
||||
Nachbarschafts-Abkommen (Pico-Peering-artig)
|
||||
|
||||
## Phase 4 — Inhalte & Apps (Freenet)
|
||||
|
||||
- [ ] `freenet-core` als Sidecar auf 1–2 Nodes
|
||||
- [ ] Nachbarschafts-Wiki / lokale Dienste als Freenet-Contracts
|
||||
- [ ] Offline-Fähigkeit: Netz funktioniert ohne Internet (lokale Dienste)
|
||||
|
||||
## Phase 5 — Vernetzung darüber hinaus
|
||||
|
||||
- [ ] Peering mit Freifunk-Clouds oder anderen Nachbarschaftsnetzen
|
||||
- [ ] Echtes Backbone: eigene Glasfaser in Straßen, ggf. IXP-Peering
|
||||
(langfristig, NYC-Mesh-Stil)
|
||||
- [ ] Federated Viertel: mehrere AKI-Netze verbinden sich
|
||||
Reference in New Issue
Block a user