Dlaczego nie przechowujemy kopii Twojej książki adresowej

Oczywisty sposób zbudowania produktu do udostępniania kontaktów to zaimportowanie wszystkiego. Ściągnąć każdy kontakt z każdego połączonego konta do własnej bazy danych, uznać ją za źródło prawdy i wypychać zmiany z powrotem. To ułatwia inżynierię: zapytania są szybkie, kontrolujesz schemat, a synchronizacja sprowadza się do „porównaj moją bazę z ich bazą”.

Celowo nie zbudowaliśmy Rolyio w ten sposób. Twoje kontakty żyją w Google i Microsoft. Rolyio przechowuje relacje udostępniania i uprawnienia — powiązania między kopiami kontaktu na różnych kontach — a nie lustrzaną kopię Twojej książki adresowej. Ten wpis wyjaśnia, co to konkretnie oznacza i dlaczego uważamy to za właściwy kompromis.

Co faktycznie przechowujemy

Gdy łączysz konto i udostępniasz etykietę, baza danych Rolyio zawiera:

• Rekordy kont i tokeny OAuth — tokeny zaszyfrowane w spoczynku algorytmem AES-256-GCM.
• Metadane etykiet — cienką warstwę nad prawdziwymi strukturami dostawcy. Etykieta jest grupą kontaktów Google lub kategorią Outlooka; przechowujemy informację, do której grupy/kategorii się mapuje i komu jest udostępniona.
• Udostępnienia i role — kto ma Podgląd, Edycję lub Może udostępniać dalej na której etykiecie, łącznie z oczekującymi udostępnieniami dla osób, które jeszcze się nie zalogowały.
• Klastry powiązań — rekord mówiący, że „kontakt X na koncie Google właściciela i kontakt Y na koncie Outlook odbiorcy to ta sama osoba”. To rdzeń systemu: mapowanie tożsamości, a nie przechowywanie treści.
• Stan synchronizacji — tokeny synchronizacji przyrostowej, odciski zmian do ochrony przed echem i znaczniki czasu do rozwiązywania konfliktów.

Czego tam nie ma: tabeli z Twoimi kontaktami. Gdy działa synchronizacja, dane kontaktów przepływają przez silnik synchronizacji z jednego konta dostawcy na drugie, prowadzone przez powiązania i role — nie osiadają w żadnym magazynie po naszej stronie.

Jest jeden celowy, ograniczony wyjątek: gdy udostępniony kontakt zostaje usunięty, przechowujemy migawkę w Koszu przez 30 dni, aby przypadkowe usunięcie — Twoje lub kogoś z zespołu — dało się odwrócić. Po 30 dniach migawka jest czyszczona. To siatka bezpieczeństwa z datą ważności, a nie cień książki adresowej. (Możesz też wyczyścić ją samodzielnie; zobacz Kosz i przywracanie oraz usuń swoje dane.)

Dlaczego powiązania wygrywają z kopiami

Mniejsza powierzchnia ataku

Architektura bezpieczeństwa zaczyna się od niewygodnego założenia: każdy system może zostać skompromitowany. Pytanie brzmi, co dostaje atakujący. W architekturze lustrzanej odpowiedź to każdy kontakt każdego klienta — nazwiska, numery telefonów, relacje — w jednej bazie danych. W architekturze powiązań danych kontaktowych, na których zależałoby atakującemu, po prostu nie ma skąd zabrać. Istnieją metadane: które etykiety są komu udostępnione, plus zaszyfrowane tokeny, których klucz przechowywany jest oddzielnie od bazy.

Wolimy nie być miodem na muchy. Najmniej ryzykowne dane to te, których nigdy nie przechowano.

Brak drugiego źródła prawdy

Każda lustrzana kopia w końcu rozjeżdża się ze swoim oryginałem. Zmirrorowana baza kontaktów i kopia Google będą dryfować — tu nieudana synchronizacja, tam wyścig — a wtedy produkt musi zdecydować, która wersja jest prawdziwa. Użytkownicy tracą w obu przypadkach: albo narzędzie pokazuje nieaktualne dane, albo — co gorsza — „naprawia” kopię dostawcy własną, przestarzałą wersją.

Utrzymując autorytatywność dostawcy, Rolyio omija całą tę kategorię problemów. To, co widzisz na contacts.google.com albo w Outlooku, jest prawdą. Utwórz grupę kontaktów w Google, a pojawi się w Rolyio; zmień nazwę etykiety w Rolyio, a zmieni się w Google. Zadaniem silnika synchronizacji jest przenoszenie zmian między kopiami u dostawców — z rozwiązywaniem konfliktów „ostatni zapis wygrywa” z poszanowaniem ról oraz ochroną przed echem opartą na odciskach zmian, dzięki której nasze własne zapisy nigdy nie są mylone z edycjami użytkowników. Mechanikę dokumentuje artykuł jak działa synchronizacja.

Udostępnianie, które kończy się, gdy się kończy

Powiązania mają jeszcze jedną właściwość, której brakuje kopiom: można je tanio i całkowicie zerwać. Gdy cofasz udostępnienie etykiety, Rolyio usuwa udostępnione kontakty z książek adresowych odbiorców i kasuje odpowiadające im powiązania. W naszej bazie nie zostaje żadna szczątkowa kopia widoku odbiorcy, bo nigdy jej tam nie było. Odwołanie dostępu to odejmowanie, a nie projekt sprzątania.

Ta sama logika działa, jeśli całkiem odchodzisz z Rolyio. Twoja książka adresowa nigdy nie była w naszych rękach, więc nie ma czego eksportować z powrotem ani czego kasowania nam powierzać — usunięcie konta usuwa relacje i zaszyfrowane tokeny, a Twoje kontakty pozostają dokładnie tam, gdzie zawsze były: na Twoim koncie Google lub Microsoft.

Ile nas to kosztuje

Uczciwość wymaga wyliczenia wad, bo płacimy za nie codziennie:

• Synchronizacja jest trudniejsza w budowie. Bez centralnej kopii każda operacja musi uwzględniać N kopii po stronie dostawców połączonych powiązaniami. Rozwiązywanie konfliktów, semantyka usunięć (nagrobki respektujące role) i deduplikacja po adresie e-mail — wszystko musi działać w środowisku rozproszonym.
• Dziedziczymy ograniczenia dostawców. Google nie oferuje powiadomień push dla kontaktów, więc strona Google synchronizuje się przez odpytywanie mniej więcej co 60 sekund z tokenami przyrostowymi. Microsoft Graph daje nam webhooki, więc strona Microsoft działa niemal w czasie rzeczywistym — ale Graph nie pozwala zmienić nazwy kategorii. Lustrzana kopia mogłaby takie asymetrie tuszować; my je ujawniamy i projektujemy z ich uwzględnieniem.
• Niektóre funkcje po prostu odpadają. Wszystko, co wymaga analizowania całej Twojej książki adresowej po stronie serwera, kłóci się z nieposiadaniem całej Twojej książki adresowej. To ograniczenie uważamy za zaletę.

Test, który stosujemy

Gdy oceniamy nową funkcję, pytanie brzmi: czy da się ją zbudować z powiązań, ról i interfejsów API dostawców, bez gromadzenia danych kontaktowych po naszej stronie? Jeśli tak — budujemy. Jeśli nie — szukamy innego kształtu. Udostępnianie między ekosystemami Google Workspace i Microsoft 365 — flagowa funkcja produktu — przeszło ten test: wymaga powiązań tożsamości między ekosystemami i synchronizacji świadomej ról, a nie centralnego magazynu kontaktów.

Jeśli taka architektura odpowiada Twojemu wyobrażeniu o tym, jak infrastruktura powinna traktować Twoje dane, połącz konto i przyjrzyj się, o co prosimy — przyrostowe zakresy OAuth opowiadają tę samą historię co ten wpis.