Memarium FAQ

Po co Memarium potrzebuje paszportu?

1. Bo Memarium jest organem konstytucyjnym, nie usługą CRUD. Memarium nie jest „bazą z danymi modułu". To wspólna pamięć węzła z czterema przestrzeniami o różnych politykach konstytucyjnych (Personal/Community/Public/Crisis). Każde wejście do Memarium jest aktem politycznym: „kto ma prawo coś zapisać w pamięci Community? kto może odczytać Personal innego modułu? kto może ogłosić kryzys?". Taki akt musi mieć pojedynczy, jawny, audytowalny punkt decyzji. Paszport to właśnie to: uzewnętrzniona reprezentacja uprawnienia, która wchodzi przez drzwi razem z żądaniem, zamiast być ukrytą w „kto wywołał funkcję w tym samym procesie". Bez paszportu mielibyśmy ambient authority — „jeżeli kod działa w węźle, to ma dostęp" — co jest klasycznym anty-wzorcem (confused deputy).

2. Bo separacja ról operator ↔ moduł ↔ delegat musi być strukturalna, nie umowna. Paszport nosi w sobie pola, które są nośnikami trzech rozłącznych semantyk: A0 (operator) — człowiek/administracja węzła, szeroki zakres, rozliczany osobowo; A1 (moduł lokalny) — Monus, Sensorium, Agora; wąski zakres, rozliczany per moduł; A2 (delegat przez nym) — pseudonimowy agent, rozliczany przez ścieżkę delegacji. Gdybyśmy to zrobili lokalnym ACL-em, musielibyśmy w każdym wywołaniu ręcznie udowadniać „to naprawdę Monus, a nie ktoś podszywający się". Paszport podpisany i związany z caller-identity przesuwa ten dowód na moment wystawienia, a dispatch-gate tylko weryfikuje, nie ustanawia. To jest ta sama różnica co między „każdy pokój ma własny zamek z własnym kluczem, który kopiujemy ręcznie" a „drzwi sprawdzają paszport wystawiony przez jeden urząd".

3. Bo delegacja z cofnięciem jest wymaganiem dziedzinowym, nie ozdobą. Memarium musi umożliwić: „Monus może przez 24h delegować do pod-agenta prawo dopisywania do Personal tylko dla topic-class X". Bez paszportu to wymaga albo kopiowania poświadczeń (które nie dają się cofnąć), albo trzymania per-delegacja wpisów w lokalnej tabeli (co nie przenosi się między węzłami i łamie stratyfikację). Z paszportem: nym wystawia cert delegacji z TTL, target-id daje ziarno do cofnięcia, a feed rewokacji (lokalny + statyczny + seed-directory) — ten sam, który już mamy — realizuje unieważnienie. Jeden mechanizm na całym węźle, zero duplikacji.

4. Bo audit-time decision musi być uchwycony w momencie decyzji, nie rekonstruowany post hoc. audit_decision() zwraca "denied:binding-mismatch" w momencie bramy, nie w momencie analizy logów. To oznacza, że fakt rozliczeniowy ma tę samą przyczynę, co odpowiedź sieciowa (reason: "binding_mismatch"), correlation_id spina żądanie ↔ denial ↔ wpis w ledgerze, a przyszła analiza „dlaczego Monusowi odmówiono 412 razy w kwietniu" jest rozpytaniem po danych, nie detektywistyką po tracach. Paszport jest artefaktem wprowadzającym kontekst do momentu decyzji (caller, grant, target, scope, nonce) — bez niego strata ta jest odtwarzalna tylko heurystycznie.

5. Bo stratyfikacja wymaga cienkich, stabilnych bram. Dispatch-gate (daemon) → engine (memarium-service). Engine ufa, że bramka już zautoryzowała; engine nie zna pojęcia „operator", „moduł", „delegacja". To jest dokładnie ta separacja, którą stosujemy w Sealer (gate authorization + engine policy = allow-all-as-invariant). Paszport jest interfejsem bramki: jedno wejście, jeden kontrakt, jedna reprezentacja. Gdyby nie paszport, każdy engine musiałby wiedzieć o wszystkich klasach caller-identity — czyli complecting warstw w stylu, od którego uciekamy. Dodatkowo: ta sama bramka obsłuży przyszły community-key service i kolejne organy — bez zmian w enginie Memarium. Paszport skaluje się jako koncept, nie jako kod.

6. Bo portability między deploymentami wymaga pojęć, nie konfiguracji. Węzeł może biec jako jednoosobowy pod, federacyjny relay, kontener serwerowy albo instancja testowa. W każdym z tych przypadków „kto jest operatorem, a kto modułem" jest inne. Paszport jako struktura danych przenosi się między tymi kontekstami; ACL jako lokalna tabela w konfigu nie przenosi się nigdzie. To zgodne z zasadą „dane jako wspólny język, logika na brzegach": paszport to dane, a polityka w bramce to logika brzegowa.

7. Bo Crisis wymaga autoryzacji, której nie można sfałszować z wewnątrz. memarium.crisis_resolve jest operacją, w której moduł mówi węzłowi „możesz wrócić do Running". To jest klasyczny wektor eskalacji: złośliwy/uszkodzony moduł ogłasza „wszystko ok", węzeł zdejmuje degradację, konstytucja zostaje naruszona. Paszport z operator-only scope na crisis_resolve realizuje tu twarde rozróżnienie: moduł może zaraportować sygnał (crisis-detected przez bus, per-module), ale nie może zamknąć epizodu. Bez paszportu to rozróżnienie wymaga procesowej separacji (osobne UID-y, sandboxy) — kosztownej i niedostępnej w deploymentach, gdzie wszystko żyje w jednym procesie.

8. Krótko, w jednym zdaniu. Paszport to uzewnętrzniona, audytowalna, delegowalna i cofalna reprezentacja uprawnienia, która pozwala stratyfikować autoryzację (brama) od wykonania (engine), zachować rozdział ról A0/A1/A2, i przenieść ten sam wzorzec na kolejne organy konstytucyjne węzła. Wszystko inne — reason dictionary, HTTP statusy, denied:* w ledgerze — to konsekwencje tej decyzji, nie jej przyczyny. Usunięcie paszportu oznaczałoby albo ambient authority (niedopuszczalne konstytucyjnie), albo rozsianie logiki autoryzacji po enginach (niedopuszczalne rzemieślniczo).