Nacho Coll

Háttér#

2007 óta építek az AWS-en — még az S3 és az EC2 legkorábbi napjaiból, jóval azelőtt, hogy a „felhő” lett volna az alapértelmezett válasz. AWS Enterprise Architectként production-szintű rendszereket terveztem olyan kiemelt ügyfeleknek, mint a LEGO, a Nordea, a Vueling, és mások a Fortune-500-as vállalati szegmensből. Ekkor alakultak ki azok az üzemeltetési ösztönök, amelyek ma mindent meghatároznak, amit csinálok: költségfegyelem, több régiós megbízhatóság, és az, hogy a megfigyelhetőséget (observability) az első naptól komolyan vesszük, nem utólag ragasztjuk hozzá.

2019 óta párhuzamosan két dologra összpontosítok: a blokklánc- és decentralizált tárolási termékek infrastruktúrájára, valamint a szoftverfejlesztés AI-oldalára — mindkettőre ugyanazt az enterprise-architektúrai fegyelmet alkalmazva. Ez az az alap, amelyen ma a Blockchain Web Services (BWS) működik: egy AI-natív megoldásgyár, egyetlen működési jelmondattal: Demand Becomes Product. A validált piaci keresletet production-ready szoftverré alakítjuk — emberek tervezik, AI gyorsítja, és végig felelősséggel tartozunk érte. Minden kódsornak, amely a BWS-től származik, van egy néven nevezett felelős mérnöke.

A BWS ugyanebből a fegyelemből több éles terméket is szállít. Az IPFS.NINJA ezek egyike; a többiek közé tartozik:

• OpenAgile.AI — mérnöki fegyelem az AI-asszisztált fejlesztéshez.
• Zellbox — CRM időpont-alapú kkv-k számára: ügyfelek, foglalások és WhatsApp emlékeztetők egyetlen beérkezett üzenetek mappában.
• WallaWhats — valós idejű WhatsApp értesítések, amikor a kedvenc X/Twitter fiókjaid posztolnak.
• Badges.ninja — blokkláncon hitelesített digitális jelvények vizuális tervezővel és REST API-val.
• IPFS.NINJA — a legegyszerűbb IPFS pinning és feltöltési API, dedikált gateway-ekkel és bőkezű ingyenes csomaggal.
• Blockchain Database — egyetlen API a blokklánc adatrétegként történő használatához.
• NFT.zK — egyszerű API NFT-k létrehozásához Web3-szakértelem nélkül.
• Telegram XBot — egy Telegram bot, amely nyomon követi az X-aktivitást, és kiemeli a legaktívabb közösségi hozzájárulókat.

A BWS 2025 közepén állt át az AI-natív működésre. Az AI nem egy funkció volt, amit hozzáadtunk — hanem egy vállalat, amivé váltunk. A mérnöki mérce nem változott: az változott, hogy mennyi kutatást, vázépítést és tesztelést tud ma már az AI elvégezni, így egy kis csapat is ugyanolyan formájú production szoftvert tud szállítani, amihez korábban egy sokkal nagyobb csapatra lett volna szükség.

Mivel foglalkozunk nap mint nap#

A mindennapjaim a teljes BWS megoldás-portfóliót lefedik — irányítom a termékek roadmapjeit, átnézem a technikai terveket a csapattal, finomítom az AI-asszisztált szállítási munkafolyamatot, amely mindegyiket életre kelti, és biztosítom, hogy a mérnöki fegyelem egységes maradjon az egyik terméktől a másikig. Minden terméknek megvan a saját heti ritmusa; az én feladatom az összekötő szövet közöttük.

Az IPFS.NINJA esetében konkrétan azt szeretnénk elérni, hogy a szolgáltatás szűk fókuszú és vertikális maradjon: egy REST API a fájlok feltöltéséhez (JSON, képek, PDF-ek, tetszőleges bináris fájlok), pin-kezelés, dedikált, világszerte elérhető gateway-ek, felhasználónkénti analitika, aláírt feltöltési tokenek, és egy Node/Python SDK — mindezt egy ténylegesen használható ingyenes csomagon, a fizetős csomagok pedig 5 $/hónaptól indulnak a piacon megszokott 20 $ helyett. Olyan területek, amelyeken a csapat mostanában aktívan dolgozott:

• Feltöltési útvonal megbízhatósága — a feltöltési API gyorsan tartása tartós terhelés alatt: kérés-összevonás (request coalescing), többrészes feltöltési útvonalak nagy fájlokhoz, és védekező újrapróbálkozások, hogy egy átmeneti hiba az edge-ünk és az IPFS cluster között soha ne jelenjen meg elveszett fájlként a hívó felé.
• Pin tartósság — node-ok közötti replikáció, egyeztetés a pin nyilvántartásunk és az alapul szolgáló cluster állapota között, valamint háttérben futó ellenőrzések, amelyek a lemezen bekövetkező eltéréseket (drift) még azelőtt elkapják, hogy törött CID-dé válnának.
• Dedikált gateway teljesítménye — minden fizetős csomag saját gateway hostnevet kap. A p95 latencia alacsonyan tartása régiók között, a magas cache-találati arány, és a népszerű tartalom előmelegítése az edge-re folyamatos finomhangolási feladat.
• Funkciópaletta — a mag upload/pin API-n túl a platform mappafeltöltést, CAR-importot más szolgáltatóktól való tömeges migrációhoz, S3-kompatibilis végpontokat, IPNS rekordkezelést, kép-optimalizálást a gateway-en, aláírt feltöltési tokeneket a böngészőoldali feltöltésekhez, egy MCP szervert, és CID-enkénti analitikát is kínál. Minden képesség önálló, elsőosztályú végpont, nem mellékprojekt.
• Költségmérnökség — az, hogy az IPFS.NINJA 5 dollártól indulhat, míg a versenytársak 20 dollártól, nem egy veszteséges csali trükk. Ez folyamatos munka a saját infrastruktúránk gazdaságosságán, hogy az egységköltségek ténylegesen indokolják a kiskereskedelmi árat.
• Ügyféltámogatás — minden ticketet közvetlenül mi kezelünk. Ha írsz a hello@ipfs.ninja címre, egy valódi embertől kapsz választ — és a legtöbb napon ez az ember én vagyok.

Cikkek, amelyeket írtam vagy átnéztem#

Az oldalon található bejegyzések többségét az én nevem alatt publikáljuk. Néhányat egy AI-asszisztens vázol fel (lásd a szerkesztési folyamatot a teljes munkafolyamatért), amelyeket én nézek át publikálás előtt; másokat elejétől a végéig a csapat ír. Mindkét esetben minden kódpélda ellenőrzésen esik át az éles API-val szemben, mielőtt publikáljuk.

Néhány jellemző bejegyzés:

• IPFS CID-ek 2026-ban: Hogyan működik a tartalom-alapú címzés — gyakorlati magyarázat a tartalom-alapú címzés alapjairól.
• Pinatáról IPFS.NINJA-ra: Lépésről lépésre migrációs útmutató (2026) — üzemeltetési runbook, amelyet kézzel írtunk a valós migrációk során látott mintázatok alapján.
• 7 IPFS pinning szolgáltatás összehasonlítása 2026-ban — őszinte összehasonlítás; az árak ellenőrizve az egyes szolgáltatók nyilvános dokumentációjával szemben.