Alternative Filebase : épinglage IPFS simple sans S3

Comparaison rapide : Filebase vs IPFS Ninja

Conclusion : si vous configurez déjà des clients AWS SDK de toute façon, Filebase s’intègre naturellement. Si vous voulez envoyer un fichier vers IPFS en une seule commande curl, IPFS Ninja gagne en simplicité.

Uploader un fichier sur IPFS en 30 secondes

Voici le chemin d’upload sur IPFS Ninja. Pas de SDK, pas de XML, pas d’étape de création de bucket :

curl -X POST https://api.ipfs.ninja/upload/new \
  -H "X-Api-Key: bws_a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "Hello from IPFS Ninja!",
    "description": "My first file"
  }'

Réponse :

{
  "cid": "bafkreib4mrow...",
  "sizeMB": 0.00002,
  "uris": {
    "ipfs": "ipfs://bafkreib4mrow...",
    "url": "https://ipfs.ninja/ipfs/bafkreib4mrow..."
  }
}

C’est tout. Ce CID est épinglé, accessible sur IPFS et disponible via la gateway publique immédiatement.

Voici maintenant le flux équivalent sur Filebase :

1. Créer un compte et un bucket dans la console Filebase.
2. Générer une paire clé d’accès + clé secrète.
3. Configurer un client S3 avec l’endpoint https://s3.filebase.com, la région us-east-1 et vos identifiants.
4. Appeler putObject avec le contenu de votre fichier.
5. Interroger les métadonnées de l’objet pour récupérer le CID IPFS (il apparaît en tant qu’en-tête x-amz-meta-cid une fois que Filebase l’a épinglé).

Ce n’est pas mauvais en soi — c’est simplement plus de pièces mobiles que la plupart des projets REST-natifs n’en ont besoin.

Pourquoi les développeurs buttent sur la friction S3 avec Filebase

La compatibilité S3 de Filebase est réellement utile quand :

• Vous avez une infrastructure existante qui parle S3 (fonctions Lambda, modules Terraform, agents de sauvegarde).
• Vous stockez de gros fichiers et souhaitez la sémantique d’upload multipart que vous connaissez déjà.
• Votre équipe maîtrise AWS et le SDK S3 est déjà une dépendance.

Mais beaucoup de développeurs qui intègrent IPFS dans une app web, une dApp ou un pipeline CI ne viennent pas de cet univers. Ils se heurtent à :

Des réponses d’erreur en XML. S3 renvoie du XML. Votre appel JavaScript fetch reçoit <?xml version="1.0" ...><Error><Code>InvalidAccessKeyId</Code> et vous devez ajouter un parseur XML pour déboguer.

La gestion des identifiants. L’auth style S3 (clé d’accès + secret + signature de requête HMAC-SHA256) n’est pas triviale à implémenter from scratch dans un navigateur ou une edge function. Les URLs pré-signées aident, mais les générer côté serveur ajoute un aller-retour.

La récupération du CID en tant qu’afterthought. Le CID est une métadonnée sur l’objet S3, pas la réponse principale. Vous devez soit parser les en-têtes de réponse, soit appeler un endpoint de métadonnées séparé.

Pas de tokens d’upload signés natifs. Si vous voulez que les utilisateurs uploadent directement depuis un navigateur sans exposer les identifiants serveur, Filebase vous oblige à construire vous-même un endpoint de génération d’URL pré-signée.

Les signed upload tokens d’IPFS Ninja gèrent ce pattern nativement : générez un token à durée limitée côté serveur une seule fois, intégrez-le dans votre frontend, et laissez les utilisateurs faire des POST directement vers api.ipfs.ninja jusqu’à l’expiration du token ou sa révocation.

Comparaison des tarifs

Pour les projets petits à moyens, le passage du gratuit au premier plan payant représente $5/mo sur IPFS Ninja contre environ $20/mo sur Filebase. Si vous construisez un side project ou un MVP de startup, cette différence compte.

Comparaison des fonctionnalités de gateway

Les deux services proposent des gateways IPFS dédiées (sous-domaines qui servent votre contenu épinglé en HTTPS). Là où ils diffèrent :

Filebase vous offre une gateway dédiée sur les plans payants. Elle sert le contenu de votre bucket et s’intègre à leur espace de noms S3.

Les gateways IPFS Ninja à https://{slug}.gw.ipfs.ninja supportent :

• Modes d’accès : restreint (token requis), ouvert (public) ou dossier (listing de répertoire).
• Liste blanche d’IPs : verrouillez une gateway à des IPs serveur connues.
• Restrictions d’origine : limitez à des origines HTTP spécifiques, utile pour les scénarios CORS navigateur uniquement.
• Optimisation d’images : l’endpoint /image/{cid} vous permet de redimensionner, recadrer et convertir le format à la volée — pas besoin d’un CDN d’images séparé.

Si votre cas d’usage consiste à servir des assets vers un frontend web, la restriction d’origine CORS et les endpoints d’optimisation d’images intégrés vous évitent une intégration de service supplémentaire.

Épingler un CID existant

Vous avez déjà un CID provenant d’un autre nœud ou service ? Les deux plateformes vous permettent de l’épingler sans ré-uploader. Sur IPFS Ninja :

curl -X POST https://api.ipfs.ninja/pin \
  -H "X-Api-Key: bws_a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4" \
  -H "Content-Type: application/json" \
  -d '{
    "cid": "bafkreib4mrow...",
    "description": "Pinned from external source"
  }'

Sur Filebase, vous épinglez via un PUT vers votre bucket avec le CID en en-tête de métadonnée personnalisé, puis Filebase le récupère et l’épingle. Le workflow CID-first d’IPFS Ninja est plus direct si vous venez d’un état d’esprit IPFS-natif plutôt que S3-natif.

Consultez what is IPFS pinning pour une explication approfondie de l’importance de l’épinglage et de ce qui se passe quand le contenu n’est pas épinglé.

Uploads côté client sans exposer les identifiants

C’est une question d’architecture courante : comment permettre à un navigateur d’uploader vers IPFS sans embarquer votre clé API côté client ?

Approche Filebase : générez une URL S3 PUT pré-signée sur votre serveur, retournez-la au client, le client fait un PUT directement. Pattern S3 pre-sign standard, ça fonctionne bien, mais vous devez implémenter l’endpoint de signature côté serveur.

Approche IPFS Ninja : appelez /token/upload/new (ou générez via le dashboard) pour créer un token d’upload signé. Intégrez ce token dans votre frontend. Le client poste vers api.ipfs.ninja en utilisant Authorization: Signed {token}. Le token peut être limité à expirer après un délai défini ou révoqué instantanément depuis le dashboard.

// Frontend code — token was fetched from your server
const token = 'your-signed-upload-token';

const response = await fetch('https://api.ipfs.ninja/upload/new', {
  method: 'POST',
  headers: {
    'Authorization': `Signed ${token}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    content: btoa(fileContentAsArrayBuffer), // base64 for binary
    description: 'User uploaded file',
  }),
});

const { cid, uris } = await response.json();
console.log('Pinned at:', uris.url);

Pour un guide plus détaillé des patterns d’upload, consultez how to upload files to IPFS.

Quand choisir quand même Filebase

Cet article se veut honnête, pas un pitch à sens unique.

Choisissez Filebase si :

• Votre codebase utilise déjà AWS SDK v3 ou Boto3 et vous voulez zéro dépendance supplémentaire.
• Vous migrez de S3 vers IPFS et souhaitez simplement changer d’endpoint plutôt que réécrire la logique d’upload.
• Vous stockez de très gros fichiers et avez besoin d’un upload multipart fiable avec la sémantique S3 (bien qu’IPFS Ninja dispose aussi d’une large upload API).
• Votre équipe a une expertise AWS approfondie et trouve l’auth S3 plus familière que les en-têtes REST.

Choisissez IPFS Ninja si :

• Vous voulez un seul POST /upload/new pour obtenir un CID en retour sans étapes intermédiaires.
• Vous construisez une app frontend-first et avez besoin de tokens d’upload sécurisés côté client sans bâtir une infrastructure de pre-sign.
• Vous voulez l’optimisation d’images et des gateways à accès contrôlé sans ajouter un autre service.
• Vous êtes sensible au prix et le point d’entrée à $5/mo compte pour votre stade de projet.

Résumé

Filebase est un produit solide pour les équipes qui vivent déjà dans l’écosystème AWS. Sa compatibilité S3 est un vrai avantage dans ce contexte. Mais pour les développeurs qui veulent simplement épingler des fichiers sur IPFS via une REST API propre — et récupérer un CID immédiatement — la couche S3 ajoute de la cérémonie sans bénéfice.

IPFS Ninja maintient la surface d’API minimale : upload, pin, fetch. La gateway, l’optimisation d’images et les tokens d’upload sont disponibles quand vous en avez besoin, sans être requis d’emblée.

Pour une vue d’ensemble de la façon dont IPFS Ninja se compare aux autres services, consultez best IPFS pinning services.

Prêt à commencer à épingler ? Créez un compte gratuit — 500 fichiers, 1 Go de stockage, sans carte bancaire requise.

À propos de cet article : Cet article a été rédigé par un assistant IA en utilisant le workflow de génération de contenu d’IPFS.NINJA, puis relu et approuvé par Nacho Coll. Tous les exemples de code ont été vérifiés sur l’API IPFS.NINJA en production. Si vous repérez une inexactitude, veuillez ouvrir une issue sur https://github.com/ipfs-ninja/feedback. Lisez-en plus sur how we use AI in our content et découvrez the people behind IPFS.NINJA.