Odpowiedzialne prowadzenie produktu czatu dla dorosłych: Lista kontrolna dla twórców

Kto odpowiada za co

Myśl o stosie w dwóch warstwach. API dostarcza legalną treść dla dorosłych, fikcję i kontrowersyjne tematy bez odrzucania, dla użytkowników powyżej 18. roku życia. Wszystko wokół modelu, ludzi, którzy mają do niego dostęp, zasad, do których się zobowiązują i tego, co dzieje się, gdy coś pójdzie nie tak, należy do Ciebie. Ten podział jest uwalniający, ale tylko wtedy, gdy poważnie potraktujesz swoją część.

Oto krótka tabela odpowiedzialności do powieszenia na ścianie.

Kwestia	Platforma	Twoja aplikacja
Treści seksualne z udziałem małoletnich	Zawsze blokowane (403)	Wyjaśnij to, zakończ scenę, zapobiegaj obejściom
Wiek Twoich użytkowników	Wyłącznie dla dorosłych zgodnie z regulaminem	Bramka i weryfikacja na wejściu
Zasady wewnętrzne wykraczające poza prawo	Nie stosowane	Napisz, opublikuj i egzekwuj je
Nadużycia na użytkownika	300 zapytań na minutę na klucz	Limity na użytkownika i na dzień
Klucz tajny	Wydaje go	Przechowuj go na swoim serwerze

To są wskazówki techniczne, a nie porady prawne; zasady różnią się w zależności od miejsca, więc sprawdź wymagania tam, gdzie mieszkają Twoi użytkownicy.

Bramka weryfikująca wiek, która naprawdę blokuje

Baner z przyciskiem "Mam 18 lat" to minimum, a uparty małoletni może go kliknąć. Nadal ma to znaczenie, ponieważ rejestruje oświadczenie o zgodzie i utrzymuje uczciwość Twojej polityki. Klucz polega na tym, gdzie to egzekwujesz. Jeśli sprawdzenie tylko ukrywa czat w przeglądarce, każdy może wywołać Twój endpoint bezpośrednio. Zmusz serwer do odmowy rozmowy, dopóki nie istnieje podpisany znacznik.

Copyimport crypto from "node:crypto";

// Minimal 18+ gate: the user must confirm before the chat routes work.
// Replace the confirmation with a real verification step when your market requires it.
const SECRET = process.env.GATE_SECRET;   // random string kept on the server

function sign(value) {
  return crypto.createHmac("sha256", SECRET).update(value).digest("hex");
}

export function issueAdultCookie(res, userId) {
  const stamp = String(Date.now());
  const payload = `${userId}.${stamp}`;
  res.cookie("adult_ok", `${payload}.${sign(payload)}`, {
    httpOnly: true, sameSite: "strict", secure: true, maxAge: 30 * 24 * 3600 * 1000,
  });
}

export function requireAdult(req, res, next) {
  const raw = req.cookies?.adult_ok || "";
  const [userId, stamp, sig] = raw.split(".");
  if (!sig || sign(`${userId}.${stamp}`) !== sig) {
    return res.status(403).json({ state: "age_required" });
  }
  req.userId = userId;
  next();
}

Podłącz requireAdult przed każdą trasą czatu. Dodaj silniejszą weryfikację, gdy Twój rynek lub poziom ryzyka tego wymaga, na przykład trzecią stronę weryfikacji wieku, i utrzymaj znacznik na tyle krótkotrwały, abyś mógł ponownie zapytać. Nigdy nie kieruj się do studentów lub szkół w swoim marketingu i umieść bramkę przed pokazaniem jakiejkolwiek treści dla dorosłych, w tym podglądów i przykładowych rozmów.

Pisanie własnej polityki treści

Model nie odrzuca legalnej treści dla dorosłych, więc to Ty decydujesz, co pozwala Twój produkt. Wystarczy jedna strona polityki. Omów, co jest mile widziane, co jest niedozwolone w Twojej społeczności, nawet jeśli jest legalne (na przykład nękanie realnych osób lub wyciek danych osobowych), jak użytkownicy mogą zgłaszać problemy i jakie działania podejmujesz: ostrzeżenia, tymczasowe wyciszenia, bana.

1. Opublikuj ją tam, gdzie użytkownicy się logują, w prostym języku.
2. Zaplanuj to w swoim prompt systemowym. Linia taka jak "Wszystkie postacie są dorosłe; zakończ każdą scenę, która staje się bez zgody lub dotyczy realnych, nazwanych osób" utrzymuje bota zgodnym z Twoimi zasadami.
3. Uczyń egzekwowanie nudnym. Zdecyduj o progach z góry, aby moderatorzy nie improwizowali.
4. Przejrzyj politykę co kwartał, gdy Twój produkt się rozwija.

Ścieżka zgłoszeń dostępna dla użytkowników

Dodaj mały przycisk zgłoszenia do każdej wiadomości i spraw, aby działał bez konieczności logowania. Gdy ktoś zgłosi odpowiedź, złap minimum potrzebne do działania: identyfikator użytkownika, identyfikator wiadomości, krótki powód i znacznik czasu. Przekieruj to do kolejki, którą obserwują moderatorzy.

Copyapp.post("/api/report", requireAdult, express.json(), (req, res) => {
  const { messageId, reason } = req.body;
  // Store only what you need to act on: who, which message, why, when.
  queueForModerator({ userId: req.userId, messageId, reason: String(reason).slice(0, 500), at: Date.now() });
  res.json({ ok: true });
});

Trzymaj się wąskich obietnic. Powiedz użytkownikom dokładnie, co wyzwala zgłoszenie i przechowuj tylko to, czego wymaga Twoja polityka i obowiązujące przepisy. Przeglądaj, jak długo przechowujesz zgłoszenia i usuwaj je zgodnie z harmonogramem. Potwierdzaj każde zgłoszenie osobie, które je złożyła, nawet jednowierszowym podziękowaniem, ponieważ użytkownicy przestają zgłaszać, gdy wydaje się, że nic się nie dzieje. Śledź, jak szybko moderatorzy zamykają sprawy i ustaw cel, który możesz realnie osiągnąć.

Projektowanie pod blokowanie małoletnich 403

Treści seksualne z udziałem małoletnich są zawsze blokowane, zarówno w fikcji, jak i w odgrywaniu ról, a API odpowiada kodem 403 i kodem content_blocked. Nie ponawiaj tego i nie próbuj przeformułować po stronie użytkownika. Zamiast tego traktuj to jako moment produktowy, który zasługuje na jasny design.

• Przetłumacz to na serwerze na stan, który zna Twój interfejs, więc surowy tekst z upstreamu nigdy nie trafi na ekran.
• Powiedz, co się stało w jednym spokojnym zdaniu i wymień zasadę.
• Zakończ lub zresetuj scenę. Opcja „kontynuuj mimo wszystko” podważa sens działania.
• Zaloguj zdarzenie z identyfikatorem użytkownika, aby powtarzające się próby mogły uruchamiać Twoje mechanizmy egzekwowania.
• Nie zgaduj intencji. Niektóre bloki wynikają z niejednoznacznej formułki; neutralna wiadomość działa w obu przypadkach.

Copy// server: translate upstream outcomes into states your UI understands
if (upstream.status === 403) {
  return res.status(403).json({
    state: "content_blocked",
    message: "That request breaks our rules, so we can't continue this scene.",
  });
}
if (upstream.status === 402) return res.status(503).json({ state: "paused" });
if (upstream.status === 503) return res.status(503).json({ state: "busy" });

Copy// browser: show a calm, specific message for each state
const MESSAGES = {
  content_blocked: "This scene can't continue. Sexual content involving minors is never allowed. Start a new chat any time.",
  age_required: "Please confirm you are 18 or older to use the chat.",
  slow_down: "You're sending messages quickly. Give it a few seconds.",
  daily_limit: "You've reached today's message allowance. Come back tomorrow.",
  paused: "Chat is briefly unavailable. We're on it.",
  busy: "The service is busy. Try again in a moment.",
};

async function send(messages) {
  const res = await fetch("/api/chat", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ messages }),
  });
  if (!res.ok) {
    const info = await res.json().catch(() => ({}));
    showBanner(MESSAGES[info.state] || "Something went wrong.");
    if (info.state === "content_blocked") endCurrentScene();
    return null;
  }
  return res;
}

Kontrola nadużyć i limitów na użytkownika

Twój pojedynczy klucz API pozwala na 300 zapytań na minutę łącznie, dzielonych przez wszystkich użytkowników. Jedno konto skryptowe może zagłodzić wszystkich innych, więc egzekwuj limity uczciwego użytkowania samodzielnie, znacznie poniżej tego limitu. Przykład ogranicza każdego użytkownika do 12 wiadomości na minutę i przydziela mu dzienny budżet tokenów mierzony od figury usage w końcowym czacie strumieniowym.

Copyconst WINDOW_MS = 60_000;
const PER_USER_PER_MIN = 12;       // your product rule, far below the key's 300
const DAILY_TOKEN_BUDGET = 60_000; // per user, tracked from the usage chunk

const hits = new Map();            // userId -> array of timestamps
const spent = new Map();           // userId -> tokens used today

export function userLimit(req, res, next) {
  const now = Date.now();
  const recent = (hits.get(req.userId) || []).filter((t) => now - t < WINDOW_MS);
  if (recent.length >= PER_USER_PER_MIN) {
    return res.status(429).json({ state: "slow_down" });
  }
  if ((spent.get(req.userId) || 0) >= DAILY_TOKEN_BUDGET) {
    return res.status(429).json({ state: "daily_limit" });
  }
  recent.push(now);
  hits.set(req.userId, recent);
  next();
}

export function recordUsage(userId, totalTokens) {
  spent.set(userId, (spent.get(userId) || 0) + totalTokens);
}

W produkcji przechowuj liczniki w wspólnym magazynie zamiast w pamięci procesu, aby limity przetrwały restarty i działały na wielu serwerach. Dodaj umiarkowany max_tokens do każdego zapytania, aby ograniczyć najgorszy przypadek, i obserwuj 402 na swoim własnym saldzie. Darmowy kredyt próbny za $0.50 na 7 dni to miły sposób na przetestowanie tych kontroli przed przybyciem prawdziwego ruchu.

Przechowuj klucz na serwerze

Nigdy nie wysyłaj klucza w pakietach front-end, aplikacjach mobilnych ani publicznych repozytoriach. Przechowuj go jako zmienną środowiskową lub w menedżerze sekretów, ładuj tylko w swoim backendzie i wyklucz go z logów i raportów o błędach. Jeśli podejrzewasz ujawnienie, wygeneruj go ponownie ze swojego konta; stary klucz przestaje działać natychmiast, więc miej gotowe wdrożenie. Pamiętaj, że jeden klucz przypisany jest do konta, co czyni warstwę proxy jeszcze cenniejszą. web chat tutorial pokazuje ten wzorzec od początku do końca, a docs wymieniają kody błędów, które Twój wrapper powinien mapować.

Checklista przed uruchomieniem

Przejdź przez tę listę dzień przed otwarciem drzwi. Każda pozycja zajmuje kilka minut i zapobiega klasie problemów, które są bolesne do naprawienia po przybyciu użytkowników.

1. Spróbuj złamać bramę. Wywołaj trasę czatu za pomocą curl bez ciasteczka. Powinna zwrócić 403 z age_required, a nie odpowiedź modelu.
2. Uruchom każdy stan. Podmień upstream tak, aby zwracał kolejno 402, 403, 429 i 503, i potwierdź, że każdy z nich wyświetla odpowiedni baner i nie wycieka surowego tekstu błędu.
3. Przeczytaj swoją politykę na głos. Jeśli moderator nie jest w stanie rozstrzygnąć przypadku na jej podstawie w ciągu minuty, doprecyzuj sformułowania.
4. Przetestuj przycisk zgłoszenia z ekranu telefonu. Kontrolka, do której trudno dotrzeć, nie liczy się jako ścieżka zgłoszeniowa.
5. Wyszukaj klucz w repozytorium. Sprawdź foldery frontendowe, wyniki budowania, przykładowe konfiguracje i historię commitów. Wygeneruj go ponownie, jeśli znajdziesz go gdziekolwiek publicznie.
6. Ustaw alerty. Powiadom o błędzie 402, skoku blokad 403 od jednego użytkownika oraz wzroście dziennego zużycia tokenów.
7. Przygotuj przełącznik pauzy. Pojedyncza flaga, która wyłącza czat w sposób elegancki, jest nieoceniona podczas incydentu.

Bezpieczeństwo nigdy nie jest zakończone, ani lista; dodawaj elementy za każdym razem, gdy incydent nauczy Cię czegoś nowego, i dziel się nimi z każdym, kto dołączy do Twojego zespołu. Przeglądaj listę, gdy dodajesz funkcje takie jak przesyłanie obrazów w swoim własnym UI, pokoje grupowe lub publiczne udostępnianie postaci, ponieważ każda z nich otwiera nowe ścieżki nadużyć. Aby uzyskać pomoc w kształtowaniu samych postaci, przeczytaj persona design guide i trzymaj podstawy notatek integracyjnych w docs pod ręką, gdy Twój zespół rośnie.