यूरोप में बना, और आपका डेटा कहाँ रहता है

Nessie कहाँ बना है, आपका डेटा कहाँ रहता है, और जब आप इसे सेल्फ़-होस्ट करते हैं तो आपके नियंत्रण में क्या है।

इसे कौन बनाता है, और किस कानून के तहत

Nessie को UnlikeOtherAI s.r.o. बनाती है, जो चेक गणराज्य में पंजीकृत कंपनी है और चेक कानून के तहत काम करती है।

यह पेज बताता है कि सॉफ़्टवेयर कैसे बना है और कहाँ चलता है। यह कोई अनुपालन (compliance) घोषणा नहीं है: Nessie के पास कोई सुरक्षा प्रमाणन नहीं है, और यहाँ लिखी किसी भी बात को ऐसा नहीं समझा जाना चाहिए। कौन-सा व्यक्तिगत डेटा किस आधार पर प्रोसेस होता है, यह गोपनीयता नीति का विषय है, जो एक अलग पेज है।

होस्टेड प्रोडक्ट कहाँ चलता है

Nessie Cloud यूरोपीय होस्टिंग प्रोवाइडरों पर चलता है — Scaleway, Hetzner और अन्य। हम हर प्रोवाइडर की सबसे अच्छी सेवा चुनते हैं, इसलिए प्रोडक्ट के अलग-अलग हिस्से अलग-अलग प्रोवाइडर पर चल सकते हैं, सभी यूरोप में।

इससे अधिक सटीक जानकारी — कोई खास साइट, शहर या डेटासेंटर — यहाँ जान-बूझकर नहीं दी गई है, क्योंकि वह किसी के ध्यान में आए बिना पुरानी हो जाएगी।

सेल्फ़-होस्टिंग में चुनाव आपके हाथ में रहता है

सेल्फ़-होस्टेड इंस्टेंस कहाँ चलेगा, यह डिप्लॉयमेंट की सेटिंग है, प्रोडक्ट की नहीं। सिंगल-मशीन रास्ता एक Docker Compose स्टैक है, जिसे आप अपनी चुनी हुई मशीन पर रखते हैं। मैनेज्ड क्लाउड के Terraform ट्री में रीजन एक ऐसा इनपुट है जिसका कोई डिफ़ॉल्ट है ही नहीं: वहाँ कुछ भी अंदाज़े से तय नहीं किया जा सकता, इसलिए वहाँ किसी चीज़ का डिफ़ॉल्ट नहीं है, और डेटाबेस, ऑब्जेक्ट-स्टोरेज बकेट और सेवाएँ सब उसी रीजन का अनुसरण करती हैं जो आप बताते हैं।

इसी सवाल से जुड़ी दो संरचनात्मक बातें भी मायने रखती हैं। क्यू और रीयलटाइम ट्रांसपोर्ट, दोनों PostgreSQL हैं — रास्ते में न कोई Redis है और न कोई मैसेज ब्रोकर, इसलिए जगह तय करने के लिए कोई तीसरा सिस्टम नहीं है। और ऑब्जेक्ट स्टोरेज S3-संगत है, किसी एक वेंडर से बँधा नहीं; रेफ़रेंस डिप्लॉयमेंट एक निजी नेटवर्क पर कंटेनर में MinIO चलाता है, जिसका अपना कोई ingress नहीं है। जिन हिस्सों को कहीं न कहीं रहना ही है — डेटाबेस, ऑब्जेक्ट स्टोर और दो Node सेवाएँ — वे सब वहीं रहते हैं जहाँ आप उन्हें रखते हैं। इसे खड़ा कैसे करें, यह इंस्टॉलेशन पेज पर है।

Nessie क्या रखता है — और जान-बूझकर क्या नहीं रखता

पहचान की कॉपी नहीं बनती

UnlikeOtherAI साइन-इन के साथ, पहचान प्रोवाइडर (identity provider) लोगों की पहचान को मैनेज और स्टोर करता है — ऑथेंटिकेशन फ़ैक्टर, प्रोफ़ाइल, संगठन और टीम की सदस्यता, और आमंत्रण। Nessie एक relying party है, दूसरा पहचान सिस्टम नहीं। यह जितना आर्किटेक्चर का फ़ैसला है, उतना ही डेटा का भी: जो पहचान Nessie कभी स्टोर ही नहीं करता, वह उससे लीक नहीं हो सकती, खो नहीं सकती, और मिटाना भूला भी नहीं जा सकता।

users टेबल में असल में प्रोवाइडर का स्थिर यूज़र आइडेंटिफ़ायर रहता है — वह कुंजी जिससे बाकी सब कुछ जुड़ता है — साथ में ईमेल पता, नाम और अवतार की एक गैर-प्रामाणिक प्रति, और प्रोडक्ट-स्थानीय फ़ील्ड (प्राथमिकताएँ, सर्वनाम, सेशन रद्द करने के लिए टोकन वर्ज़न)। यह प्रति सिर्फ़ इसलिए है कि हर पंक्ति के लिए अलग अनुरोध किए बिना नाम और तस्वीर दिखाई जा सके, और इसे प्रोवाइडर के सत्यापित क्लेम से लॉगिन पर, टीम बदलने पर और सेशन रिफ़्रेश पर दोबारा सिंक किया जाता है। कोई मान गढ़ा नहीं जाता: जिस व्यक्ति का नाम प्रोवाइडर ने नहीं बताया, उसकी जगह तब तक उसका ईमेल पता दिखता है। पासवर्ड हैश सिर्फ़ ऐसे इंस्टॉल के बूटस्ट्रैप ओनर के लिए होता है जिसमें कोई पहचान प्रोवाइडर है ही नहीं।

यही बात संरचना पर भी लागू होती है। प्रोवाइडर का एक संगठन Nessie का एक संगठन है, जो प्रोवाइडर के संगठन आईडी से जुड़ा होता है; जिस टीम का कोई अपस्ट्रीम लिंक नहीं, वह स्थानीय अंदाज़े पर लौटने के बजाय 404 TEAM_NOT_LINKED लौटाती है, और लाइव रोस्टर रीड पहचान प्रोवाइडर तक जाता है और कुछ भी सहेजता नहीं।

दो प्रतियाँ अभी हटी नहीं हैं, और इसके उलट कुछ जताना बेईमानी होगी। संगठन और टीम के नाम अब भी बाइंडिंग आईडी के साथ स्थानीय रूप से सहेजे जाते हैं, और सिंक्रनाइज़ेशन के बीच सामान्य अनुरोधों को स्थानीय सदस्यता पंक्तियाँ ही अधिकृत करती हैं। दोनों को हटाना रिपॉज़िटरी में दर्ज, खुला हुआ काम है, ऐसा कुछ नहीं जो पूरा हो चुका हो।

कुछ भी व्यावसायिक नहीं

भुगतान केंद्रीय बिलिंग सेवा मैनेज करती है। Nessie पेमेंट-प्रोवाइडर का ग्राहक, सब्सक्रिप्शन, इनवॉइस, कीमत, क्रेडिट बैलेंस, टॉप-अप नीति, भुगतान की सहमति, स्टेटमेंट या रद्दीकरण की स्थिति कुछ भी स्टोर नहीं करता, और टैरिफ़ की गणना भी नहीं करता। वह तैयार रूप में दिए गए मान पढ़कर बस दिखा देता है।

सीक्रेट

कोई सीक्रेट स्टोर करने के लिए कॉन्फ़िगर किया हुआ वॉल्ट ज़रूरी है। डेटाबेस में कोई फ़ॉलबैक जान-बूझकर नहीं है और प्लेनटेक्स्ट का कोई रास्ता भी नहीं: वॉल्ट के बिना सीक्रेट सहेजना, रोटेट करना और रद्द करना, कम सुरक्षित तरीके पर उतरने के बजाय, त्रुटि लौटाता है। सीक्रेट के बारे में Nessie के अपने रिकॉर्ड में कोई मान, कोई सिफ़रटेक्स्ट, कोई कुंजी और कोई वॉल्ट टोकन नहीं होता — सिर्फ़ एक अपारदर्शी रेफ़रेंस और उसका मेटाडेटा — और वॉल्ट पाथ सिर्फ़ संरचनात्मक आइडेंटिफ़ायर से बनते हैं, कभी किसी संगठन, टीम, प्रोजेक्ट या व्यक्ति के नाम से नहीं।

OAuth क्लाइंट की तरह काम करने के लिए Nessie को जो क्रेडेंशियल खुद रखने पड़ते हैं — कनेक्टर और मेलबॉक्स के क्रेडेंशियल, वेबहुक सीक्रेट, सेशन रिफ़्रेश सामग्री, एक्ज़ीक्यूटर पेलोड — वे उद्देश्य से बँधे AES-256-GCM लिफ़ाफ़ों में सील किए जाते हैं, एक वर्ज़न वाली की रिंग के तहत जो सेशन साइनिंग सीक्रेट से अलग रूट है, और जिसकी रोटेशन प्रक्रिया दस्तावेज़ में दर्ज है।

मॉडल को लेकर भी एक नियम है: किसी सीक्रेट का होना जाना जा सकता है और उसे इस्तेमाल करने के लिए अधिकृत किया जा सकता है, पर सीक्रेट की सामग्री मॉडल के संदर्भ, प्रॉम्प्ट, टूल आर्ग्युमेंट, टूल परिणाम, मेमोरी, एम्बेडिंग, सर्च, लॉग या संदेशों में नहीं जानी चाहिए। किसी एजेंट को सीक्रेट इस्तेमाल करने की अनुमति दी जा सकती है। उसे सीक्रेट उजागर करने की अनुमति कभी नहीं दी जा सकती।

नीचे की डिस्क एन्क्रिप्टेड हैं या नहीं, यह उस मशीन की खासियत है जिस पर डिप्लॉयमेंट चलता है। रिपॉज़िटरी डेटाबेस और ऑब्जेक्ट-स्टोरेज वॉल्यूम के लिए वॉल्यूम-स्तर का एन्क्रिप्शन स्थापित नहीं करती, इसलिए यह पेज उसका दावा नहीं करता।

टेनेंट आइसोलेशन

Nessie डिज़ाइन से ही मल्टी-टेनेंट है: एक डेटाबेस, जिसमें हर पंक्ति ठीक एक संगठन की होती है और हर चाइल्ड टेबल में organization_id होता है। आइसोलेशन दो जगह लागू होता है — हर क्वेरी में लगी स्कोप क्लॉज़, और उस कॉलम पर असली फ़ॉरेन की, जिन्हें बयालीस कंस्ट्रेंट में तब जोड़ा गया जब एक आंतरिक ऑडिट में दर्जनों टेबल पर यह कॉलम मौजूद तो मिला, पर उस पर कोई कंस्ट्रेंट नहीं था।

एक कन्फ़ॉर्मेंस सूट HTTP सीमा पर इस नियम को थामे रखता है। वह अधिकतम अधिकार वाला हमलावर तैयार करता है — अपने ही संगठन का पूरा ओनर — और जाँचता है कि दूसरे संगठन के संसाधनों की हर मानक रीड 403, 404 या खाली जवाब दे, और हर मानक बदलाव अस्वीकार हो तथा दूसरे संगठन की पंक्ति जस की तस रहे। इसमें चैनल, मंज़ूरियाँ, ऑडिट लॉग, ट्रिगर, एजेंट और उनकी बाइंडिंग, रन, प्रोजेक्ट, टास्क, थ्रेड, कनेक्शन, वर्कफ़्लो इंस्टॉलेशन, MCP इंस्टेंस, नॉलेज बेस और अलर्ट शामिल हैं।

तंत्र के बारे में सटीक रहें तो: यह एप्लिकेशन-स्तर का प्रवर्तन और फ़ॉरेन की है, PostgreSQL की रो-लेवल सिक्योरिटी नहीं। कोई RLS पॉलिसी नहीं है और डेटाबेस की तरफ़ से कोई अतिरिक्त सुरक्षा नहीं है, और कन्फ़ॉर्मेंस सूट असली डेटाबेस के बजाय एक विश्वसनीय इन-मेमोरी स्टोर पर चलता है, इसलिए वह कोड की लिखी स्कोप क्लॉज़ को प्रमाणित करता है, उस SQL को नहीं जो कोई सर्वर चलाता है। रिपॉज़िटरी यह बात सूट के अपने दस्तावेज़ में कहती है, और यह पेज भी।

ऑडिट ट्रेल

हर परिणामकारी कार्रवाई दर्ज होती है: किसने और किस रूप में कार्रवाई की — व्यक्ति, एजेंट या सेवा — क्या किया, किस संसाधन पर, किस संगठन, प्रोजेक्ट, टीम या चैनल में, वह सफल रही या अस्वीकृत हुई, क्यों, और अनुरोध के साथ आया अनुरोध आईडी, पता और यूज़र एजेंट।

लॉग डिज़ाइन से ही केवल जोड़ने योग्य (append-only) है और बाहर से उसमें लिखने का कोई तरीका नहीं है: POST /api/audit-log मौजूद ही नहीं है, और यह जान-बूझकर है। प्रविष्टियाँ कड़ी में बँधी हैं — हर प्रविष्टि अपने कैनोनिकल फ़ील्ड का SHA-256 डाइजेस्ट और उस संगठन की पिछली प्रविष्टि का डाइजेस्ट साथ रखती है — इसलिए बदली या हटाई गई पंक्ति कड़ी तोड़ देती है और पकड़ी जा सकती है। संगठन का ओनर या एडमिन माँग पर इस कड़ी को जाँच सकता है, और अगर वह टूटी है, तो उसे बताया जाता है कि पहली बार कहाँ टूटी।

दो ईमानदार सीमाएँ। कड़ी लॉग को छेड़छाड़ का प्रमाण देने वाला बनाती है, छेड़छाड़ से सुरक्षित नहीं: इसके पीछे न डेटाबेस-स्तर पर लिखने का अधिकार हटाया गया है और न write-once स्टोरेज है, इसलिए गारंटी रोकथाम की नहीं, पता लगाने की है। और प्रविष्टियाँ डिफ़ॉल्ट रूप से अनिश्चित काल तक रखी जाती हैं — हटाने से पहले एक्सपोर्ट के साथ कॉन्फ़िगर करने योग्य रिटेंशन डिज़ाइन किया गया है, बना नहीं है। प्रविष्टियों में सीक्रेट या पूरे रिक्वेस्ट बॉडी रखना भी वर्जित है, और संवेदनशील मेटाडेटा फ़ील्ड के एक तय सेट के नाम भीतर आते समय छिपा दिए जाते हैं।

लागत लेजर

हर मॉडल इनवोकेशन संगठन के नाम दर्ज होता है, और उस यूज़र, टीम, प्रोजेक्ट, चैनल, एजेंट और रन के नाम भी जहाँ से वह आया, साथ में खर्च हुए टोकन, और प्रोवाइडर द्वारा बताई गई लागत व Nessie का अपना अनुमान दोनों साथ-साथ। जो मेट्रिक प्रोवाइडर नहीं बताता, वह अंदाज़े से भरने के बजाय null के रूप में रखी जाती है। रिपोर्ट संगठन का ओनर या एडमिन पढ़ सकता है।

यह लेजर ऑपरेशनल टेलीमेट्री है — संगठन ने कितना खर्च किया और किसकी ओर से। यह इनवॉइस नहीं है और बिलिंग का अधिकृत स्रोत भी नहीं।

थर्ड पार्टी, जब आप होस्टेड प्रोडक्ट इस्तेमाल करते हैं

होस्टेड डिप्लॉयमेंट सेवाओं के एक छोटे, तय समूह से बात करता है। मॉडल ट्रैफ़िक और वेब सर्च सीधे प्रोवाइडरों तक नहीं जाते: दोनों UnlikeOtherAI के चलाए एक गेटवे से निकलते हैं, जहाँ अपस्ट्रीम मॉडल और सर्च प्रोवाइडर बैठे हैं। साइन-इन और बिलिंग UnlikeOtherAI के ऑथेंटिकेटर पर जाते हैं। सीक्रेट वॉल्ट एप्लिकेशन के साथ ही सेल्फ़-होस्टेड है। सर्वर द्वारा बनाए गए वीडियो-कॉल लिंक डिफ़ॉल्ट रूप से सार्वजनिक Jitsi सेवा पर जाते हैं।

बाकी लगभग सब कुछ तब तक बंद है जब तक कोई ऑपरेटर उसे कॉन्फ़िगर न करे, और वह चुपचाप विफल होने के बजाय यह बता देता है: जुड़े हुए Google, Microsoft और Slack अकाउंट; Amazon SES पर एजेंट ईमेल, जिसे डिप्लॉयमेंट अपने ही अकाउंट में बिना किसी बिचौलिए के चलाता है; मोबाइल और ब्राउज़र पुश; रिसर्च और बोर्ड-सोर्स कनेक्टर; क्लाउड ब्राउज़र। दो बातें अलग से कहने लायक हैं, क्योंकि वे डेटा के जाने की जगह बदल देती हैं:

• जुड़े हुए मेलबॉक्स आपके प्रोवाइडर के पास ही रहते हैं। मेल आपके प्रोवाइडर से लाइव पढ़ा जाता है, IMAP और SMTP के ज़रिए या प्रोवाइडर के अपने साइन-इन से; Nessie सील किया हुआ क्रेडेंशियल रखता है, और अकाउंट के बारे में और कुछ नहीं। Clients इनबॉक्स से जोड़ा गया मेलबॉक्स इसका अपवाद है: आप चाहते हैं कि उसकी बातचीत हर ग्राहक के साथ रखी जाए, इसलिए वह कॉपी की जाती है।
• ऐप में वॉइस कॉल Nessie से होकर नहीं गुज़रतीं। API एक क्रेडेंशियल जारी करता है और क्लाइंट ऑडियो कनेक्शन खुद खोलता है। डिक्टेशन और टेलीफ़ोन कॉल अलग हैं: उनका ऑडियो Nessie से होकर उन स्पीच और मॉडल प्रोवाइडरों तक जाता है जो उसे प्रोसेस करते हैं।

इन्फ़रेंस की एक बात इसी सिद्धांत पर चलती है: हस्ताक्षरित कॉलर-आइडेंटिटी हेडर सिर्फ़ कॉन्फ़िगर किए गए चैट होस्ट को भेजे जाते हैं, इसलिए एम्बेडिंग को किसी और एंडपॉइंट की ओर मोड़ने पर भी उस एंडपॉइंट को उस व्यक्ति के बारे में कोई डेलिगेशन असर्शन नहीं मिलता जिसका टेक्स्ट एम्बेड हो रहा है।

होस्टेड प्रोडक्ट कई इन्फ़रेंस प्रोवाइडर इस्तेमाल करता है और लागत व गुणवत्ता के हिसाब से उनमें से चुनता है। एक संगठन एडमिन में चुन सकेगा कि उसके एजेंट कौन-से प्रोवाइडर इस्तेमाल कर सकते हैं: सिर्फ़ पश्चिमी, सिर्फ़ यूरोपीय, सिर्फ़ चीनी, या कोई पसंद नहीं — यानी हर काम के लिए सबसे कुशल प्रोवाइडर। सेल्फ़-होस्ट किया गया इंस्टेंस अपने प्रोवाइडर खुद चुनता है।

खुद चलाने पर यह सब बदल जाता है

ऊपर की हर थर्ड पार्टी सेल्फ़-होस्टेड इंस्टेंस पर कॉन्फ़िगरेशन का चुनाव है। इन्फ़रेंस को किसी भी OpenAI-संगत एंडपॉइंट पर मोड़ा जा सकता है, आपके अपने हार्डवेयर पर चल रहे एंडपॉइंट पर भी। कनेक्टर तब तक बंद रहते हैं जब तक आप उन्हें चालू न करें। UnlikeOtherAI साइन-इन समर्थित रास्ता है, और जिस डिप्लॉयमेंट में कोई पहचान प्रोवाइडर है ही नहीं, वह बूटस्ट्रैप ओनर के साथ एक अनबाउंड संगठन के रूप में चलता है।

इस पूरी व्यवस्था का मक़सद यही है: सॉफ़्टवेयर वही रहता है, और वह कहाँ चलेगा तथा किस तक पहुँच सकेगा, यह फ़ैसला उसी का है जो उसे चलाता है। इसका तरीका इंस्टॉलेशन पेज पर है।