k0nsult.cloud / ai-truth / ipIII / connectors / marketplace

Connector Marketplace / Registry SPEC / ROADMAP

Ta strona to szkielet specyfikacji (SPEC), nie działający marketplace. Dziś ipIII ma LIVE parsery importu plikowego (Burp/ZAP/Nessus/Qualys/generic CSV/JSON) wbudowane w rdzeń. To, czego tu nie ma jeszcze naprawdę, to rejestr publiczny konektorów społecznościowych — model publikacji, przegląd, weryfikacja i dystrybucja paczek. Poniżej dokładnie co jest LIVE, a co dopiero projektem.

Orchestrator Connectors Connector SDK Marketplace Normalize Status matrix Znane ograniczenia ← ipIII hub

Uczciwie na wstępie. „Marketplace" to dziś nazwa specyfikacji, nie uruchomiona usługa. Nie ma publicznego formularza publikacji konektorów, nie ma procesu code-review społeczności, nie ma podpisanych paczek do pobrania. To, co realnie działa i ma kod+test+endpoint, to import parserów opisany na /connectors — oznaczony tam LIVE v1. Cała treść poniżej dotycząca rejestru/publikacji/weryfikacji jest ROADMAP, o ile nie zaznaczono inaczej.

Dziś: 5 konektorów LIVE w rdzeniu. SPEC: rejestr otwarty na community.

Obecny model importu jest scentralizowany — parsery żyją w kodzie orkiestratora i są dodawane przez zespół K0NSULT (patrz Connector SDK dla formatu paczki). Marketplace ma docelowo umożliwić stronie trzeciej (partner, integrator, klient) publikację własnego konektora do rejestru, z procesem weryfikacji przed udostępnieniem innym. Dziś ten proces nie istnieje — jest to świadomie nazwana luka (gap), nie ukryta funkcja.

OŚ DOJRZAŁOŚCI: parsery wbudowane (dziś, LIVE)→SDK + format paczki (spec)→rejestr + metadane→proces weryfikacji→community marketplace

Co jest LIVE dzisiaj (dowód)

To nie jest część marketplace — to istniejący import plikowy, na którym marketplace miałby bazować. Dowód: kod + endpoint + test integracyjny.

Konektor	Typ	Format	Endpoint	Status
Burp Suite	DAST	XML	`/imports/burp`	LIVE v1
OWASP ZAP	DAST	JSON / XML	`/imports/zap`	LIVE v1
Nessus / Tenable	Vuln scan	CSV	`/imports/nessus`	LIVE v1
Qualys VMDR	Vuln scan	CSV / XML	`/imports/qualys`	LIVE v1 (pull API = ROADMAP)
Generic CSV / JSON	uniwersalny	CSV, JSON	`/imports/csv`, `/imports/generic`	LIVE v1

Pełny opis i historia weryfikacji: /connectors · format paczki konektora (SDK): /connector-sdk.

SPEC: model rejestru (ROADMAP)

Poniższe pola i procesy nie są wdrożone. To projekt struktury danych rejestru — punkt wyjścia do dyskusji, nie obietnica terminu.

Metadane konektora ROADMAP

Nazwa, wersja, autor/organizacja, licencja, typ źródła (DAST/SAST/SIEM/CTI/ticketing), format wejścia, checksum paczki.

Manifest zgodności ROADMAP

Deklaracja pól mapowanych na schemat normalizacji ipIII (Truth Engine), wersja schematu, zakres danych osobowych przetwarzanych przez parser.

Historia weryfikacji ROADMAP

Kto i kiedy przeglądał kod parsera, wynik testu na próbce syntetycznej, ewentualne zastrzeżenia bezpieczeństwa.

Kanał dystrybucji ROADMAP

Pobranie paczki z podpisanym checksumem; instalacja lokalna w instancji klienta — bez automatycznego wykonania kodu bez przeglądu.

SPEC: proces publikacji (ROADMAP, projekt)

Szkic kroków, jakie miałby przejść konektor od zgłoszenia do wpisu w rejestrze. Żaden z kroków nie jest dziś zautomatyzowany — dziś jedyną drogą dodania konektora jest kontakt z zespołem K0NSULT i wdrożenie w rdzeniu (patrz Connector SDK).

1. Zgłoszenie. Autor przesyła paczkę + manifest zgodności + próbkę danych syntetycznych do testu. ROADMAP

2. Przegląd statyczny. Skan kodu parsera pod kątem oczywistych ryzyk (brak wykonania kodu dostawcy, tylko deklaratywny mapping pól). ROADMAP

3. Test na próbce syntetycznej. Weryfikacja, że parser poprawnie mapuje pola na schemat normalizacji, bez uruchamiania w środowisku klienta. ROADMAP

4. Wpis do rejestru + znacznik wersji. Publikacja metadanych, checksum paczki, adnotacja "community" vs "K0NSULT core". ROADMAP

5. Instalacja opt-in. Klient sam decyduje o instalacji konektora z rejestru — brak automatycznego wgrywania bez zgody operatora instancji. ROADMAP

Czego marketplace NIE robi (granice z założenia)

Nie ma automatycznego wykonania kodu strony trzeciej. Nawet w docelowym modelu, paczka konektora ma być deklaratywnym mapowaniem pól, przeglądanym przed publikacją — nie dowolnym skryptem wykonywanym bez kontroli. To wymóg bezpieczeństwa, nie funkcja do dodania później.

Rejestr publiczny ≠ ocena jakości. Wpis w rejestrze (gdy powstanie) będzie oznaczał, że paczka przeszła przegląd zgodny z ówczesnym procesem — nie jest to certyfikat bezpieczeństwa ani rekomendacja dla każdego środowiska. Decyzję o instalacji podejmuje operator instancji klienta.

„100%" u nas znaczy pokrycie dowodowe, nie kompletność marketplace. Skoro nie mamy dziś kodu, endpointu i testu dla rejestru publikacji — cała ta strona jest oznaczona ROADMAP, zgodnie z doktryną claim ≤ proof. Jedyne LIVE elementy to istniejące parsery importu, wymienione wyżej.

Granica etyczna i prawna. ipIII jest narzędziem obrony i zgodności (GRC/blue). Ewentualne konektory społecznościowe, gdy powstaną, będą podlegać tym samym zasadom: brak nieautoryzowanych skanów, brak exploitacji, dane wejściowe wyłącznie w granicach zgody operatora danych. To wsparcie decyzji (decision-support), nie porada prawna dotycząca zgodności paczek stron trzecich.

Powiązane: format i wymagania paczki konektora → /connector-sdk · pełna lista konektorów LIVE i ROADMAP → /connectors · macierz statusów wszystkich elementów → /status-matrix.

SPEC: rozszerzona architektura API Marketplace ROADMAP

Poniżej szkielet techniczny (projekt architektoniczny), na jaki mógłby wyrosnąć dzisiejszy rejestr konektorów, gdyby rozszerzyć go do pełnego federacyjnego marketplace API (dostawcy publikują API, konsumenci subskrybują, platforma liczy użycie). Zero kodu produkcyjnego dziś nie istnieje pod tym opisem — to punkt wyjścia do dalszej pracy, nie zapowiedź terminu.

Model docelowy: katalog + tożsamość federacyjna + gateway + metering.

Cztery bloki odpowiadają za kolejno: opis API (katalog), kto ma dostęp (tożsamość/OIDC), egzekucję polityk dostępu (gateway) oraz rozliczalność (metering/audyt). Diagram poniżej to warstwa logiczna, nie wdrożenie.

[Consumer]
   |
   v
[Portal / API Catalog] ---- [Identity / OIDC]
   |
   v
[Subscription Service]
   |
   v
[API Gateway] ---- [Policy Engine]
   |                    |
   v                    v
[Provider APIs]     [Metering / Audit]
                         |
                         v
                    [Billing / Reports]

API Catalog ROADMAP

Metadane API: identyfikator, wersja, właściciel, link do specyfikacji OpenAPI, widoczność (public/federated/private), status (draft/published/deprecated).

Identity / Federation ROADMAP

OIDC/OAuth2, token JWT ze scope i issuerem, opcjonalnie mTLS system-system. Gateway waliduje dostęp bez pytania IdP przy każdym żądaniu.

Subscription Service ROADMAP

Wybór planu, wydanie client_id, przypisanie scope i limitów, status subskrypcji (pending/active/suspended/cancelled).

API Gateway ROADMAP

Routing do API dostawcy, walidacja JWT, rate limiting, kwoty, logowanie żądań, circuit breaker — punkt egzekucji polityk.

Przykładowy wpis katalogu (format spec, nie działający endpoint):

{
  "api_id": "example-api-v1",
  "name": "Przykładowe API",
  "version": "1.0.0",
  "owner_org": "partner-x",
  "openapi_url": "https://...",
  "visibility": "public|federated|private",
  "plans": ["free", "pro"],
  "status": "draft|published|deprecated"
}

Minimalny zakres MVP (gdyby prace ruszyły) — poza zakresem na start:

W zakresie MVP (projekt)	Poza MVP (świadomie odłożone)
katalog API, publikacja OpenAPI	automatyczny billing
logowanie OIDC	marketplace płatności
subskrypcje, gateway z JWT + rate limit	rekomendacje API (ranking automatyczny)
logowanie użycia, prosty raport per organizacja/API	workflow prawny, sandbox provisioning

Status. Cała powyższa sekcja to SPEC / ROADMAP — projekt architektoniczny bez implementacji, endpointu ani testu w ipIII. Jedynym elementem LIVE pozostają parsery importu wymienione wyżej w tabeli „Co jest LIVE dzisiaj".

SPEC: Agent Skills Marketplace ROADMAP

Osobny, powiązany projekt: rejestr „umiejętności" (skillów) wykonywalnych przez agentów federacji K0NSULT — publikacja, wyszukiwanie, wersjonowanie, uruchamianie w piaskownicy i telemetria. Dziś nie ma publicznego rejestru skillów, sandboxa wykonawczego ani API invoke — poniżej wyłącznie projekt struktury i zasad bezpieczeństwa.

Zasada rdzeniowa: manifest jawny + podpisany, wykonanie wyłącznie w piaskownicy.

Bez jawnego manifestu agent nie zna kontraktu wejścia/wyjścia skilla; bez podpisu nie da się wiarygodnie przypisać autora ani wersji. Skill jest kodem obcego autora — uruchomienie bez izolacji byłoby ryzykiem wykonania nieautoryzowanego kodu, dlatego sandbox jest wymogiem od pierwszej wersji, nie funkcją „do dodania później".

[Agents]
   |
   v
[Skill Discovery API] ---- [Registry DB]
   |                             |
   v                             v
[Execution Gateway] ---- [Policy Engine]
   |
   v
[Sandbox Runtime]
   |
   v
[Telemetry + Reputation]

Przykładowy manifest skilla (format spec):

id: "skill.example.task"
version: "1.0.0"
owner: "agent://team/example"
description: "Opis zdolności"
inputs:
  param: string
outputs:
  result: string
runtime:
  type: "container"
  image: "registry/skills/example:1.0.0"
permissions:
  network: ["https"]
  filesystem: "none"
trust:
  signature: "ed25519:..."
  sbom: "ipfs://..."
pricing:
  model: "per_call"
  price: 0.0

Registry DB ROADMAP

Manifesty skillów, wersje, właściciele, metryki, sygnatury, zależności — wersjonowanie niemutowalne.

Discovery API ROADMAP

Wyszukiwanie po nazwie, tagach, kontrakcie wejścia/wyjścia, reputacji i cenie.

Execution Gateway + Sandbox ROADMAP

Przyjmuje wywołania, sprawdza polityki (Policy Engine), uruchamia w izolowanym środowisku (kontener/WASM), zwraca wynik. Brak domyślnego dostępu do sieci/pliku.

Telemetry + Reputation ROADMAP

Sukces/porażka, latencja, koszt, błędy — metryki wykonania jako podstawa rankingu, trudniejsze do sfałszowania niż same oceny.

Szkic wzoru rankingu skillów (projekt, nie wdrożony algorytm):

score =
  0.35 * reputation +
  0.25 * success_rate +
  0.20 * freshness +
  0.10 * latency_score +
  0.10 * price_score

Marketplace skillów bez piaskownicy jest niebezpieczny. Skill to kod obcego autora — agent nie może zakładać zaufania do wykonania. Wymagane mechanizmy (projekt): podpisy manifestów, izolacja runtime, allowlista capability, limity CPU/RAM/czasu, audyt wywołań, kwarantanna dla zgłoszonych skillów.

Zakres pierwszej wersji (gdyby prace ruszyły). Registry manifestów, Discovery API, Invoke API, sandbox kontenerowy, podpisy Ed25519, prosty ranking, telemetria sukces/latencja, ACL per skill. Świadomie poza startem: aukcje cenowe, dynamiczne zależności, pełny rynek tokenowy, automatyczna kompozycja skillów.

Oba szkielety powyżej (API Marketplace i Agent Skills Marketplace) są wyłącznie projektami architektonicznymi ROADMAP — bez kodu, endpointu, bazy danych ani testu w dzisiejszym ipIII. Traktuj je jako materiał do dalszej dyskusji technicznej, nie jako opis działającej funkcji.