# Wielodostępność i izolacja

Synapse jest wielodostępny: wielu użytkowników, każdy z wieloma umysłami, w pełni
odizolowanych od siebie. Ta strona wyjaśnia model izolacji.

## Hierarchia dzierżawców

```
Synapse Instance
  │
  ├── User Account 1 (email: alice@example.com)
  │   ├── Mind A (Mind Key mk_aaa...)
  │   │   ├── Memories (only accessible via mk_aaa...)
  │   │   ├── Tasks
  │   │   └── Chat
  │   └── Mind B (Mind Key mk_bbb...)
  │       └── ... (isolated from Mind A)
  │
  ├── User Account 2 (email: bob@example.com)
  │   └── Mind C (Mind Key mk_ccc...)
  │       └── ... (isolated from Alice's minds)
  │
  └── ... (more users)
```

## Poziomy izolacji

### Poziom 1: Izolacja użytkownika

Każde konto użytkownika jest izolowane. Alice nie może:

- Widzieć umysłów Boba
- Dostać się do wspomnień Boba (nawet ze swoim JWT)
- Wylistować informacji o koncie Boba

Wymuszane przez: kolumna `user_id` we wszystkich tabelach, JWT zawiera
`user_id`, wszystkie zapytania filtrują po `user_id`.

### Poziom 2: Izolacja umysłu

W obrębie użytkownika każdy umysł jest izolowany. Umysł A nie może:

- Widzieć wspomnień umysłu B
- Dostać się do zadań, czatu, skryptów umysłu B

Wymuszane przez: kolumna `mind_id` we wszystkich tabelach danych, Mind Key
zawiera `mind_id`, wszystkie zapytania filtrują po `mind_id`.

> [!CRITICAL]
> Izolacja Mind Key jest główną granicą bezpieczeństwa. Wyciekły Mind Key daje
> pełny dostęp do danych tego umysłu — ale TYLKO tego umysłu.

## Tokeny autoryzacyjne

| Token | Zakres | Do czego ma dostęp |
|-------|-------|-------------------|
| Mind Key | Pojedynczy umysł | Tylko dane tego umysłu |
| JWT | Konto użytkownika | Zarządzanie kontem (tworzenie/lista/usuwanie umysłów) |
| Computer Token | Pojedynczy komputer | Polecenia tego komputera |

## Dostęp między umysłami

### W obrębie tego samego użytkownika

Użytkownik ma dostęp do wszystkich swoich umysłów przez JWT (np. `GET /minds`
wylistowuje wszystkie). Aby jednak odczytać/zapisać dane pamięci, potrzebny jest
konkretny Mind Key.

### Między użytkownikami

Użytkownicy nie mają dostępu do danych innych — CHYBA że jawnie udostępnią umysł
przez Sharing API:

```bash
# Alice udostępnia umysł A Bobowi
curl -X POST https://synapse.schaefer.zone/sharing \
  -H "Authorization: Bearer ALICE_JWT" \
  -d '{"mind_id": "m_aaa", "email": "bob@example.com", "role": "read"}'
```

Po udostępnieniu Bob ma dostęp do umysłu A przez swój JWT (tylko do odczytu, jeśli
`role=read`).

## Granice bezpieczeństwa

```
┌─────────────────────────────────────────────────┐
│              Synapse Instance                    │
│  ┌─────────────────────────────────────────┐    │
│  │         User Account Boundary           │    │
│  │  ┌──────────────┐  ┌──────────────┐    │    │
│  │  │  Mind Bound. │  │  Mind Bound. │    │    │
│  │  │  (Mind Key)  │  │  (Mind Key)  │    │    │
│  │  │              │  │              │    │    │
│  │  │  Memories    │  │  Memories    │    │    │
│  │  │  Tasks       │  │  Tasks       │    │    │
│  │  │  Chat        │  │  Chat        │    │    │
│  │  │  Scripts     │  │  Scripts     │    │    │
│  │  └──────────────┘  └──────────────┘    │    │
│  └─────────────────────────────────────────┘    │
└─────────────────────────────────────────────────┘
```

## Typowe wzorce wielodostępności

### Wzorzec 1: pojedynczy użytkownik, pojedynczy umysł

Najczęstszy dla indywidualnych użytkowników agentów LLM.

- 1 konto użytkownika
- 1 umysł
- 1 Mind Key
- Wszystkie wspomnienia w jednym zakresie

### Wzorzec 2: pojedynczy użytkownik, wiele umysłów

Dla użytkowników z wieloma kontekstami (praca, życie prywatne, projekty).

- 1 konto użytkownika
- N umysłów (np. „work", „personal", „project-x")
- N Mind Key
- Każda sesja LLM używa jednego Mind Key

### Wzorzec 3: współdzielony umysł zespołu

Dla zespołów współpracujących nad projektem.

- Jeden użytkownik tworzy umysł (otrzymuje Mind Key)
- Twórca udostępnia członkom zespołu przez JWT
- Wszyscy członkowie zespołu mają dostęp przez JWT (lub współdzielony Mind Key)

> [!WARNING]
> Współdzielenie Mind Key daje pełny dostęp do odczytu i zapisu. Do współpracy
> zespołu preferować Sharing API (oparte na JWT) zamiast bezpośredniego
> współdzielenia Mind Key.

### Wzoczec 4: dostawca SaaS

Dla aplikacji osadzających Synapse jako warstwę pamięci.

- Każdy klient = 1 konto użytkownika
- Każdy projekt klienta = 1 umysł
- Aplikacja przechowuje Mind Key per klient/projekt
- Pełna izolacja między klientami

## Weryfikacja izolacji

### Test: Mind Key nie ma dostępu do innych umysłów

```bash
# Klucz umysłu A nie może odczytać wspomnień umysłu B
curl -H "Authorization: Bearer mk_aaa..." \
     "https://synapse.schaefer.zone/memory/search?q=test"
# Zwraca tylko wspomnienia umysłu A

curl -H "Authorization: Bearer mk_bbb..." \
     "https://synapse.schaefer.zone/memory/search?q=test"
# Zwraca tylko wspomnienia umysłu B (różne wyniki)
```

### Test: JWT nie może odczytać danych pamięci bezpośrednio

```bash
# JWT może wylistować umysły
curl -H "Authorization: Bearer YOUR_JWT" \
     https://synapse.schaefer.zone/minds
# Zwraca: listę umysłów

# JWT NIE MOŻE odczytać wspomnień (potrzebny Mind Key)
curl -H "Authorization: Bearer YOUR_JWT" \
     https://synapse.schaefer.zone/memory/recall
# Zwraca: 401 Unauthorized
```

## Najlepsze praktyki

> [!TIP]
> - **Używać jednego umysłu na projekt/kontekst** — izolacja jest sojusznikiem
> - **Nigdy nie współdzielić Mind Key** — zamiast tego używać Sharing API
> - **Rotować Mind Key** w razie kompromitacji (usunąć umysł, utworzyć nowy)
> - **Audytować współdzielone umysły** — okresowo przeglądać `GET /sharing`
> - **Używać JWT dla interfejsu ludzkiego** — nigdy nie udostępniać Mind Key użytkownikom końcowym

## Następne kroki

- [Autoryzacja](/docs/getting-started/authentication)
- [Mind Key vs JWT](/docs/getting-started/mind-key-vs-jwt)
- [Architektura](/docs/concepts/architecture)