PHANTOM DOCS
·
ARCHITEKTURA

Warstwa P2P

Jak działa bezpośrednia komunikacja peer-to-peer między węzłami .onion.

Co oznacza P2P w Phantom

W Phantom nie istnieje centralny serwer wiadomości. Każde urządzenie jest jednocześnie klientem i małym serwerem ukrytym za adresem .onion. Gdy piszesz do kontaktu, aplikacja nie wysyła treści do chmury ani kolejki pośredniej — zestawia połączenie bezpośrednio z urządzeniem rozmówcy przez sieć Tor.

Warstwa P2P odpowiada za logikę rozmowy: znalezienie kontaktu po adresie .onion, zestawienie sesji, utrzymanie połączenia, potwierdzanie odbioru i ponawianie wysyłki, jeśli druga strona jest chwilowo niedostępna.

Tor ukrywa trasę i adresy IP. Szyfrowanie E2E chroni treść. Warstwa P2P spina te dwie rzeczy w działający komunikator bez serwera centralnego.

Trzy warstwy połączenia

Najprościej: Phantom buduje rozmowę z trzech niezależnych warstw. Każda ma inne zadanie i inną granicę odpowiedzialności.

1 — TOŻSAMOŚĆ .ONION

Adres rozmówcy wskazuje jego ukrytą usługę Tor. To odpowiednik numeru telefonu, ale bez numeru SIM, e-maila i centralnej książki adresowej.

2 — TRANSPORT TOR

Połączenie idzie przez Hidden Service, bez exit node'a. Żadna strona nie poznaje adresu IP drugiej strony.

3 — SESJA P2P

Po zestawieniu kanału aplikacje wymieniają ramki protokołu: handshake, wiadomości, potwierdzenia i statusy obecności.

4 — SZYFROWANIE E2E

Treść wiadomości jest szyfrowana przed wysłaniem. Warstwa P2P przenosi zaszyfrowany pakiet, ale go nie interpretuje.

Jak wygląda zestawienie sesji

Gdy dodajesz kontakt przez QR albo ręcznie wpisany adres, Phantom zapisuje adres .onion i próbuje zestawić bezpośrednią sesję. Nie pyta żadnego katalogu użytkowników, bo taki katalog nie istnieje.

  1. Użytkownik A zna adres .onion użytkownika B

    Adres pochodzi z QR, linku zaproszenia albo ręcznego wpisania. To wystarcza, żeby rozpocząć próbę połączenia.

  2. Phantom buduje obwód Tor

    Aplikacja łączy się z lokalnym proxy SOCKS5 Tora, a Tor znajduje Hidden Service odbiorcy przez mechanizm introduction points i rendezvous point.

  3. Urządzenia wykonują handshake

    Po otwarciu kanału aplikacje wymieniają minimalne informacje protokołu: wersję, identyfikator kontaktu, klucze sesji i parametry szyfrowania.

  4. Rozmowa przechodzi w tryb aktywny

    Od tego momentu wiadomości, potwierdzenia odbioru i status online płyną bezpośrednio między urządzeniami.

Telefon A
  → Tor SOCKS5 (127.0.0.1:9050)
  → obwód Tor A
  → Rendezvous Point
  ← obwód Tor B
  ← Hidden Service telefonu B
  ← lokalny listener Phantom (127.0.0.1:8080)

Format logiczny wiadomości

Warstwa P2P nie musi znać tekstu wiadomości. Dla niej wiadomość to zaszyfrowany obiekt z metadanymi technicznymi potrzebnymi do dostarczenia i uporządkowania rozmowy.

{
  "type": "message",
  "conversation_id": "local-contact-id",
  "message_id": "01J9Y7...",
  "sent_at": 1730914200,
  "payload": "<zaszyfrowany blob E2E>",
  "ack_required": true
}

payload jest szyfrowany end-to-end. Pola techniczne służą do deduplikacji, sortowania i potwierdzania dostarczenia. Jeśli ten sam pakiet dotrze drugi raz po ponowieniu wysyłki, aplikacja rozpoznaje message_id i nie pokazuje duplikatu w rozmowie.

Potwierdzenia i ponawianie

W klasycznym komunikatorze serwer pełni rolę bufora: przyjmuje wiadomość, przechowuje ją i oddaje odbiorcy później. W Phantom ten mechanizm jest lokalny i ograniczony do urządzeń rozmówców.

SytuacjaZachowanie Phantom
Kontakt onlineWiadomość jest wysyłana natychmiast przez aktywną sesję P2P.
Brak potwierdzeniaNadawca trzyma wiadomość w lokalnej kolejce i ponawia próbę.
Kontakt offlineWiadomość czeka lokalnie na urządzeniu nadawcy, aż odbiorca znów będzie osiągalny.
Duplikat po ponowieniuOdbiorca ignoruje duplikat na podstawie identyfikatora wiadomości.
Brak centralnego serwera oznacza ważny kompromis: jeśli obie strony są offline w różnym czasie, nie ma zewnętrznej skrzynki, która przechowa wiadomość za nie. Phantom wybiera prywatność metadanych zamiast wygody globalnej chmury.

Obecność i status kontaktu

Status online w Phantom nie pochodzi z serwera obecności. Aplikacja ocenia go na podstawie realnej osiągalności kontaktu przez Tor i ostatniej aktywnej sesji.

Przykład

online
  → istnieje aktywna sesja P2P
  → ostatni ping/pong wrócił poprawnie
  → kanał Tor nadal jest dostępny

offline
  → nie udało się zestawić kanału
  → ostatnia sesja wygasła
  → wiadomości trafiają do lokalnej kolejki nadawcy

To dlatego zielona kropka przy kontakcie oznacza coś konkretnego: nie "serwer widział użytkownika minutę temu", tylko "aplikacja może teraz rozmawiać z tym węzłem przez Tor".

Dlaczego nie ma serwera pośredniczącego

Serwer centralny jest wygodny, ale tworzy stały punkt obserwacji. Nawet gdy treść jest szyfrowana, serwer może widzieć kto z kim rozmawia, kiedy, jak często i z jakiego adresu IP. Phantom usuwa ten punkt z architektury.

ElementKomunikator z serweremPhantom P2P
DostarczaniePrzez centralną kolejkęBezpośrednio urządzenie do urządzenia
Adres IPWidoczny dla operatora serweraUkryty przez Tor Hidden Service
Metadane relacjiSerwer zna graf kontaktówBrak centralnego grafu kontaktów
Offline inboxWygodny, ale centralnyLokalna kolejka po stronie nadawcy

Granice warstwy P2P

P2P nie rozwiązuje wszystkiego. Ta warstwa odpowiada za transport między urządzeniami, ale nie zastępuje higieny bezpieczeństwa, ochrony urządzenia ani świadomego zarządzania tożsamością.

CZEGO P2P NIE UKRYWA

Jeśli sam powiążesz swój adres .onion z prawdziwą tożsamością, warstwa P2P tego nie odwróci. Adres nadal nie zdradza IP, ale rozmówca może wiedzieć, że należy do Ciebie.

CZEGO P2P NIE NAPRAWIA

Jeśli telefon jest przejęty przez malware, atakujący może czytać wiadomości na ekranie albo przed szyfrowaniem. Przed tym chroni separacja urządzeń i twardy model operacyjny, nie sama sieć P2P.