Architektura danych
i kluczy.

01 · Mapa całego przepływu

Źródła: S01, S02, S03, S08, S16, S20, S23, S28, S32.

Boardy są modułami uruchamianymi w aplikacji. Host rejestruje Chatboards Chats, YouTube, CV, Acta Network, Go To Market, XShelf, The Map of Everything, Astral, Vet i Settings. Daje im kontekst sesji oraz klienty System, Actanet i Swaplock Query. Rejestracja boardu nie oznacza automatycznie kompletnego backendu ani identycznej polityki szyfrowania. Główny opis poniżej odtwarza przepływ Chatboards Chats; współdzielony pakiet @mirrorboards-shell/datarooms jest również wykorzystywany przez Go To Market. S01, S02, S43

02 · Hierarchia kluczy i warstwy szyfrowania

Źródła: S04, S05, S06, S07, S11, S12, S13, S14, S15.

Hasło skarbca nie jest kluczem pokoju. Otwiera strażnika, który pozwala odzyskać CEK, następnie master, a z niego klucze zabezpieczające prywatne tożsamości. Room key jest osobno losowany. Każda przygotowywana rewizja treści otrzymuje nowy DEK; ponowienie tego samego przygotowanego uploadu wykorzystuje zachowany szyfrogram. To rozdziela zmianę sposobu odblokowania od szyfrowania dużych plików.

Format danych pokoju: version (1 B) | nonce (12 B) | ciphertext | tag (16 B), czyli 29 B narzutu. Hash karty to SHA-256 szyfrogramu. Przed odszyfrowaniem klient sprawdza hash, kontekst, rozmiar oraz dozwolony adres magazynu. AAD uwierzytelnia pięć pól kontekstu; parent, children i size należą do deskryptora/publikacji, nie do tej piątki AAD. S14, S15, S19

Co pozostaje jawne w kopercie skarbca: wersja, vault_id, epoka, rodzaje i identyfikatory strażników, parametry KDF, credential ID, zasięg i transporty. Zaszyfrowane są master oraz treść zawierająca tożsamości i etykiety. AAD koperty to CBOR z wersją, vault_id i epoką. Nie należy utożsamiać paddingu z ukryciem wszystkich metadanych. S06

Granica WASM: prywatne klucze tożsamości są używane przez interfejs skarbca bez zwykłego eksportowania ich do boardu. Odszyfrowany room key jest jednak przekazywany do kodu JS, a treść istnieje w pamięci React/Query. Kod wywołuje fill(0)/zwalnianie sekretów i czyści kontekst przy zmianie dostępu; nie jest to sprzętowa izolacja ani dowód wymazania wszystkich kopii tekstu w pamięci przeglądarki. S11, S18, S22

03 · Logowanie, System i rejestracja tożsamości

Źródła: S03, S23, S24, S25, S26, S27, S35.

System przechowuje relacje między użytkownikiem XAuth, osobą, systemami/organizacjami, dostępami i kontami łańcuchowymi. Obsługuje także ustawienia marketplace/kolejności oraz rejestr pokoi. Te rekordy są dostępne serwerowi; XKeys nie szyfruje całej bazy System. Wariant nazwy private trzyma właściwą nazwę w System, a na łańcuch trafia losowy alias mb-…. To ukrycie przed publicznym rejestrem, nie przed System. S24, S25

Transport jest przypisany do konkretnej sesji, a X-Account-Index wybiera slot cookie. To pozycja konta w przeglądarce, nie trwały identyfikator osoby ani skarbca. Zwykłe logowanie nie otwiera vaultu; reset danych logowania nie odtwarza historycznych kluczy memo/pokoi. XAuth przekazuje hasło logowania do Zitadel, podczas gdy hasło urządzenia XKeys służy lokalnej kryptografii. S03, S10, S23, S26

Zitadel jest źródłem tożsamości i sesji. Redis stanowi opcjonalny cache m.in. listy passkeys i statusów weryfikacji, zapisany jako JSON z TTL; nie jest skarbcem kluczy treści. Wartości hashy haseł i dokładne szyfrowanie wewnętrznej bazy Zitadel nie były przedmiotem tego przeglądu. S26, S27

04 · Utworzenie pokoju i publiczny ślad

Źródła: S16, S17, S24, S29, S35.

W obecnych pokojach Chatboards description jest markerem {app: "chatboards", storage: "s3", version: 1}. Nazwa użytkowa, podsumowanie i sloty dokumentów znajdują się w szyfrowanym manifeście aplikacji. Techniczna nazwa dr-UUID, identyfikator właściciela i istnienie pokoju pozostają publiczne. System rejestruje pokój niezależnie od nazwy boardu; nie wymaga app == chatboards. S17, S24, S29

Konta mają identyfikatory 1.2.x, pokoje 1.23.x, a content cards 1.26.x. Rejestracja pokoju w System i utworzenie go w Swaplock są oddzielnymi zapisami. Utrata odpowiedzi nie oznacza, że operacja się nie wykonała: klient przechowuje informacje o oczekującej transakcji i odzyskuje rezultat przez receipt/indexer. S16, S20

Dostęp ma dwa poziomy. Relacja w System pomaga znaleźć zasób i określa uprawnienia podmiotu w aplikacji. Możliwość odszyfrowania wynika z klucza memo i otrzymanej koperty room key. Zmiana wyłącznie relacji w System nie unieważnia już skopiowanego klucza. Backend Actanet ma operacje członkostwa, rotacji i regrant; ich obecność nie dowodzi dostępności wszystkich wariantów w aktualnym UI. S18, S36

05 · Gdzie trafiają wiadomości i pliki: pełny upload

Źródła: S14, S19, S20, S21, S28, S30.

Lokalizacja obiektów z konfiguracji: bucket mirrorboards-actanet-content, OVH WAW, stałe adresy https://mirrorboards-actanet-content.s3.waw.io.cloud.ovh.net/objects/…. staging/ jest prywatny; docelowy obiekt ma public-read. Publiczny jest szyfrogram, nie odszyfrowany dokument. Autoryzacja pobierania docelowych bajtów nie zastępuje kryptografii — link może pobrać ktoś bez sesji. Dokładny URL aplikacja otrzymuje z usług storage, a czytnik sprawdza public_base_url. S19, S28, S30, S33

Duży plik nie przechodzi przez Chat API ani System. Najpierw idzie z przeglądarki do S3. Następnie Actanet pobiera i ponownie publikuje zweryfikowane bajty szyfrogramu, więc stwierdzenie „backend w ogóle nie dotyka bajtów pliku” byłoby nieprawdziwe. Actanet nie dostaje w tym przepływie klucza do odszyfrowania. S28, S30

Załącznik ma dwie warstwy. Pierwszy obiekt to zaszyfrowane surowe bajty pliku typu protokołu urn:mirrorboards:blob:1. Drugi to szyfrowany manifest dokumentu: oryginalna nazwa, MIME, rozmiar, hash plaintextu, stan usunięcia i referencja do pierwszego obiektu, w tym jego opakowany DEK. Publikacja manifestu wskazuje children, które utrzymują blob przy życiu. MIME pliku i jego nazwa nie muszą trafiać do publicznej karty; publiczny type określa rodzaj zasobu protokołu. S21, S29

Limit plaintextu wynosi 100 000 000 B, szyfrogramu 100 000 029 B. Przygotowany upload ma limit czasu; nie jest to termin ważności opublikowanego URL. Limit z kodu: 8 aktywnych uploadów i 200 000 058 B na właściciela, do 4 jednoczesnych weryfikacji w procesie. To limity implementacji, nie potwierdzone bieżące wykorzystanie produkcyjne. S28, S30

06 · Odczyt, historia i odwoływanie dostępu

Źródła: S18, S19, S20, S22, S31.

Aktualny kod posiada UI historii kart i odtwarzania wersji. Starsza notatka operacyjna nadal mówi o „UI deferred”; w tym punkcie rozstrzyga nowsza implementacja. Czytnik historii korzysta z content_cards/get_revisions/query. Ten indeks przedstawia stany kart na granicach bloków, więc nie jest to gwarancja pokazania każdej pośredniej rewizji w jednym bloku. Dokładne podpisane publikacje są osobno utrwalane w storage ledger. S20, S31, S33

Zmiana expected_hash zapewnia kontrolę współbieżnego zapisu: nowa wersja nie powinna nadpisać obcej zmiany bez zauważenia konfliktu. Usunięcie dokumentu w boardzie publikuje deleted: true. Nie jest równoznaczne z fizycznym usunięciem obiektu S3 ani historii. Potwierdzone rewizje są zachowywane, a GC ma dotyczyć osieroconych uploadów po co najmniej 24 godzinach i tylko po bezpiecznej weryfikacji braku referencji. S20, S21, S30, S33

Trzy różne rotacje: zmiana strażnika dotyczy otwierania mastera; rotacja mastera zmienia epokę skarbca i przepakowuje jego zawartość; rotacja room key dotyczy nowych danych pokoju i kopert członków. Usunięcie strażnika bez rotacji nie odbiera mu możliwości otwarcia zachowanej starej koperty. Usunięcie członka nie usuwa jego wcześniejszych kopii room key, treści ani szyfrogramów. Brak podstaw, aby deklarować forward secrecy dla każdej wiadomości: tutaj nie ma protokołu ratchet per wiadomość. To wnioski z opisanej konstrukcji. S04, S18, S36

07 · Rozmowa z AI: granica poufności

Źródła: S32, S34, S37, S38, S39.

Chatboards wysyła wiadomości rozmowy; materiały projektu nie są jeszcze automatycznie dołączane. Sam upload PDF nie oznacza OCR, indeksowania wektorowego ani RAG. UI mówi o tym wprost, a runtime nie ma w tej ścieżce narzędzia pobierającego pliki projektu. Nie przenoszę możliwości dawnych proxy i innych boardów do obecnego Chat API. S32, S34

Snapshot w S3 może przechowywać pełną historię, nazwy i statusy wiadomości. Request modelu ogranicza się do maksymalnie 200 wiadomości i 128 KiB serializacji; pomija wskazane nieudane wiadomości oraz puste odpowiedzi asystenta. API dodatkowo waliduje wejście. SSE nie jest trwałym logiem rozmowy: runtime używa without_memory(), a trwały zapis inicjuje frontend. Domyślne limity backendu: 120 s, 4096 tokenów odpowiedzi, 2 jednoczesne uruchomienia na konto w procesie. S29, S32, S34, S37

Wartość domyślna zależy od warstwy. Kod ChatConfig domyślnie wybiera agent, ale Pulumi ustawia AI_MODEL_PROFILE_DEFAULT=fast. Oba domyślne aliasy to klasa -open. Lokalny katalog gateway opisuje tę klasę jako dopuszczającą trening u dostawców; to opis intencji konfiguracji, nie przeprowadzona tutaj weryfikacja bieżących warunków OpenRoutera lub konkretnego modelu. Alias mb/agent-std jest zdefiniowany w gateway, lecz nie należy do domyślnej mapy profili Chat API. S37, S38, S39

Logowanie gateway jest włączone w wykonywanej konfiguracji: EnableLogging: true, LogsStore.Enabled: true, SQLite /app/data/logs.db. Wolumen /app/data jest emptyDir, więc nie jest trwałą historią po usunięciu poda. Starszy komentarz w main.go mówi o wyłączonych logach; rozstrzygają wartości w config.go. Zakres przechowywania promptów/odpowiedzi, redakcja i eksport logów nie zostały sprawdzone, dlatego diagram nie obiecuje „zero retention”. S38, S39

Zaszyfrowane przechowywanie rozmowy nie oznacza, że treść pozostaje nieczytelna podczas inferencji. Plaintext zna przeglądarka, Chat API, AI gateway i wybrany dostawca; routing i fallbacki mogą zmieniać ostatniego odbiorcę.

08 · Kopie skarbca, AutoUnlock i nowe urządzenie

Źródła: S04, S08, S09, S10, S40, S41, S42.

Lokalna baza xkeys zawiera stores envelopes i marks. Koperta urządzenia jest adresowana account:<user_id>; znaczniki świeżości są przechowywane oddzielnie. AutoUnlock używa w envelopes osobnego klucza obejmującego API URL i user_id, z JSON-em {vaultId, epoch, password}. To jawne hasło zapisane na tym urządzeniu, nie dodatkowo zaszyfrowany sekret. Nie jest częścią backupu ani uploadu koperty. Zabezpieczenie aplikacyjne przy lokalnym odczycie bazy jest zatem inne niż w trybie ręcznego wpisywania hasła. S09, S10

Przenośna koperta usuwa odbiorców typu device-password; hasło lokalnego urządzenia nie wystarcza do otwarcia samej koperty pobranej z serwera na nowym urządzeniu. Wspierane typy strażników to hardware key, platform passkey, device password i recovery code. Opcja odzyskiwania zarządzanego przez Mirrorboards jest w wizardzie wyłączona („Wkrótce”). MetaMask nie jest typem strażnika w bieżącym formacie. S04, S06, S42

Zapis koperty wymaga rosnącej dokładnie o jeden revision; epoch liczy rotacje mastera. Serwer sprawdza podpis Ed25519, a rotacja klucza zapisu wymaga podpisów starym i nowym kluczem. Pierwszy zapis opiera się na przedstawionym kluczu publicznym i bramce sesji. list_owned jest filtrowane po koncie, natomiast get(vault_id) wymaga sesji, lecz nie sprawdza, czy adres należy do pytającego. Poufność koperty opiera się na szyfrowaniu. S08

Pairing nie wysyła krótkiego kodu jako hasła szyfrującego do relay. CPace służy do uzgodnienia sekretu między urządzeniami; zaszyfrowany payload zawiera master, CEK i vault ID. Urządzenie dołączające potrzebuje również zgodnej koperty. Przyznanie dostępu wymaga ponownego dowodu strażnika. Limity i skierowanie prośby do tego samego konta XAuth są częścią ochrony. S40, S41

09 · Rozmieszczenie usług i trwałość

Źródła: S08, S28, S30, S33, S38, S39, S44, S45.

Diagram przedstawia logiczne rozmieszczenie wynikające z repozytorium; nie deklaruje, że każda usługa ma własny fizyczny serwer. W szczególności XKeys wykorzystuje AppDbEnvelope z rodziny czatu i schemat xkeys, choć obecny Chat API nie zapisuje tam wiadomości. Nazwa pakietu lub bazy nie dowodzi przechowywania treści rozmów. S08, S32, S44

Backup registry i backup vaultu rozwiązują różne problemy. Registry odtwarza historię publikacji i powiązań z obiektami; nie posiada plaintextu dokumentów ani kluczy umożliwiających ich odszyfrowanie. Odzyskanie dokumentu wymaga równocześnie zachowanego szyfrogramu, poprawnych metadanych i odpowiednich kluczy użytkownika/pokoju. Sama koperta bez strażnika albo sam bucket bez kluczy nie wystarczą. Harmonogram CNPG deklaruje codzienny backup 02:00 UTC i archiwizację WAL, prywatny bucket oraz retencję 30 dni. Ta retencja nie ogranicza czasu życia opublikowanych obiektów. Nie sprawdzałem w tej sesji skuteczności backupów ani opóźnienia WAL. S33, S45

HTTPS publicznych hostów wynika z adresów aplikacji i infrastruktury. Wewnętrzne URL-e do XAuth oraz AI gateway używają http://…svc.cluster.local. Nie zweryfikowano aktywnego service mesh/mTLS, szyfrowania wszystkich dysków i backupów na poziomie dostawcy ani dokładnych reguł sieciowych. Nie należy dopisywać takich gwarancji do szyfrowania realizowanego przez XKeys.

10 · Tabela: co, gdzie i kto może przeczytać

Tabela syntetyzuje diagramy 01–09 i przypisane im źródła. Ochrona przed odczytem treści nie ukrywa wszystkich metadanych ani nie zastępuje kontroli kodu uruchamianego na urządzeniu.

11 · Zakres i rzeczy, których nie należy dopowiadać

1. XFiles/IPFS nie jest ścieżką uploadu opisanego Chatboards. Obecny router xfiles-korea ma pustą listę endpointów. Repozytorium zawiera historyczne komponenty IPFS i XFiles, ale analizowana ścieżka korzysta z Actanet storage i S3. Nie oznacza to, że żaden inny produkt w workspace ich nie używa. S46
2. Szyfrowanie storage i prywatność AI to osobne właściwości. Nie można określić całej aplikacji jako „serwer nigdy nie widzi wiadomości”, jeśli użytkownik wysyła je do AI.
3. Autoryzacja nie jest kluczem deszyfrującym. XAuth i System nie otwierają vaultu. Skopiowane wcześniej klucze/treść nie znikają po zmianie ACL.
4. Aktualny frontend i dawny mirrorboards-chat-proxy-ai nie są tą samą ścieżką. Obecny Chat API jest w Rust/Rig; diagram nie przypisuje mu dawnych narzędzi, głosu czy integracji bez dowodu wywołania. S32, S34
5. API boardów jest odrębnym rozszerzeniem. Host zna boards.mirrorboards.chat; ta rodzina montuje routery Astral/Marketing/Strategy/Crossword. Nie bierze udziału w pokazanym uploadzie Chatboards. Każdy konkretny board z własnym backendem wymaga odrębnego prześledzenia zakresu wysyłanych danych. S01, S47
6. To mapa kodu, nie atest bezpieczeństwa. Nie uruchamiałem testów kryptograficznych, pentestu, produkcyjnego capture ruchu ani restore drill. Walidacja artefaktu obejmuje renderowanie diagramów, otwieranie HTML, interakcje i spójność odnośników do istniejących plików.

12 · Źródła i możliwość aktualizacji

Odnośniki poniżej prowadzą do kodu w repozytoriach GitHub; prywatne repozytoria wymagają uprawnionego konta. Odciski opisują analizowany stan lokalny. Przy pliku zmienionym względem HEAD odnośnik pokazuje bazowy commit, a SHA-256 identyfikuje analizowany plik. evidence.json zawiera SHA-256 pliku, commit repozytorium i informację, czy dany plik różnił się od HEAD. Nazwy sekretów opisują zależności; dokument nie zawiera ich wartości. Diagramy można edytować jako Mermaid w tym pliku lub w katalogu diagrams/. HTML ma osadzone SVG, działa bez CDN i bez kontaktu z API produktu.