Faza beta Otwarte źródła

Twoje dane. Twoje klucze. Twoja kontrola.

MindooDB to baza danych local-first z synchronizacją i szyfrowaniem end-to-end, przeznaczona do bezpiecznej współpracy — serwery mogą przechowywać i synchronizować dane, ale nie mogą ich czytać. Działa w trybie klient-serwer, peer-to-peer i wyłącznie lokalnie. Dla przeglądarek, Node.js i React Native. Napędza też Haven, graficzny obszar roboczy do wspólnej pracy dla zespołów, które chcą tego modelu zaufania, nie budując własnego klienta.

Koncepcja szyfrowania end-to-end: dane zaszyfrowane od urządzenia po serwer albo chmurę
Wprowadzenie

Obejrzyj i posłuchaj

Pogłębione wprowadzenie do MindooDB — wygenerowane przez NotebookLM z dokumentacji MindooDB.

Wideo wprowadzające

Wizualny przegląd tego, jak MindooDB trzyma dane zaszyfrowane end-to-end, a przy tym pozwala na współpracę w czasie rzeczywistym i synchronizację local-first.

I jeszcze jedno, NotebookLM: mówi się „MindooDB” (z krótkim i). Ale nieważne. :-)

Przechowywanie zero-trust
Włamanie na serwer daje szyfrogram

Klucze zostają na urządzeniach. Trzy niezależne warstwy szyfrowania: AES-256-GCM w spoczynku, RSA na użytkownika w tranzycie, TLS na łączu. Serwery nigdy nie widzą tekstu jawnego.

UX local-first
Praca bez sieci

Twórz i edytuj lokalnie. Uzgadnianie zaczyna się od metadanych i przesyła tylko to, co się zmieniło — pasmo zależy od różnicy, nie od całkowitego rozmiaru.

Współpraca
Scalanie bez konfliktów

CRDT Automerge sprawiają, że równoczesne edycje zbiegają się automatycznie. Synchronizacja niezależna od kolejności — wpisy mogą docierać w dowolnej sekwencji.

Jak to działa

Serwery mogą synchronizować i przechowywać — ale nie czytać

Klucze zostają na urządzeniach
Klienty trzymają klucze prywatne; serwer przechowuje zaszyfrowane bloby; synchronizacja wymienia brakujące zaszyfrowane wpisy.
Klienty szyfrują przed synchronizacją. Serwery przechowują szyfrogram. Synchronizacja wymienia tylko te zaszyfrowane wpisy, których Ci brakuje.
  • Podpisywanie każdej zmiany (autorstwo + integralność)
  • Szyfrowanie, zanim dane opuszczą urządzenie (poufność)
  • Magazyn append-only (ścieżka audytu)
  • Synchronizacja adresowana treścią (przesyłanie tylko braków)
  • Działa w trybie klient-serwer i peer-to-peer
Co można na tym zbudować

Zastosowania i możliwości

Podpisana historia odporna na manipulacje
Historia append-only, kryptograficznie łańcuchowana — dla audytowalności i integralności.
Precyzyjny dostęp
Nazwane klucze dają kontrolę dostępu w modelu need-to-know dla wrażliwych dokumentów.
Zaszyfrowane załączniki
Przesyłanie we fragmentach, odczyt strumieniowy i deduplikacja w całym tenancie.
Podróż w czasie
Odtwórz stan dokumentu na dowolny moment i przejdź całą historię.
Widoki wirtualne
Hierarchicznie skategoryzowane widoki z sumami (inspirowane Domino/Notes).
Synchronizacja wszędzie
Wdrożenia peer-to-peer, klient-serwer i hybrydowe na tych samych prymitywach. Tryb synchronizacji gęstej ogranicza pasmo przy pierwszej konfiguracji na urządzeniu mobilnym.
Pierwsze kroki

Wybierz środowisko uruchomieniowe i zacznij kodować

Te fragmenty pochodzą z zestawu testów MindooDB, żeby trzymały się rzeczywistych wzorców użycia.

Dlaczego MindooDB?

Kiedy wybrać MindooDB, a kiedy alternatywę

MindooDB jest zbudowany pod aplikacje, w których szyfrowanie end-to-end, praca offline i współpraca wielu stron są niezbędne. Oto, gdzie pasuje najlepiej.

Wybierz MindooDB, gdy:
  • Potrzebujesz szyfrowania end-to-end i nie możesz zaufać swojemu dostawcy hostingu
  • Potrzebujesz pełnych ścieżek audytu z kryptograficzną integralnością
  • Potrzebujesz pracy local-first w terenie albo w miejscach odciętych od sieci
  • Współpracujesz ponad organizacjami i potrzebujesz precyzyjnej kontroli dostępu
  • Potrzebujesz technicznych mechanizmów zgodności — szyfrowania, podpisanych ścieżek audytu i skoordynowanego usuwania danych, które wspierają programy HIPAA, SOX, RODO i PCI-DSS
  • Potrzebujesz współpracy wielu stron z różnymi poziomami dostępu
Rozważ alternatywę, gdy:
  • Potrzebujesz tylko prostych operacji CRUD bez współpracy
  • Zawsze masz niezawodne połączenie sieciowe i nie potrzebujesz local-first
  • Nie potrzebujesz szyfrowania end-to-end i możesz zaufać swojemu dostawcy hostingu
  • Masz proste wymagania wobec kontroli dostępu, które nie potrzebują szyfrowania na poziomie dokumentu
  • Potrzebujesz złożonych zapytań relacyjnych, które nie mieszczą się w modelu dokumentowym
  • Masz bardzo wysoką przepustowość zapisu, która może być wyzwaniem dla magazynów append-only
Krótkie porównanie
Funkcja MindooDB PostgreSQL/Firebase Blockchainy
Szyfrowanie end-to-end Tak (serwery nie odszyfrują) Nie (klucze po stronie serwera) Nie (domyślnie publiczne)
Local-first Wbudowane Wymaga własnej logiki Wymaga sieci
Ścieżki audytu Append-only, kryptograficznie łańcuchowane Wymaga własnej implementacji Niezmienne zapisy publiczne
Współpraca wielu organizacji Precyzyjna kontrola dostępu Kontrola dostępu po stronie serwera Widoczność wszystko albo nic
Prywatność danych Domyślnie prywatne Zależy od bezpieczeństwa serwera Domyślnie publiczne

Zobacz szczegółowe porównanie →

Zaufanie i przejrzystość

Gotowość produkcyjna i sygnały zaufania

Aktualny stan

MindooDB jest oprogramowaniem w wersji beta — API może się zmienić bez zapowiedzi. Funkcje rdzenia są stabilne i przetestowane, ale przed wdrożeniem produkcyjnym zalecamy dokładną ocenę.

Co jest stabilne
  • Podstawowe protokoły szyfrowania i synchronizacji
  • Operacje CRDT na dokumentach
  • Widoki wirtualne i indeksowanie
  • Przechowywanie załączników
Co może się zmienić
  • Nazwy i sygnatury metod API
  • Opcje konfiguracji
  • Wewnętrzne struktury danych
Bezpieczeństwo i przejrzystość
  • Otwarte źródła — Cała baza kodu na GitHubie
  • Audyt bezpieczeństwa — Opisany w dokumentacji audytu
  • Model zagrożeń — Zakłada, że serwery są przejęte
  • Gwarancje kryptograficzne — Podpisy Ed25519, szyfrowanie AES-256-GCM
Społeczność

Aktywny rozwój, obszerna dokumentacja i rosnąca społeczność. Zobacz na GitHubie →