4nk/website
5
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: initial commit (website)

Browse Source
This commit is contained in:
debian 2025-09-29 08:24:59 +00:00 committed by 4NK Dev
commit 0dfaff3d8b
34 changed files with 4426 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

48
.gitignore vendored Normal file
View File

@ -0,0 +1,48 @@
# Dependencies
node_modules/
.pnpm-store/
.bun/
# Builds
build/
dist/
.next/
.out/
.vercel/
.cache/
.tmp/
.temp/
# Logs
npm-debug.log*
yarn-debug.log*
yarn-error.log*
.pnpm-debug.log*
*.log
# Env
.env
.env.*
*.local
# Coverage
coverage/
# Editors/IDE
.idea/
.vscode/
# OS
.DS_Store
Thumbs.db
# Python
__pycache__/
.venv/
venv/
# Misc
*.swp
*.swo
*.orig

26
404.html Normal file
View File

@ -0,0 +1,26 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Page not found - 4NK</title>
<link rel="stylesheet" href="styles.css">
<link rel="icon" type="image/png" href="favicon.png">
</head>
<body>
<div class="background-pattern"></div>
<div class="container" style="min-height: 100vh; display: flex; align-items: center; justify-content: center; text-align: center;">
<div>
<h1 style="font-size: 6rem; color: var(--primary-orange); margin-bottom: 1rem;">404</h1>
<h2 style="font-size: 2rem; color: var(--text-light); margin-bottom: 2rem;">Page not found</h2>
<p style="color: var(--text-gray); margin-bottom: 3rem; font-size: 1.2rem;">
The page you are looking for doesn’t exist or has been moved.
</p>
<a href="/" class="btn btn-primary" style="text-decoration: none;">
Back to home
</a>
</div>
</div>
</body>
</html>

131
README.md Normal file
View File

@ -0,0 +1,131 @@
# Site 4NK - The self-custodial cloud infrastructure
## Description
Site web moderne pour 4NK, une infrastructure révolutionnaire qui redéfinit la sécurité et la décentralisation. Le site met en valeur l'identité visuelle de la marque avec un design sombre et des effets de glow orange/jaune.
## Caractéristiques
### Design
- **Thème sombre** avec fond noir et effets de glow
- **Logos SVG** animés avec effets de lumière
- **Typographie moderne** utilisant la police Inter
- **Design responsive** pour mobile et desktop
- **Animations fluides** et effets de parallaxe
### Sections
1. **Header** - Navigation fixe avec logo animé
2. **Hero** - Section principale avec logo grand format et titre
3. **Services** - Présentation des services avec icônes animées
4. **À propos** - Description de l'entreprise avec logo showcase
5. **Contact** - Formulaire de contact interactif
6. **Footer** - Liens et informations de bas de page
### Effets visuels
- **Glow effects** sur les logos et éléments interactifs
- **Particules flottantes** en arrière-plan
- **Animations CSS** et JavaScript
- **Curseur personnalisé** avec effet de glow
- **Transitions fluides** entre les sections
## Structure des fichiers
```
website/
├── index.html # Structure HTML principale
├── styles.css # Styles CSS avec animations
├── script.js # JavaScript pour interactions
└── README.md # Documentation
```
## Installation et utilisation
### Prérequis
- Serveur web local (Python, Node.js, ou autre)
- Navigateur moderne supportant CSS3 et JavaScript
### Lancement local
1. **Avec Python** (recommandé) :
```bash
cd /home/debian/website
python3 -m http.server 8080
```
2. **Accès** :
Ouvrir http://localhost:8080 dans votre navigateur
### Alternative avec Node.js
```bash
npx serve /home/debian/website -p 8080
```
## Personnalisation
### Couleurs
Les couleurs principales sont définies dans les variables CSS :
- `--primary-orange: #FF6B35`
- `--secondary-orange: #FF8E53`
- `--accent-orange: #FFA500`
- `--gold: #FFD700`
### Logos
Les logos sont créés en SVG avec des gradients et filtres pour les effets de glow. Ils peuvent être facilement modifiés dans le code HTML.
### Animations
Les animations sont contrôlées par CSS et JavaScript. Les durées et effets peuvent être ajustés dans les fichiers respectifs.
## Compatibilité
- **Navigateurs** : Chrome, Firefox, Safari, Edge (versions récentes)
- **Responsive** : Mobile, tablette, desktop
- **Technologies** : HTML5, CSS3, JavaScript ES6+
## Performance
- **Optimisé** pour le chargement rapide
- **Images SVG** pour une qualité vectorielle
- **CSS minifiable** pour la production
- **JavaScript modulaire** et optimisé
## Développement
### Structure du code
- **HTML sémantique** avec sections bien définies
- **CSS organisé** avec variables et animations
- **JavaScript modulaire** avec gestion d'événements
### Améliorations possibles
- Ajout d'un système de build (Webpack, Vite)
- Optimisation des performances
- Tests automatisés
- Intégration CI/CD
## Licence
Projet développé pour 4NK - Tous droits réservés.
---
**Note** : Ce site a été créé pour mettre en valeur l'identité visuelle de 4NK avec un design moderne et des effets visuels impressionnants.
## Configuration et scripts (backend mailer)
- **Backend**: Node/Express + Nodemailer dans `server/`
- **Endpoint**: POST `/contact` (proxy via nginx)
- **Config nginx**: `conf/4nk.network.conf`
- **Docs nginx**: `conf/README.md`
- **Scripts**: `scripts/reload-nginx.sh`, `scripts/test-contact.sh`, `scripts/install-mailer.sh`
- **Systemd example**: `conf/4nk-mailer.service.example`
### Variables d'environnement (charger via systemd)
- `SERVER_PORT` (defaut: 3001)
- `SMTP_HOST` (defaut: 127.0.0.1)
- `SMTP_PORT` (defaut: 25)
- `SMTP_SECURE` (defaut: false)
- `SMTP_TLS_REJECT_UNAUTHORIZED` (defaut: false)
- `SMTP_FROM` (defaut: no-reply@4nk.network)
- `SMTP_TO` (defaut: nicolas.cantu@4nk.network)
Placez ces variables dans `/etc/default/4nk-mailer` et pointez `EnvironmentFile` depuis `conf/4nk-mailer.service.example`.

141
about_more.html Normal file
View File

@ -0,0 +1,141 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>4NK — About more</title>
<link rel="icon" type="image/png" href="/favicon.png">
<link rel="stylesheet" href="/styles.css">
<style>
.page { max-width: 960px; margin: 4rem auto; padding: 0 1rem; }
h1, h2, h3 { margin: 1.5rem 0 .5rem; }
.lead { opacity: .9; }
.section { margin: 2rem 0; }
ul { padding-left: 1.2rem; }
.header-actions { margin: 1.5rem 0 2rem; display: flex; gap: .75rem; }
.manifesto-grid { display: grid; grid-template-columns: 1fr 1fr; gap: 1.5rem; align-items: stretch; }
.manifesto-figure { align-self: start; }
.manifesto-img { height: 100%; width: auto; max-width: 100%; object-fit: contain; border-radius: 8px; box-shadow: 0 10px 30px rgba(255,107,53,.15); }
@media (max-width: 768px) {
.manifesto-grid { grid-template-columns: 1fr; }
.manifesto-img { width: 100%; height: auto; }
}
</style>
</head>
<body>
<div class="page">
<h1>4NK — Self‑Custodial Cloud OS</h1>
<p class="lead">Safer, simpler, sovereign, and inexpensive.</p>
<div class="header-actions">
<a class="btn btn-secondary" href="/">Back to homepage</a>
</div>
<div class="section">
<h2>What’s the problem?</h2>
<p>The cloud market is dominated by permissioned and vulnerable third‑party solutions. Users pay increasingly high rent to someone to manage their identities and access their own data, while facing hacks, ransoms and surveillance. Digital sovereignty is a well‑understood requirement, yet everyone pays the price of simplicity at their own expense. Every time we click “accept,” we reinforce economic, security, and policy dependency. What if the solution was in our own hands?</p>
</div>
<div class="section">
<h2>How to fix this? — Manifesto</h2>
<div class="manifesto-grid">
<div class="manifesto-figure">
<img src="/img/Clipboard%20-%2026%20septembre%202025%2013_46.png" alt="4NK illustration" class="manifesto-img">
</div>
<div>
<p>We want to own and manage our logins, sharing, payments, messages, and identity without passing through central servers or leaking metadata. We want to handle it all directly on and from our devices.</p>
<ul>
<li>No CAPEX, no data centers required</li>
<li>Each user is a building block of the infrastructure</li>
<li>Every flow is a cryptographic proof</li>
<li>Every action is a verifiable validation</li>
</ul>
<p>We want digital sovereignty to be a technical reality, not a third‑party promise.</p>
</div>
</div>
</div>
<div class="section">
<h2>Introducing the Self‑Custodial Cloud OS</h2>
<p>An app to rebuild the web—upright:</p>
<ul>
<li><b>Identity</b>: users own and manage their keys</li>
<li><b>Security</b>: distributed and fully encrypted storage</li>
<li><b>Infrastructure‑less</b>: leverage existing underused devices (laptops, servers)</li>
<li><b>Network layer</b>: distributed and open; islands of nodes</li>
<li><b>Proofs at every step</b>: verifiable and anchored in Bitcoin</li>
<li><b>Third‑party dependencies</b>: none</li>
<li><b>Open‑source</b></li>
</ul>
<p>No blockchain and no token: a client‑side infrastructure that extends Bitcoin’s properties for everyday use.</p>
</div>
<div class="section">
<h2>What can we do with it?</h2>
<ul>
<li><b>Personal sovereignty</b>: secure document storage and sharing; “100% local” LLM on user content</li>
<li><b>Collaborative</b>: P2P secure messaging (no central server, no metadata leakage); secure document workflows (encrypted storage and sharing, simple identity management, timestamped proofs at every step); discovery and publishing of “contracts”; payment layer</li>
</ul>
</div>
<div class="section">
<h2>Bitcoin under the hood</h2>
<ul>
<li>Secure messaging with an embedded Bitcoin wallet in the browser using silent payments for secure and metadata‑less messaging</li>
<li>Log in with one scan: native Lightning support (no Stripe, no PayPal)</li>
<li>Records and actions are timestamped on Bitcoin L1 (a few bytes/day)</li>
</ul>
</div>
<div class="section">
<h2>How it works</h2>
<p>Super‑simple user experience:</p>
<ul>
<li>Lightweight background app turns existing, often‑idle equipment into a node</li>
<li>100% browser‑based UX to interact with the node, locally or remotely, for owners and invitees</li>
<li>Log in with one scan, 2FA options, multi‑sig, including phone enrollment</li>
<li>Secure messaging layer with no metadata leakage</li>
<li>“Chat‑first” experience (roadmap)</li>
</ul>
<h3>Networks</h3>
<ul>
<li>Every user is a building block of the new infrastructure</li>
<li>Professional islands and opt‑in to larger networks (forming Layer 2s)</li>
<li>Scale‑out, small or large</li>
</ul>
</div>
<div class="section">
<h2>Disrupting a huge market</h2>
<p>The cloud and collaborative market is dominated by GAFAMs, a TAM of $250B. “Under‑the‑radar” SAM is about $80M. Beyond 2030 ambition: $3–5B (≈2% of the market).</p>
</div>
<div class="section">
<h2>Status</h2>
<ul>
<li>Main software development: done</li>
<li>$500K revenue from paid POC customers over the last 24 months</li>
<li>Pipeline: 5–10 prospects from SMBs to Tier‑1 operators (Orange, Docaposte), sales cycle evolving</li>
<li>Pre‑production white‑label service targeted to French Notaries</li>
<li>Soon to launch: DOCV.fr (B2C2B freemium)</li>
</ul>
</div>
<div class="section">
<h2>What’s next?</h2>
<p>Pre‑series round: raise $500K from strategic, supportive partners.</p>
<p><b>Key objectives</b> include GTM kickoff (sales/marketing, PLG motion), profession‑centric deployments (notaries, lawyers, family offices, local public branches, health), white‑label distribution (convert Tier1/2 POCs), opportunistic SMB workflows, feature iteration toward PMF and international reach, and reaching break‑even with $1M ARR to enter Series A in under 15 months.</p>
<p><b>$100M ARR in 5 years is feasible.</b></p>
</div>
<div class="section">
<h2>Who we are</h2>
<p>4NK and its ecosystem. Tomorrow’s winners don’t wait for the next hack — contact us today for a demo.</p>
<p>
<a class="btn btn-primary" href="mailto:contact@4nk.network">Request a demo</a>
<a class="btn btn-secondary" href="/">Back to homepage</a>
</p>
</div>
</div>
<script src="/script.js"></script>
</body>
</html>

23
conf/4nk-mailer.service.example Normal file
View File

@ -0,0 +1,23 @@
[Unit]
Description=4NK Website Mailer (Express/Nodemailer)
After=network.target
[Service]
Type=simple
WorkingDirectory=/home/debian/website/server
ExecStart=/usr/bin/node index.js
Restart=always
RestartSec=2
Environment=NODE_ENV=production
# Optional: external environment file
# Create /etc/default/4nk-mailer and uncomment the next line
# EnvironmentFile=/etc/default/4nk-mailer
NoNewPrivileges=true
ProtectSystem=full
ProtectHome=true
PrivateTmp=true
[Install]
WantedBy=multi-user.target

74
conf/4nk.network.conf Normal file
View File

@ -0,0 +1,74 @@
# Configuration nginx pour 4nk.network
# Redirection HTTP vers HTTPS et service du site statique
events {
worker_connections 1024;
}
http {
# Redirection HTTP vers HTTPS pour 4nk.network
server {
listen 80;
server_name 4nk.network www.4nk.network;
# Redirection permanente vers HTTPS
return 301 https://$server_name$request_uri;
}
# Configuration HTTPS pour 4nk.network
server {
listen 443 ssl;
http2 on;
server_name 4nk.network www.4nk.network;
# Configuration SSL (certificats auto-signés temporaires)
ssl_certificate /etc/ssl/4nk.network/fullchain.pem;
ssl_certificate_key /etc/ssl/4nk.network/privkey.pem;
# Configuration SSL moderne
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
# Headers de sécurité
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options DENY always;
add_header X-Content-Type-Options nosniff always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
# Configuration du site
root /home/debian/website;
index index.html;
# Gestion des fichiers statiques
location / {
try_files $uri $uri/ =404;
# Cache pour les fichiers statiques
location ~* \.(css|js|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
}
# Gestion des erreurs
error_page 404 /404.html;
# Proxy pour l'API de contact
location /contact {
proxy_pass http://127.0.0.1:3001;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
# Logs
access_log /var/log/nginx/4nk.network.access.log;
error_log /var/log/nginx/4nk.network.error.log;
}
}

179
conf/README.md Normal file
View File

@ -0,0 +1,179 @@
# Configuration nginx pour 4nk.network
## Configuration actuelle
Le site 4nk.network est configuré avec nginx pour servir le site statique avec les fonctionnalités suivantes :
### ✅ Fonctionnalités implémentées
- **Redirection HTTP → HTTPS** : Toutes les requêtes HTTP sont automatiquement redirigées vers HTTPS
- **Certificats SSL** : Certificats auto-signés temporaires (en attente de configuration DNS)
- **Headers de sécurité** : HSTS, X-Frame-Options, X-Content-Type-Options, etc.
- **HTTP/2** : Support du protocole HTTP/2 pour de meilleures performances
- **Cache optimisé** : Cache des fichiers statiques (CSS, JS, images) pour 1 an
- **Logs** : Logs d'accès et d'erreur spécifiques au domaine
- **Proxy /contact** : Requêtes POST du formulaire vers le backend local `127.0.0.1:3001`
### 📁 Fichiers de configuration
- `4nk.network.conf` : Configuration nginx principale
- `letsencrypt-setup.sh` : Script pour migrer vers Let's Encrypt
- `README.md` : Cette documentation
- `4nk-mailer.service.example` : Exemple d'unité systemd pour le backend mailer
## 🚀 Prochaines étapes
### 1. Configuration DNS
Pour activer les certificats Let's Encrypt, vous devez configurer le DNS :
```bash
# Enregistrements DNS requis
4nk.network. A [IP_DU_SERVEUR]
www.4nk.network. A [IP_DU_SERVEUR]
```
### 2. Migration vers Let's Encrypt
Une fois le DNS configuré, exécutez le script de migration :
```bash
sudo /home/debian/website/conf/letsencrypt-setup.sh
```
Ce script va :
- Vérifier que le DNS pointe vers ce serveur
- Générer les certificats Let's Encrypt
- Mettre à jour la configuration nginx
- Configurer le renouvellement automatique
### 3. Test de la configuration
```bash
# Test de la redirection HTTP → HTTPS
curl -I http://4nk.network
# Test de l'accès HTTPS
curl -I https://4nk.network
# Test du proxy /contact (attend 400 si champs manquants)
curl -i -X POST https://4nk.network/contact -H 'content-type: application/json' -d '{"name":"","email":"","message":""}'
# Test des headers de sécurité
curl -I https://4nk.network | grep -E "(Strict-Transport-Security|X-Frame-Options)"
```
## 🔧 Gestion de la configuration
### Redémarrage de nginx
```bash
# Test de la configuration
sudo nginx -t
# Rechargement de la configuration
sudo systemctl reload nginx
# Redémarrage complet
sudo systemctl restart nginx
```
### Vérification des certificats
```bash
# Certificats auto-signés actuels
sudo openssl x509 -in /etc/ssl/4nk.network/fullchain.pem -text -noout
# Certificats Let's Encrypt (après migration)
sudo certbot certificates
```
### Logs
```bash
# Logs d'accès
sudo tail -f /var/log/nginx/4nk.network.access.log
# Logs d'erreur
sudo tail -f /var/log/nginx/4nk.network.error.log
## Backend mailer (Express + Nodemailer)
- Service HTTP local: `http://127.0.0.1:3001`
- Endpoints: `POST /contact`, `GET /health`
- Code: `/home/debian/website/server/index.js`
### Variables d'environnement supportées
- `SERVER_PORT` (defaut: 3001)
- `SMTP_HOST` (defaut: 127.0.0.1)
- `SMTP_PORT` (defaut: 25)
- `SMTP_SECURE` (defaut: false)
- `SMTP_TLS_REJECT_UNAUTHORIZED` (defaut: false)
- `SMTP_FROM` (defaut: no-reply@4nk.network)
- `SMTP_TO` (defaut: nicolas.cantu@4nk.network)
Vous pouvez utiliser un fichier d'environnement chargé par systemd via `EnvironmentFile`.
### Exemple d'unité systemd
Voir `conf/4nk-mailer.service.example` et adaptez le chemin de `EnvironmentFile` si besoin.
```
## 📊 Monitoring
### Vérification du statut
```bash
# Statut nginx
sudo systemctl status nginx
# Test de connectivité
curl -I https://4nk.network
# Vérification SSL
openssl s_client -connect 4nk.network:443 -servername 4nk.network
```
### Renouvellement des certificats
Les certificats Let's Encrypt sont automatiquement renouvelés via cron :
```bash
# Vérifier la tâche cron
crontab -l | grep certbot
# Renouvellement manuel
sudo certbot renew --dry-run
```
## 🛡️ Sécurité
### Headers de sécurité configurés
- `Strict-Transport-Security` : Force HTTPS pendant 1 an
- `X-Frame-Options: DENY` : Empêche le clickjacking
- `X-Content-Type-Options: nosniff` : Empêche le MIME sniffing
- `X-XSS-Protection` : Protection XSS
- `Referrer-Policy` : Contrôle des référents
### Configuration SSL
- Protocoles : TLSv1.2 et TLSv1.3
- Ciphers modernes et sécurisés
- Session cache optimisé
- Prefer server ciphers désactivé
## 📝 Notes importantes
1. **DNS requis** : Les certificats Let's Encrypt nécessitent que le domaine pointe vers ce serveur
2. **Ports ouverts** : Assurez-vous que les ports 80 et 443 sont ouverts
3. **Sauvegarde** : La configuration actuelle est sauvegardée avant migration
4. **Renouvellement** : Les certificats Let's Encrypt expirent tous les 90 jours
## 🔗 Liens utiles
- [Documentation nginx](https://nginx.org/en/docs/)
- [Let's Encrypt](https://letsencrypt.org/)
- [Certbot](https://certbot.eff.org/)
- [SSL Labs Test](https://www.ssllabs.com/ssltest/)

126
conf/letsencrypt-setup.sh Executable file
View File

@ -0,0 +1,126 @@
#!/bin/bash
# Script pour configurer Let's Encrypt pour 4nk.network
# À exécuter une fois que le DNS est configuré
set -e
DOMAIN="4nk.network"
EMAIL="admin@4nk.network"
NGINX_CONF="/etc/nginx/sites-available/4nk.network.conf"
BACKUP_CONF="/etc/nginx/sites-available/4nk.network.conf.backup"
echo "🔧 Configuration Let's Encrypt pour $DOMAIN"
echo "=============================================="
# Vérifier que le domaine pointe vers ce serveur (prise en charge IPv4/IPv6)
echo "📡 Vérification DNS (A/AAAA) et IP publique (v4/v6)..."
# Récupère les enregistrements DNS A et AAAA
DOMAIN_IPV4S=$(dig +short A $DOMAIN | tr '\n' ' ' | sed 's/ *$//')
DOMAIN_IPV6S=$(dig +short AAAA $DOMAIN | tr '\n' ' ' | sed 's/ *$//')
# Récupère les IP publiques du serveur (si existantes)
SERVER_IPV4=$(curl -4 -s https://api.ipify.org || true)
SERVER_IPV6=$(curl -6 -s https://api64.ipify.org || true)
echo " Domaine A: ${DOMAIN_IPV4S:-none}"
echo " Domaine AAAA: ${DOMAIN_IPV6S:-none}"
echo " Serveur v4: ${SERVER_IPV4:-none}"
echo " Serveur v6: ${SERVER_IPV6:-none}"
DNS_OK=false
# Correspondance IPv4 si disponible
if [ -n "$SERVER_IPV4" ] && echo "$DOMAIN_IPV4S" | grep -q "\b$SERVER_IPV4\b"; then
DNS_OK=true
fi
# Correspondance IPv6 si disponible
if [ -n "$SERVER_IPV6" ] && echo "$DOMAIN_IPV6S" | grep -q "\b$SERVER_IPV6\b"; then
DNS_OK=true
fi
if [ "$DNS_OK" != true ]; then
echo "❌ Erreur: Le domaine $DOMAIN ne pointe pas vers l'IP publique de ce serveur"
echo " Vérifiez les enregistrements DNS A et/ou AAAA selon votre connectivité."
exit 1
fi
echo "✅ DNS configuré correctement (A/AAAA)"
# Sauvegarder la configuration actuelle
echo "💾 Sauvegarde de la configuration nginx..."
sudo cp "$NGINX_CONF" "$BACKUP_CONF"
# Créer une configuration temporaire pour certbot
echo "🔧 Création de la configuration temporaire..."
sudo tee /tmp/4nk.network-temp.conf > /dev/null <<EOF
# Configuration nginx temporaire pour certbot
server {
listen 80;
server_name $DOMAIN www.$DOMAIN;
root /home/debian/website;
index index.html;
location / {
try_files \$uri \$uri/ =404;
}
}
EOF
# Remplacer la configuration nginx
sudo cp /tmp/4nk.network-temp.conf "$NGINX_CONF"
sudo nginx -t
sudo systemctl reload nginx
# Générer les certificats Let's Encrypt
echo "🔐 Génération des certificats Let's Encrypt..."
sudo certbot --nginx -d $DOMAIN -d www.$DOMAIN --non-interactive --agree-tos --email $EMAIL
# Vérifier que les certificats ont été générés
if [ -f "/etc/letsencrypt/live/$DOMAIN/fullchain.pem" ]; then
echo "✅ Certificats Let's Encrypt générés avec succès"
# Mettre à jour la configuration nginx avec les vrais certificats
echo "🔧 Mise à jour de la configuration nginx..."
sudo sed -i "s|/etc/ssl/$DOMAIN/fullchain.pem|/etc/letsencrypt/live/$DOMAIN/fullchain.pem|g" "$NGINX_CONF"
sudo sed -i "s|/etc/ssl/$DOMAIN/privkey.pem|/etc/letsencrypt/live/$DOMAIN/privkey.pem|g" "$NGINX_CONF"
sudo sed -i "s|# Configuration SSL (certificats auto-signés temporaires)|# Configuration SSL (Let's Encrypt)|g" "$NGINX_CONF"
sudo nginx -t
sudo systemctl reload nginx
echo "🎉 Configuration terminée avec succès !"
echo " Site accessible sur: https://$DOMAIN"
echo " Redirection HTTP vers HTTPS activée"
echo " Certificats SSL valides et sécurisés"
# Configurer le renouvellement automatique (cron si disponible, sinon systemd timer de certbot)
echo "🔄 Configuration du renouvellement automatique..."
if command -v crontab >/dev/null 2>&1; then
(crontab -l 2>/dev/null; echo "0 12 * * * /usr/bin/certbot renew --quiet") | crontab -
echo " Cron installé pour le renouvellement quotidien."
else
echo " 'crontab' indisponible. Certbot a déjà installé un timer systemd (recommandé)."
echo " Vous pouvez vérifier via: systemctl list-timers | grep certbot"
fi
else
echo "❌ Erreur lors de la génération des certificats"
echo "🔄 Restauration de la configuration de sauvegarde..."
sudo cp "$BACKUP_CONF" "$NGINX_CONF"
sudo systemctl reload nginx
exit 1
fi
echo ""
echo "📋 Résumé de la configuration:"
echo " - Domaine: $DOMAIN et www.$DOMAIN"
echo " - Redirection HTTP → HTTPS"
echo " - Certificats SSL Let's Encrypt"
echo " - Headers de sécurité activés"
echo " - Renouvellement automatique configuré"
echo ""
echo "🌐 Testez votre site: https://$DOMAIN"

BIN
docs/4NK PITCH V0.1.pdf Normal file
View File

Binary file not shown.

75
docs/custordian_killer.md Normal file
View File

@ -0,0 +1,75 @@
4NK: the self-custodial cloud infrastructure
For fifteen years, Bitcoin has proven that a decentralized network can secure value without any trusted intermediary. Every block, every signature, every verification is performed by the users themselves. No need for a centralized custodian: everyone can verify, everyone can hold.
But outside of payments, the digital world still relies everywhere on trusted third parties:
centralized clouds and servers,
messaging platforms,
digital identity services,
storage solutions.
These custodians capture data, impose costs, and create points of failure. They are the equivalent of banks before Bitcoin: convenient, but vulnerable and intrusive.
4NK: Bitcoin beyond payment
4NK is a client-side infrastructure layer that extends Bitcoin’s native properties to everyday digital uses:
The resilience of a distributed proof network → every flow becomes verifiable, without relying on a server.
Money as a universal mechanism → reliable remuneration for security.
Cryptography as identity → public keys extended into digital identities.
How does it work?
Encrypted messaging: based on non-interactive secret sharing derived from Silent Payments. Each message generates a unique, encrypted, and untraceable secret, with no third party involved.
Off-chain contracts: signed by Bitcoin wallets, validated by peers, and linked to a layer-2 oracle (Signet) regularly anchored on the Bitcoin mainnet.
Distributed storage: files kept locally between stakeholders or in a mesh network, never in cleartext, never in a public cloud.
Payments in one scan: native Lightning integration, no Stripe, no PayPal.
Everything is operated client-side (Client-Side Validation). No custodian.
Custodian-killer
Just as Bitcoin killed the need for a central bank to hold and transfer value, 4NK kills the need for digital custodians to identify, exchange, store, and contract.
This is not a new blockchain. This is not a token. It is the natural extension of Bitcoin:
distributed proofs as a foundation,
money as a universal rail,
public keys as digital identities,
secret sharing as sovereign messaging.
4NK is not a theory
Notaries: legal acts anchored on a proof layer over Bitcoin.
SMEs: sovereign document management, serverless messaging.
Public bodies: integrations underway with operators.
Healthcare: POC in deployment.
Every time, the model is the same: replace a custodian with Bitcoin + client-side.
The result
Making Bitcoin not only the currency of trust, but also the universal infrastructure layer of the digital world:
Simpler login: four words + multisignature across devices.
Simpler payments: compatible with all Bitcoin rails + integrated Silent Payment wallet (web & mobile).
Cheaper, no CAPEX: more users = more resources.
Cheaper, no infrastructure: less tooling, less supervision, less complexity.
More secure: encryption directly by user identities, redundancy included.
More resilient: no central point, no centralized rights management.
Fully verifiable cryptographically via the anchoring layer.
Everything is a contract: compliance with agreements, norms, and standards is cryptographically enforced between final parties, where the proof system is also the payment system.
As fast as needed: there is always a route to deliver the information.
Our focus
Local AI experiences integrated into a “Chat First” UX, replacing legacy workflows.
Effective support, separate from core development.
Our ambition
To make Bitcoin not only the currency of trust, but also the universal infrastructure layer of the internet:
identity,
messaging,
contracts,
storage.
An internet where the user is sovereign, verification is local, and custodians belong permanently to the past.
4NK: the self-custodial cloud infrastructure.

721
docs/manifest.md Normal file
View File

@ -0,0 +1,721 @@
4NK : Manifeste d'une troisième voie pour un web souverain, sobre et vérifiable
4NK : le web plus simple, moins cher, plus fiable et souverain.
Synthèse
Aujourd’hui, notre internet vit une crise structurelle. D’un côté, le Web2 a apporté la simplicité d’usage mais repose sur une architecture centralisée qui fuit les données par défaut. Chaque interaction génère des métadonnées captées et exploitées par des plateformes privées. Cela a conduit à un internet exploité, où l’utilisateur a perdu toute maîtrise de ses informations. Résultat : 9 Français sur 10 ont déjà vu leurs données personnelles circuler sur le dark web. De l’autre, les États ont tenté de réagir par la fragmentation : clouds souverains, règles nationales, blockchains publiques nationales. Mais cela produit une balkanisation du réseau : des internets fermés, surveillés, incompatibles, qui ne restaurent pas la confiance.
Le Web3, censé être l’alternative, a échoué. Il a voulu tout décentraliser, créant de nouvelles complexités : wallets, tokens, frais de transactions, dépendance à quelques blockchains dominantes. Le Web5, initié par Jack Dorsey, a eu l’intuition juste : combiner la simplicité du Web2 et la résilience cryptographique du Web3. Mais il est resté limité par sa dépendance Bitcoin comme unique rail monétaire forcé.
C’est dans ce contexte qu’apparaît 4NK. 4NK n’est pas une couche marketing, ni une énième blockchain. C’est une infrastructure distribuée, sobre et vérifiable : une troisième voie.
Nos principes sont clairs :
Relais neutres en mesh : ils ne contrôlent rien, ne stockent rien, ne surveillent rien. Ils ne font que synchroniser et répliquer des preuves cryptographiques.
Souveraineté de l’utilisateur : les clés, les données, les identités restent exclusivement sous contrôle des utilisateurs.
Vérifiabilité universelle : chaque action est ancrée et traçable cryptographiquement, sans dépendre d’un tiers.
Sobriété numérique : aucune infrastructure lourde, aucun cloud étranger, pas de CAPEX supplémentaires. La résilience découle de la distribution, pas de la duplication énergivore.
Concrètement, l’expérience reste identique au Web2 : même simplicité, même fluidité. Mais sous le capot, plus de fuites structurelles, plus de dépendance aux plateformes ou aux États. 4NK permet de :
sécuriser la messagerie, les documents et n'importe quel flux numérique,
ancrer et horodater de façon immuable des preuves,
gérer une identité numérique souveraine et portable,
simplifier les paiements et interactions,
assurer la conformité réglementaire sans exposition massive de données.
En résumé, 4NK brise le plafond de verre de la cybersécurité. Là où les infrastructures centralisées finissent toujours par fuir malgré les audits et certifications, 4NK rend la fuite impossible par design. C’est une infrastructure de résilience, où l’utilisateur est souverain, où la confiance repose sur des preuves, et où l’internet retrouve son universalité sans être exploité ni fragmenté.
4NK, c’est la troisième voie : un web souverain, simple, sobre et vérifiable.
4NK déploie sa technologie par étapes : d’abord auprès des professions réglementées et secteurs critiques (notariat, logistique, santé), puis via des modules isolés distribués par intégrateurs et opérateurs pour atteindre PME et collectivités. À horizon 2027-2030, l’ambition est une extension européenne, fondée sur un modèle distribué « sans infrastructure », alliant souveraineté, sobriété et conformité réglementaire accessible à tous les services numériques, partout, en open source.
Un internet exploité et fragmenté : entre asymétrie économique et cloisonnement politique
Une promesse originelle détournée
L’internet est né d’une ambition claire : relier des réseaux hétérogènes pour permettre la circulation libre et universelle de l’information. Il devait constituer un espace neutre, distribué par nature, favorisant la coopération scientifique, la communication entre individus et, à terme, l’innovation sociale et économique.
Or, trente ans après, ce projet initial a été profondément altéré. Le réseau mondial se trouve aujourd’hui piégé dans une double impasse : d’un côté, son exploitation par des infrastructures privées qui en font un outil de captation et de surveillance ; de l’autre, son cloisonnement progressif par les États qui tentent de le fragmenter pour en reprendre le contrôle. Ce double mouvement a transformé le web en un espace structurellement insécure, où l’utilisateur n’a ni maîtrise réelle de ses données, ni garantie de neutralité.
L’exploitation structurelle du Web2
Le Web2, tel que nous le connaissons, repose sur une architecture client-serveur qui place les données des utilisateurs au cœur de plateformes centralisées. Cette conception a apporté une simplicité d’usage et une accessibilité sans précédent : réseaux sociaux, moteurs de recherche, commerce en ligne, services de cloud.
Cependant, cette commodité est indissociable d’un problème de design : le Web2 a été pensé pour fuir les données par défaut. Chaque interaction – connexion, recherche, message, clic – génère des flux d’informations qui, loin d’être limités à l’action souhaitée, produisent une masse de métadonnées invisibles. Ces traces révèlent des comportements, des profils, des préférences, et sont ensuite exploitées pour générer des modèles économiques fondés sur la publicité ciblée, la recommandation algorithmique et la revente de données.
L’utilisateur perd alors la maîtrise de ce qu’il révèle au monde. Cette asymétrie informationnelle alimente la puissance économique des grandes plateformes, qui transforment ces données en confort d’usage (personnalisation, fluidité), mais aussi en intelligence artificielle “imbattable”, entraînée par les comportements collectifs de milliards d’individus.
Conséquences économiques et sociétales
Cette exploitation systématique ne relève pas seulement de l’atteinte à la vie privée : elle engendre des conséquences économiques et sociales majeures, déjà visibles dans plusieurs secteurs.
Fermeture de sociétés fragilisées : de nombreuses entreprises ont dû cesser leur activité après une fuite massive de données ou une cyberattaque, révélant l’absence de maîtrise comme une cause directe de faillite.
Dégradation manifeste de la confiance : des observatoires comme bonjourlafuite.eu.org recensent quotidiennement les fuites massives de données. Chaque mois, ce sont des millions de comptes compromis, alimentant un climat général de défiance.
Pillage industriel invisible : la captation de données stratégiques (brevets, secrets industriels, données R&D) constitue une forme de spoliation silencieuse. Elle fragilise la compétitivité nationale et les chaînes de valeur, sans que les victimes en aient immédiatement conscience.
Complexification de l’expérience utilisateur : les utilisateurs sont confrontés à une prolifération de logins, de mots de passe et de procédures d’authentification de plus en plus lourdes. Ce paradoxe est frappant : le Web2 promettait simplicité et immédiateté, il produit désormais friction et surcharge cognitive.
Pertes de revenus liées au paiement : les systèmes centralisés de paiement en ligne, coûteux et opaques, freinent les transactions, provoquent des abandons d’achat et créent une dépendance aux intermédiaires financiers.
Crise de l’identification numérique : l’impossible identification fluide, ou à l’inverse des procédures si complexes qu’elles découragent l’usage, détruit progressivement la confiance dans les services numériques.
Ces conséquences ne sont pas marginales. Elles touchent directement la société dans son ensemble. Neuf Français sur dix ont déjà vu leurs données d’identité circuler sur le dark web, conséquence directe de fuites dans des bases centralisées. Ce chiffre, souvent rappelé dans les rapports de cybersécurité, illustre l’ampleur d’une fragilité systémique : tant que les données restent concentrées, elles constituent une cible unique et donc inévitablement compromise.
La fragmentation étatique : l’autre impasse
Face à ces dérives, les États ont tenté de réagir en érigeant des barrières numériques. Sous couvert de souveraineté, ils imposent des régulations de localisation des données, développent des clouds dits “de confiance” ou établissent des infrastructures nationales prétendument neutres.
Cette stratégie aboutit cependant à une balkanisation du réseau. Chaque territoire impose ses propres règles d’accès, ses systèmes d’authentification, ses formats propriétaires. L’universalité originelle du web est remplacée par un archipel d’internets fragmentés, parfois incompatibles, toujours surveillés.
Le cas de la blockchain Archipel, fermée après quelques années d’expérimentation, illustre ce paradoxe. Pensée comme un outil de souveraineté numérique, elle s’est révélée incohérente dans son principe : un État, par nature centralisateur, ne peut piloter une infrastructure décentralisée sans la vider de son sens.
Un double échec structurel
Le bilan est clair :
Le Web2 produit un internet exploité, dont la valeur est captée par des infrastructures privées, au détriment des utilisateurs et des économies nationales.
Les tentatives de reprise en main étatique produisent un internet dystopique et fragmenté, où l’autonomie promise se transforme en nouvelles dépendances.
Ce double échec crée un plafond de verre : malgré les audits, les certifications, les réglementations et les meilleures pratiques, les données continuent de fuir, la confiance continue de se dégrader et la résilience reste hors d’atteinte.
Ce constat fonde la nécessité d’une refonte de l’infrastructure elle-même. Ce n’est pas l’ajout de couches réglementaires ni la simple amélioration des pratiques qui suffira. Seule une architecture différente, pensée pour restaurer la souveraineté de l’utilisateur tout en préservant la simplicité d’usage, peut briser ce plafond de verre.
L’identité numérique : clé de voûte de la sécurité et des usages souverains
L’identité comme pivot du numérique contemporain
Dans l’infrastructure numérique actuelle, l’identité est devenue la clé de voûte de tous les usages : se connecter, signer, payer, accéder à des services, échanger des données. Sans identité robuste et maîtrisée, aucune souveraineté numérique n’est possible.
Or, c’est précisément ce point névralgique qui concentre aujourd’hui les antagonismes :
Les plateformes du Web2 ont transformé l’identité en identifiant publicitaire. Les comptes Google, Apple ou Facebook servent d’“identité universelle”, mais au prix d’une captation totale des usages et d’un suivi omniprésent.
Le Web3 a voulu rendre l’identité programmable par les blockchains, mais il l’a réduite à une simple clé publique exposée, souvent réutilisée partout, produisant une traçabilité excessive et une exposition de la vie privée.
Les États cherchent à imposer des identités numériques centralisées (cartes d’identité électroniques, login public universel), mais ce modèle concentre le pouvoir et fait peser un risque systémique : un seul centre peut contrôler, surveiller ou bloquer les usages de millions d’individus.
Ainsi, la centralité de l’identité rend visibles trois risques majeurs : la surveillance (quand l’identité est contrôlée par l’État), la captation économique (quand elle est détenue par des plateformes privées) et la traçabilité excessive (quand elle est réduite à une clé unique dans les blockchains).
Les limites et contradictions actuelles
L’architecture actuelle de l’identité numérique n’est pas seulement imparfaite : elle est dangereuse. La concentration des données d’identité dans de grands registres – qu’ils soient publics ou privés – engendre des fuites massives qui mettent directement en danger les populations. Ces bases centralisées, souvent administrées par des institutions censées protéger les citoyens, deviennent les cibles privilégiées des cybercriminels.
Les conséquences ne sont pas seulement économiques (fraude, usurpation, pillage industriel) mais physiques : des personnes sont exposées à des risques de mutilations, de séquestrations ou d’attaques ciblées lorsque leurs informations sensibles (adresses, biométries, données médicales) circulent sur le dark web. Or, ces fuites ne sont pas accidentelles : elles sont structurellement inévitables tant que l’identité repose sur des registres centraux.
Cette fragilisation des citoyens contraste avec l’inefficacité manifeste des dispositifs de surveillance qui la justifient. Ainsi, les mécanismes de lutte contre le blanchiment (AML), qui imposent une collecte massive de données personnelles, ne produisent que des résultats marginaux : seuls 0,02 % des flux illicites mondiaux sont effectivement affectés par ces dispositifs. En d’autres termes, les citoyens subissent une surveillance invasive et risquée pour un bénéfice dérisoire en matière de sécurité financière réelle.
À cette logique s’ajoute une dérive croissante : la généralisation du contrôle d’âge systématisé sur les services numériques. Sous prétexte de protéger les mineurs, des millions d’utilisateurs – y compris des enfants – sont contraints de fournir leurs identités numériques pour accéder à des contenus. Cette pratique engendre la constitution de bases d’identités numériques d’enfants, hautement sensibles et extrêmement dangereuses. La création de telles bases expose une population vulnérable à des risques majeurs en cas de fuite, sans que le bénéfice pour la protection réelle de l’enfance soit démontré.
Ces contradictions révèlent l’impasse : plus l’identité numérique est centralisée et collectée massivement, plus elle devient une menace pour les citoyens, tout en produisant des résultats dérisoires dans la lutte contre la criminalité et les abus.
La tension est manifeste : plus l’identité numérique devient un outil universel, plus elle se transforme en point unique de vulnérabilité.
Les conséquences économiques et sociales d’un internet vulnérable
Un coût systémique croissant
L’insécurité structurelle du Web2 – fuites de données, dépendance aux plateformes, fragilité des infrastructures centralisées – engendre un coût massif, souvent sous-estimé. Selon les estimations de l’OCDE et de l’ENISA, les cyberattaques et fuites de données coûtent déjà plusieurs points de PIB par an aux économies avancées. Mais ces chiffres globaux masquent une réalité plus fine : ce ne sont pas seulement les “attaques” qui coûtent cher, mais le design même du réseau qui rend ces pertes inévitables.
Les entreprises : faillites, pillage et perte de compétitivité
Faillites liées aux fuites de données : de nombreuses PME et ETI ferment leurs portes à la suite d’une compromission massive. L’accès aux comptes clients, la perte de données stratégiques ou la fuite de secrets industriels peuvent suffire à détruire la confiance et la viabilité d’une entreprise.
Pillage industriel invisible : les fuites ne concernent pas seulement des données personnelles. Plans, brevets, prototypes, informations financières circulent discrètement sur des marchés parallèles. La spoliation de propriété intellectuelle est rarement médiatisée, mais elle constitue une hémorragie silencieuse pour la compétitivité nationale.
Surcoûts de conformité et de sécurité : pour compenser la vulnérabilité de leurs infrastructures, les entreprises investissent dans des audits, certifications, couches défensives. Ces coûts croissants ne créent pas de valeur ajoutée, mais deviennent un poste budgétaire incompressible.
Les citoyens : perte de confiance et surcharge cognitive
Données massivement exposées : neuf Français sur dix ont déjà vu leurs données d’identité personnelles figurer sur le dark web. Ce chiffre illustre non pas des incidents isolés, mais une fuite structurelle des bases centralisées.
Défiance envers le numérique : confrontés à des messages permanents d’alerte (“votre mot de passe a été compromis”), les citoyens perdent confiance. L’usage du numérique devient une source d’anxiété.
Surcharge cognitive liée à l’identification : logins multiples, mots de passe complexes, authentification multi-facteurs. L’expérience est devenue laborieuse, éloignant la promesse initiale de simplicité.
Exclusion numérique : certains publics (personnes âgées, petites entreprises sans DSI) renoncent à certains services faute de maîtriser les procédures complexes.
Les États : fragmentation et perte de souveraineté
Balkanisation du réseau : pour répondre à l’insécurité, les États érigent des murs numériques (clouds nationaux, obligations de localisation). Cela produit des réseaux fragmentés, incompatibles avec l’universalité initiale du web.
Perte de légitimité : chaque nouvelle fuite dans des bases administratives fragilise la confiance des citoyens envers l’État comme garant de la sécurité numérique.
Souveraineté illusoire : les clouds nationaux restent dépendants de couches logicielles et matérielles étrangères, ce qui limite leur autonomie réelle.
Un cercle vicieux
L’ensemble de ces conséquences alimente un cercle vicieux :
Plus les fuites se multiplient, plus les utilisateurs perdent confiance.
Plus la confiance se dégrade, plus les acteurs multiplient les couches défensives et réglementaires.
Plus les couches se multiplient, plus l’expérience utilisateur se complexifie et plus les coûts augmentent.
Et malgré tout, les fuites continuent, car le problème est architectural et non opérationnel.
En d’autres termes : tant que l’infrastructure repose sur la centralisation, les pertes sont inévitables.
4NK comme levier de sortie
Les conséquences économiques et sociales de l’internet vulnérable ne peuvent être contenues par des ajustements incrémentaux. Elles appellent une refonte du socle technique.
Pour les entreprises, 4NK offre une architecture où la fuite structurelle est impossible, réduisant les risques de faillite et de spoliation.
Pour les citoyens, il garantit une expérience simple (identique au Web2), tout en redonnant la souveraineté sur l’identité et les données.
Pour les États, il propose une alternative à la fragmentation : une infrastructure distribuée, neutre, où ils peuvent être un acteur parmi d’autres, mais jamais un centre de contrôle exclusif.
Le Web3 : une décentralisation illusoire et contre-productive
Genèse et promesse du Web3
Le terme Web3 est apparu au milieu des années 2010, dans le sillage du succès des blockchains publiques comme Bitcoin et Ethereum. Il se présentait comme une révolution : un “nouveau web” dans lequel l’utilisateur retrouverait enfin la maîtrise de ses données et de ses interactions, grâce à des architectures distribuées.
La promesse était séduisante :
se libérer de l’emprise des plateformes centralisées du Web2,
remplacer les services classiques par des applications décentralisées (dApps),
redonner à chacun la capacité de posséder et de monétiser ses données,
créer un écosystème où la confiance n’émane plus d’un tiers mais du code.
Pour ses promoteurs, le Web3 représentait donc le chaînon manquant : un web qui ne serait plus capté par des géants privés, ni fragmenté par des États, mais auto-régulé par ses participants.
L’erreur de conception : vouloir tout décentraliser
Cette ambition reposait sur une hypothèse implicite : la décentralisation totale serait non seulement possible, mais désirable. Chaque processus, chaque donnée, chaque fonction du web devait être porté par une blockchain, validé par un consensus, et inscrit dans un registre immuable.
Or, cette hypothèse se révèle être une erreur de design.
Impossibilité technique : tout ne peut pas être inscrit dans une blockchain. Le stockage massif de données, la gestion d’applications complexes, ou même la simple indexation des contenus deviennent vite insoutenables en termes de performance et de coûts.
Non-sens fonctionnel : tout ne gagne pas à être décentralisé. Certaines tâches (ex. : calcul intensif, traitement local, routage de contenu) sont plus efficaces lorsqu’elles sont traitées de manière distribuée mais non “chaînée”.
Surcharge économique : chaque opération devenait une transaction soumise à des frais (“gas fees”). Au lieu de libérer les utilisateurs, le Web3 a créé une barrière financière imprévisible et parfois prohibitive.
Complexité d’usage : wallets, clés privées, tokens multiples. La promesse de simplicité du Web2 a été remplacée par une expérience réservée à une minorité d’initiés.
En voulant tout décentraliser, le Web3 a abouti à l’inverse de sa promesse : il a recentralisé autour de quelques blockchains dominantes (Ethereum, Binance Smart Chain), tout en créant une dépendance aux intermédiaires (exchanges, wallets custodians) chargés de gérer la complexité pour l’utilisateur.
La décentralisation : moyen ou finalité ?
L’erreur fondamentale du Web3 est d’avoir confondu moyen et finalité.
La finalité n’est pas la décentralisation pour elle-même. C’est la résilience : la capacité d’un service numérique à continuer de fonctionner malgré les pannes, les attaques ou les pressions politiques et économiques.
Le moyen, parfois, est la décentralisation. Distribuer les fonctions critiques sur plusieurs nœuds, réduire les points uniques de défaillance, éviter la dépendance à un seul acteur.
Mais vouloir “tout décentraliser” revient à créer une usine à gaz, qui perd son sens et son efficacité. Ce qui doit être décentralisé, ce sont les infrastructures critiques : celles qui assurent la sécurité, la souveraineté et la vérifiabilité des données. Le reste peut et doit conserver des logiques de simplicité et d’efficacité.
Une innovation détournée de son but
Cette confusion a entraîné le Web3 dans une dérive : la multiplication des tokens et des blockchains privées. Chaque projet prétendait incarner une nouvelle couche du web, mais finissait par créer son propre écosystème clos, déconnecté des autres, et centré sur la valorisation spéculative de son jeton.
Ainsi, au lieu de libérer les utilisateurs, le Web3 a créé de nouvelles dépendances :
dépendance aux plateformes d’échange pour convertir ou sécuriser les tokens,
dépendance à des protocoles énergivores et coûteux,
dépendance à des gouvernances opaques, souvent concentrées entre quelques investisseurs initiaux.
En d’autres termes, le Web3 a produit une illusion de décentralisation, tout en reproduisant, sous une autre forme, les asymétries de pouvoir qu’il prétendait combattre.
Leçons du Web3
De l’expérience du Web3, deux leçons majeures doivent être retenues :
La décentralisation est un outil, pas un horizon. Elle doit être appliquée là où elle augmente la résilience et la confiance, et non généralisée par dogme.
La simplicité d’usage est non négociable. Un modèle qui complexifie l’expérience utilisateur est condamné à rester marginal, quel que soit son intérêt théorique.
C’est sur ce constat que d’autres propositions ont émergé, dont le Web5, qui se présente comme une tentative de synthèse entre la simplicité du Web2 et la résilience du Web3.
Le Web5, une provocation assumée
En 2022, Jack Dorsey – fondateur de Twitter et PDG de Square (rebaptisé Block) – a surpris le monde numérique en annonçant le lancement du Web5. Le choix du nom était en lui-même une provocation. En sautant directement du Web3 au Web5, Dorsey envoyait un message : les labels “Web3” et “Web4” ne sont que des artifices marketing, déconnectés des véritables enjeux architecturaux du web.
En réalité, le terme “Web3” avait déjà été détourné de son usage historique. Dans la littérature académique, le Web3 désignait le “Web sémantique”, proposé par Tim Berners-Lee, et non pas une vague de blockchains et de tokens. Dorsey a donc volontairement ironisé sur cette dérive, en affirmant que son Web5 n’était pas une nouvelle génération mais “une somme : Web2 + Web3”.
Une synthèse : simplicité du Web2, résilience du Web3
Le Web5 se définit avant tout comme une synthèse :
le Web2, pour la simplicité et l’expérience utilisateur fluide. L’idée est de ne pas bouleverser l’usage quotidien : les interfaces, les parcours et la convivialité restent identiques.
le Web3, pour la résilience et la souveraineté, mais appliquées de manière ciblée : les données et processus deviennent vérifiables, ancrés dans des mécanismes cryptographiques, et distribués entre pairs.
La proposition est donc de combiner le meilleur des deux mondes : un web simple et familier, mais souverain et vérifiable par conception.
Une architecture en mesh : les relais neutres
Sur le plan technique, le Web5 repose sur une architecture en mesh, c’est-à-dire un réseau de relais interconnectés.
Ces relais servent de points de rencontre et de transmission.
Contrairement aux clouds, ils n’ont aucun pouvoir : ils ne contrôlent pas, ne stockent pas durablement et n’accèdent pas aux données.
Leur fonction est limitée à la synchronisation des utilisateurs et à la réplication des preuves cryptographiques.
Cette neutralité repose sur des standards émergents :
DID (Decentralized Identifiers), pour identifier de manière autonome chaque utilisateur, organisation ou service.
VC (Verifiable Credentials), pour attester et vérifier des attributs (identité, droits, certifications) sans dépendre d’un tiers central.
En combinant ces briques, le Web5 construit un modèle où l’utilisateur reste souverain de bout en bout : il détient ses identités, contrôle ses données et interagit via des relais neutres.
Le rôle de Square/Block : Bitcoin comme horizon
Le projet n’était pas seulement technologique. Il servait aussi une stratégie d’entreprise. Square, devenue Block, s’est développée sur la base des paiements numériques. L’ambition implicite du Web5 était de positionner Bitcoin comme le rail monétaire du nouvel internet.
Dans cette vision, l’identité (DID), les données (VC) et les transactions se rejoignaient dans une architecture où Bitcoin devenait l’infrastructure de règlement universelle. Cette orientation a donné au projet une puissance symbolique, mais aussi une limite : en étant trop frontalement associé à Bitcoin, il s’est coupé d’une adoption plus large, notamment en Europe, où la régulation (MiCA, AML5) impose des contraintes fortes aux crypto-actifs.
Forces et limites du Web5
Forces :
Une critique lucide des impasses du Web2 (captation des données) et du Web3 (illusion de décentralisation totale).
Une architecture pragmatique : relais en mesh, neutres par conception.
L’adoption de standards ouverts (DID, VC) en cohérence avec les travaux académiques sur l’identité décentralisée.
Une vision claire : combiner simplicité et souveraineté.
Limites :
Une dépendance stratégique à Bitcoin, qui restreint l’universalité de la proposition.
Une initiative trop liée à un acteur privé (Block), ce qui a suscité la méfiance de communautés plus ouvertes.
Une difficulté à dépasser le stade de l’expérimentation, faute d’un écosystème élargi.
Conclusion : un jalon plus qu’une fin
Le Web5 doit être compris non comme une “nouvelle génération” du web, mais comme un jalon.
Il a permis de redéfinir la décentralisation non comme une fin mais comme un moyen.
Il a rappelé que la simplicité d’usage reste essentielle.
Il a montré la viabilité d’architectures de relais neutres, où l’infrastructure n’a plus de pouvoir sur la donnée.
Cependant, son ancrage trop étroit à Bitcoin et à la stratégie de Square a limité son adoption. Le Web5 n’est donc pas l’aboutissement, mais une étape qui prépare le terrain à d’autres propositions, comme 4NK, qui reprennent ses intuitions tout en les émancipant de leurs contraintes.
Solid et Tim Berners-Lee : le rêve contrarié du W3C
L’origine : du Web sémantique au Web3 académique
Avant que le terme “Web3” ne soit accaparé par l’univers des blockchains et des tokens, il désignait dans les travaux académiques une évolution du web vers plus de sens et d’interopérabilité : le Web sémantique. Tim Berners-Lee, inventeur du web, défendait l’idée que les données publiées en ligne devaient être liées et interprétables par les machines, grâce à des standards universels. L’objectif n’était pas la décentralisation pour elle-même, mais la construction d’un web où les applications pouvaient collaborer, interagir et partager de l’information sans barrières.
Le projet Solid s’inscrit dans cette filiation. Il reprend l’idée que l’utilisateur doit redevenir le centre de gravité du web, mais en y ajoutant une dimension politique et éthique : la souveraineté des données personnelles.
L’ambition : pods personnels et souveraineté des données
Solid propose un modèle simple mais puissant :
chaque utilisateur possède un espace de données personnel appelé pod (personal online datastore),
il choisit qui peut lire, écrire ou utiliser ces données,
les applications ne “possèdent” plus les données, elles y accèdent temporairement avec le consentement de l’utilisateur.
Pour rendre ce modèle viable, Solid s’appuie sur des briques techniques issues de la recherche en identité numérique :
les DID (Decentralized Identifiers), permettant à chacun de posséder un identifiant numérique autonome, non dépendant d’un fournisseur central,
les VC (Verifiable Credentials), permettant de prouver une information (âge, diplôme, statut) sans révéler l’ensemble des données personnelles associées.
Ce cadre ouvrait la voie à un web radicalement différent : un écosystème où les données ne sont plus extraites par les plateformes, mais prêtées temporairement par l’utilisateur, qui en conserve le contrôle intégral.
Le rôle du W3C : vers un standard universel
Pour donner à Solid une légitimité mondiale, Berners-Lee a placé le projet sous l’égide du W3C (World Wide Web Consortium), organisme qu’il avait fondé et qui définit depuis trente ans les standards du web (HTML, CSS, HTTP).
L’idée était claire : faire de Solid et de ses protocoles (pods, DID, VC) de nouveaux standards universels, adoptés par les navigateurs, intégrés dans les applications, et capables de s’imposer face aux modèles propriétaires.
Si le pari avait réussi, le web aurait pu basculer vers une ère où chaque individu contrôlait réellement son identité numérique et ses données personnelles, dans un cadre ouvert, neutre et interopérable.
Les biais et les freins : GAFAM, États et neutralisation des protocoles
Mais l’ambition s’est heurtée à des forces politiques et économiques considérables.
Les GAFAM (Google, Apple, Facebook, Amazon, Microsoft) ont pesé de tout leur poids au sein du W3C. Leur modèle repose précisément sur la centralisation et l’exploitation des données. Adopter Solid et ses protocoles aurait fragilisé leur modèle économique.
Les États ont également exercé une influence. Un standard mondial d’identité décentralisée risquait de priver les gouvernements de leur capacité de contrôle sur les identités numériques et les infrastructures critiques.
Le W3C lui-même a montré ses limites : son processus de consensus, censé garantir l’ouverture, s’est révélé vulnérable aux intérêts économiques dominants.
Résultat : les protocoles DID et VC, pourtant conçus pour être des piliers d’un web souverain, ont été bridés dans leur adoption. Au lieu d’être pleinement intégrés comme socle du web, ils sont restés confinés à des projets expérimentaux ou à des consortiums restreints.
Héritage : un rêve affaibli mais fondateur
Solid n’a pas disparu, mais son impact est resté marginal. Les pods personnels n’ont pas trouvé de déploiement massif, et l’idée d’une identité universelle, neutre et décentralisée, n’a pas franchi le seuil critique.
Pourtant, son héritage est majeur. Solid a mis sur la table trois principes essentiels :
La donnée comme bien personnel, et non comme ressource exploitée.
L’identité comme infrastructure, fondée sur des standards ouverts.
Le web comme commun, où les standards doivent primer sur les plateformes.
Ces principes irriguent aujourd’hui les réflexions autour de l’identité décentralisée, des infrastructures souveraines et des alternatives aux clouds centralisés. Ils constituent un point d’ancrage pour les projets qui, comme 4NK, veulent conjuguer souveraineté, résilience et simplicité.
Archipel : l’illusion des blockchains étatiques
Contexte et ambitions
Au milieu des années 2010, la France a cherché à se positionner sur le terrain de la souveraineté numérique. Consciente des risques liés à la dépendance aux GAFAM et aux clouds étrangers, l’Agence nationale de la sécurité des systèmes d’information (ANSSI) et des acteurs publics comme Docapost (filiale du groupe La Poste) ont exploré la possibilité de créer une blockchain souveraine.
C’est ainsi qu’est née l’initiative Archipel. Présentée comme une infrastructure de confiance, Archipel devait fournir aux administrations, aux entreprises et aux collectivités un cadre sécurisé pour ancrer des documents, certifier des transactions et développer de nouveaux services numériques publics.
L’objectif affiché était double :
garantir que les données sensibles ne transitent pas par des blockchains étrangères (Ethereum, Bitcoin),
affirmer une autonomie française face aux géants technologiques.
Une blockchain étatique
Archipel se présentait comme une blockchain “publique et souveraine”. Elle devait être exploitée par des nœuds répartis entre acteurs publics et partenaires institutionnels, afin de fournir une décentralisation “de confiance”.
En pratique, il s’agissait d’un compromis : une infrastructure distribuée, mais sous contrôle étatique. Le modèle se voulait un mélange entre :
la transparence et la traçabilité des blockchains publiques,
la gouvernance centralisée d’une infrastructure publique nationale.
Le non-sens structurel
C’est précisément ce compromis qui a révélé un non-sens structurel. Une blockchain tire sa résilience et sa légitimité du fait qu’aucun acteur ne peut en contrôler le fonctionnement. C’est l’absence de centre qui crée la confiance.
Or, dans le cas d’Archipel :
l’État définissait les règles,
l’État contrôlait les opérateurs de nœuds,
l’État pouvait, en théorie, orienter ou censurer les usages.
Cette contradiction revenait à vider la blockchain de son essence. Archipel n’était pas une décentralisation, mais une recentralisation maquillée. L’État, par nature centralisateur, ne peut piloter une infrastructure réellement distribuée sans en détruire le principe même.
L’arrêt du projet
Après quelques années d’expérimentation, Archipel a été arrêté. Les raisons avancées étaient multiples :
coûts élevés de maintenance,
faible adoption par les entreprises et collectivités,
difficulté à rivaliser avec les blockchains publiques mondiales déjà massivement adoptées,
absence de modèle économique viable.
Mais la véritable cause tenait à son incohérence de conception : Archipel prétendait être décentralisé, tout en restant sous contrôle d’un centre. Cette contradiction a condamné le projet dès son origine.
Enseignements
L’échec d’Archipel illustre une leçon fondamentale :
La décentralisation ne peut pas être décrétée par un État.
Lorsqu’elle est pilotée par une autorité centrale, elle perd sa raison d’être et devient une infrastructure hybride, coûteuse, inefficace et non crédible.
Cet échec ne doit cependant pas masquer l’importance de la question de la souveraineté. Archipel a montré qu’il existe un besoin réel d’infrastructures de confiance, capables de garantir la sécurité et la résilience. Mais il a aussi montré que la souveraineté ne peut pas être confondue avec la centralisation nationale.
C’est précisément ce que des projets comme 4NK cherchent à résoudre : proposer une infrastructure réellement distribuée, où l’État, comme tout autre acteur, peut être un nœud parmi d’autres, mais jamais le centre unique de contrôle.
4NK : une infrastructure souveraine, simple et vérifiable
Philosophie générale
4NK naît d’un constat : l’internet actuel est prisonnier de deux modèles qui se révèlent insoutenables.
Le premier, celui du Web2, a démontré la puissance de l’expérience utilisateur fluide et universelle, mais il repose sur un vice de conception : il fuit les données par défaut et les livre à des plateformes privées qui en tirent une puissance économique et algorithmique colossale.
Le second, celui du Web3, a montré l’intérêt des mécanismes cryptographiques distribués, mais a échoué à les rendre pertinents, en voulant tout décentraliser. La décentralisation est devenue un but, alors qu’elle n’est qu’un moyen.
Le Web5, proposé par Jack Dorsey, a eu l’intuition juste d’une synthèse : simplicité d’usage et souveraineté par des relais en mesh. Mais ce projet est resté dépendant d’une stratégie d’entreprise (Square/Block), centrée sur Bitcoin comme rail de paiement mondial.
Les expériences institutionnelles, comme Solid (Tim Berners-Lee, W3C) ou Archipel (blockchain française), ont échoué : le premier, biaisé par le poids des GAFAM et des États dans la normalisation ; le second, pris dans le non-sens d’une “décentralisation” pilotée par un État centralisateur.
Dans ce contexte, 4NK se définit comme une troisième voie : une infrastructure conçue pour être neutre, distribuée, vérifiable et sobre, où l’utilisateur conserve la simplicité du Web2 tout en bénéficiant de la résilience et de la souveraineté promises – mais jamais réalisées – par le Web3 et ses dérivés.
Principes architecturaux
4NK repose sur une conception claire et minimaliste :
Relais neutres en mesh : l’infrastructure se compose de relais interconnectés qui ne contrôlent rien. Contrairement aux clouds, ils n’ont ni accès ni pouvoir sur les données. Leur fonction unique est la synchronisation et la réplication des preuves cryptographiques.
Utilisateurs souverains : les clés cryptographiques demeurent exclusivement sous le contrôle des utilisateurs. Les données, processus et identités ne peuvent être validés qu’à travers leur consentement.
Vérifiabilité universelle : chaque action, donnée ou transaction est ancrée et traçable de manière cryptographique. La confiance ne repose plus sur un opérateur tiers, mais sur une preuve vérifiable par tous.
Sobriété numérique : l’infrastructure ne nécessite aucun CAPEX supplémentaire, ne déploie pas de centres massifs et ne repose pas sur des clouds étrangers. La résilience est obtenue par la distribution, non par la duplication énergivore.
Expérience utilisateur : continuité du Web2
La conception de 4NK part d’un principe cardinal : l’utilisateur ne doit pas être confronté à une complexité nouvelle.
L’expérience reste identique au Web2 : les applications fonctionnent avec fluidité, ergonomie et simplicité.
La gestion des clés, des relais et des preuves cryptographiques est invisible.
L’utilisateur final ne “voit” pas l’infrastructure, il en bénéficie.
En ce sens, 4NK ne demande pas de rupture culturelle ou cognitive : il offre la même immédiateté que les services centralisés, mais sans leurs vulnérabilités.
Sécurité et vérifiabilité
La sécurité de 4NK ne repose pas sur la confiance déclarée mais sur des garanties cryptographiques :
Chiffrement intégral : aucune donnée ne transite en clair.
Ancrages distribués : les preuves sont inscrites dans un réseau distribué, et répliquées entre pairs pour empêcher toute falsification.
Absence de fuites par design : contrairement au Web2, où chaque action révèle des métadonnées, l’architecture 4NK est construite pour ne rien exposer qui puisse être exploité sans consentement.
Traçabilité universelle : la vérification est possible sans dépendre d’un serveur ou d’un opérateur spécifique.
Ce modèle brise le “plafond de verre” qui limite les architectures actuelles : malgré audits et certifications, un système centralisé finira toujours par fuir. Avec 4NK, la fuite est structurellement empêchée.
Une infrastructure de résilience
4NK applique la décentralisation là où elle est utile : dans l’infrastructure même.
Les relais en mesh remplacent les points uniques de défaillance.
Les services fonctionnent même si certains nœuds disparaissent.
La souveraineté ne dépend plus d’une plateforme ou d’un État, mais d’une architecture distribuée par conception.
Cette orientation redéfinit la finalité : non pas décentraliser pour décentraliser, mais construire des services numériques résilients.
La troisième voie
En somme, 4NK s’inscrit dans une filiation mais aussi dans une rupture :
avec le Web2, il conserve la simplicité d’usage mais élimine la fuite des données,
avec le Web3, il conserve la vérifiabilité cryptographique mais rejette la décentralisation totale comme horizon,
avec le Web5, il reprend l’architecture mesh mais sans dépendre d’un modèle économique particulier,
avec Solid, il reprend l’idée de souveraineté des données, mais sans laisser le W3C ou les GAFAM en brider l’ambition,
contre Archipel, il refuse l’illusion d’une décentralisation pilotée par un centre étatique.
4NK incarne ainsi une infrastructure de confiance réellement distribuée, où l’utilisateur est souverain, où l’infrastructure est neutre, et où la confiance se démontre cryptographiquement, sans dépendre d’aucune autorité centrale.
Le plafond de verre des infrastructures actuelles et comment 4NK le brise
Le “plafond de verre” de la cybersécurité
Depuis deux décennies, les organisations investissent massivement dans la cybersécurité : audits, certifications ISO, conformité RGPD, solutions de monitoring, pare-feu de nouvelle génération, segmentation des réseaux, cloud de confiance. Pourtant, les fuites de données et les compromissions continuent de se multiplier. Chaque nouvelle amélioration semble retarder l’échéance, sans jamais résoudre le problème.
Ce phénomène peut être décrit comme un plafond de verre : un seuil structurel au-delà duquel la sécurité ne progresse plus, même avec les meilleures pratiques.
Les limites des architectures centralisées
Ce plafond de verre n’est pas dû à la mauvaise volonté des acteurs ni au manque d’outils. Il provient directement de l’architecture même des infrastructures numériques actuelles.
Concentration des données : en centralisant les informations dans quelques silos (clouds, serveurs centraux, bases de données consolidées), on crée des cibles uniques, attractives et vulnérables.
Surface d’attaque élargie : plus une plateforme centralise d’usages, plus elle concentre de points d’entrée pour les attaquants.
Asymétrie de contrôle : l’utilisateur n’a pas la maîtrise effective de ce qui est collecté ou révélé. Même sans attaque, l’infrastructure fuit “par design”.
Complexité croissante : pour compenser, on multiplie couches de sécurité, authentifications fortes, audits, ce qui dégrade l’expérience utilisateur et augmente les coûts.
En d’autres termes, le Web2 est structurellement vulnérable, car il repose sur une logique de concentration.
Conséquences visibles et invisibles
Les conséquences de ce plafond de verre sont multiples :
Fuites massives : 9 Français sur 10 ont déjà vu leurs données personnelles apparaître sur le dark web.
Pertes économiques : fermetures d’entreprises, spoliation industrielle invisible, abandons de paiement en ligne liés à la complexité des procédures.
Perte de confiance : les utilisateurs multiplient les stratégies de contournement (adresses jetables, refus d’authentification, évitement des services numériques).
Poids financier croissant : les dépenses de cybersécurité explosent, mais sans amélioration proportionnelle du niveau de protection.
Ce constat alimente une forme de désillusion collective : la cybersécurité classique ne parvient plus à rassurer ni à protéger durablement.
Vers une identité vérifiable et confidentielle
Pour sortir de cette impasse, l’identité numérique doit répondre simultanément à trois exigences :
Vérifiabilité : tout acteur doit pouvoir vérifier l’authenticité d’une identité ou d’un attribut (âge, statut, diplôme) sans dépendre d’un tiers central.
Confidentialité : les données ne doivent pas être révélées au-delà de ce qui est strictement nécessaire.
Souveraineté : l’utilisateur doit rester le seul maître de son identité, sans dépendre ni d’une plateforme privée, ni d’un État, ni d’un registre centralisé.
Une inspiration cryptographique : les adresses silent payment de Bitcoin
L’innovation de Bitcoin ne réside pas seulement dans sa monnaie, mais dans sa cryptographie appliquée aux usages distribués. Parmi ces principes, les adresses dites silent payment offrent une piste précieuse : elles permettent de recevoir un paiement unique sans réutiliser une adresse publique visible.
En dérivant ce principe, il est possible de concevoir une identité confidentielle et vérifiable :
Chaque usage (connexion, signature, échange de document) génère une adresse dérivée unique, qui ne permet pas de relier directement les différentes actions d’un utilisateur.
L’identité maîtresse reste secrète et souveraine, détenue uniquement par l’utilisateur.
Les contreparties reçoivent des preuves ponctuelles (credentials vérifiables), limitées au contexte et non réutilisables ailleurs.
Ce mécanisme permet d’éviter le piège du Web3 (réutilisation d’une clé publique traçable) tout en garantissant l’interopérabilité et la vérifiabilité cryptographique.
L’identité comme socle souverain de 4NK
Dans l’architecture 4NK, l’identité numérique devient ainsi le point de départ de tous les usages :
Chaque utilisateur possède une identité cryptographique auto-souveraine.
Les relais du réseau ne voient jamais l’identité complète, seulement des preuves contextuelles.
Les processus métiers (contrats, documents, paiements, signatures) s’appuient sur ces identités souveraines, réduisant les fuites et supprimant la dépendance à des registres externes.
Ce modèle établit l’identité comme un bien commun : ni une ressource commerciale pour les plateformes, ni un outil de contrôle pour les États, mais un droit fondamental cryptographiquement garanti.
Comment 4NK brise ce plafond
La proposition de 4NK est de changer l’architecture pour dépasser ce seuil.
Pas de centre, pas de cible unique : l’infrastructure repose sur des relais en mesh qui ne stockent ni ne contrôlent les données. L’attaque systémique devient impossible.
Vérifiabilité par conception : chaque action est ancrée et prouvée cryptographiquement. La confiance n’est plus déclarative mais démontrable.
Aucune fuite structurelle : contrairement au Web2, aucune métadonnée n’est exposée par défaut. Les données circulent uniquement avec le consentement de l’utilisateur.
Simplicité maintenue : au lieu de complexifier l’expérience, l’infrastructure reste invisible. L’utilisateur bénéficie d’une sécurité maximale sans effort supplémentaire.
Sobriété : la résilience est obtenue par la distribution, non par la duplication énergivore ni par l’accumulation de couches défensives.
Ainsi, 4NK ne promet pas une sécurité “meilleure” que celle des clouds centralisés, mais une sécurité d’un autre ordre : structurelle, démontrable, non dépendante d’un tiers.
Conclusion
Le plafond de verre des infrastructures actuelles ne peut être franchi par des ajustements incrémentaux. Il ne s’agit pas d’améliorer les clouds ou de renforcer les audits, mais de changer de paradigme.
En concevant une infrastructure neutre, distribuée et vérifiable, 4NK propose une rupture : un internet où la sécurité n’est plus un service ajouté, mais une propriété intrinsèque de l’architecture.
Vers une économie de la confiance vérifiable : dépasser la capture financière et la centralisation
Le financement des infrastructures du Web2 : de la technique au produit financier
Le Web2 s’est construit sur un modèle d’infrastructures massives : datacenters, réseaux mondiaux, plateformes logicielles intégrées. Au départ, ces infrastructures avaient une logique essentiellement technique : offrir aux entreprises et aux particuliers des services accessibles, mutualiser les coûts et accélérer l’innovation.
Mais très rapidement, ce modèle s’est transformé en produit financier. Les clouds publics et les grandes plateformes numériques ne sont pas de simples opérateurs techniques : ce sont des instruments d’investissement.
Les CAPEX massifs nécessaires à la construction de datacenters sont financés par des fonds d’investissement et amortis par des abonnements récurrents.
Les OPEX récurrents (consommation électrique, maintenance, sécurité) sont répercutés aux clients sous la forme de frais opaques : stockage, egress, niveaux de service.
La souveraineté numérique devient un actif privatisé : les infrastructures appartiennent à des acteurs globaux dont les décisions sont guidées par la rentabilité actionnariale.
Ainsi, le modèle du Web2 repose sur une logique de rente permanente. Les utilisateurs et les entreprises ne cessent de payer pour accéder à leurs propres données. Les coûts ne reflètent plus seulement la technique, mais la stratégie financière des investisseurs. La souveraineté est donc captée, non par les États ni par les citoyens, mais par les marchés.
Le Web3 et la centralisation des blockchains de Venture Capital
Le Web3 a prétendu rompre avec cette logique en proposant la décentralisation des infrastructures par la blockchain. Mais en pratique, il a reproduit les mêmes asymétries de pouvoir, sous une nouvelle forme.
La quasi-totalité des blockchains dites “publiques” – Ethereum, Solana, Polygon, Avalanche – sont en réalité des blockchains de Venture Capital. Leur développement a été financé par des levées de fonds, et leur gouvernance repose sur la concentration des jetons entre quelques investisseurs institutionnels.
Contrôle de fait par les investisseurs : les fonds qui ont financé ces projets possèdent une part significative de la supply de tokens, et donc la majorité des droits de vote.
Infrastructure recentralisée : malgré le discours de décentralisation, une poignée de validateurs concentre la majorité des transactions, souvent opérés par des acteurs spécialisés liés aux mêmes fonds.
Illusion de l’indépendance : la gouvernance on-chain se veut collective, mais elle reflète les intérêts financiers des bailleurs plutôt que la souveraineté des utilisateurs.
En d’autres termes, le Web3 a remplacé la dépendance aux hyperscalers par une dépendance aux investisseurs privés. Seule une blockchain échappe à ce schéma : Bitcoin, née sans financement initial ni levée de fonds, qui reste la seule infrastructure numérique d’ampleur mondiale indépendante du capital-risque.
Les initiatives étatiques : la souveraineté décrétée
Face à ces dérives, plusieurs États ont tenté de créer leurs propres infrastructures dites “souveraines”, comme Archipel en France ou Alastria en Espagne. Mais ces projets se sont heurtés à un paradoxe :
des budgets publics massifs engagés en CAPEX pour construire des infrastructures nationales,
une centralisation étatique qui contredit la logique même de la décentralisation,
une faible adoption : les entreprises et collectivités restent méfiantes face à des systèmes imposés, coûteux et sous-utilisés.
Ces initiatives démontrent que la souveraineté ne peut pas être décrétée par le haut. Elle doit être inscrite dans l’architecture elle-même, sinon elle se réduit à une nouvelle forme de dépendance.
Le modèle 4NK : neutralité, sobriété et confiance vérifiable
4NK se distingue de ces modèles par une approche radicalement différente. Plutôt que de transformer l’infrastructure en produit financier (Web2), ou en actif spéculatif (Web3), ou en projet budgétaire (États), 4NK conçoit l’infrastructure comme un commun technique neutre :
Pas de CAPEX côté client : 4NK s’appuie sur les équipements existants, sans déploiement de datacenters supplémentaires.
Pas de rente spéculative : il ne crée pas de jeton gouverné par des investisseurs.
Pas de dépendance étatique : l’État peut être un nœud parmi d’autres, mais jamais le centre de contrôle.
Des relais neutres : ils ne voient ni ne contrôlent les données, leur seul rôle est la synchronisation cryptographique entre pairs.
Vérifiabilité par conception : la confiance ne dépend pas d’une promesse ni d’une réglementation, mais d’une preuve cryptographique accessible à tous.
En d’autres termes, 4NK transforme l’économie numérique : là où les modèles antérieurs reposent sur la dette (financière, énergétique, organisationnelle), 4NK fonde une économie de la preuve – sobre, distribuée et indépendante des investisseurs.
L’énergie : de l’inflation à la sobriété structurelle
L’économie des infrastructures numériques ne se mesure pas seulement en argent : elle se mesure aussi en énergie. Les modèles dominants ont montré leurs limites.
Web2 – Datacenters énergivores : les clouds et plateformes centralisées s’appuient sur d’immenses datacenters, nécessitant alimentation continue, refroidissement industriel et redondances massives. Chaque nouveau service se traduit par une croissance exponentielle de la consommation, même lorsque l’on tente de “verdir” artificiellement ces infrastructures par de la compensation.
Web3 – Inflation énergétique et duplication : les blockchains de preuve de travail comme Bitcoin, et plus encore les blockchains hybrides ou de preuve d’enjeu, reproduisent une logique de duplication coûteuse. Dans beaucoup de cas, chaque opération est traitée comme un événement à part entière, multipliant inutilement les écritures, donc la consommation. Même les blockchains dites “sobres” restent dépendantes d’une réplication intégrale de l’état, énergivore par construction.
Initiatives publiques – CAPEX lourds et inefficacité énergétique : les blockchains financées par des budgets publics (Archipel, Alastria) ont souvent consisté à recréer des serveurs dédiés, sans bénéfice de mutualisation ni de maillage mondial. Résultat : un coût énergétique non négligeable pour une résilience limitée.
4NK – Sobriété par conception : l’architecture de 4NK prend le contre-pied des modèles énergivores. Plutôt que de multiplier des centres de données massifs, elle s’appuie sur les équipements existants — postes utilisateurs et serveurs déjà déployés — pour distribuer la résilience. Pas de duplication industrielle inutile, pas de refroidissement mécanique permanent, pas de fermes de calcul. La consommation énergétique marginale est quasi nulle et la résilience découle du maillage naturel du réseau. Surtout, 4NK exploite Bitcoin non pas comme un système de paiement (même si cela reste possible), mais comme un socle d’ancrage de preuves. La sécurité de Bitcoin est mutualisée : une seule transaction peut servir de racine cryptographique pour certifier un arbre complet de données. Ainsi, des milliards d’ancrages — documents, identités, processus — peuvent être sécurisés par une unique inscription, bénéficiant de la puissance de calcul colossale du réseau. Le coût énergétique n’augmente pas avec le nombre d’ancrages : il reste constant et se répartit sur l’ensemble des usages, ce qui fait de cette approche une forme de sobriété structurelle, inscrite dans la conception même de 4NK.
Cette propriété fait de Bitcoin une assise unique : la dépense énergétique massive qu’il mobilise n’est pas dupliquée par chaque utilisateur, elle est partagée et amortie collectivement. En combinant ce socle avec une architecture distribuée sobre (relais en mesh, sans duplication inutile), 4NK parvient à garantir une sécurité maximale avec une empreinte minimale.
Conclusion : sortir de la capture financière et énergétique
L’histoire récente du numérique révèle une trajectoire claire :
Le Web2 a transformé l’infrastructure en produit financier, capté par les fonds d’investissement et les plateformes, au prix d’une dépendance économique et d’une consommation énergétique exponentielle.
Le Web3 a prétendu décentraliser, mais la plupart de ses blockchains se sont recentralisées entre les mains du capital-risque, reproduisant les mêmes asymétries de pouvoir, aggravées par une spéculation permanente.
Les initiatives publiques ont échoué à incarner la souveraineté, car une décentralisation décrétée par l’État se réduit à une centralisation coûteuse et inefficace.
Sur le plan énergétique, ces modèles entretiennent une inflation continue : datacenters toujours plus massifs, blockchains spéculatives, projets publics redondants.
Dans ce paysage, 4NK introduit une rupture. Son architecture distribue la résilience sur les équipements existants, sans créer de centres énergivores ni de CAPEX lourds. Sa sobriété est une propriété intrinsèque, et non un argument marketing. Surtout, en exploitant Bitcoin comme socle d’ancrage, 4NK bénéficie d’une sécurité mutualisée : une seule transaction peut certifier des milliards d’ancrages, sans coût énergétique supplémentaire, en héritant de la puissance de calcul colossale du réseau.
Ainsi, là où les infrastructures antérieures reposent sur la capture financière et énergétique, 4NK propose une économie de la preuve : neutre, distribuée, vérifiable, sobre. La souveraineté ne s’achète pas, ne se décrète pas, ne se spécule pas : elle se démontre cryptographiquement, et devient une propriété collective du réseau.
Mise en œuvre opérationnelle de 4NK
Principes d’architecture
L’architecture réseau de 4NK vise à garantir trois propriétés : isolation, résilience, vérifiabilité. Contrairement aux clouds centralisés, où toutes les données transitent par des serveurs propriétaires, 4NK distribue les composants critiques sur les équipements des utilisateurs et les connecte via des relais neutres.
Cette approche repose sur plusieurs zones logiques :
Zone utilisateur : accès par navigateur ou client, sans modification majeure de l’expérience (similaire au Web2) et il réplique la data entre strictement les partie prenantes de ces échanges en directe (pc, téléphones, serveurs strictement ciblés) chiffé par ses clés de ses identité qu'il a lui meme généré (transparent).
Zone relais (mesh) : points de passage cryptographiques qui assurent la transmission mais n’ont aucun accès aux données.
Zone applicative distribuée : services métiers (API, stockage chiffré, oracles) fonctionnant sur des conteneurs isolés.
Zone blockchain : interaction limitée à Bitcoin pour l’ancrage de preuves, via des nœuds dédiés qui ne sont pas exposés publiquement.
Les relais neutres : cœur de la résilience
Le relais est un composant central de 4NK. Il assure trois fonctions :
synchronisation entre pairs (partage des ancrages et preuves),
résilience par redondance naturelle (si un relais disparaît, un autre prend le relais),
neutralité : aucun relais ne peut lire ni modifier les données, car tout est chiffré bout en bout.
La neutralité est garantie par design : le relais transporte uniquement des flux chiffrés et des hachages cryptographiques, sans jamais accéder aux contenus.
Intégration des identités souveraines
Chaque utilisateur possède une identité cryptographique souveraine, dérivée d’un système proche des silent payments de Bitcoin :
chaque usage (connexion, signature, partage) génère une clé dérivée unique, impossible à relier à l’identité maîtresse,
les relais et services ne reçoivent que des preuves ponctuelles, limitées au contexte,
les identités sont vérifiables (via DID/VC) mais confidentielles, sans exposition massive ni base centralisée.
Ce mécanisme supprime la vulnérabilité des bases d’identités centralisées et réduit le risque systémique.
Ancrage sur Bitcoin
4NK s’appuie sur Bitcoin non pour gérer des paiements, mais pour ancrer des preuves cryptographiques.
Une seule transaction Bitcoin peut servir de racine cryptographique à un arbre entier de données.
Des milliards d’ancrages – documents, identités, processus – peuvent ainsi être certifiés par cette unique inscription.
Le coût énergétique reste constant, car il est mutualisé sur l’ensemble des usages, bénéficiant de la puissance de calcul colossale du réseau Bitcoin.
Cet ancrage confère à 4NK une sécurité de niveau mondial, indépendante de tout acteur privé ou étatique.
Sécurité et isolation des flux
Les spécifications réseau de 4NK renforcent cette logique :
seuls les ports nécessaires sont exposés publiquement (reverse proxy),
les services critiques (relay, oracle, nœud Bitcoin) sont isolés sur des réseaux dédiés, inaccessibles de l’extérieur,
le chiffrement systématique garantit qu’aucun flux n’est exploitable par un intermédiaire.
Ainsi, même si une partie du réseau est compromise, l’attaquant ne peut ni accéder aux données ni falsifier les ancrages.
Gouvernance distribuée
La gouvernance de 4NK n’est pas centralisée :
chaque organisation ou utilisateur est un nœud,
les relais sont interchangeables et peuvent être opérés par n’importe quel acteur,
aucun acteur unique (ni plateforme privée, ni État, ni consortium) ne peut imposer une décision ou contrôler l’infrastructure.
Cette gouvernance distribuée n’empêche pas la régulation : elle garantit simplement que la souveraineté de l’infrastructure est inscrite dans le design, et ne dépend pas d’une promesse politique ou contractuelle.
4NK n'a aucun serveur ni aucune partie prenante dans les infrastructures et services (sauf engagement contractuel explicite et spécifique pour les besoins d'un projet).
Stratégie de déploiement : une migration progressive vers le Web souverain
Un principe : migrer par les usages, non par la contrainte
Les révolutions techniques échouent lorsqu’elles demandent à tous les utilisateurs de changer brutalement leurs pratiques. La force de 4NK est d’offrir une migration indolore, en commençant par des services concrets, déjà familiers, mais portés par une infrastructure nouvelle. La stratégie repose sur un principe simple : apporter immédiatement de la valeur métier, tout en préparant une transformation structurelle.
Première étape : la gestion documentaire souveraine (Docv)
Le premier cas d’usage est la GED souveraine. Docv permet aux entreprises, professions réglementées et collectivités de gérer, archiver et certifier leurs documents sans dépendre de serveurs centralisés.
Valeur immédiate : conformité réglementaire (RGPD, NIS2, NF 461), archivage probatoire, confidentialité renforcée.
Différenciation : “infrastructure sans infrastructure” – Docv fonctionne sur les équipements existants, sans CAPEX supplémentaire.
Impact stratégique : démontrer que la migration peut se faire par services, sans rupture d’usage ni complexité pour l’utilisateur.
Docv constitue donc la porte d’entrée vers l’écosystème 4NK.
Deuxième étape : messageries chiffrées et communications souveraines
La communication constitue le deuxième pilier. Les messageries actuelles (WhatsApp, Gmail, Teams) reposent toutes sur des serveurs centraux. Même lorsqu’elles sont chiffrées de bout en bout, la métadonnée (qui parle à qui, quand, où) reste exploitée par les opérateurs.
L’approche 4NK consiste à déployer des messageries chiffrées souveraines, reposant sur les relais neutres du réseau :
aucun serveur central ne détient l’historique,
chaque utilisateur reste souverain de ses clés,
les messages sont synchronisés par le maillage 4NK, sans possibilité d’analyse de trafic par une plateforme.
Cette étape élargit l’usage de 4NK au-delà du document : elle installe la confiance dans la communication quotidienne.
Troisième étape : traçabilité distribuée et probatoire
Une fois les documents et les communications sécurisés, la stratégie s’étend aux chaînes de valeur : logistique, industrie, santé.
Chaque événement (facture, bon de livraison, mesure médicale, transaction administrative) est ancré dans le réseau.
La preuve est vérifiable par tout acteur, sans dépendance à une base centrale.
La traçabilité devient distribuée et probatoire, et non plus déclarative.
Ce déploiement répond à des besoins critiques, renforcés par les réglementations (facturation électronique 2026, traçabilité sanitaire, audits ISO).
Quatrième étape : moyens de connexion et d’identification innovants
Aujourd’hui, l’un des points de friction majeurs du Web est l’authentification : mots de passe multiples, bases de données compromises, complexité croissante.
L’architecture 4NK introduit des moyens de login souverains :
identités auto-souveraines (DID) vérifiables,
dérivées cryptographiques inspirées des silent payments de Bitcoin, qui génèrent une adresse unique par usage, impossible à relier à l’identité maîtresse,
authentification fluide, sans mot de passe, et sans collecte centralisée d’identifiants.
Ce modèle permet à la fois la simplicité du Web2 et la souveraineté cryptographique : chaque utilisateur contrôle son identité et choisit ce qu’il révèle.
Cinquième étape : paiements intégrés et décentralisés
Le dernier levier de migration est celui du paiement. Le Web actuel repose sur des systèmes centralisés (Visa, Mastercard, Stripe, PayPal), coûteux, opaques et soumis à des régulations hétérogènes.
4NK propose des paiements désintermédiés, intégrés dans son infrastructure :
micropaiements fluides pour accéder à des services numériques,
règlement pair à pair sans dépendance à un processeur central,
ancrage sur Bitcoin pour bénéficier de la sécurité mutualisée, sans imposer son usage direct à l’utilisateur.
L’objectif n’est pas d’imposer une monnaie, mais de rendre les paiements invisibles, sûrs et universellement vérifiables, comme le reste de l’infrastructure.
Une trajectoire de migration progressive
Cette stratégie suit un chemin clair :
Docv (GED) – sécuriser les documents.
Messageries chiffrées – sécuriser les communications.
Traçabilité distribuée – sécuriser les chaînes de valeur.
Identités souveraines – sécuriser la connexion et l’accès.
Paiements intégrés – sécuriser les transactions économiques.
Impacts macro-économiques et sociétaux d’une migration vers un web souverain
Un enjeu de compétitivité industrielle
Le numérique centralisé actuel fragilise directement la compétitivité des entreprises :
Pillage industriel invisible : les données circulant par les clouds étrangers alimentent des concurrents mondiaux, capables de copier innovations, stratégies et procédés.
Coût croissant de la conformité : audits, certifications et sécurisations ajoutées sur des infrastructures centralisées gonflent les coûts sans supprimer les vulnérabilités.
Dépendance technologique : les entreprises européennes bâtissent leurs services sur des plateformes américaines ou asiatiques, perdant ainsi leur autonomie stratégique.
Avec 4NK, la souveraineté structurelle des infrastructures supprime ces dépendances. Les données restent sous contrôle des utilisateurs, vérifiables mais inaccessibles à des tiers. Les coûts de sécurité deviennent prévisibles et soutenables. L’innovation ne fuit plus par défaut : elle peut être monétisée et valorisée localement.
Un levier pour l’emploi et l’écosystème numérique
Le modèle du cloud et des blockchains de VC concentre la valeur dans quelques hubs (Silicon Valley, Asie). Les entreprises utilisatrices deviennent captives, mais la richesse créée ne reste pas sur le territoire.
Un modèle distribué comme 4NK réinjecte la valeur dans les tissus locaux :
emplois de proximité : intégration, accompagnement, formation des entreprises et collectivités, plutôt que gestion de datacenters lointains ;
écosystème diversifié : chaque acteur (collectivité, PME, administration) peut devenir opérateur de relais, acteur de confiance, fournisseur de services complémentaires ;
soutien à la filière européenne : interopérabilité avec les standards ouverts et indépendance face aux fonds de capital-risque étrangers.
Ainsi, la migration vers 4NK crée un effet multiplicateur économique : moins de fuite de capitaux, plus de valeur retenue localement.
Une réponse aux crises de confiance sociétales
Aujourd’hui, la défiance vis-à-vis du numérique s’accroît :
9 Français sur 10 ont déjà vu leurs données circuler sur le dark web ;
les contrôles d’identité massifs exposent les citoyens à des risques physiques (fraudes, séquestrations, usurpations) ;
les dispositifs de lutte contre le blanchiment (AML), très intrusifs, n’ont d’impact que sur 0,02 % des flux illicites.
La conséquence est une perte de confiance généralisée : les citoyens hésitent à utiliser les services numériques, et les institutions peinent à légitimer leurs politiques.
Avec 4NK, la confiance est vérifiable :
l’identité devient auto-souveraine et confidentielle,
aucune base centralisée ne peut être massivement compromise,
chaque usage produit une preuve locale, réutilisable sans divulgation excessive.
Ce modèle restaure une confiance structurelle, non par des promesses ou par la coercition, mais par la cryptographie.
Sobriété et résilience collective
Le numérique actuel repose sur une dette énergétique croissante : datacenters massifs, duplication inutile des données, blockchains énergivores. Cette trajectoire est incompatible avec les objectifs de sobriété et de résilience écologique.
4NK, au contraire, introduit une sobriété par conception :
réutilisation des équipements existants,
absence de duplication industrielle,
sécurité mutualisée via Bitcoin (une transaction ancre des milliards d’usages).
Ainsi, la transition numérique peut enfin se concilier avec les impératifs écologiques.
Risques et limites de 4NK
Si l’architecture 4NK apporte une rupture en matière de sécurité, de souveraineté et de sobriété, elle n’est pas exempte de défis ni de limites :
Maturité et adoption : comme toute innovation structurelle, son efficacité dépend d’une masse critique d’utilisateurs et de relais. La période de transition peut générer une coexistence complexe avec les infrastructures traditionnelles.
Responsabilisation des utilisateurs : en redonnant aux individus et aux organisations la maîtrise de leurs clés et de leurs identités, 4NK supprime les points de défaillance centralisés mais introduit un besoin d’éducation et d’accompagnement. Sans bonnes pratiques, la souveraineté peut devenir vulnérabilité.
Interopérabilité réglementaire : la conformité avec certains cadres légaux (AML, KYC, eIDAS, etc.) suppose un dialogue constant avec les régulateurs, afin d’éviter que les institutions exigent des modèles centralisés incompatibles avec l’approche distribuée.
Dépendance partielle au socle Bitcoin : bien que l’ancrage soit mutualisé et énergétiquement stable, il existe une dépendance indirecte à la résilience du réseau Bitcoin lui-même.
Résistance des acteurs établis : les clouds, plateformes et blockchains de VC disposent de moyens financiers et politiques considérables pour freiner l’adoption d’un modèle qui réduit leur rente.
Ces limites ne remettent pas en cause la pertinence de 4NK, mais elles imposent une stratégie de déploiement réaliste, progressive et accompagnée, ainsi qu’un effort pédagogique majeur.
Conclusion : un choix de société et de raison
La migration progressive vers une infrastructure distribuée, neutre et vérifiable n’est pas une option technique secondaire : c’est un choix de société et de raison.
Rester prisonnier du modèle actuel – clouds centralisés, blockchains de Venture Capital, initiatives étatiques lourdes – signifie accepter un internet moins sûr (fuites structurelles), plus coûteux (rente financière et énergétique), plus complexe (multiplication des couches de sécurité, logins et conformités), et moins souverain (captation par des acteurs privés ou centralisation politique).
Adopter 4NK, au contraire, c’est choisir un modèle plus sécurisé (par design, sans bases centralisées à compromettre), moins cher (pas de CAPEX massifs, coûts d’exploitation stables, réduction du coût attendu des fuites), parfois plus simple (expérience identique au Web2, sans complexité de gestion pour l’utilisateur), et plus souverain (aucune capture par le capital-risque ou par un État centralisateur, une souveraineté garantie par la cryptographie).
En ce sens, 4NK n’est pas seulement une innovation technologique, mais une alternative rationnelle : une infrastructure qui répond simultanément aux exigences de sécurité, de coût, de simplicité et de souveraineté, et qui incarne une nouvelle économie politique du numérique – une économie de la preuve et de la confiance vérifiable.

165
docs/manifest_en.md Normal file
View File

@ -0,0 +1,165 @@
4NK: A third way for a sovereign, frugal, and verifiable web
4NK: a web that is simpler, cheaper, more reliable, and sovereign.
Summary
Today, the internet faces a structural crisis. On one side, Web2 brought ease of use but rests on a centralized architecture that leaks data by default. Every interaction generates metadata captured and exploited by private platforms. This has led to an exploited internet, where users have lost control of their information. On the other side, States tried to react with fragmentation: sovereign clouds, national rules, national public blockchains. But that produces a balkanized network: closed, monitored, incompatible internets that do not restore trust.
Web3, supposed to be the alternative, failed. It tried to decentralize everything, creating new complexities: wallets, tokens, transaction fees, dependence on a few dominant blockchains. Web5, initiated by Jack Dorsey, had the right intuition: combine the simplicity of Web2 and the cryptographic resilience of Web3. But it remained limited by its reliance on Bitcoin as a forced, single monetary rail.
This is the context in which 4NK appears. 4NK is not a marketing layer nor yet another blockchain. It is a distributed, frugal, and verifiable infrastructure: a third way.
Our principles are clear:
- Neutral mesh relays: they control nothing, store nothing, surveil nothing. They only synchronize and replicate cryptographic proofs.
- User sovereignty: keys, data, identities remain exclusively under users’ control.
- Universal verifiability: every action is anchored and cryptographically traceable, without relying on a third party.
- Digital frugality: no heavy infrastructure, no foreign cloud, no extra CAPEX. Resilience comes from distribution, not energy‑hungry duplication.
Concretely, the experience stays identical to Web2: same simplicity, same fluidity. Under the hood, no structural leaks, no dependence on platforms or States. 4NK enables:
- securing messaging, documents, and any digital flow,
- immutable anchoring and timestamping of proofs,
- sovereign and portable digital identity,
- simpler payments and interactions,
- regulatory compliance without massive data exposure.
In short, 4NK breaks the cybersecurity glass ceiling. Where centralized infrastructures inevitably leak despite audits and certifications, 4NK makes leakage impossible by design. It is an infrastructure of resilience, where the user is sovereign, where trust rests on proofs, and where the internet regains its universality without being exploited or fragmented.
4NK, the third way: a sovereign, simple, frugal, and verifiable web.
Rollout plan
4NK deploys its technology in stages: first to regulated professions and critical sectors (notaries, logistics, health), then through isolated modules distributed by integrators and operators to reach SMEs and municipalities. By 2027–2030, the ambition is a European expansion based on a “no‑infrastructure” distributed model, combining sovereignty, frugality, and accessible regulatory compliance for all digital services, everywhere, in open source.
An exploited and fragmented internet: between economic asymmetry and political partition
The original promise diverted
The internet was born from a clear ambition: connect heterogeneous networks to enable free and universal circulation of information. It was meant to be a neutral, inherently distributed space that encouraged scientific cooperation, communication between individuals, and ultimately social and economic innovation.
Thirty years on, that original project has been deeply altered. The global network is trapped in a double dead‑end: on one side, exploitation by private infrastructures that turn it into a tool for capture and surveillance; on the other, its progressive partition by States trying to fragment it to regain control. This dual movement has transformed the web into a structurally insecure space where the user has neither real control of their data nor any guarantee of neutrality.
Structural exploitation of Web2
Web2 relies on a client‑server architecture that places user data at the heart of centralized platforms. This brought unprecedented ease of use and accessibility. However, this convenience is inseparable from a design flaw: Web2 was made to leak data by default. Each interaction generates flows of information that produce a mass of invisible metadata. These traces reveal behaviors, profiles, and preferences and are exploited to fuel business models based on targeted advertising, algorithmic recommendation, and data resale.
Economic and societal consequences
- Company closures caused by massive leaks or cyberattacks
- Visible degradation of trust: daily lists of massive breaches
- Invisible industrial pillage of strategic data
- User experience complexity: multiple logins, passwords, heavy 2FA
- Revenue loss in payments: costly centralized rails
- Digital identity crisis
State fragmentation: the other dead‑end
Sovereign clouds, localization rules, “trusted” infrastructures produce a balkanized network: incompatible, closed, and surveilled internets that replace universality with archipelagos.
A structural double failure
- Web2 yields an exploited internet where value is captured by private infrastructures
- State attempts produce dystopian, fragmented internet
Identity as the keystone of sovereign uses
Identity has become the keystone of all uses: login, sign, pay, access services, exchange data. Without robust, user‑controlled identity, no digital sovereignty is possible.
Current limits and contradictions
- Centralized identity registries inevitably leak
- Surveillance mechanisms are invasive and inefficient
- Expanding age‑verification builds highly sensitive databases of children’s identities
A rising systemic cost: insecurity, dependence, fragile infrastructures
- Business bankruptcies caused by compromise
- Invisible pillage of intellectual property
- Compliance and security cost inflation without added value
- Citizens: distrust, cognitive overload, digital exclusion
- States: balkanization and illusory sovereignty
The vicious circle: more leaks → less trust → more defensive layers → more complexity and costs → leaks continue
4NK as a way out: change the infrastructure itself
- For businesses: make structural leakage impossible
- For citizens: Web2‑like simplicity with sovereign identity and data
- For States: an alternative to fragmentation with a neutral distributed infrastructure
Why Web3 failed (and what to keep)
- You cannot put everything on a blockchain; not everything benefits from decentralization
- Gas fees create economic friction; UX becomes complex
- Recentralization around a few dominant chains and custodial intermediaries
- Decentralization is a means, not an end. The end is resilience
Web5 and Solid taught valuable lessons but were constrained by governance, politics, or an overly narrow strategic alignment. 4NK learns from these paths while avoiding their limits.
4NK: sovereign, simple, verifiable infrastructure
Architectural principles:
- Neutral mesh relays that control nothing and only synchronize proofs
- Sovereign users: keys remain exclusively with users
- Universal verifiability: every action is anchored and traceable
- Frugal by design: no extra CAPEX, no foreign clouds
User experience: continuity of Web2
- Keep UX identical to Web2 while making the infrastructure invisible
Security and verifiability
- End‑to‑end encryption, distributed anchoring, no metadata leakage by design, universal traceability
A resilience infrastructure
- Remove single points of failure; services continue even as some nodes disappear
The “third way” in practice
- Keep Web2 simplicity, remove data leakage
- Keep Web3’s cryptographic verifiability, reject “decentralize everything”
- Mesh relay architecture without private capture or state control
Breaking the glass ceiling
Centralization concentrates data, expands attack surface, and forces endless defensive layers. 4NK replaces declared trust with provable trust and eliminates structural leakage by design while maintaining simplicity and frugality.
Economy of verifiable trust
- Web2: infrastructure turned into financial product (rents)
- Web3: token‑centric, VC‑dominated blockchains
- State projects: costly, controlled, weakly adopted
- 4NK: neutral common infrastructure, no CAPEX client‑side, no token rent, no state control, proofs by design
Energy sobriety
- Reuse existing equipment; no industrial duplication
- Use Bitcoin as a shared anchoring layer: one transaction can certify billions of anchors via Merkle aggregation; cost does not scale with usage
Operational implementation
Zones:
- User zone (browser/client)
- Relay zone (mesh)
- Distributed application zone
- Bitcoin anchoring zone
Relays: synchronize anchors, provide redundancy, remain blind by design
Sovereign identities
- Derivation per‑use (inspired by silent payments) → unlinkability
- Verifiable yet confidential credentials
Anchoring on Bitcoin
- One Bitcoin transaction as cryptographic root for entire data trees → global security without per‑use energy inflation
Security and isolation
- Minimal exposure (reverse proxy), isolated critical services, systematic encryption
Distributed governance
- Any organization/user can run nodes; no single actor can impose decisions
Deployment strategy (progressive migration)
1) Sovereign document management (Docv)
2) Encrypted messaging and sovereign communications
3) Distributed, probative traceability across value chains
4) Innovative identity and login methods (passwordless, derived addresses)
5) Integrated, decentralized payments (micropayments, P2P, Bitcoin‑anchored)
Macro‑economic and societal impacts
- Industrial competitiveness: end of data pillage, predictable security costs, local value capture
- Jobs and ecosystem: local integration and support, diversified operators, European independence
- Restoring trust: verifiable identity, no massive registries, proofs without overexposure
- Ecological sobriety: minimal marginal energy through distribution and shared Bitcoin anchoring
Risks and limits
- Maturity and adoption thresholds
- Responsibility shift to users for key management (needs education)
- Regulatory interoperability (dialogue to avoid forced centralization)
- Indirect dependence on Bitcoin’s resilience
- Resistance from entrenched actors
Conclusion
Migrating to a distributed, neutral, and verifiable infrastructure is not a secondary technical option: it is a rational societal choice. 4NK offers an infrastructure where security is a property of the architecture itself—provable, sovereign, frugal—making the internet simpler, cheaper, and more trustworthy.

85
docs/power_again.md Normal file
View File

@ -0,0 +1,85 @@
Tribune : la solution française pour reprendre le contrôle avec un numérique souverain et sobre
4NK : le web plus simple, moins cher, plus fiable et souverain.
Introduction
Les cyberattaques sont devenues l’une des premières causes d’arrêt d’activité pour les organisations européennes. Chaque semaine, des entreprises, des collectivités et des institutions de toutes tailles se retrouvent paralysées par des ransomwares. Pourtant, toutes avaient investi massivement dans des infrastructures réputées fiables : clouds publics internationaux, clouds souverains, API mutualisées, services managés.
Le constat est implacable : les architectures hypercentralisées ne garantissent plus ni sécurité, ni souveraineté, ni fiabilité.
Selon l’ENISA, plus de 60 % des incidents majeurs en Europe en 2022 concernaient des fournisseurs de services cloud ou API tiers, dont la compromission affectait en cascade des milliers de clients. Le site bonjourlafuite.eu.org, qui recense quotidiennement les fuites de données, illustre l’ampleur du phénomène : Microsoft 365, Google Workspace, OVH, mais aussi des clouds régionaux ou des API d’identité nationale ont été victimes d’exfiltrations massives.
Le problème n’est pas seulement américain. Il est structurel : tout cloud, toute API centralisée concentre les risques, attire les attaques et ouvre la voie à la surveillance. Les failles techniques se doublent d’ingérences politiques et commerciales. Ainsi, le Cloud Act américain (2018) oblige tout prestataire US à fournir les données qu’il héberge, y compris celles des Européens, tandis que l’arrêt Schrems II de la CJUE (2020) a confirmé l’incompatibilité de ces pratiques avec le RGPD. Mais en parallèle, des prestataires européens ont eux aussi été critiqués pour leurs failles, leur dépendance cachée à des technologies non-européennes, ou leur incapacité à garantir une traçabilité transparente.
Un numérique devenu invérifiable et manipulé
La crise est aussi épistémologique. Avec l’essor de l’IA générative, distinguer un vrai document d’un faux devient quasiment impossible. Contrats falsifiés, identités usurpées, deepfakes indétectables : chaque donnée peut être altérée en quelques secondes.
Parallèlement, le modèle économique dominant repose sur la captation et l’exploitation systématique des données. Les plateformes et certains États utilisent la surveillance de masse pour manipuler les comportements, orienter les décisions ou imposer des scores sociaux et économiques. La souveraineté numérique de l’Europe, et même la légitimité de ses institutions, se trouvent compromises.
La rupture apportée par 4NK : décentralisation et sobriété
La réponse ne réside pas dans « plus de cloud » ou « plus d’API », mais dans moins de dépendance, plus de contrôle, et davantage de sobriété.
C’est l’approche de 4NK, qui développe une infrastructure Web 5.0, conçue pour briser les verrous de la centralisation grâce à plusieurs innovations radicales :
Décentralisation des droits
Les accès et permissions ne sont plus gérés par un serveur maître mais répartis entre les appareils des utilisateurs. Les règles sont publiées, signées et vérifiées en pair-à-pair. Aucun administrateur central ne peut altérer ou détourner les droits.
Stockage sans cloud ni API centralisée
Les fichiers ne passent jamais par un point unique de contrôle. Ils sont chiffrés, stockés localement ou dans un réseau distribué temporaire, puis validés côté client. Aucun service externe, aucune API propriétaire, aucun SPOF (single point of failure).
Validation côté client
Chaque transaction, identité ou document est vérifié directement par l’appareil de l’utilisateur grâce à un SDK cryptographique. Ce n’est pas une « confiance en tiers » mais une preuve vérifiable en un clic. Contrairement au Web 3.0 dépendant de blockchains coûteuses, il s’agit ici d’une validation légère et universelle, intégrable partout.
Cartographie souveraine des données
Chaque utilisateur définit lui-même une carte de ses données :
quelles données existent,
qui peut y accéder,
selon quelles règles,
avec quelle durée de validité.
Ces règles sont inscrites cryptographiquement dans le protocole, et ne peuvent être ni modifiées ni contournées par les infrastructures. Les serveurs et réseaux ne voient ni le contenu, ni les métadonnées, ni même les relations entre utilisateurs : ils ne transportent que des flux chiffrés, validés côté client.
Dans ce modèle, les infrastructures n’ont aucun pouvoir : elles relaient et stockent temporairement, sans jamais accéder aux clés, aux règles, ni aux usages. L’intégralité du pouvoir normatif est déplacée vers les utilisateurs, qui deviennent les véritables régulateurs de leurs données.
Simplification radicale
Connexion sans mot de passe : appairage par clé cryptographique, sans gestion d’identifiants centralisés.
Paiement désintermédié : facturation en jetons probatoires, ancrés sur Bitcoin, sans intermédiaires bancaires lourds.
Vérification instantanée : document, signature, transaction – tout peut être prouvé par son hash, immédiatement vérifiable par n’importe qui.
Comparaison avec les clouds centralisés
Contenu de l’article
Vers une domination inévitable
Cette rupture crée un nouveau territoire numérique :
moins cher,
plus simple,
plus sûr,
juridiquement souverain,
écologiquement sobre.
À terme, les géants actuels, prisonniers de leur modèle centralisé, ne pourront rivaliser. Leur sécurité reste fragile, leur coût élevé, leur gouvernance opaque. L’histoire nous enseigne qu’aucun modèle centralisé ne résiste longtemps à l’arrivée d’une alternative distribuée : le Minitel a cédé face au Web, et demain, le cloud centralisé cédera face au Web 5.0 souverain et vérifiable.
Une alternative existe déjà
Face à ce constat, il serait facile de croire qu’un tel modèle n’est qu’une utopie théorique. Pourtant, la solution existe, elle est française, et elle sera ouverte en open source dès la fin de l’année : il s’agit de 4NK.
Construit depuis plusieurs années sur une base technologique radicalement différente des clouds et API centralisées, 4NK propose dès aujourd’hui un premier produit opérationnel : Docv, une GED souveraine et sobre déjà adoptée par les notaires et des PME de la logistique. Ces premières intégrations métiers prouvent que le modèle fonctionne, qu’il répond à des besoins critiques, et qu’il peut être déployé sans complexité, sur les équipements existants.
Une stratégie de déploiement massif
Une technologie, aussi radicale soit-elle, ne transforme le monde que lorsqu’elle se déploie largement. La vision de 4NK repose sur une stratégie progressive mais massive : commencer par des cas d’usage probants, démontrer leur robustesse, puis généraliser l’approche.
Via l'intégration chez les éditeurs phares, les syndicats et les groupements de professionnels, les TPE, PME et collectivités locales accèdent à cette souveraineté numérique par la voie la plus immédiate : la gestion électronique de documents (GED) pour sécuriser l'ensemble des flux métier. Dans ce cadre, la technologie 4NK assure à moindre coût la confidentialité, l’intégrité et la traçabilité des dossiers sensibles : marchés publics, factures, contrats, délibérations ou archives. Là où les solutions cloud classiques exposent les données à des failles, des dépendances tarifaires ou des ingérences, la GED souveraine fondée sur 4NK permet à chaque organisation, même modeste, de retrouver la maîtrise totale de ses flux.
Les grands comptes bénéficient, eux, d’une suite plus large d’outils et de services développés par des intégrateurs et éditeurs partenaires s’appuyant sur 4NK comme socle. Ces solutions couvrent un spectre complet : messageries chiffrées en mesh, stockage distribué, gestion décentralisée des identités et des droits, intégration d’oracles d’ancrage probatoires, et bientôt intelligence artificielle locale, exécutée sans exposition des données à des clouds externes. Autrement dit, la sécurité, la confidentialité et la souveraineté ne sont pas des options mais des caractéristiques natives de ces environnements.
Et fin septembre un SaaS grand public et professionnel, ouvrant un accès simplifié à cet espace numérique souverain, sobre et interopérable, sans CAPEX ni complexité d’intégration.
Ainsi, la stratégie n’est pas de répliquer le modèle des clouds dominants en créant une infrastructure centralisée de plus, mais au contraire de tisser un réseau distribué d’usages concrets, où chaque acteur – qu’il soit une petite entreprise, une collectivité ou un grand groupe – devient un nœud souverain du Web 5.0. Les messageries chiffrées, les espaces documentaires probatoires et les IA locales ne sont pas des add-ons, mais des composantes natives, garanties par la cryptographie et vérifiables en un clic.
Ce maillage progressif crée un écosystème où la confiance ne dépend plus d’un prestataire mais d’une preuve distribuée. Une fois établi, il ouvre un territoire numérique où l’Europe peut enfin conjuguer sécurité, indépendance et sobriété.
Conclusion
Il est temps pour l’Europe de reprendre le contrôle. Les dérives documentées – espionnage, fuites massives, dépendance aux clouds et API centralisées – montrent que notre modèle actuel est insoutenable.
Les solutions distribuées existent. Elles sont plus sûres, plus sobres, plus simples. Elles offrent une cartographie des données où seul l’utilisateur définit les règles, et où les infrastructures n’ont aucun pouvoir.
Le choix est clair : continuer à subir un numérique invérifiable, énergivore et sous tutelle, ou construire un numérique souverain et sobre, fondé sur la cryptographie distribuée, la vérifiabilité universelle et la souveraineté individuelle des données.

144
docs/storage_story.md Normal file
View File

@ -0,0 +1,144 @@
Comment 4NK s'incrit dans l’histoire et l’avenir du stockage des données : vers une distribution et une ouverture sans captation
4NK : le web plus simple, moins cher, plus fiable et souverain.
Introduction
L’histoire du stockage des données est celle d’un long mouvement d’abstraction : à chaque rupture technique, la complexité s’efface derrière une expérience plus simple et plus fluide. Les systèmes de fichiers ont rendu les données manipulables, les formats universels les ont rendues partageables, les bases relationnelles les ont rendues interrogeables, et le big data les a rendues exploitables à l’échelle planétaire. Chaque étape a donc été à la fois invisible dans son infrastructure et révolutionnaire dans ses usages, consacrant de nouveaux géants capables d’exploiter cette asymétrie.
Ainsi, si l’on observe bien une tendance générale vers plus de distribution et plus d’ouverture, elle est demeurée incomplète : l’ouverture concernait surtout les formats et l’interopérabilité, la distribution servait principalement à la scalabilité. Ni la sécurité intrinsèque des données, ni la souveraineté sur les métadonnées n’ont réellement accompagné cette progression.
Pourtant, cette histoire linéaire et triomphante dissimule aussi des zones d’ombre. Deux dimensions majeures sont longtemps restées les parents pauvres de l’évolution du stockage :
La sécurité : si les données ont gagné en accessibilité et en rapidité, leur intégrité et leur protection n’ont pas suivi le même rythme. Les premiers systèmes de fichiers offraient des mécanismes rudimentaires de permissions, les bases relationnelles introduisaient le contrôle d’accès, mais la sécurisation systématique — cryptographie native, auditabilité, résilience face aux attaques — est restée secondaire face à la priorité donnée à la performance et à la commodité.
La protection contre la captation des métadonnées : plus encore que les données elles-mêmes, ce sont leurs traces — qui a accédé, quand, depuis où, dans quel contexte — qui ont été exploitées massivement par les plateformes. Or, ces métadonnées n’ont jamais bénéficié du même soin : invisibles pour l’utilisateur, elles sont devenues une ressource stratégique pour la publicité, la surveillance et la concentration de pouvoir.
Cela s'explique par plusieurs raison :
Techniquement, les priorités étaient ailleurs (performance, scalabilité, simplicité d’usage) ; et le chiffrement de la donnée stockée, vue comme une fin en soi ;
Economiquement, les modèles d’affaires des acteurs dominants reposaient justement sur la collecte et l’exploitation des métadonnées ;
Politiquement et sociétalement, ni les usagers ni les régulateurs n’ont exigé tôt une protection structurelle, laissant la captation devenir la norme; la militariation, l'espionnage et le contrôle aussi, par ce biais.
Mais les limites de ces manquements sont réelles et plus criantes encore aujourd'hui :
Limites techniques Sur le plan technique, la nécessité croissante de sécurisation devient paradoxalement un frein à l’efficacité et à la concentration. La multiplication des protocoles de protection et des vérifications détourne une part importante des ressources humaines et computationnelles. Les attaques ciblant la supply chain démontrent que les vulnérabilités ne résident plus seulement dans les systèmes centraux mais dans l’ensemble de l’écosystème interconnecté, rendant la protection exhaustive quasiment impossible. Les fuites répétées de données, qu’elles proviennent de négligences internes ou d’exfiltrations organisées, accentuent la perte de confiance. À cela s’ajoute un phénomène récent d’effacement ou d’indisponibilité croissante des données sur le web, réduisant la capacité de vérification et d’accumulation de connaissances.
Limites économiques Sur le plan économique, l’évolution actuelle se heurte à l’explosion des coûts énergétiques nécessaires au fonctionnement des infrastructures numériques à grande échelle. Le déploiement massif de centres de données, d’IA et de réseaux engendre une consommation d’électricité difficilement soutenable. Les coûts matériels suivent la même dynamique, avec une dépendance accrue à des composants critiques (semi-conducteurs, terres rares) dont l’approvisionnement reste limité et vulnérable. Enfin, les failles de sécurité ont un impact budgétaire considérable : vols, interruptions de service, rançongiciels et réparations se traduisent en pertes directes mais aussi en investissements croissants dans une sécurité toujours imparfaite.
Limites politiques Sur le plan politique, la souveraineté numérique devient un enjeu central, mais la fragmentation mondiale complique l’émergence de normes stables et partagées. Les infrastructures critiques et les données se trouvent ainsi soumises à des législations contradictoires et à des rivalités de puissance. Ce contexte nourrit des dérives dystopiques, allant de la surveillance de masse aux manipulations informationnelles, fragilisant la liberté et la confiance publiques. Parallèlement, l’absence de mécanismes fiables de certification des preuves numériques rend incertain le fonctionnement des institutions, qu’il s’agisse de justice, de régulation ou de gouvernance internationale. L’articulation entre innovation, protection des libertés et stabilité institutionnelle demeure ainsi profondément précaire.Le "Cloud" est une expression tout à fait manifeste de dépocession des supports physiques vers non pas des nuages mais des géant de l'industie numérique.
C’est ce déficit historique sur la sécurité et la protection de la captation des métadonnées qui rend aujourd’hui nécessaire une approche nouvelle : replacer l’identité et la validation côté client au cœur du cycle de vie de la donnée, pour intégrer la sécurité et la souveraineté dès l’architecture et physiquement opérée hors cloud, hors éditeurs, pour par les utilisateurs, souverains entre eux, depuis leurs ressources inutilisées.
Voici donc une petite retrospective
1960-1980 – Les systèmes de fichiers hiérarchiques qui ont permis à IBM, Microsoft et Apple de démocratiser l’informatique
Technique : introduction des systèmes FAT (1977), HFS (1985) et ext (1992). Organisation hiérarchique des fichiers et masquage de la gestion bas niveau.
Usage : les utilisateurs manipulent pour la première fois directement leurs fichiers et dossiers, avec une interface accessible.
Business : IBM reste dominant sur le mainframe, Microsoft étend son pouvoir via MS-DOS, Apple innove avec une ergonomie graphique.
Ouverture / distribution : cette étape reste très centralisée (chaque machine isole son système de fichiers), mais elle ouvre la voie à une standardisation minimale et à l’idée que la donnée est manipulable par tous.
Sécurité : permissions rudimentaires par utilisateur, mais absence de chiffrement systématique ; les données restent exposées aux accès locaux non autorisés.
Captation des métadonnées : pratiquement inexistante, car les journaux d’activité sont limités et peu exploités ; l’usage reste local.
Captation des supports physiques : forte dépendance aux disques et bandes magnétiques propriétaires, qui enferment l’utilisateur dans un écosystème matériel.
1980-1995 – Les formats propriétaires intégrés aux logiciels qui ont consolidé la domination de Microsoft avec Office
Technique : formats binaires fermés, spécifiques à chaque logiciel.
Usage : expérience fluide pour l’utilisateur mais enfermement dans des silos non interopérables.
Business : Microsoft triomphe avec Office, en s’appuyant sur Windows comme environnement dominant.
Ouverture / distribution : régression forte. L’ouverture disparaît, la donnée est captive, et la distribution reste inexistante.
Sécurité : aucune garantie d’intégrité ou de confidentialité ; les fichiers peuvent être copiés ou modifiés sans vérification.
Captation des métadonnées : invisibles pour l’utilisateur, mais déjà exploitées par les logiciels via les en-têtes ou informations cachées (auteur, historique d’édition).
Captation des supports physiques : standardisation autour du PC IBM et de Windows, qui enferme la donnée dans un couple matériel/logiciel dominant.
1990-2000 – Les formats portables et universels qui ont rendu Adobe incontournable avec le PDF
Technique : apparition de formats lisibles partout (JPEG, PDF, XML). Spécifications publiques et interopérabilité.
Usage : documents facilement partageables entre machines, indépendamment du logiciel d’origine.
Business : Adobe devient incontournable, Microsoft profite de l’ouverture partielle de sa suite, et le Web s’appuie sur ces formats pour croître.
Ouverture / distribution : progression majeure. Les formats universels permettent pour la première fois une circulation large des données entre systèmes hétérogènes.
Sécurité : premiers mécanismes de chiffrement intégrés (mot de passe dans PDF), mais contournables et rarement utilisés.
Captation des métadonnées : les fichiers embarquent des métadonnées invisibles (auteur, date, géolocalisation parfois), que les utilisateurs ignorent et que certains acteurs exploitent.
Captation des supports physiques : toujours concentrée sur les disques locaux et serveurs centralisés ; l’échange reste dépendant du support (CD-ROM, disquette, réseau limité).
1970-2000 – Les bases relationnelles qui ont fait émerger Oracle comme référence de la gestion de données
Technique : invention du modèle relationnel (1970), naissance des SGBDR commerciaux (Oracle 1979, IBM DB2 1983, SQL Server 1989). Standardisation du langage SQL.
Usage : applications métiers fiables, requêtes rapides et cohérentes pour des millions d’enregistrements.
Business : Oracle, IBM et Microsoft bâtissent leur domination sur l’économie de l’information.
Ouverture / distribution : l’ouverture progresse par la standardisation (SQL), mais la distribution reste limitée : les bases relationnelles sont centralisées dans des serveurs uniques.
Sécurité : contrôle d’accès granulaire par utilisateur, mais peu de chiffrement natif des données stockées.
Captation des métadonnées : journaux de transactions et traces d’accès détaillées, nécessaires pour l’audit, mais susceptibles d’être exploitées par les administrateurs.
Captation des supports physiques : dépendance forte aux infrastructures propriétaires (serveurs Unix, bases propriétaires), qui conditionnent l’évolutivité.
2000-2010 – HDFS et le traitement big data qui ont fait émerger Google avec une nouvelle recherche planétaire
Technique : Google conçoit GFS (2003), MapReduce (2004), Bigtable (2006) ; Hadoop (2006) popularise le modèle. Les données sont découpées, répliquées et traitées en parallèle.
Usage : recherche instantanée, flux en temps réel, personnalisation de masse.
Business : Google prend une avance décisive ; Amazon et Facebook s’imposent aussi en exploitant le big data.
Ouverture / distribution : forte progression. Les données sont massivement distribuées entre serveurs, mais la gouvernance reste fermée et centralisée par quelques acteurs.
Sécurité : chiffrement partiel, souvent absent des premiers clusters ; priorité donnée à la vitesse plutôt qu’à la confidentialité.
Captation des métadonnées : cœur du modèle : logs, clics, temps de lecture, localisation et connexions deviennent une ressource stratégique.
Captation des supports physiques : les infrastructures reposent sur des data centers centralisés gigantesques, verrouillés par les géants du Web.
2010-2020 – Les bases en graphe qui ont permis à Facebook et LinkedIn de dominer la mise en relation
Technique : graphes orientés nœuds/arêtes, capables de représenter des milliards de relations.
Usage : suggestions d’amis, recommandations de produits, graphes de connaissances.
Business : Facebook, LinkedIn et Google consolident leur domination.
Ouverture / distribution : ouverture fonctionnelle (les relations sont mieux exposées et exploitables), mais centralisation accrue : les graphes appartiennent à des plateformes fermées.
Sécurité : centralisation des droits d’accès et protection interne, mais pas de chiffrement natif des graphes.
Captation des métadonnées : poussée à l’extrême : chaque interaction, relation ou clic devient une ressource pour les algorithmes de recommandation.
Captation des supports physiques : dépendance accrue aux fermes de serveurs dédiées aux graphes massifs, concentrées dans les data centers des plateformes.
2025-2040 – Les formats sémantiques distribués de 4NK qui inaugurent une nouvelle souveraineté des données
Technique : l’architecture de 4NK repose sur l'identité propre et portable de chacun et de ses droits, un stockage distribué, une messageries associées aux données, des contrats associés aux données vérifié par tous par cryptographie, fondé sur les ressources inutilisées des utilisateurs. Chaque nœud authentifie, vérifie, chiffre, ancre, relaie, et stocke la donnée. Les échanges se font par adressage cryptographique, garantissant l’authenticité sans dépendance à un serveur central, sans cloud, sans dépendance éditeur.
Usage : login en 1 scan , paiement en 1 scan, data off line, "tout véfifiable" l’utilisateur dispose d’un accès fluide et universel à ses données, vérifiées et protégées, tout en gardant le contrôle exclusif sur leur circulation. L’optimisation locale permet d’exploiter l’IA directement sur des données fiables, sans exposition ni fuite vers des clouds externes.
Business : ce modèle dépasse les limites actuelles des clouds centralisés, dont la valeur repose sur la captation des données et des métadonnées. 4NK ouvre la voie à une économie distribuée et souveraine : l’infrastructure est partagée et auto-scalable 0 CAPEX, les coûts sont réduits par la mutualisation, et les utilisateurs deviennent co-acteurs de l’écosystème pour démultiplier les coopérations à travers le monde, et Bitcoin est à la fois le réseau de preuves finales et de paiement.
Ouverture / distribution : progression décisive. Les formats sémantiques universels assurent compatibilité avec les standards présents et futurs ; la distribution se fait nativement entre pairs, sans concentration dans des data centers, ni la dépendance à leurs régulations.
Sécurité : chaque fragment est chiffré, signé et vérifiable par validation côté client. L’intégrité, la confidentialité et la provenance sont garanties dès la conception, sans dépendre d’un tiers de confiance.
Captation des métadonnées : éliminée par conception. Les traces d’usage ne sont pas centralisées ni monétisées, les relais sont anonymes et fongibles, depuis des adresses "masquées" échangeant sans interraction des secrets, et les usages restent sous le contrôle exclusif de l’utilisateur, qui décide de leur partage.
Captation des supports physiques : neutralisée par la mutualisation. L’infrastructure ne repose pas sur quelques data centers vulnérables mais sur une multitude de terminaux distribués, résilients et diversifiés.
Conclusion
L’histoire du stockage met en lumière une constante : à chaque cycle, la complexité technique s’efface derrière une promesse de simplicité, tandis que la gouvernance reste concentrée entre les mains de quelques acteurs dominants.
Si l’ouverture des formats et la distribution des architectures ont élargi les usages, elles n’ont jamais résolu les angles morts fondamentaux que sont la sécurité intrinsèque et la protection des métadonnées.
Ces limites apparaissent désormais comme des verrous majeurs, tant sur le plan technique que sur les plans économique et politique.
La véritable rupture ne peut donc venir uniquement d’un nouveau palier de performance, mais d’une transformation organisationnelle et architecturale : replacer l’identité et la validation du côté des utilisateurs, intégrer la souveraineté et la sécurité au cœur des infrastructures, et mutualiser les ressources disponibles hors des logiques centralisées.
Ce n’est qu’à cette condition qu’il sera possible de dépasser le cycle historique de concentration et de dépendance, pour ouvrir la voie à un stockage réellement distribué, fiable et souverain. C'est pour cela que 4NK existe.

65
docs/talk.md Normal file
View File

@ -0,0 +1,65 @@
Avec l’essor des outils en ligne, nous avons tous, en entreprise et chez soi, des ressources sous-exploitées.
💻 Pensez un instant à votre ordinateur, à votre smartphone.
Chaque jour, ces machines passent la majeure partie de leur temps en veille, attendant votre prochaine action. Pourtant, elles contiennent une puissance de calcul, de stockage et de sécurité immense.
➡️ C’est comme si nous laissions nos voitures tourner au ralenti dans le garage, sans jamais vraiment utiliser leur moteur.
📡 En parallèle, que faisons-nous ?
* Nous louons, à prix fort, la puissance de serveurs, détenus par quelques acteurs américains.
* Nous leur confions nos documents, nos conversations, nos identités numériques, nos paiements.
Et chaque fois que nous nous connectons, chaque fois que nous cliquons sur « accepter », nous renforçons cette dépendance :
* Dépendance économique
* Dépendance sécuritaire
* Dépendance politique
⚠️ Mais ces infrastructures centralisées montrent leurs limites :
* Multiplication des fuites de données
* Explosion des cyberattaques
* Coûts croissants
* Règles imposées de l’extérieur, parfois extraterritoriales
Risque de balkanisation d’Internet
* Pertes liées à la complexité du login et du paiement
➡️ Les dystopies ne sont plus des fictions : elles se dessinent dans nos usages quotidiens.
❓ Alors posons une question simple : et si la solution n’était pas “ailleurs”, mais déjà entre nos mains ?
Et si la souveraineté numérique, la sécurité et la simplicité venaient non pas de toujours plus de datacenters, mais de ce que nous avons déjà, sous-exploité, sur nos propres terminaux ?
☁️✨ C’est ce que nous appelons le cloud serverless client side.
Un modèle où :
* Le login, le partage, le paiement, la messagerie et l’identité ne passent plus par des serveurs centraux,
* Mais sont opérés directement sur vos appareils.
👉 Pas de CAPEX, pas de datacenters.
👉 Chaque utilisateur devient une brique de l’infrastructure.
👉 Chaque flux est une preuve cryptographique, chaque action une validation vérifiable.
🚀 Ce n’est pas une utopie lointaine.
Avec 4NK, cette vision se matérialise déjà par :
* Une GED probatoire pour les professions réglementées,
* Une messagerie souveraine et chiffrée,
* Une identité numérique portable.
Dans 2-3 ans, 4NK ce sera l'implémentation "bas niveau" virtualisée, une révolution des OS en noeuds actifs et souverain d'Internet.
➡️ Les premières pierres d’un Internet où la souveraineté est une propriété technique, et non une promesse politique.
🎯 Le véritable enjeu est simple :
👉 Voulons-nous continuer à dépendre d’infrastructures fragiles, coûteuses et centralisées ?
👉 Ou voulons-nous bâtir un numérique européen où la liberté, la confiance et la simplicité ne sont plus négociables ?
💡 Je crois que la réponse est déjà en nous, dans les ressources que nous possédons et que nous n’exploitons pas encore.
Le choix, est clair :
* Subir le numérique qui vient, ou
* Inventer celui que nous voulons.

BIN
favicon.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.2 MiB

BIN
img/ChatGPT Image 25 sept. 2025, 22_03_26.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.2 MiB

BIN
img/ChatGPT Image 25 sept. 2025, 22_07_33.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.9 MiB

BIN
img/Clipboard - 26 septembre 2025 13_46.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 3.2 KiB

BIN
img/infra.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.3 MiB

BIN
img/logo.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.2 MiB

182
index.html Normal file
View File

@ -0,0 +1,182 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>4NK - The self-custodial cloud infrastructure</title>
<link rel="icon" type="image/png" href="favicon.png">
<link rel="stylesheet" href="styles.css">
<link rel="canonical" href="https://4nk.network/">
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Inter:wght@300;400;500;600;700&display=swap" rel="stylesheet">
</head>
<body>
<div class="background-pattern"></div>
<header class="header">
<nav class="nav">
<div class="nav-logo">
<div class="logo-container">
<img src="img/logo.png" alt="4NK Logo" class="logo-img">
</div>
</div>
<div class="nav-menu">
<a href="#home" class="nav-link">Home</a>
<a href="#services" class="nav-link">Services</a>
<a href="#about" class="nav-link">About</a>
<a href="#contact" class="nav-link">Contact</a>
</div>
</nav>
</header>
<main>
<section id="home" class="hero">
<div class="hero-content">
<div class="hero-logo">
<img src="/img/infra.png" alt="4NK Hero Logo" class="hero-logo-img">
</div>
<div class="hero-text">
<h1 class="hero-title">
<span class="brand-name">4NK</span>
<span class="brand-subtitle">Infrastructure</span>
<span class="brand-tagline">custodian-killer</span>
</h1>
<p class="hero-description">
A revolutionary infrastructure redefining security and decentralization.
Our cutting-edge technology removes intermediaries and puts control in your hands.
</p>
<div class="hero-buttons">
<button class="btn btn-primary">Discover</button>
<a class="btn btn-secondary" href="/about_more.html">Learn more</a>
</div>
</div>
</div>
</section>
<section id="services" class="services">
<div class="container">
<h2 class="section-title">Our Services</h2>
<div class="services-grid">
<div class="service-card">
<div class="service-icon">
<svg viewBox="0 0 100 100" class="service-svg">
<circle cx="50" cy="50" r="40" fill="none" stroke="url(#heroGradient)" stroke-width="3" filter="url(#heroGlow)"/>
<path d="M30 50 L45 65 L70 35" fill="none" stroke="url(#heroGradient)" stroke-width="3" filter="url(#heroGlow)"/>
</svg>
</div>
<h3>Decentralized Security</h3>
<p>Secure infrastructure with no single point of failure</p>
</div>
<div class="service-card">
<div class="service-icon">
<svg viewBox="0 0 100 100" class="service-svg">
<rect x="20" y="30" width="60" height="40" fill="none" stroke="url(#heroGradient)" stroke-width="3" filter="url(#heroGlow)"/>
<path d="M40 50 L50 60 L60 50" fill="none" stroke="url(#heroGradient)" stroke-width="3" filter="url(#heroGlow)"/>
</svg>
</div>
<h3>Resilient Storage</h3>
<p>Distributed and cryptographically secured storage solutions</p>
</div>
<div class="service-card">
<div class="service-icon">
<svg viewBox="0 0 100 100" class="service-svg">
<path d="M50 20 L70 40 L70 70 L30 70 L30 40 Z" fill="none" stroke="url(#heroGradient)" stroke-width="3" filter="url(#heroGlow)"/>
<circle cx="50" cy="45" r="5" fill="url(#heroGradient)" filter="url(#heroGlow)"/>
</svg>
</div>
<h3>Self-custodial cloud infrastructure</h3>
<p>Eliminating intermediaries for full control</p>
</div>
</div>
</div>
</section>
<section id="about" class="about">
<div class="container">
<div class="about-content">
<div class="about-text">
<h2>About 4NK</h2>
<p>
4NK represents a new era of technology infrastructure.
Our self-custodial cloud infrastructure approach revolutionizes how we think about
security, decentralization, and data control.
</p>
<p>
With our cutting-edge technology, we eliminate traditional points of failure
and create a resilient, transparent ecosystem entirely under your control.
</p>
</div>
<div class="about-visual">
<div class="logo-showcase">
<img src="/img/infra.png" alt="4NK Showcase Logo" class="showcase-logo-img">
</div>
</div>
</div>
</div>
</section>
<section id="contact" class="contact">
<div class="container">
<h2 class="section-title">Contact</h2>
<div class="contact-content">
<div class="contact-info">
<h3>Get in touch</h3>
<p>Ready to revolutionize your infrastructure? Contact us to discover how 4NK can transform your approach to security and decentralization.</p>
</div>
<div class="contact-form">
<form>
<div class="form-group">
<input type="text" placeholder="Name" required>
</div>
<div class="form-group">
<input type="email" placeholder="Email" required>
</div>
<div class="form-group">
<textarea placeholder="Message" rows="5" required></textarea>
</div>
<button type="submit" class="btn btn-primary">Send</button>
</form>
</div>
</div>
</div>
</section>
</main>
<footer class="footer">
<div class="container">
<div class="footer-content">
<div class="footer-logo">
<div class="footer-logo-container">
<img src="img/logo.png" alt="4NK Footer Logo" class="footer-logo-img">
</div>
<div class="footer-text">
<span class="brand-name">4NK</span>
<span class="brand-subtitle">The self-custodial cloud infrastructure</span>
</div>
</div>
<div class="footer-links">
<a href="#home">Home</a>
<a href="#services">Services</a>
<a href="#about">About</a>
<a href="#contact">Contact</a>
<a href="/powered_by_bitcoin.html">Powered by Bitcoin</a>
<a href="/manifest_en.html">Manifest</a>
<a href="https://git.4nkweb.com" target="_blank" rel="noopener">git.4nkweb.com</a>
</div>
</div>
<div class="footer-bottom">
<p>&copy; 2024 4NK. All rights reserved.</p>
</div>
</div>
</footer>
<script src="script.js"></script>
</body>
</html>

115
manifest_en.html Normal file
View File

@ -0,0 +1,115 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>4NK — Manifest</title>
<link rel="icon" type="image/png" href="/favicon.png">
<link rel="stylesheet" href="/styles.css">
<style>
.page { max-width: 980px; margin: 4rem auto; padding: 0 1rem; }
.header-actions { margin: 1.5rem 0 2rem; display: flex; gap: .75rem; }
.section { margin: 2rem 0; }
ul { padding-left: 1.2rem; }
</style>
</head>
<body>
<div class="page">
<h1>4NK — Manifest</h1>
<div class="header-actions">
<a class="btn btn-secondary" href="/">Back to homepage</a>
</div>
<div class="section">
<h2>A third way for a sovereign, frugal, and verifiable web</h2>
<p>4NK proposes a web that is simpler, cheaper, more reliable, and sovereign.</p>
<p>Today, the internet faces a structural crisis. Web2 brought ease of use but relies on centralized architectures that leak data by default. States reacted with fragmentation (sovereign clouds, national rules), producing balkanized, incompatible networks that do not restore trust. Web3 tried to decentralize everything and created new complexities; Web5 had the right intuition but remained constrained by a single monetary rail. 4NK is neither marketing nor another blockchain. It is a distributed, frugal, and verifiable infrastructure: a third way.</p>
</div>
<div class="section">
<h2>Principles</h2>
<ul>
<li><b>Neutral mesh relays</b>: control nothing, store nothing, surveil nothing; they only synchronize and replicate cryptographic proofs.</li>
<li><b>User sovereignty</b>: keys, data, and identities remain exclusively under users’ control.</li>
<li><b>Universal verifiability</b>: every action is anchored and cryptographically traceable without relying on a third party.</li>
<li><b>Digital frugality</b>: no heavy infrastructure or foreign clouds; resilience comes from distribution, not energy‑hungry duplication.</li>
</ul>
<p>Experience remains Web2‑like—same simplicity and fluidity—without structural leaks or platform dependency. 4NK secures messaging and documents, anchors proofs immutably, enables sovereign identity, simplifies payments, and satisfies compliance without massive data exposure.</p>
</div>
<div class="section">
<h2>Bitcoin beyond payments</h2>
<ul>
<li>Encrypted messaging with per‑message secrets (inspired by silent payments), no third party involved.</li>
<li>Off‑chain contracts signed by wallets, validated by peers, linked to a layer‑2 oracle anchored on Bitcoin.</li>
<li>Distributed storage: data remains with stakeholders or in a mesh, never in cleartext on public clouds.</li>
<li>One‑scan payments: native Lightning integration, no Stripe or PayPal.</li>
</ul>
<p>Everything runs client‑side (Client‑Side Validation). No custodians.</p>
</div>
<div class="section">
<h2>Why not Web3 or “state blockchains”?</h2>
<ul>
<li>Not everything should be on a blockchain; gas fees add friction and UX complexity.</li>
<li>Most “public” chains are VC‑dominated; decentralization often recentralizes around a few actors.</li>
<li>State “sovereign blockchains” are centralization in disguise and see weak adoption.</li>
</ul>
<p>Decentralization is a means, not an end. The end is resilience. 4NK applies distribution where it matters: the infrastructure itself.</p>
</div>
<div class="section">
<h2>Architecture</h2>
<ul>
<li><b>Zones</b>: user (browser/client), relay (mesh), distributed application services, Bitcoin anchoring.</li>
<li><b>Relays</b>: synchronize anchors, provide redundancy, remain blind by design.</li>
<li><b>Sovereign identities</b>: per‑use key derivation for unlinkability; verifiable yet confidential credentials.</li>
<li><b>Anchoring</b>: one Bitcoin transaction acts as a cryptographic root for entire trees (Merkle aggregation) → global security without per‑use energy inflation.</li>
<li><b>Security</b>: minimal exposure via reverse proxies; isolation of critical services; systematic end‑to‑end encryption.</li>
<li><b>Governance</b>: any organization or user can operate nodes; no single actor can impose decisions.</li>
</ul>
</div>
<div class="section">
<h2>UX continuity and energy efficiency</h2>
<p>4NK keeps the Web2 user experience while making the infrastructure invisible. It reuses existing equipment and avoids industrial duplication. Bitcoin provides a shared anchoring layer: a single transaction can certify billions of anchors—cost does not scale with usage.</p>
</div>
<div class="section">
<h2>Deployment strategy</h2>
<ol>
<li>Sovereign document management (Docv)</li>
<li>Encrypted messaging and sovereign communications</li>
<li>Distributed, probative traceability across value chains</li>
<li>Innovative identity and login methods (passwordless, derived addresses)</li>
<li>Integrated, decentralized payments (micropayments, P2P, Bitcoin‑anchored)</li>
</ol>
</div>
<div class="section">
<h2>Impacts</h2>
<ul>
<li><b>Industrial competitiveness</b>: ends data pillage; predictable security costs; local value capture.</li>
<li><b>Jobs and ecosystem</b>: local integration and support; diversified operators; European independence.</li>
<li><b>Trust</b>: verifiable identity; no massive registries; proofs without overexposure.</li>
<li><b>Ecology</b>: minimal marginal energy thanks to distribution and shared Bitcoin anchoring.</li>
</ul>
</div>
<div class="section">
<h2>Risks and limits</h2>
<ul>
<li>Maturity and adoption thresholds; education for key management.</li>
<li>Regulatory interoperability to avoid forced centralization.</li>
<li>Indirect dependence on Bitcoin’s resilience; resistance from entrenched actors.</li>
</ul>
</div>
<div class="section">
<h2>Conclusion</h2>
<p>Migrating to a distributed, neutral, and verifiable infrastructure is a rational societal choice. 4NK makes security a property of the architecture itself—provable, sovereign, and frugal—so the internet becomes simpler, cheaper, and more trustworthy.</p>
</div>
</div>
<script src="/script.js"></script>
</body>
</html>

109
powered_by_bitcoin.html Normal file
View File

@ -0,0 +1,109 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>4NK — Powered by Bitcoin</title>
<link rel="icon" type="image/png" href="/favicon.png">
<link rel="stylesheet" href="/styles.css">
<style>
.page { max-width: 960px; margin: 4rem auto; padding: 0 1rem; }
h1, h2, h3 { margin: 1.5rem 0 .5rem; }
.section { margin: 1.25rem 0; }
ul { padding-left: 1.2rem; }
.header-actions { margin: 1.5rem 0 2rem; display: flex; gap: .75rem; }
</style>
</head>
<body>
<div class="page">
<h1>Powered by Bitcoin</h1>
<div class="header-actions">
<a class="btn btn-secondary" href="/">Back to homepage</a>
</div>
<h2>4NK: the self-custodial cloud infrastructure</h2>
<p>For fifteen years, Bitcoin has proven that a decentralized network can secure value without any trusted intermediary. Every block, every signature, every verification is performed by the users themselves. No need for a centralized custodian: everyone can verify, everyone can hold.</p>
<p>But outside of payments, the digital world still relies everywhere on trusted third parties:</p>
<ul>
<li>centralized clouds and servers,</li>
<li>messaging platforms,</li>
<li>digital identity services,</li>
<li>storage solutions.</li>
</ul>
<p>These custodians capture data, impose costs, and create points of failure. They are the equivalent of banks before Bitcoin: convenient, but vulnerable and intrusive.</p>
<h2>4NK: Bitcoin beyond payments</h2>
<p>4NK is a client-side infrastructure layer that extends Bitcoin’s native properties to everyday digital uses:</p>
<ul>
<li>The resilience of a distributed proof network → every flow becomes verifiable, without relying on a server.</li>
<li>Money as a universal mechanism → reliable remuneration for security.</li>
<li>Cryptography as identity → public keys extended into digital identities.</li>
</ul>
<h2>How does it work?</h2>
<ul>
<li>Encrypted messaging: based on non-interactive secret sharing derived from silent payments. Each message generates a unique, encrypted, and untraceable secret, with no third party involved.</li>
<li>Off-chain contracts: signed by Bitcoin wallets, validated by peers, and linked to a layer-2 oracle (Signet) regularly anchored on the Bitcoin mainnet.</li>
<li>Distributed storage: files kept locally between stakeholders or in a mesh network, never in cleartext, never in a public cloud.</li>
<li>Payments in one scan: native Lightning integration, no Stripe, no PayPal.</li>
</ul>
<p>Everything is operated client-side (Client-Side Validation). No custodian.</p>
<h2>Custodian-killer</h2>
<p>Just as Bitcoin killed the need for a central bank to hold and transfer value, 4NK kills the need for digital custodians to identify, exchange, store, and contract.</p>
<p>This is not a new blockchain. This is not a token. It is the natural extension of Bitcoin:</p>
<ul>
<li>distributed proofs as a foundation,</li>
<li>money as a universal rail,</li>
<li>public keys as digital identities,</li>
<li>secret sharing as sovereign messaging.</li>
</ul>
<h2>4NK is not a theory</h2>
<ul>
<li>Notaries: legal acts anchored on a proof layer over Bitcoin.</li>
<li>SMEs: sovereign document management, serverless messaging.</li>
<li>Public bodies: integrations underway with operators.</li>
<li>Healthcare: POC in deployment.</li>
</ul>
<p>Every time, the model is the same: replace a custodian with Bitcoin + client-side.</p>
<h2>The result</h2>
<p>Making Bitcoin not only the currency of trust, but also the universal infrastructure layer of the digital world:</p>
<ul>
<li>Simpler login: four words + multisignature across devices.</li>
<li>Simpler payments: compatible with all Bitcoin rails + integrated Silent Payment wallet (web & mobile).</li>
<li>Cheaper, no CAPEX: more users = more resources.</li>
<li>Cheaper, no infrastructure: less tooling, less supervision, less complexity.</li>
<li>More secure: encryption directly by user identities, redundancy included.</li>
<li>More resilient: no central point, no centralized rights management.</li>
<li>Fully verifiable cryptographically via the anchoring layer.</li>
<li>Everything is a contract: compliance with agreements, norms, and standards is cryptographically enforced between final parties, where the proof system is also the payment system.</li>
<li>As fast as needed: there is always a route to deliver information.</li>
</ul>
<h2>Our focus</h2>
<ul>
<li>Local AI experiences integrated into a “Chat First” UX, replacing legacy workflows.</li>
<li>Effective support, separate from core development.</li>
</ul>
<h2>Our ambition</h2>
<p>To make Bitcoin not only the currency of trust, but also the universal infrastructure layer of the internet:</p>
<ul>
<li>identity,</li>
<li>messaging,</li>
<li>contracts,</li>
<li>storage.</li>
</ul>
<p>An internet where the user is sovereign, verification is local, and custodians belong permanently to the past.</p>
<p><b>4NK: the self-custodial cloud infrastructure.</b></p>
<hr style="margin: 2rem 0; opacity:.2;">
<p>
Looking for more context? Read the full <a href="/manifest_en.html">Manifest</a>.
</p>
</div>
<script src="/script.js"></script>
</body>
</html>

5
robots.txt Normal file
View File

@ -0,0 +1,5 @@
User-agent: *
Allow: /
Sitemap: https://4nkweb5.com/sitemap.xml

329
script.js Normal file
View File

@ -0,0 +1,329 @@
// Script principal pour le site 4NK
document.addEventListener('DOMContentLoaded', function() {
// Animation d'apparition des éléments au scroll
const observerOptions = {
threshold: 0.1,
rootMargin: '0px 0px -50px 0px'
};
const observer = new IntersectionObserver(function(entries) {
entries.forEach(entry => {
if (entry.isIntersecting) {
entry.target.classList.add('fade-in-up');
}
});
}, observerOptions);
// Observer tous les éléments à animer
const animatedElements = document.querySelectorAll('.service-card, .about-text, .about-visual, .contact-info, .contact-form');
animatedElements.forEach(el => {
observer.observe(el);
});
// Navigation smooth scroll
const navLinks = document.querySelectorAll('.nav-link');
navLinks.forEach(link => {
link.addEventListener('click', function(e) {
e.preventDefault();
const targetId = this.getAttribute('href');
const targetSection = document.querySelector(targetId);
if (targetSection) {
const headerHeight = document.querySelector('.header').offsetHeight;
const targetPosition = targetSection.offsetTop - headerHeight;
window.scrollTo({
top: targetPosition,
behavior: 'smooth'
});
}
});
});
// Effet de parallaxe sur le logo principal
const heroLogo = document.querySelector('.hero-logo-img');
window.addEventListener('scroll', function() {
const scrolled = window.pageYOffset;
const rate = scrolled * -0.5;
if (heroLogo) {
heroLogo.style.transform = `translateY(${rate}px) rotate(${scrolled * 0.1}deg)`;
}
});
// Animation du header au scroll
const header = document.querySelector('.header');
window.addEventListener('scroll', function() {
if (window.scrollY > 100) {
header.style.background = 'rgba(10, 10, 10, 0.98)';
header.style.boxShadow = '0 2px 20px rgba(255, 107, 53, 0.1)';
} else {
header.style.background = 'rgba(10, 10, 10, 0.95)';
header.style.boxShadow = 'none';
}
});
// Effet de typing pour le titre principal
function typeWriter(element, text, speed = 100) {
let i = 0;
element.innerHTML = '';
function type() {
if (i < text.length) {
element.innerHTML += text.charAt(i);
i++;
setTimeout(type, speed);
}
}
type();
}
// Animation des icônes de services
const serviceIcons = document.querySelectorAll('.service-svg');
serviceIcons.forEach(icon => {
icon.addEventListener('mouseenter', function() {
this.style.animation = 'serviceIconPulse 1s ease-in-out infinite';
});
icon.addEventListener('mouseleave', function() {
this.style.animation = 'serviceIconPulse 3s ease-in-out infinite';
});
});
// Effet de particules flottantes
function createParticles() {
const particlesContainer = document.createElement('div');
particlesContainer.className = 'particles';
document.body.appendChild(particlesContainer);
for (let i = 0; i < 20; i++) {
const particle = document.createElement('div');
particle.className = 'particle';
particle.style.left = Math.random() * 100 + '%';
particle.style.animationDelay = Math.random() * 10 + 's';
particle.style.animationDuration = (Math.random() * 10 + 10) + 's';
particlesContainer.appendChild(particle);
}
}
// Créer les particules
createParticles();
// Effet de glow sur les boutons
const buttons = document.querySelectorAll('.btn');
buttons.forEach(button => {
button.addEventListener('mouseenter', function() {
this.style.boxShadow = '0 8px 25px rgba(255, 107, 53, 0.5), 0 0 20px rgba(255, 107, 53, 0.3)';
});
button.addEventListener('mouseleave', function() {
if (this.classList.contains('btn-primary')) {
this.style.boxShadow = '0 4px 15px rgba(255, 107, 53, 0.3)';
} else {
this.style.boxShadow = 'none';
}
});
});
// Gestion du formulaire de contact
const contactForm = document.querySelector('.contact-form form');
if (contactForm) {
contactForm.addEventListener('submit', async function(e) {
e.preventDefault();
const submitBtn = this.querySelector('.btn-primary');
const originalText = submitBtn.textContent;
submitBtn.textContent = 'Sending...';
submitBtn.disabled = true;
const name = this.querySelector('input[placeholder="Name"]').value.trim();
const email = this.querySelector('input[placeholder="Email"]').value.trim();
const message = this.querySelector('textarea[placeholder="Message"]').value.trim();
try {
const resp = await fetch('/contact', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ name, email, message })
});
if (!resp.ok) throw new Error('Failed');
submitBtn.textContent = 'Message sent!';
submitBtn.style.background = '#4CAF50';
setTimeout(() => {
submitBtn.textContent = originalText;
submitBtn.disabled = false;
submitBtn.style.background = '';
this.reset();
}, 2000);
} catch (err) {
submitBtn.textContent = 'Send failed';
submitBtn.style.background = '#E53935';
setTimeout(() => {
submitBtn.textContent = originalText;
submitBtn.disabled = false;
submitBtn.style.background = '';
}, 2000);
}
});
}
// Effet de cursor personnalisé
const cursor = document.createElement('div');
cursor.className = 'custom-cursor';
cursor.style.cssText = `
position: fixed;
width: 20px;
height: 20px;
background: radial-gradient(circle, rgba(255, 107, 53, 0.8) 0%, transparent 70%);
border-radius: 50%;
pointer-events: none;
z-index: 9999;
transition: transform 0.1s ease;
display: none;
`;
document.body.appendChild(cursor);
// Suivi du curseur
document.addEventListener('mousemove', function(e) {
cursor.style.left = e.clientX - 10 + 'px';
cursor.style.top = e.clientY - 10 + 'px';
cursor.style.display = 'block';
});
// Cacher le curseur personnalisé quand on quitte la page
document.addEventListener('mouseleave', function() {
cursor.style.display = 'none';
});
// Effet de hover sur les liens
const links = document.querySelectorAll('a, .btn');
links.forEach(link => {
link.addEventListener('mouseenter', function() {
cursor.style.transform = 'scale(1.5)';
cursor.style.background = 'radial-gradient(circle, rgba(255, 215, 0, 0.8) 0%, transparent 70%)';
});
link.addEventListener('mouseleave', function() {
cursor.style.transform = 'scale(1)';
cursor.style.background = 'radial-gradient(circle, rgba(255, 107, 53, 0.8) 0%, transparent 70%)';
});
});
// Animation des logos images
const logos = document.querySelectorAll('.logo-img, .hero-logo-img, .showcase-logo-img, .footer-logo-img');
logos.forEach(logo => {
logo.addEventListener('mouseenter', function() {
this.style.filter = 'drop-shadow(0 0 20px var(--primary-orange)) drop-shadow(0 0 40px var(--accent-orange))';
});
logo.addEventListener('mouseleave', function() {
// Restaurer le filtre original selon le type de logo
if (this.classList.contains('hero-logo-img')) {
this.style.filter = 'drop-shadow(0 0 20px var(--primary-orange))';
} else if (this.classList.contains('showcase-logo-img')) {
this.style.filter = 'drop-shadow(0 0 15px var(--primary-orange))';
} else if (this.classList.contains('footer-logo-img')) {
this.style.filter = 'drop-shadow(0 0 8px var(--primary-orange))';
} else {
this.style.filter = 'drop-shadow(0 0 10px var(--primary-orange))';
}
});
});
// Effet de parallaxe sur les sections
const parallaxElements = document.querySelectorAll('.hero, .services, .about, .contact');
window.addEventListener('scroll', function() {
const scrolled = window.pageYOffset;
parallaxElements.forEach((element, index) => {
const rate = scrolled * -0.5;
const sectionOffset = element.offsetTop;
const sectionHeight = element.offsetHeight;
if (scrolled + window.innerHeight > sectionOffset && scrolled < sectionOffset + sectionHeight) {
element.style.transform = `translateY(${rate * 0.1}px)`;
}
});
});
// Animation des cartes de services au scroll
const serviceCards = document.querySelectorAll('.service-card');
const serviceObserver = new IntersectionObserver(function(entries) {
entries.forEach((entry, index) => {
if (entry.isIntersecting) {
setTimeout(() => {
entry.target.style.opacity = '1';
entry.target.style.transform = 'translateY(0)';
}, index * 200);
}
});
}, { threshold: 0.1 });
serviceCards.forEach(card => {
card.style.opacity = '0';
card.style.transform = 'translateY(50px)';
card.style.transition = 'all 0.6s ease';
serviceObserver.observe(card);
});
// Effet de glow sur le texte principal
const brandName = document.querySelector('.brand-name');
if (brandName) {
setInterval(() => {
const intensity = Math.random() * 0.5 + 0.5;
brandName.style.textShadow = `0 0 ${30 * intensity}px rgba(255, 107, 53, ${intensity}), 0 0 ${50 * intensity}px rgba(255, 165, 0, ${intensity * 0.5})`;
}, 1000);
}
// Animation de chargement initial
window.addEventListener('load', function() {
document.body.style.opacity = '0';
document.body.style.transition = 'opacity 1s ease';
setTimeout(() => {
document.body.style.opacity = '1';
}, 100);
});
// Gestion du menu mobile (si nécessaire)
const navToggle = document.createElement('button');
navToggle.className = 'nav-toggle';
navToggle.innerHTML = '☰';
navToggle.style.cssText = `
display: none;
background: none;
border: none;
color: var(--text-light);
font-size: 1.5rem;
cursor: pointer;
padding: 0.5rem;
`;
// Ajouter le toggle au nav si on est sur mobile
if (window.innerWidth <= 768) {
const nav = document.querySelector('.nav');
nav.appendChild(navToggle);
navToggle.addEventListener('click', function() {
const navMenu = document.querySelector('.nav-menu');
navMenu.style.display = navMenu.style.display === 'flex' ? 'none' : 'flex';
});
}
// Mise à jour du menu mobile au redimensionnement
window.addEventListener('resize', function() {
const navMenu = document.querySelector('.nav-menu');
if (window.innerWidth > 768) {
navMenu.style.display = 'flex';
navToggle.style.display = 'none';
} else {
navToggle.style.display = 'block';
navMenu.style.display = 'none';
}
});
console.log('Site 4NK chargé avec succès !');
});

20
scripts/install-mailer.sh Normal file
View File

@ -0,0 +1,20 @@
#!/bin/bash
set -euo pipefail
cd /home/debian/website/server
if ! command -v node >/dev/null 2>&1; then
echo "Node.js is required" >&2
exit 1
fi
printf "Installing dependencies...\n"
if [ -f package-lock.json ]; then
npm ci
else
npm install --no-fund --no-audit
fi
printf "Mailer ready in /home/debian/website/server\n"

11
scripts/reload-nginx.sh Normal file
View File

@ -0,0 +1,11 @@
#!/bin/bash
set -euo pipefail
printf "[1/2] Testing nginx config...\n"
sudo nginx -t | sed -u 's/^/[nginx-test] /'
printf "[2/2] Reloading nginx...\n"
sudo systemctl reload nginx
printf "Done.\n"

11
scripts/test-contact.sh Normal file
View File

@ -0,0 +1,11 @@
#!/bin/bash
set -euo pipefail
URL=${1:-https://4nk.network/contact}
printf "POST %s\n" "$URL"
curl -i -sS -X POST "$URL" \
-H 'content-type: application/json' \
--data '{"name":"Test User","email":"test@example.com","message":"Hello from script"}' | sed -u 's/^/[contact] /'

62
server/index.js Normal file
View File

@ -0,0 +1,62 @@
import express from 'express';
import helmet from 'helmet';
import nodemailer from 'nodemailer';
import process from 'process';
import 'dotenv/config';
const app = express();
const port = process.env.PORT ? Number(process.env.PORT) : (process.env.SERVER_PORT ? Number(process.env.SERVER_PORT) : 3001);
app.disable('x-powered-by');
app.use(helmet({ contentSecurityPolicy: false }));
app.use(express.json());
app.use(express.urlencoded({ extended: true }));
const smtpHost = process.env.SMTP_HOST || '127.0.0.1';
const smtpPort = process.env.SMTP_PORT ? Number(process.env.SMTP_PORT) : 25;
const smtpSecure = String(process.env.SMTP_SECURE || 'false').toLowerCase() === 'true';
const smtpRejectUnauthorized = String(process.env.SMTP_TLS_REJECT_UNAUTHORIZED || 'false').toLowerCase() === 'true';
const smtpUser = process.env.SMTP_USER;
const smtpPassword = process.env.SMTP_PASSWORD;
const mailTransport = nodemailer.createTransport({
host: smtpHost,
port: smtpPort,
secure: smtpSecure,
auth: smtpUser && smtpPassword ? {
user: smtpUser,
pass: smtpPassword
} : undefined,
tls: { rejectUnauthorized: smtpRejectUnauthorized }
});
app.post('/contact', async (req, res) => {
const name = String(req.body.name || '').trim();
const email = String(req.body.email || '').trim();
const message = String(req.body.message || '').trim();
if (!name || !email || !message) {
return res.status(400).json({ ok: false, error: 'Missing fields' });
}
try {
await mailTransport.verify();
await mailTransport.sendMail({
from: process.env.SMTP_FROM || 'no-reply@4nk.network',
to: process.env.SMTP_TO || 'nicolas.cantu@4nk.network',
subject: `[4NK Contact] ${name}`,
replyTo: email,
text: `From: ${name} <${email}>\n\n${message}`,
});
return res.json({ ok: true });
} catch (err) {
console.error('Mail send failed:', err);
return res.status(502).json({ ok: false, error: 'Mail delivery failed' });
}
});
app.get('/health', (req, res) => res.json({ ok: true }));
app.listen(port, '127.0.0.1', () => {
console.log(`Mailer listening on http://127.0.0.1:${port}`);
});

866
server/package-lock.json generated Normal file
View File

@ -0,0 +1,866 @@
{
"name": "4nk-website-mailer",
"version": "1.0.0",
"lockfileVersion": 3,
"requires": true,
"packages": {
"": {
"name": "4nk-website-mailer",
"version": "1.0.0",
"license": "MIT",
"dependencies": {
"dotenv": "^16.4.5",
"express": "^4.19.2",
"helmet": "^7.1.0",
"nodemailer": "^6.9.14"
}
},
"node_modules/accepts": {
"version": "1.3.8",
"resolved": "https://registry.npmjs.org/accepts/-/accepts-1.3.8.tgz",
"integrity": "sha512-PYAthTa2m2VKxuvSD3DPC/Gy+U+sOA1LAuT8mkmRuvw+NACSaeXEQ+NHcVF7rONl6qcaxV3Uuemwawk+7+SJLw==",
"license": "MIT",
"dependencies": {
"mime-types": "~2.1.34",
"negotiator": "0.6.3"
},
"engines": {
"node": ">= 0.6"
}
},
"node_modules/array-flatten": {
"version": "1.1.1",
"resolved": "https://registry.npmjs.org/array-flatten/-/array-flatten-1.1.1.tgz",
"integrity": "sha512-PCVAQswWemu6UdxsDFFX/+gVeYqKAod3D3UVm91jHwynguOwAvYPhx8nNlM++NqRcK6CxxpUafjmhIdKiHibqg==",
"license": "MIT"
},
"node_modules/body-parser": {
"version": "1.20.3",
"resolved": "https://registry.npmjs.org/body-parser/-/body-parser-1.20.3.tgz",
"integrity": "sha512-7rAxByjUMqQ3/bHJy7D6OGXvx/MMc4IqBn/X0fcM1QUcAItpZrBEYhWGem+tzXH90c+G01ypMcYJBO9Y30203g==",
"license": "MIT",
"dependencies": {
"bytes": "3.1.2",
"content-type": "~1.0.5",
"debug": "2.6.9",
"depd": "2.0.0",
"destroy": "1.2.0",
"http-errors": "2.0.0",
"iconv-lite": "0.4.24",
"on-finished": "2.4.1",
"qs": "6.13.0",
"raw-body": "2.5.2",
"type-is": "~1.6.18",
"unpipe": "1.0.0"
},
"engines": {
"node": ">= 0.8",
"npm": "1.2.8000 || >= 1.4.16"
}
},
"node_modules/bytes": {
"version": "3.1.2",
"resolved": "https://registry.npmjs.org/bytes/-/bytes-3.1.2.tgz",
"integrity": "sha512-/Nf7TyzTx6S3yRJObOAV7956r8cr2+Oj8AC5dt8wSP3BQAoeX58NoHyCU8P8zGkNXStjTSi6fzO6F0pBdcYbEg==",
"license": "MIT",
"engines": {
"node": ">= 0.8"
}
},
"node_modules/call-bind-apply-helpers": {
"version": "1.0.2",
"resolved": "https://registry.npmjs.org/call-bind-apply-helpers/-/call-bind-apply-helpers-1.0.2.tgz",
"integrity": "sha512-Sp1ablJ0ivDkSzjcaJdxEunN5/XvksFJ2sMBFfq6x0ryhQV/2b/KwFe21cMpmHtPOSij8K99/wSfoEuTObmuMQ==",
"license": "MIT",
"dependencies": {
"es-errors": "^1.3.0",
"function-bind": "^1.1.2"
},
"engines": {
"node": ">= 0.4"
}
},
"node_modules/call-bound": {
"version": "1.0.4",
"resolved": "https://registry.npmjs.org/call-bound/-/call-bound-1.0.4.tgz",
"integrity": "sha512-+ys997U96po4Kx/ABpBCqhA9EuxJaQWDQg7295H4hBphv3IZg0boBKuwYpt4YXp6MZ5AmZQnU/tyMTlRpaSejg==",
"license": "MIT",
"dependencies": {
"call-bind-apply-helpers": "^1.0.2",
"get-intrinsic": "^1.3.0"
},
"engines": {
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
"node_modules/content-disposition": {
"version": "0.5.4",
"resolved": "https://registry.npmjs.org/content-disposition/-/content-disposition-0.5.4.tgz",
"integrity": "sha512-FveZTNuGw04cxlAiWbzi6zTAL/lhehaWbTtgluJh4/E95DqMwTmha3KZN1aAWA8cFIhHzMZUvLevkw5Rqk+tSQ==",
"license": "MIT",
"dependencies": {
"safe-buffer": "5.2.1"
},
"engines": {
"node": ">= 0.6"
}
},
"node_modules/content-type": {
"version": "1.0.5",
"resolved": "https://registry.npmjs.org/content-type/-/content-type-1.0.5.tgz",
"integrity": "sha512-nTjqfcBFEipKdXCv4YDQWCfmcLZKm81ldF0pAopTvyrFGVbcR6P/VAAd5G7N+0tTr8QqiU0tFadD6FK4NtJwOA==",
"license": "MIT",
"engines": {
"node": ">= 0.6"
}
},
"node_modules/cookie": {
"version": "0.7.1",
"resolved": "https://registry.npmjs.org/cookie/-/cookie-0.7.1.tgz",
"integrity": "sha512-6DnInpx7SJ2AK3+CTUE/ZM0vWTUboZCegxhC2xiIydHR9jNuTAASBrfEpHhiGOZw/nX51bHt6YQl8jsGo4y/0w==",
"license": "MIT",
"engines": {
"node": ">= 0.6"
}
},
"node_modules/cookie-signature": {
"version": "1.0.6",
"resolved": "https://registry.npmjs.org/cookie-signature/-/cookie-signature-1.0.6.tgz",
"integrity": "sha512-QADzlaHc8icV8I7vbaJXJwod9HWYp8uCqf1xa4OfNu1T7JVxQIrUgOWtHdNDtPiywmFbiS12VjotIXLrKM3orQ==",
"license": "MIT"
},
"node_modules/debug": {
"version": "2.6.9",
"resolved": "https://registry.npmjs.org/debug/-/debug-2.6.9.tgz",
"integrity": "sha512-bC7ElrdJaJnPbAP+1EotYvqZsb3ecl5wi6Bfi6BJTUcNowp6cvspg0jXznRTKDjm/E7AdgFBVeAPVMNcKGsHMA==",
"license": "MIT",
"dependencies": {
"ms": "2.0.0"
}
},
"node_modules/depd": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/depd/-/depd-2.0.0.tgz",
"integrity": "sha512-g7nH6P6dyDioJogAAGprGpCtVImJhpPk/roCzdb3fIh61/s/nPsfR6onyMwkCAR/OlC3yBC0lESvUoQEAssIrw==",
"license": "MIT",
"engines": {
"node": ">= 0.8"
}
},
"node_modules/destroy": {
"version": "1.2.0",
"resolved": "https://registry.npmjs.org/destroy/-/destroy-1.2.0.tgz",
"integrity": "sha512-2sJGJTaXIIaR1w4iJSNoN0hnMY7Gpc/n8D4qSCJw8QqFWXf7cuAgnEHxBpweaVcPevC2l3KpjYCx3NypQQgaJg==",
"license": "MIT",
"engines": {
"node": ">= 0.8",
"npm": "1.2.8000 || >= 1.4.16"
}
},
"node_modules/dotenv": {
"version": "16.6.1",
"resolved": "https://registry.npmjs.org/dotenv/-/dotenv-16.6.1.tgz",
"integrity": "sha512-uBq4egWHTcTt33a72vpSG0z3HnPuIl6NqYcTrKEg2azoEyl2hpW0zqlxysq2pK9HlDIHyHyakeYaYnSAwd8bow==",
"license": "BSD-2-Clause",
"engines": {
"node": ">=12"
},
"funding": {
"url": "https://dotenvx.com"
}
},
"node_modules/dunder-proto": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/dunder-proto/-/dunder-proto-1.0.1.tgz",
"integrity": "sha512-KIN/nDJBQRcXw0MLVhZE9iQHmG68qAVIBg9CqmUYjmQIhgij9U5MFvrqkUL5FbtyyzZuOeOt0zdeRe4UY7ct+A==",
"license": "MIT",
"dependencies": {
"call-bind-apply-helpers": "^1.0.1",
"es-errors": "^1.3.0",
"gopd": "^1.2.0"
},
"engines": {
"node": ">= 0.4"
}
},
"node_modules/ee-first": {
"version": "1.1.1",
"resolved": "https://registry.npmjs.org/ee-first/-/ee-first-1.1.1.tgz",
"integrity": "sha512-WMwm9LhRUo+WUaRN+vRuETqG89IgZphVSNkdFgeb6sS/E4OrDIN7t48CAewSHXc6C8lefD8KKfr5vY61brQlow==",
"license": "MIT"
},
"node_modules/encodeurl": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/encodeurl/-/encodeurl-2.0.0.tgz",
"integrity": "sha512-Q0n9HRi4m6JuGIV1eFlmvJB7ZEVxu93IrMyiMsGC0lrMJMWzRgx6WGquyfQgZVb31vhGgXnfmPNNXmxnOkRBrg==",
"license": "MIT",
"engines": {
"node": ">= 0.8"
}
},
"node_modules/es-define-property": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/es-define-property/-/es-define-property-1.0.1.tgz",
"integrity": "sha512-e3nRfgfUZ4rNGL232gUgX06QNyyez04KdjFrF+LTRoOXmrOgFKDg4BCdsjW8EnT69eqdYGmRpJwiPVYNrCaW3g==",
"license": "MIT",
"engines": {
"node": ">= 0.4"
}
},
"node_modules/es-errors": {
"version": "1.3.0",
"resolved": "https://registry.npmjs.org/es-errors/-/es-errors-1.3.0.tgz",
"integrity": "sha512-Zf5H2Kxt2xjTvbJvP2ZWLEICxA6j+hAmMzIlypy4xcBg1vKVnx89Wy0GbS+kf5cwCVFFzdCFh2XSCFNULS6csw==",
"license": "MIT",
"engines": {
"node": ">= 0.4"
}
},
"node_modules/es-object-atoms": {
"version": "1.1.1",
"resolved": "https://registry.npmjs.org/es-object-atoms/-/es-object-atoms-1.1.1.tgz",
"integrity": "sha512-FGgH2h8zKNim9ljj7dankFPcICIK9Cp5bm+c2gQSYePhpaG5+esrLODihIorn+Pe6FGJzWhXQotPv73jTaldXA==",
"license": "MIT",
"dependencies": {
"es-errors": "^1.3.0"
},
"engines": {
"node": ">= 0.4"
}
},
"node_modules/escape-html": {
"version": "1.0.3",
"resolved": "https://registry.npmjs.org/escape-html/-/escape-html-1.0.3.tgz",
"integrity": "sha512-NiSupZ4OeuGwr68lGIeym/ksIZMJodUGOSCZ/FSnTxcrekbvqrgdUxlJOMpijaKZVjAJrWrGs/6Jy8OMuyj9ow==",
"license": "MIT"
},
"node_modules/etag": {
"version": "1.8.1",
"resolved": "https://registry.npmjs.org/etag/-/etag-1.8.1.tgz",
"integrity": "sha512-aIL5Fx7mawVa300al2BnEE4iNvo1qETxLrPI/o05L7z6go7fCw1J6EQmbK4FmJ2AS7kgVF/KEZWufBfdClMcPg==",
"license": "MIT",
"engines": {
"node": ">= 0.6"
}
},
"node_modules/express": {
"version": "4.21.2",
"resolved": "https://registry.npmjs.org/express/-/express-4.21.2.tgz",
"integrity": "sha512-28HqgMZAmih1Czt9ny7qr6ek2qddF4FclbMzwhCREB6OFfH+rXAnuNCwo1/wFvrtbgsQDb4kSbX9de9lFbrXnA==",
"license": "MIT",
"dependencies": {
"accepts": "~1.3.8",
"array-flatten": "1.1.1",
"body-parser": "1.20.3",
"content-disposition": "0.5.4",
"content-type": "~1.0.4",
"cookie": "0.7.1",
"cookie-signature": "1.0.6",
"debug": "2.6.9",
"depd": "2.0.0",
"encodeurl": "~2.0.0",
"escape-html": "~1.0.3",
"etag": "~1.8.1",
"finalhandler": "1.3.1",
"fresh": "0.5.2",
"http-errors": "2.0.0",
"merge-descriptors": "1.0.3",
"methods": "~1.1.2",
"on-finished": "2.4.1",
"parseurl": "~1.3.3",
"path-to-regexp": "0.1.12",
"proxy-addr": "~2.0.7",
"qs": "6.13.0",
"range-parser": "~1.2.1",
"safe-buffer": "5.2.1",
"send": "0.19.0",
"serve-static": "1.16.2",
"setprototypeof": "1.2.0",
"statuses": "2.0.1",
"type-is": "~1.6.18",
"utils-merge": "1.0.1",
"vary": "~1.1.2"
},
"engines": {
"node": ">= 0.10.0"
},
"funding": {
"type": "opencollective",
"url": "https://opencollective.com/express"
}
},
"node_modules/finalhandler": {
"version": "1.3.1",
"resolved": "https://registry.npmjs.org/finalhandler/-/finalhandler-1.3.1.tgz",
"integrity": "sha512-6BN9trH7bp3qvnrRyzsBz+g3lZxTNZTbVO2EV1CS0WIcDbawYVdYvGflME/9QP0h0pYlCDBCTjYa9nZzMDpyxQ==",
"license": "MIT",
"dependencies": {
"debug": "2.6.9",
"encodeurl": "~2.0.0",
"escape-html": "~1.0.3",
"on-finished": "2.4.1",
"parseurl": "~1.3.3",
"statuses": "2.0.1",
"unpipe": "~1.0.0"
},
"engines": {
"node": ">= 0.8"
}
},
"node_modules/forwarded": {
"version": "0.2.0",
"resolved": "https://registry.npmjs.org/forwarded/-/forwarded-0.2.0.tgz",
"integrity": "sha512-buRG0fpBtRHSTCOASe6hD258tEubFoRLb4ZNA6NxMVHNw2gOcwHo9wyablzMzOA5z9xA9L1KNjk/Nt6MT9aYow==",
"license": "MIT",
"engines": {
"node": ">= 0.6"
}
},
"node_modules/fresh": {
"version": "0.5.2",
"resolved": "https://registry.npmjs.org/fresh/-/fresh-0.5.2.tgz",
"integrity": "sha512-zJ2mQYM18rEFOudeV4GShTGIQ7RbzA7ozbU9I/XBpm7kqgMywgmylMwXHxZJmkVoYkna9d2pVXVXPdYTP9ej8Q==",
"license": "MIT",
"engines": {
"node": ">= 0.6"
}
},
"node_modules/function-bind": {
"version": "1.1.2",
"resolved": "https://registry.npmjs.org/function-bind/-/function-bind-1.1.2.tgz",
"integrity": "sha512-7XHNxH7qX9xG5mIwxkhumTox/MIRNcOgDrxWsMt2pAr23WHp6MrRlN7FBSFpCpr+oVO0F744iUgR82nJMfG2SA==",
"license": "MIT",
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
"node_modules/get-intrinsic": {
"version": "1.3.0",
"resolved": "https://registry.npmjs.org/get-intrinsic/-/get-intrinsic-1.3.0.tgz",
"integrity": "sha512-9fSjSaos/fRIVIp+xSJlE6lfwhES7LNtKaCBIamHsjr2na1BiABJPo0mOjjz8GJDURarmCPGqaiVg5mfjb98CQ==",
"license": "MIT",
"dependencies": {
"call-bind-apply-helpers": "^1.0.2",
"es-define-property": "^1.0.1",
"es-errors": "^1.3.0",
"es-object-atoms": "^1.1.1",
"function-bind": "^1.1.2",
"get-proto": "^1.0.1",
"gopd": "^1.2.0",
"has-symbols": "^1.1.0",
"hasown": "^2.0.2",
"math-intrinsics": "^1.1.0"
},
"engines": {
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
"node_modules/get-proto": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/get-proto/-/get-proto-1.0.1.tgz",
"integrity": "sha512-sTSfBjoXBp89JvIKIefqw7U2CCebsc74kiY6awiGogKtoSGbgjYE/G/+l9sF3MWFPNc9IcoOC4ODfKHfxFmp0g==",
"license": "MIT",
"dependencies": {
"dunder-proto": "^1.0.1",
"es-object-atoms": "^1.0.0"
},
"engines": {
"node": ">= 0.4"
}
},
"node_modules/gopd": {
"version": "1.2.0",
"resolved": "https://registry.npmjs.org/gopd/-/gopd-1.2.0.tgz",
"integrity": "sha512-ZUKRh6/kUFoAiTAtTYPZJ3hw9wNxx+BIBOijnlG9PnrJsCcSjs1wyyD6vJpaYtgnzDrKYRSqf3OO6Rfa93xsRg==",
"license": "MIT",
"engines": {
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
"node_modules/has-symbols": {
"version": "1.1.0",
"resolved": "https://registry.npmjs.org/has-symbols/-/has-symbols-1.1.0.tgz",
"integrity": "sha512-1cDNdwJ2Jaohmb3sg4OmKaMBwuC48sYni5HUw2DvsC8LjGTLK9h+eb1X6RyuOHe4hT0ULCW68iomhjUoKUqlPQ==",
"license": "MIT",
"engines": {
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
"node_modules/hasown": {
"version": "2.0.2",
"resolved": "https://registry.npmjs.org/hasown/-/hasown-2.0.2.tgz",
"integrity": "sha512-0hJU9SCPvmMzIBdZFqNPXWa6dqh7WdH0cII9y+CyS8rG3nL48Bclra9HmKhVVUHyPWNH5Y7xDwAB7bfgSjkUMQ==",
"license": "MIT",
"dependencies": {
"function-bind": "^1.1.2"
},
"engines": {
"node": ">= 0.4"
}
},
"node_modules/helmet": {
"version": "7.2.0",
"resolved": "https://registry.npmjs.org/helmet/-/helmet-7.2.0.tgz",
"integrity": "sha512-ZRiwvN089JfMXokizgqEPXsl2Guk094yExfoDXR0cBYWxtBbaSww/w+vT4WEJsBW2iTUi1GgZ6swmoug3Oy4Xw==",
"license": "MIT",
"engines": {
"node": ">=16.0.0"
}
},
"node_modules/http-errors": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/http-errors/-/http-errors-2.0.0.tgz",
"integrity": "sha512-FtwrG/euBzaEjYeRqOgly7G0qviiXoJWnvEH2Z1plBdXgbyjv34pHTSb9zoeHMyDy33+DWy5Wt9Wo+TURtOYSQ==",
"license": "MIT",
"dependencies": {
"depd": "2.0.0",
"inherits": "2.0.4",
"setprototypeof": "1.2.0",
"statuses": "2.0.1",
"toidentifier": "1.0.1"
},
"engines": {
"node": ">= 0.8"
}
},
"node_modules/iconv-lite": {
"version": "0.4.24",
"resolved": "https://registry.npmjs.org/iconv-lite/-/iconv-lite-0.4.24.tgz",
"integrity": "sha512-v3MXnZAcvnywkTUEZomIActle7RXXeedOR31wwl7VlyoXO4Qi9arvSenNQWne1TcRwhCL1HwLI21bEqdpj8/rA==",
"license": "MIT",
"dependencies": {
"safer-buffer": ">= 2.1.2 < 3"
},
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/inherits": {
"version": "2.0.4",
"resolved": "https://registry.npmjs.org/inherits/-/inherits-2.0.4.tgz",
"integrity": "sha512-k/vGaX4/Yla3WzyMCvTQOXYeIHvqOKtnqBduzTHpzpQZzAskKMhZ2K+EnBiSM9zGSoIFeMpXKxa4dYeZIQqewQ==",
"license": "ISC"
},
"node_modules/ipaddr.js": {
"version": "1.9.1",
"resolved": "https://registry.npmjs.org/ipaddr.js/-/ipaddr.js-1.9.1.tgz",
"integrity": "sha512-0KI/607xoxSToH7GjN1FfSbLoU0+btTicjsQSWQlh/hZykN8KpmMf7uYwPW3R+akZ6R/w18ZlXSHBYXiYUPO3g==",
"license": "MIT",
"engines": {
"node": ">= 0.10"
}
},
"node_modules/math-intrinsics": {
"version": "1.1.0",
"resolved": "https://registry.npmjs.org/math-intrinsics/-/math-intrinsics-1.1.0.tgz",
"integrity": "sha512-/IXtbwEk5HTPyEwyKX6hGkYXxM9nbj64B+ilVJnC/R6B0pH5G4V3b0pVbL7DBj4tkhBAppbQUlf6F6Xl9LHu1g==",
"license": "MIT",
"engines": {
"node": ">= 0.4"
}
},
"node_modules/media-typer": {
"version": "0.3.0",
"resolved": "https://registry.npmjs.org/media-typer/-/media-typer-0.3.0.tgz",
"integrity": "sha512-dq+qelQ9akHpcOl/gUVRTxVIOkAJ1wR3QAvb4RsVjS8oVoFjDGTc679wJYmUmknUF5HwMLOgb5O+a3KxfWapPQ==",
"license": "MIT",
"engines": {
"node": ">= 0.6"
}
},
"node_modules/merge-descriptors": {
"version": "1.0.3",
"resolved": "https://registry.npmjs.org/merge-descriptors/-/merge-descriptors-1.0.3.tgz",
"integrity": "sha512-gaNvAS7TZ897/rVaZ0nMtAyxNyi/pdbjbAwUpFQpN70GqnVfOiXpeUUMKRBmzXaSQ8DdTX4/0ms62r2K+hE6mQ==",
"license": "MIT",
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
"node_modules/methods": {
"version": "1.1.2",
"resolved": "https://registry.npmjs.org/methods/-/methods-1.1.2.tgz",
"integrity": "sha512-iclAHeNqNm68zFtnZ0e+1L2yUIdvzNoauKU4WBA3VvH/vPFieF7qfRlwUZU+DA9P9bPXIS90ulxoUoCH23sV2w==",
"license": "MIT",
"engines": {
"node": ">= 0.6"
}
},
"node_modules/mime": {
"version": "1.6.0",
"resolved": "https://registry.npmjs.org/mime/-/mime-1.6.0.tgz",
"integrity": "sha512-x0Vn8spI+wuJ1O6S7gnbaQg8Pxh4NNHb7KSINmEWKiPE4RKOplvijn+NkmYmmRgP68mc70j2EbeTFRsrswaQeg==",
"license": "MIT",
"bin": {
"mime": "cli.js"
},
"engines": {
"node": ">=4"
}
},
"node_modules/mime-db": {
"version": "1.52.0",
"resolved": "https://registry.npmjs.org/mime-db/-/mime-db-1.52.0.tgz",
"integrity": "sha512-sPU4uV7dYlvtWJxwwxHD0PuihVNiE7TyAbQ5SWxDCB9mUYvOgroQOwYQQOKPJ8CIbE+1ETVlOoK1UC2nU3gYvg==",
"license": "MIT",
"engines": {
"node": ">= 0.6"
}
},
"node_modules/mime-types": {
"version": "2.1.35",
"resolved": "https://registry.npmjs.org/mime-types/-/mime-types-2.1.35.tgz",
"integrity": "sha512-ZDY+bPm5zTTF+YpCrAU9nK0UgICYPT0QtT1NZWFv4s++TNkcgVaT0g6+4R2uI4MjQjzysHB1zxuWL50hzaeXiw==",
"license": "MIT",
"dependencies": {
"mime-db": "1.52.0"
},
"engines": {
"node": ">= 0.6"
}
},
"node_modules/ms": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/ms/-/ms-2.0.0.tgz",
"integrity": "sha512-Tpp60P6IUJDTuOq/5Z8cdskzJujfwqfOTkrwIwj7IRISpnkJnT6SyJ4PCPnGMoFjC9ddhal5KVIYtAt97ix05A==",
"license": "MIT"
},
"node_modules/negotiator": {
"version": "0.6.3",
"resolved": "https://registry.npmjs.org/negotiator/-/negotiator-0.6.3.tgz",
"integrity": "sha512-+EUsqGPLsM+j/zdChZjsnX51g4XrHFOIXwfnCVPGlQk/k5giakcKsuxCObBRu6DSm9opw/O6slWbJdghQM4bBg==",
"license": "MIT",
"engines": {
"node": ">= 0.6"
}
},
"node_modules/nodemailer": {
"version": "6.10.1",
"resolved": "https://registry.npmjs.org/nodemailer/-/nodemailer-6.10.1.tgz",
"integrity": "sha512-Z+iLaBGVaSjbIzQ4pX6XV41HrooLsQ10ZWPUehGmuantvzWoDVBnmsdUcOIDM1t+yPor5pDhVlDESgOMEGxhHA==",
"license": "MIT-0",
"engines": {
"node": ">=6.0.0"
}
},
"node_modules/object-inspect": {
"version": "1.13.4",
"resolved": "https://registry.npmjs.org/object-inspect/-/object-inspect-1.13.4.tgz",
"integrity": "sha512-W67iLl4J2EXEGTbfeHCffrjDfitvLANg0UlX3wFUUSTx92KXRFegMHUVgSqE+wvhAbi4WqjGg9czysTV2Epbew==",
"license": "MIT",
"engines": {
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
"node_modules/on-finished": {
"version": "2.4.1",
"resolved": "https://registry.npmjs.org/on-finished/-/on-finished-2.4.1.tgz",
"integrity": "sha512-oVlzkg3ENAhCk2zdv7IJwd/QUD4z2RxRwpkcGY8psCVcCYZNq4wYnVWALHM+brtuJjePWiYF/ClmuDr8Ch5+kg==",
"license": "MIT",
"dependencies": {
"ee-first": "1.1.1"
},
"engines": {
"node": ">= 0.8"
}
},
"node_modules/parseurl": {
"version": "1.3.3",
"resolved": "https://registry.npmjs.org/parseurl/-/parseurl-1.3.3.tgz",
"integrity": "sha512-CiyeOxFT/JZyN5m0z9PfXw4SCBJ6Sygz1Dpl0wqjlhDEGGBP1GnsUVEL0p63hoG1fcj3fHynXi9NYO4nWOL+qQ==",
"license": "MIT",
"engines": {
"node": ">= 0.8"
}
},
"node_modules/path-to-regexp": {
"version": "0.1.12",
"resolved": "https://registry.npmjs.org/path-to-regexp/-/path-to-regexp-0.1.12.tgz",
"integrity": "sha512-RA1GjUVMnvYFxuqovrEqZoxxW5NUZqbwKtYz/Tt7nXerk0LbLblQmrsgdeOxV5SFHf0UDggjS/bSeOZwt1pmEQ==",
"license": "MIT"
},
"node_modules/proxy-addr": {
"version": "2.0.7",
"resolved": "https://registry.npmjs.org/proxy-addr/-/proxy-addr-2.0.7.tgz",
"integrity": "sha512-llQsMLSUDUPT44jdrU/O37qlnifitDP+ZwrmmZcoSKyLKvtZxpyV0n2/bD/N4tBAAZ/gJEdZU7KMraoK1+XYAg==",
"license": "MIT",
"dependencies": {
"forwarded": "0.2.0",
"ipaddr.js": "1.9.1"
},
"engines": {
"node": ">= 0.10"
}
},
"node_modules/qs": {
"version": "6.13.0",
"resolved": "https://registry.npmjs.org/qs/-/qs-6.13.0.tgz",
"integrity": "sha512-+38qI9SOr8tfZ4QmJNplMUxqjbe7LKvvZgWdExBOmd+egZTtjLB67Gu0HRX3u/XOq7UU2Nx6nsjvS16Z9uwfpg==",
"license": "BSD-3-Clause",
"dependencies": {
"side-channel": "^1.0.6"
},
"engines": {
"node": ">=0.6"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
"node_modules/range-parser": {
"version": "1.2.1",
"resolved": "https://registry.npmjs.org/range-parser/-/range-parser-1.2.1.tgz",
"integrity": "sha512-Hrgsx+orqoygnmhFbKaHE6c296J+HTAQXoxEF6gNupROmmGJRoyzfG3ccAveqCBrwr/2yxQ5BVd/GTl5agOwSg==",
"license": "MIT",
"engines": {
"node": ">= 0.6"
}
},
"node_modules/raw-body": {
"version": "2.5.2",
"resolved": "https://registry.npmjs.org/raw-body/-/raw-body-2.5.2.tgz",
"integrity": "sha512-8zGqypfENjCIqGhgXToC8aB2r7YrBX+AQAfIPs/Mlk+BtPTztOvTS01NRW/3Eh60J+a48lt8qsCzirQ6loCVfA==",
"license": "MIT",
"dependencies": {
"bytes": "3.1.2",
"http-errors": "2.0.0",
"iconv-lite": "0.4.24",
"unpipe": "1.0.0"
},
"engines": {
"node": ">= 0.8"
}
},
"node_modules/safe-buffer": {
"version": "5.2.1",
"resolved": "https://registry.npmjs.org/safe-buffer/-/safe-buffer-5.2.1.tgz",
"integrity": "sha512-rp3So07KcdmmKbGvgaNxQSJr7bGVSVk5S9Eq1F+ppbRo70+YeaDxkw5Dd8NPN+GD6bjnYm2VuPuCXmpuYvmCXQ==",
"funding": [
{
"type": "github",
"url": "https://github.com/sponsors/feross"
},
{
"type": "patreon",
"url": "https://www.patreon.com/feross"
},
{
"type": "consulting",
"url": "https://feross.org/support"
}
],
"license": "MIT"
},
"node_modules/safer-buffer": {
"version": "2.1.2",
"resolved": "https://registry.npmjs.org/safer-buffer/-/safer-buffer-2.1.2.tgz",
"integrity": "sha512-YZo3K82SD7Riyi0E1EQPojLz7kpepnSQI9IyPbHHg1XXXevb5dJI7tpyN2ADxGcQbHG7vcyRHk0cbwqcQriUtg==",
"license": "MIT"
},
"node_modules/send": {
"version": "0.19.0",
"resolved": "https://registry.npmjs.org/send/-/send-0.19.0.tgz",
"integrity": "sha512-dW41u5VfLXu8SJh5bwRmyYUbAoSB3c9uQh6L8h/KtsFREPWpbX1lrljJo186Jc4nmci/sGUZ9a0a0J2zgfq2hw==",
"license": "MIT",
"dependencies": {
"debug": "2.6.9",
"depd": "2.0.0",
"destroy": "1.2.0",
"encodeurl": "~1.0.2",
"escape-html": "~1.0.3",
"etag": "~1.8.1",
"fresh": "0.5.2",
"http-errors": "2.0.0",
"mime": "1.6.0",
"ms": "2.1.3",
"on-finished": "2.4.1",
"range-parser": "~1.2.1",
"statuses": "2.0.1"
},
"engines": {
"node": ">= 0.8.0"
}
},
"node_modules/send/node_modules/encodeurl": {
"version": "1.0.2",
"resolved": "https://registry.npmjs.org/encodeurl/-/encodeurl-1.0.2.tgz",
"integrity": "sha512-TPJXq8JqFaVYm2CWmPvnP2Iyo4ZSM7/QKcSmuMLDObfpH5fi7RUGmd/rTDf+rut/saiDiQEeVTNgAmJEdAOx0w==",
"license": "MIT",
"engines": {
"node": ">= 0.8"
}
},
"node_modules/send/node_modules/ms": {
"version": "2.1.3",
"resolved": "https://registry.npmjs.org/ms/-/ms-2.1.3.tgz",
"integrity": "sha512-6FlzubTLZG3J2a/NVCAleEhjzq5oxgHyaCU9yYXvcLsvoVaHJq/s5xXI6/XXP6tz7R9xAOtHnSO/tXtF3WRTlA==",
"license": "MIT"
},
"node_modules/serve-static": {
"version": "1.16.2",
"resolved": "https://registry.npmjs.org/serve-static/-/serve-static-1.16.2.tgz",
"integrity": "sha512-VqpjJZKadQB/PEbEwvFdO43Ax5dFBZ2UECszz8bQ7pi7wt//PWe1P6MN7eCnjsatYtBT6EuiClbjSWP2WrIoTw==",
"license": "MIT",
"dependencies": {
"encodeurl": "~2.0.0",
"escape-html": "~1.0.3",
"parseurl": "~1.3.3",
"send": "0.19.0"
},
"engines": {
"node": ">= 0.8.0"
}
},
"node_modules/setprototypeof": {
"version": "1.2.0",
"resolved": "https://registry.npmjs.org/setprototypeof/-/setprototypeof-1.2.0.tgz",
"integrity": "sha512-E5LDX7Wrp85Kil5bhZv46j8jOeboKq5JMmYM3gVGdGH8xFpPWXUMsNrlODCrkoxMEeNi/XZIwuRvY4XNwYMJpw==",
"license": "ISC"
},
"node_modules/side-channel": {
"version": "1.1.0",
"resolved": "https://registry.npmjs.org/side-channel/-/side-channel-1.1.0.tgz",
"integrity": "sha512-ZX99e6tRweoUXqR+VBrslhda51Nh5MTQwou5tnUDgbtyM0dBgmhEDtWGP/xbKn6hqfPRHujUNwz5fy/wbbhnpw==",
"license": "MIT",
"dependencies": {
"es-errors": "^1.3.0",
"object-inspect": "^1.13.3",
"side-channel-list": "^1.0.0",
"side-channel-map": "^1.0.1",
"side-channel-weakmap": "^1.0.2"
},
"engines": {
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
"node_modules/side-channel-list": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/side-channel-list/-/side-channel-list-1.0.0.tgz",
"integrity": "sha512-FCLHtRD/gnpCiCHEiJLOwdmFP+wzCmDEkc9y7NsYxeF4u7Btsn1ZuwgwJGxImImHicJArLP4R0yX4c2KCrMrTA==",
"license": "MIT",
"dependencies": {
"es-errors": "^1.3.0",
"object-inspect": "^1.13.3"
},
"engines": {
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
"node_modules/side-channel-map": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/side-channel-map/-/side-channel-map-1.0.1.tgz",
"integrity": "sha512-VCjCNfgMsby3tTdo02nbjtM/ewra6jPHmpThenkTYh8pG9ucZ/1P8So4u4FGBek/BjpOVsDCMoLA/iuBKIFXRA==",
"license": "MIT",
"dependencies": {
"call-bound": "^1.0.2",
"es-errors": "^1.3.0",
"get-intrinsic": "^1.2.5",
"object-inspect": "^1.13.3"
},
"engines": {
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
"node_modules/side-channel-weakmap": {
"version": "1.0.2",
"resolved": "https://registry.npmjs.org/side-channel-weakmap/-/side-channel-weakmap-1.0.2.tgz",
"integrity": "sha512-WPS/HvHQTYnHisLo9McqBHOJk2FkHO/tlpvldyrnem4aeQp4hai3gythswg6p01oSoTl58rcpiFAjF2br2Ak2A==",
"license": "MIT",
"dependencies": {
"call-bound": "^1.0.2",
"es-errors": "^1.3.0",
"get-intrinsic": "^1.2.5",
"object-inspect": "^1.13.3",
"side-channel-map": "^1.0.1"
},
"engines": {
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
"node_modules/statuses": {
"version": "2.0.1",
"resolved": "https://registry.npmjs.org/statuses/-/statuses-2.0.1.tgz",
"integrity": "sha512-RwNA9Z/7PrK06rYLIzFMlaF+l73iwpzsqRIFgbMLbTcLD6cOao82TaWefPXQvB2fOC4AjuYSEndS7N/mTCbkdQ==",
"license": "MIT",
"engines": {
"node": ">= 0.8"
}
},
"node_modules/toidentifier": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/toidentifier/-/toidentifier-1.0.1.tgz",
"integrity": "sha512-o5sSPKEkg/DIQNmH43V0/uerLrpzVedkUh8tGNvaeXpfpuwjKenlSox/2O/BTlZUtEe+JG7s5YhEz608PlAHRA==",
"license": "MIT",
"engines": {
"node": ">=0.6"
}
},
"node_modules/type-is": {
"version": "1.6.18",
"resolved": "https://registry.npmjs.org/type-is/-/type-is-1.6.18.tgz",
"integrity": "sha512-TkRKr9sUTxEH8MdfuCSP7VizJyzRNMjj2J2do2Jr3Kym598JVdEksuzPQCnlFPW4ky9Q+iA+ma9BGm06XQBy8g==",
"license": "MIT",
"dependencies": {
"media-typer": "0.3.0",
"mime-types": "~2.1.24"
},
"engines": {
"node": ">= 0.6"
}
},
"node_modules/unpipe": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/unpipe/-/unpipe-1.0.0.tgz",
"integrity": "sha512-pjy2bYhSsufwWlKwPc+l3cN7+wuJlK6uz0YdJEOlQDbl6jo/YlPi4mb8agUkVC8BF7V8NuzeyPNqRksA3hztKQ==",
"license": "MIT",
"engines": {
"node": ">= 0.8"
}
},
"node_modules/utils-merge": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/utils-merge/-/utils-merge-1.0.1.tgz",
"integrity": "sha512-pMZTvIkT1d+TFGvDOqodOclx0QWkkgi6Tdoa8gC8ffGAAqz9pzPTZWAybbsHHoED/ztMtkv/VoYTYyShUn81hA==",
"license": "MIT",
"engines": {
"node": ">= 0.4.0"
}
},
"node_modules/vary": {
"version": "1.1.2",
"resolved": "https://registry.npmjs.org/vary/-/vary-1.1.2.tgz",
"integrity": "sha512-BNGbWLfd0eUPabhkXUVm0j8uuvREyTh5ovRa/dyow/BqAbZJyC+5fU+IzQOzmAKzYqYRAISoRhdQr3eIZ/PXqg==",
"license": "MIT",
"engines": {
"node": ">= 0.8"
}
}
}
}

1
server/package.json Normal file
View File

@ -0,0 +1 @@
{"name":"4nk-website-mailer","private":true,"type":"module","version":"1.0.0","main":"index.js","license":"MIT","dependencies":{"dotenv":"^16.4.5","express":"^4.19.2","helmet":"^7.1.0","nodemailer":"^6.9.14"},"scripts":{"start":"node index.js","dev":"node index.js"}}

9
sitemap.xml Normal file
View File

@ -0,0 +1,9 @@
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="https://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://4nk.network/</loc>
<lastmod>2025-09-25</lastmod>
<changefreq>weekly</changefreq>
<priority>1.0</priority>
</url>
</urlset>

703
styles.css Normal file
View File

@ -0,0 +1,703 @@
/* Reset et base */
* {
margin: 0;
padding: 0;
box-sizing: border-box;
}
html {
scroll-behavior: smooth;
}
body {
font-family: 'Inter', sans-serif;
background-color: #0a0a0a;
color: #ffffff;
line-height: 1.6;
overflow-x: hidden;
}
/* Variables CSS */
:root {
--primary-orange: #FF6B35;
--secondary-orange: #FF8E53;
--accent-orange: #FFA500;
--gold: #FFD700;
--dark-bg: #0a0a0a;
--darker-bg: #050505;
--text-light: #ffffff;
--text-gray: #b0b0b0;
--border-color: #333333;
--glow-intensity: 3px;
}
/* Pattern de fond */
.background-pattern {
position: fixed;
top: 0;
left: 0;
width: 100%;
height: 100%;
background-image:
radial-gradient(circle at 20% 20%, rgba(255, 107, 53, 0.03) 0%, transparent 50%),
radial-gradient(circle at 80% 80%, rgba(255, 165, 0, 0.03) 0%, transparent 50%),
radial-gradient(circle at 40% 60%, rgba(255, 215, 0, 0.02) 0%, transparent 50%);
z-index: -1;
}
/* Header et Navigation */
.header {
position: fixed;
top: 0;
left: 0;
width: 100%;
background: rgba(10, 10, 10, 0.95);
backdrop-filter: blur(10px);
border-bottom: 1px solid var(--border-color);
z-index: 1000;
transition: all 0.3s ease;
}
.nav {
display: flex;
justify-content: space-between;
align-items: center;
padding: 1rem 2rem;
max-width: 1200px;
margin: 0 auto;
}
.nav-logo {
display: flex;
align-items: center;
}
.logo-container {
width: 50px;
height: 50px;
display: flex;
align-items: center;
justify-content: center;
}
.logo-img {
width: 100%;
height: 100%;
object-fit: contain;
animation: logoGlow 3s ease-in-out infinite alternate;
filter: drop-shadow(0 0 10px var(--primary-orange));
}
@keyframes logoGlow {
0% { filter: drop-shadow(0 0 5px var(--primary-orange)); }
100% { filter: drop-shadow(0 0 15px var(--primary-orange)) drop-shadow(0 0 25px var(--accent-orange)); }
}
.nav-menu {
display: flex;
gap: 2rem;
}
.nav-link {
color: var(--text-light);
text-decoration: none;
font-weight: 500;
transition: all 0.3s ease;
position: relative;
}
.nav-link:hover {
color: var(--primary-orange);
text-shadow: 0 0 10px var(--primary-orange);
}
.nav-link::after {
content: '';
position: absolute;
bottom: -5px;
left: 0;
width: 0;
height: 2px;
background: var(--primary-orange);
transition: width 0.3s ease;
}
.nav-link:hover::after {
width: 100%;
}
/* Hero Section */
.hero {
min-height: 100vh;
display: flex;
align-items: center;
justify-content: center;
padding: 2rem;
position: relative;
}
.hero-content {
display: grid;
grid-template-columns: 1fr 1fr;
gap: 4rem;
align-items: center;
max-width: 1200px;
width: 100%;
}
.hero-logo {
display: flex;
justify-content: center;
align-items: center;
}
.hero-logo-img {
width: 400px;
height: 400px;
object-fit: contain;
animation: heroLogoFloat 6s ease-in-out infinite;
filter: drop-shadow(0 0 20px var(--primary-orange));
}
@keyframes heroLogoFloat {
0%, 100% { transform: translateY(0px) rotate(0deg); }
50% { transform: translateY(-20px) rotate(2deg); }
}
.hero-text {
display: flex;
flex-direction: column;
gap: 1.5rem;
}
.hero-title {
display: flex;
flex-direction: column;
gap: 0.5rem;
}
.brand-name {
font-size: 4rem;
font-weight: 700;
background: linear-gradient(135deg, var(--primary-orange), var(--accent-orange), var(--gold));
-webkit-background-clip: text;
-webkit-text-fill-color: transparent;
background-clip: text;
text-shadow: 0 0 30px rgba(255, 107, 53, 0.5);
animation: brandGlow 2s ease-in-out infinite alternate;
}
@keyframes brandGlow {
0% { text-shadow: 0 0 30px rgba(255, 107, 53, 0.5); }
100% { text-shadow: 0 0 50px rgba(255, 107, 53, 0.8), 0 0 70px rgba(255, 165, 0, 0.3); }
}
.brand-subtitle {
font-size: 2rem;
font-weight: 400;
color: var(--text-light);
opacity: 0.9;
}
.brand-tagline {
font-size: 1.5rem;
font-weight: 300;
color: var(--text-gray);
font-style: italic;
}
.hero-description {
font-size: 1.2rem;
color: var(--text-gray);
line-height: 1.8;
max-width: 500px;
}
.hero-buttons {
display: flex;
gap: 1rem;
margin-top: 1rem;
}
.btn {
padding: 1rem 2rem;
border: none;
border-radius: 8px;
font-size: 1rem;
font-weight: 600;
cursor: pointer;
transition: all 0.3s ease;
text-decoration: none;
display: inline-block;
text-align: center;
}
.btn-primary {
background: linear-gradient(135deg, var(--primary-orange), var(--secondary-orange));
color: white;
box-shadow: 0 4px 15px rgba(255, 107, 53, 0.3);
}
.btn-primary:hover {
transform: translateY(-2px);
box-shadow: 0 8px 25px rgba(255, 107, 53, 0.5);
text-shadow: 0 0 10px rgba(255, 255, 255, 0.5);
}
.btn-secondary {
background: transparent;
color: var(--text-light);
border: 2px solid var(--primary-orange);
}
.btn-secondary:hover {
background: var(--primary-orange);
color: white;
transform: translateY(-2px);
box-shadow: 0 8px 25px rgba(255, 107, 53, 0.3);
}
/* Container */
.container {
max-width: 1200px;
margin: 0 auto;
padding: 0 2rem;
}
/* Sections */
.section-title {
font-size: 3rem;
font-weight: 700;
text-align: center;
margin-bottom: 3rem;
background: linear-gradient(135deg, var(--primary-orange), var(--accent-orange));
-webkit-background-clip: text;
-webkit-text-fill-color: transparent;
background-clip: text;
}
/* Services Section */
.services {
padding: 6rem 0;
background: linear-gradient(180deg, var(--dark-bg) 0%, var(--darker-bg) 100%);
}
.services-grid {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(300px, 1fr));
gap: 2rem;
}
.service-card {
background: rgba(255, 255, 255, 0.02);
border: 1px solid var(--border-color);
border-radius: 16px;
padding: 2rem;
text-align: center;
transition: all 0.3s ease;
backdrop-filter: blur(10px);
}
.service-card:hover {
transform: translateY(-10px);
border-color: var(--primary-orange);
box-shadow: 0 20px 40px rgba(255, 107, 53, 0.1);
}
.service-icon {
width: 80px;
height: 80px;
margin: 0 auto 1.5rem;
display: flex;
align-items: center;
justify-content: center;
}
.service-svg {
width: 100%;
height: 100%;
animation: serviceIconPulse 3s ease-in-out infinite;
}
@keyframes serviceIconPulse {
0%, 100% { transform: scale(1); }
50% { transform: scale(1.1); }
}
.service-card h3 {
font-size: 1.5rem;
font-weight: 600;
margin-bottom: 1rem;
color: var(--text-light);
}
.service-card p {
color: var(--text-gray);
line-height: 1.6;
}
/* About Section */
.about {
padding: 6rem 0;
}
.about-content {
display: grid;
grid-template-columns: 1fr 1fr;
gap: 4rem;
align-items: center;
}
.about-text h2 {
font-size: 2.5rem;
font-weight: 700;
margin-bottom: 2rem;
background: linear-gradient(135deg, var(--primary-orange), var(--accent-orange));
-webkit-background-clip: text;
-webkit-text-fill-color: transparent;
background-clip: text;
}
.about-text p {
font-size: 1.1rem;
color: var(--text-gray);
line-height: 1.8;
margin-bottom: 1.5rem;
}
.about-visual {
display: flex;
justify-content: center;
align-items: center;
}
.logo-showcase {
width: 300px;
height: 300px;
display: flex;
align-items: center;
justify-content: center;
}
.showcase-logo-img {
width: 100%;
height: 100%;
object-fit: contain;
animation: showcaseRotate 20s linear infinite;
filter: drop-shadow(0 0 15px var(--primary-orange));
}
@keyframes showcaseRotate {
0% { transform: rotate(0deg); }
100% { transform: rotate(360deg); }
}
/* Contact Section */
.contact {
padding: 6rem 0;
background: linear-gradient(180deg, var(--darker-bg) 0%, var(--dark-bg) 100%);
}
.contact-content {
display: grid;
grid-template-columns: 1fr 1fr;
gap: 4rem;
align-items: start;
}
.contact-info h3 {
font-size: 2rem;
font-weight: 600;
margin-bottom: 1.5rem;
color: var(--text-light);
}
.contact-info p {
font-size: 1.1rem;
color: var(--text-gray);
line-height: 1.8;
}
.contact-form {
background: rgba(255, 255, 255, 0.02);
border: 1px solid var(--border-color);
border-radius: 16px;
padding: 2rem;
backdrop-filter: blur(10px);
}
.form-group {
margin-bottom: 1.5rem;
}
.form-group input,
.form-group textarea {
width: 100%;
padding: 1rem;
background: rgba(255, 255, 255, 0.05);
border: 1px solid var(--border-color);
border-radius: 8px;
color: var(--text-light);
font-size: 1rem;
transition: all 0.3s ease;
}
.form-group input:focus,
.form-group textarea:focus {
outline: none;
border-color: var(--primary-orange);
box-shadow: 0 0 20px rgba(255, 107, 53, 0.2);
}
.form-group input::placeholder,
.form-group textarea::placeholder {
color: var(--text-gray);
}
/* Footer */
.footer {
background: var(--darker-bg);
border-top: 1px solid var(--border-color);
padding: 3rem 0 1rem;
}
.footer-content {
display: flex;
justify-content: space-between;
align-items: center;
margin-bottom: 2rem;
}
.footer-logo {
display: flex;
align-items: center;
gap: 1rem;
}
.footer-logo-container {
width: 40px;
height: 40px;
}
.footer-logo-img {
width: 100%;
height: 100%;
object-fit: contain;
animation: footerLogoGlow 4s ease-in-out infinite alternate;
filter: drop-shadow(0 0 8px var(--primary-orange));
}
@keyframes footerLogoGlow {
0% { filter: drop-shadow(0 0 3px var(--primary-orange)); }
100% { filter: drop-shadow(0 0 8px var(--primary-orange)) drop-shadow(0 0 15px var(--accent-orange)); }
}
.footer-text {
display: flex;
flex-direction: column;
}
.footer-text .brand-name {
font-size: 1.2rem;
font-weight: 700;
color: var(--primary-orange);
}
.footer-text .brand-subtitle {
font-size: 0.9rem;
color: var(--text-gray);
}
.footer-links {
display: flex;
gap: 2rem;
}
.footer-links a {
color: var(--text-gray);
text-decoration: none;
transition: color 0.3s ease;
}
.footer-links a:hover {
color: var(--primary-orange);
}
.footer-bottom {
text-align: center;
padding-top: 2rem;
border-top: 1px solid var(--border-color);
color: var(--text-gray);
}
/* Responsive Design */
@media (max-width: 768px) {
.nav {
padding: 1rem;
flex-direction: column;
gap: 1rem;
}
.nav-menu {
gap: 1rem;
}
.hero-content {
grid-template-columns: 1fr;
gap: 2rem;
text-align: center;
}
.hero-logo-img {
width: 250px;
height: 250px;
}
.brand-name {
font-size: 2.5rem;
}
.brand-subtitle {
font-size: 1.5rem;
}
.brand-tagline {
font-size: 1.2rem;
}
.hero-buttons {
justify-content: center;
flex-wrap: wrap;
}
.about-content {
grid-template-columns: 1fr;
gap: 2rem;
text-align: center;
}
.contact-content {
grid-template-columns: 1fr;
gap: 2rem;
}
.footer-content {
flex-direction: column;
gap: 2rem;
text-align: center;
}
.footer-links {
flex-wrap: wrap;
justify-content: center;
}
.services-grid {
grid-template-columns: 1fr;
}
.section-title {
font-size: 2rem;
}
}
@media (max-width: 480px) {
.container {
padding: 0 1rem;
}
.hero {
padding: 1rem;
}
.hero-logo-img {
width: 200px;
height: 200px;
}
.brand-name {
font-size: 2rem;
}
.btn {
padding: 0.8rem 1.5rem;
font-size: 0.9rem;
}
.service-card,
.contact-form {
padding: 1.5rem;
}
}
/* Animations d'apparition */
@keyframes fadeInUp {
from {
opacity: 0;
transform: translateY(30px);
}
to {
opacity: 1;
transform: translateY(0);
}
}
.fade-in-up {
animation: fadeInUp 0.8s ease-out forwards;
}
/* Scrollbar personnalisée */
::-webkit-scrollbar {
width: 8px;
}
::-webkit-scrollbar-track {
background: var(--darker-bg);
}
::-webkit-scrollbar-thumb {
background: var(--primary-orange);
border-radius: 4px;
}
::-webkit-scrollbar-thumb:hover {
background: var(--secondary-orange);
}
/* Effets de particules (optionnel) */
.particles {
position: fixed;
top: 0;
left: 0;
width: 100%;
height: 100%;
pointer-events: none;
z-index: -1;
}
.particle {
position: absolute;
width: 2px;
height: 2px;
background: var(--primary-orange);
border-radius: 50%;
opacity: 0.3;
animation: particleFloat 10s linear infinite;
}
@keyframes particleFloat {
0% {
transform: translateY(100vh) rotate(0deg);
opacity: 0;
}
10% {
opacity: 0.3;
}
90% {
opacity: 0.3;
}
100% {
transform: translateY(-100px) rotate(360deg);
opacity: 0;
}
}