डोमेन के लिए llms.txt: ऐसा API जिसे कोई भी AI एजेंट पढ़ सके

namefi.io/llms.txt का विस्तृत परिचय: कैसे एक सादा-टेक्स्ट फ़ाइल किसी भी AI एजेंट को रजिस्ट्रार का पूरा API खोजने और इस्तेमाल करने देती है, और यह MCP के साथ कैसे काम करती है।

Aileen Wright

Victor Zhou

Nirmit Buddhiraja10 जुल॰ 2026लगभग 12 मिनट पढ़ाई

ai-agents
domains
explainer

X पर शेयर करें

API रखने वाले हर रजिस्ट्रार के दस्तावेज़ कहीं न कहीं मौजूद होते हैं: किसी दस्तावेज़ीकरण साइट पर, किसी संदर्भ पृष्ठ पर या शायद लॉगिन के पीछे रखे OpenAPI स्पेसिफ़िकेशन में। दो दशकों तक इतना काफ़ी था, क्योंकि पाठक कोई मानव डेवलपर होता था जो इधर-उधर क्लिक कर सकता था और नेविगेशन के अतिरिक्त इंटरफ़ेस को तेज़ी से पार करके अपने काम का एक ज़रूरी अनुच्छेद खोज सकता था। इनफ़रेंस के समय उसी साइट को पढ़ रहे AI एजेंट के पास यह सुविधा नहीं होती—उसका कॉन्टेक्स्ट बजट तय है, JavaScript से रेंडर होने वाले दस्तावेज़ पोर्टल के लिए धैर्य नहीं है और हार मानने या ऐसा एंडपॉइंट गढ़ देने से पहले, जो मौजूद ही नहीं है, उसे एक ही प्रयास में समझना होता है कि API क्या करता है।

llms.txt इसी समस्या का समाधान है और Namefi इसे namefi.io/llms.txt पर प्रकाशित करता है। इस लेख में बताया गया है कि यह प्रथा क्या है, इसकी ज़रूरत क्यों पड़ी, हमारी अपनी फ़ाइल में हर सेक्शन में क्या है, वह जानबूझकर कहाँ रुकती है और Model Context Protocol (MCP) से प्रतिस्पर्धा करने के बजाय उसके साथ कैसे काम करती है। इसकी बनावट ही इसे अपनी बताई चीज़ का उदाहरण भी बनाती है: एक सार्वजनिक API विक्रेता अपनी मशीन-पठनीय खोज फ़ाइल को सरल गद्य में समझा रहा है।

एजेंट आपकी दस्तावेज़ साइट को बस क्रॉल क्यों नहीं कर सकते

llms.txt का तर्क अनुमान पर आधारित नहीं है—प्रस्ताव में इसे सीधे बताया गया है। Jeremy Howard का मूल लेख उस बाधा से शुरू होता है जिसने इसे प्रेरित किया: "बड़े भाषा मॉडल वेबसाइट की जानकारी पर लगातार अधिक निर्भर हो रहे हैं, लेकिन उनके सामने एक गंभीर सीमा है: उनकी कॉन्टेक्स्ट विंडो इतनी छोटी होती हैं कि अधिकांश वेबसाइटों को पूरा समेट नहीं सकतीं। नेविगेशन, विज्ञापनों और JavaScript वाले जटिल HTML पृष्ठों को LLM-अनुकूल सादा टेक्स्ट में बदलना कठिन भी है और अशुद्ध भी।"

यह दो समस्याओं का मेल है। किसी वास्तविक दस्तावेज़ साइट में नेविगेशन, बदलावों की सूची, मार्केटिंग कॉपी और कुकी बैनर होते हैं; किसी एक काम के लिए एजेंट को चाहिए मुट्ठी भर अनुच्छेद, जबकि बाकी लगभग सब शोर है। और इस शोर का काफ़ी हिस्सा JavaScript के पीछे रहता है, जिसे हेडलेस फ़ेच कभी चलाता ही नहीं; इसलिए एजेंट के HTTP क्लाइंट को वह पृष्ठ भी नहीं दिखता जो मानव को दिखता है। llms.txt दोनों से बच निकलती है: यह एक ही सादा-टेक्स्ट Markdown फ़ाइल है, जिसे क्रॉल करके छोटा करने के बजाय पूरा पढ़ने के लिए बनाया गया है।

`robots.txt` से तुलना और उसकी सीमा

robots.txt और वेब इंफ़्रास्ट्रक्चर समझने वाले व्यक्ति को llms.txt का स्थान बताने का सबसे तेज़ तरीका दोनों की तुलना करना है, और एक सीमा तक यह उचित भी है। robots.txt वेब क्रॉलर को निर्देश देने के लिए होती है—साइट के अपने शब्दों में, "वेबसाइट के मालिक अपनी साइट के बारे में वेब रोबोट को निर्देश देने के लिए /robots.txt फ़ाइल का उपयोग करते हैं; इसे Robots Exclusion Protocol कहा जाता है।" दोनों फ़ाइलें अनुमान लगाने योग्य रूट पाथ पर रहती हैं, दोनों सादा टेक्स्ट हैं और दोनों मानव के बजाय स्वचालित पाठकों को संबोधित करती हैं।

यह तुलना उद्देश्य के मामले में टूट जाती है। robots.txt लगभग पूरी तरह नकारात्मक निर्देश है—Disallow: /some-path क्रॉलर को बताता है कि उसे क्या नहीं छूना चाहिए। llms.txt सकारात्मक है: यह साइट क्या है और पढ़ने लायक हिस्से कहाँ हैं। यह बाड़ कम और ऐसे पाठक के लिए विषय-सूची अधिक है जो पूरी किताब पर सरसरी नज़र नहीं डाल सकता। दोनों एक-दूसरे की पूरक हैं और Namefi की साइट दोनों चलाती है।

स्पेसिफ़िकेशन वास्तव में क्या माँगता है

llms.txt मनमाने फ़ॉर्मेट में नहीं होती; प्रस्ताव क्रम से एक विशिष्ट Markdown संरचना तय करता है: वैकल्पिक बाइट-ऑर्डर मार्क, साइट के नाम वाला आवश्यक H1, ब्लॉककोट में सारांश, बिना हेडिंग वाले शून्य या अधिक विवरण सेक्शन और [name](url): notes लिंक वाले H2 से अलग किए गए शून्य या अधिक "फ़ाइल सूची" सेक्शन। एक H2 हेडिंग का विशेष अर्थ है: Optional नाम का सेक्शन संकेत देता है कि "यदि आपको छोटा कॉन्टेक्स्ट चाहिए तो यहाँ दिए URL छोड़े जा सकते हैं।" Namefi की फ़ाइल ठीक इसी हेडिंग का उपयोग करके वही करती है जो स्पेसिफ़िकेशन बताता है।

namefi.io/llms.txt का क्रमवार अवलोकन

यहाँ लाइव फ़ाइल को हर सेक्शन के अनुसार टिप्पणियों के साथ समझाया गया है—उसमें वास्तव में क्या है, सीधे क्या उद्धृत किया गया है और पहली बार पढ़ रहे एजेंट के लिए हर हिस्सा उस रूप में क्यों बनाया गया है।

सेक्शन (जैसा फ़ाइल में दिखता है)	उसमें क्या लिखा है	उसे उस रूप में क्यों बनाया गया है
H1 + ब्लॉककोट	`# Namefi API` / `> Namefi lets you register traditional domains as NFTs and manage their DNS records via API.`	स्पेसिफ़िकेशन की माँगी हुई शुरुआत—एक ऐसी पंक्ति जिस पर एजेंट कुछ और न पढ़े तब भी कार्रवाई कर सकता है।
सारांश के भीतर MCP संकेतक	`MCP server (every operation below as MCP tools): https://api.namefi.io/mcp — discovery descriptor at https://namefi.io/.well-known/mcp/servers.json`	सबसे तेज़ रास्ते—लाइव प्रोटोकॉल कनेक्शन—को सादा-टेक्स्ट रास्ते से पहले, शुरुआती तीन पंक्तियों में रखता है।
`## Base URLs`	`https://api.namefi.io/v-next/`	एक पंक्ति, कोई गद्य नहीं—कच्ची HTTP कॉल बना रहे एजेंट को ठीक यही चाहिए।
`## MCP Server (for AI agents)`	"यदि आपका क्लाइंट इसका समर्थन करता है तो MCP को प्राथमिकता दें… Claude Code में जोड़ें: `claude mcp add --transport http namefi https://api.namefi.io/mcp --header "x-api-key: YOUR_KEY"`"	प्राथमिकता स्पष्ट करता है और अनुच्छेद की जगह कॉपी-पेस्ट किया जा सकने वाला एक कमांड देता है।
`## Authentication`	"https://namefi.io/api-key… पर कुंजी बनाएँ। यह सभी ऑपरेशनों के लिए काम करती है… सीधा HTTP उपयोग (AI एजेंटों के लिए सुझाया गया): हेडर सीधे भेजें—SDK की ज़रूरत नहीं"	पाठक को स्पष्ट बताता है कि किसी लिखने वाली कॉल को प्रमाणित करने के लिए SDK, OAuth की जटिल प्रक्रिया या ब्राउज़र सेशन की ज़रूरत नहीं है।
`## Domain Registration`	तीन चरणों की `curl` शृंखला: उपलब्धता जाँचें, `POST /v-next/orders/register-domain` भेजें, फिर अंतिम स्थिति मिलने तक `GET /v-next/orders/{orderId}` पोल करें	मूल लेन-देन को अनुरोध/प्रतिक्रिया संरचना के गद्य वर्णन के बजाय चलाए जा सकने वाले कमांड के रूप में दिखाता है।
`## DNS Record Management`	ग्यारह एंडपॉइंट की तालिका (`GET`/`POST`/`PUT`/`DELETE` के साथ `/v-next/dns/records`, `/v-next/dns/park`, `/v-next/dns/forwarding` आदि), जिसमें मेथड, पाथ, प्रमाणीकरण और एक-पंक्ति का वर्णन है	संदर्भ डेटा—कई समान एंडपॉइंट—ग्यारह अनुच्छेदों के बजाय तालिका में जाता है।
समस्या-समाधान नोट	"UNAUTHORIZED (401): आपकी API कुंजी अमान्य है, उसकी अवधि समाप्त हो चुकी है या वह डोमेन मालिक के वॉलेट से संबद्ध नहीं है… रिकॉर्ड सत्यापन त्रुटियाँ: जाँचें कि `zoneName` के अंत में डॉट न हो और CNAME/MX/NS प्रकारों के `rdata` के अंत में डॉट हो…"	एजेंट को सबसे पहले मिलने की संभावना वाले विफलता प्रकारों का अनुमान लगाकर, सामान्य स्टेटस तालिका के बजाय कारण और समाधान देता है।
`## Optional`	TypeScript SDK दस्तावेज़, `@namefi/api-client` npm पैकेज, मशीन-पठनीय OpenAPI 3 स्पेसिफ़िकेशन, आउटबाउंड-एजेंट गाइड और साइनर-न्यूट्रल सहायक स्क्रिप्ट की GitHub रिपॉज़िटरी के लिंक	स्पेसिफ़िकेशन का अपना "छोटा कॉन्टेक्स्ट चाहिए तो इसे छोड़ दें" सेक्शन—ऊपर के मूल प्रवाह की पूर्व-आवश्यकताएँ नहीं, बल्कि अधिक गहराई वाले संसाधन।

फ़ाइल अंत में namefi.io/llms-full.txt की ओर संकेत करती है, जिसमें यही सामग्री Web3 भुगतान प्रवाह और उस आउटबाउंड गाइड सहित एक ही दस्तावेज़ में इनलाइन है, जिन्हें रूट फ़ाइल केवल लिंक करती है। यह विभाजन स्पेसिफ़िकेशन के अपने दो-स्तरीय पैटर्न को दोहराता है: प्रवेश बिंदु को इतना छोटा रखें कि वह आराम से कॉन्टेक्स्ट में समा जाए, और अधिक चाहिए तो एजेंट को एक लिंक पर आगे जाने दें।

सहायक फ़ाइलें: Web3 और MCP खोज

रूट फ़ाइल API के उन हिस्सों के लिए सहायक फ़ाइलें लिंक करती है जो किसी सामान्य प्रवेश बिंदु में नहीं होने चाहिए। namefi.io/web3/llms.txt उन भुगतान रास्तों का दस्तावेज़ीकरण करती है जिनकी API कुंजी के बजाय वॉलेट रखने वाले एजेंट को ज़रूरत होती है: एक x402 प्रवाह, जिसमें GET /x402/domain/{domainName} तब तक कीमत के साथ 402 Payment Required लौटाता है जब तक साइन किया हुआ X-PAYMENT हेडर नहीं जोड़ा जाता; mppx CLI से साइन किया गया MPP (Machine Payable Protocol) चुनौती-प्रतिक्रिया विकल्प; और स्मार्ट-कॉन्ट्रैक्ट वॉलेट को शामिल करने वाला मैन्युअल EIP-712 साइनिंग रास्ता। फ़ाइल स्पष्ट कहती है कि x402 रजिस्ट्रेशन के लिए "Namefi अकाउंट या EIP-712 साइनिंग की ज़रूरत नहीं—खरीदार का वॉलेट EIP-3009 transferWithAuthorization को साइन करता है।" केवल API कुंजी चाहने वाले एजेंट को इसमें से कुछ भी लोड नहीं करना पड़ता।

MCP पक्ष की अपनी खोज फ़ाइल है, जो llms.txt से पूरी तरह अलग है: namefi.io/.well-known/mcp/servers.json। यह Markdown के बजाय एक छोटा JSON डिस्क्रिप्टर है:

{
  "servers": [
    {
      "name": "namefi-api",
      "transport": "streamable-http",
      "url": "https://api.namefi.io/mcp",
      "authentication": {
        "type": "apiKey",
        "in": "header",
        "name": "x-api-key"
      },
      "documentation": "https://namefi.io/llms.txt"
    }
  ]
}

यह डिस्क्रिप्टर .well-known/ के अंतर्गत रहता है। मशीन द्वारा खोजे जा सकने वाले मेटाडेटा के लिए यही प्रथा /.well-known/security.txt भी अपनाती है—यह llms.txt के Markdown-गद्य दृष्टिकोण का अधिक सीमित, JSON-टाइप वाला सहायक है। इसका अंतिम फ़ील्ड वापस llms.txt की ओर संकेत करता है, इसलिए MCP सर्वर पहले खोज लेने वाले एजेंट के पास भी यह सरल-टेक्स्ट व्याख्या पाने का रास्ता रहता है कि वे टूल क्या करते हैं।

क्या शामिल है, क्या छोड़ा गया है और क्यों

कुछ विकल्प जानबूझकर चुने हुए दिखते हैं। लगभग हर ऑपरेशन अनुरोध स्कीमा समझाने वाले अनुच्छेद के बजाय चलाया जा सकने वाला curl कमांड है—फ़ाइल ऐसी चीज़ के लिए लिखी गई है जो कोड चलाती है, न कि ऐसी चीज़ के लिए जो अपना सारांश लिखती है। रूट फ़ाइल सब कुछ शामिल करने के बजाय बाहर लिंक करती है और llms-full.txt केवल संदर्भित सामग्री को इनलाइन करती है—स्पेसिफ़िकेशन का अपना आकार-प्रबंधन पैटर्न अक्षरशः लागू किया गया है। ## Optional सेक्शन Markdown के साथ पूर्ण OpenAPI 3 स्पेसिफ़िकेशन लिंक करता है, इसलिए सख़्त टाइप वाला स्कीमा चाहने वाले टूल को प्राथमिक पढ़ने के रास्ते में अव्यवस्था किए बिना वह मिल जाता है। और वॉलेट-आधारित भुगतान—x402, MPP, EIP-712—अपनी अलग फ़ाइल में रहता है, जिससे API-कुंजी प्रमाणीकरण और रजिस्ट्रेशन किसी भी एजेंट के पढ़ने की पहली चीज़ बने रहते हैं।

llms.txt और MCP: खोज बनाम कनेक्शन

हर हिस्सा क्या करता है, इसे सटीक रूप से समझना ज़रूरी है। llms.txt एक दस्तावेज़ है—एजेंट इसे एक बार फ़ेच करता है और जान जाता है कि API क्या है और अधिक गहरे संसाधन कहाँ हैं; जब तक कोई इसकी बात पर कार्रवाई न करे, यह निष्क्रिय टेक्स्ट है। प्रोटोकॉल के अपने वर्णन में MCP "AI ऐप्लिकेशन को बाहरी सिस्टम से जोड़ने का एक ओपन-सोर्स मानक" है—एक लाइव सेशन जिसे क्लाइंट सर्वर के साथ खोलता है और जिसके ज़रिए वह कॉल किए जा सकने वाले टूल की सूची पाता और उन्हें चलाता है।

Namefi की फ़ाइल इस संबंध को सीधे दिखाती है: llms.txt एजेंट को बताती है कि api.namefi.io/mcp पर MCP सर्वर मौजूद है और जुड़ने के लिए claude mcp add कमांड देती है। फ़ाइल पढ़ें, जानें कि लाइव टूल इंटरफ़ेस मौजूद है, जुड़ें और कार्रवाई करें। सीधे MCP पर जाने वाला एजेंट फिर भी .well-known/mcp/servers.json के ज़रिए सर्वर खोज सकता है—लेकिन उस डिस्क्रिप्टर का documentation फ़ील्ड वापस llms.txt की ओर संकेत करता है, इसलिए दोनों वास्तव में अलग-थलग होकर शायद ही कभी काम करते हैं।

दूसरे API विक्रेताओं के लिए मार्गदर्शन

कारगर llms.txt प्रकाशित करने के लिए अपने दस्तावेज़ों को नए सिरे से बनाने की ज़रूरत नहीं है:

H1, सारांश और सबसे तेज़ कनेक्शन तरीका शुरुआत में रखें—छोटे कॉन्टेक्स्ट वाला एजेंट शायद शुरुआती कुछ पंक्तियों से आगे कभी न पढ़े।
स्कीमा के गद्य के बजाय चलाए जा सकने वाले अनुरोध दिखाएँ। वास्तविक फ़ील्ड नाम वाला curl कमांड JSON बॉडी समझाने वाले अनुच्छेद से बेहतर है।
टीम की संरचना के बजाय आकार के अनुसार बाँटें। छोटी रूट फ़ाइल, उसका अधिक पूर्ण विस्तार और भुगतान जैसे विषयों की अलग फ़ाइलें आम रास्ते को छोटा रखती हैं।
केवल स्टेटस कोड नहीं, वास्तविक विफलता प्रकार दर्ज करें—किसी कॉल के 401 के बजाय 403 लौटाने का कारण उन अंकों से अधिक मायने रखता है।
छोड़ी जा सकने वाली हर सामग्री के लिए ## Optional हेडिंग इस्तेमाल करें, जैसा स्पेसिफ़िकेशन में तय है।
यदि आप MCP सर्वर चलाते हैं तो llms.txt के साथ MCP खोज डिस्क्रिप्टर प्रकाशित करें—एक "यह क्या है" का और दूसरा "मैं कैसे जुड़ूँ" का उत्तर देता है।

अक्सर पूछे जाने वाले प्रश्न

llms.txt क्या है?

यह प्रस्तावित प्रथा है—औपचारिक IETF या W3C मानक नहीं—जिसके तहत वेबसाइट के रूट पर सादा-टेक्स्ट Markdown फ़ाइल प्रकाशित की जाती है। वह AI एजेंट को बताती है कि साइट या API क्या है और अधिक विवरण कहाँ मिलेगा। यह एक निश्चित क्रम तय करती है: H1 शीर्षक, ब्लॉककोट सारांश, वैकल्पिक विवरण अनुच्छेद और H2 से अलग की गई लिंक सूचियाँ; इनमें "Optional" हेडिंग छोड़ी जा सकने वाली सामग्री के लिए आरक्षित है।

llms.txt, robots.txt से कैसे अलग है?

robots.txt Robots Exclusion Protocol के तहत वेब क्रॉलर को दिया गया नकारात्मक निर्देश है—क्या इंडेक्स नहीं करना है। llms.txt सकारात्मक है—साइट क्या है और क्या पढ़ने लायक है। वे अलग-अलग स्वचालित पाठकों के लिए हैं और आम तौर पर एक ही साइट पर साथ रहती हैं।

क्या llms.txt, MCP की जगह लेती है?

नहीं। llms.txt वह दस्तावेज़ है जिसे एजेंट एक बार पढ़कर समझता है कि API क्या करता है; MCP वह लाइव प्रोटोकॉल कनेक्शन है जिसे उसका क्लाइंट वास्तव में API के ऑपरेशन कॉल करने के लिए खोलता है। Namefi दोनों प्रकाशित करता है और सबसे पहले llms.txt ही एजेंट को बताती है कि MCP सर्वर मौजूद है।

Namefi की llms.txt फ़ाइल में क्या है?

बेस URL, MCP सर्वर संकेतक, API-कुंजी प्रमाणीकरण सेक्शन, चलाए जा सकने वाले curl उदाहरणों के साथ तीन-चरण वाला डोमेन-रजिस्ट्रेशन प्रवाह, DNS रिकॉर्ड प्रबंधन एंडपॉइंट तालिका, डोमेन-कॉन्फ़िगरेशन एंडपॉइंट, समस्या-समाधान सेक्शन और SDK, OpenAPI स्पेसिफ़िकेशन तथा वॉलेट भुगतान और आउटबाउंड वर्कफ़्लो की सहायक फ़ाइलों को लिंक करने वाला "Optional" सेक्शन।

क्या मैं AI एजेंट के बिना स्वयं llms.txt पढ़ सकता हूँ?

हाँ—यह सादा Markdown है, इसलिए मॉडल के साथ-साथ मनुष्य भी इसे पढ़ सकता है। namefi.io/llms.txt संक्षिप्त API त्वरित-संदर्भ की तरह पढ़ी जाती है; जो स्पष्टता मनुष्य को तेज़ी से समझने में मदद करती है, वही मॉडल को इसे सही ढंग से पार्स करने में भी मदद करती है।

स्रोत और आगे पढ़ने के लिए

llmstxt.org — /llms.txt फ़ाइल: पृष्ठभूमि, प्रस्ताव और फ़ॉर्मेट स्पेसिफ़िकेशन
robotstxt.org — /robots.txt के बारे में: "संक्षेप में"
modelcontextprotocol.io — Model Context Protocol (MCP) क्या है?
Namefi — namefi.io/llms.txt (इस लेख के हर टिप्पणी-सहित उद्धरण का प्राथमिक स्रोत)
Namefi — namefi.io/web3/llms.txt (x402, MPP और EIP-712 वॉलेट-भुगतान प्रवाह)
Namefi — namefi.io/.well-known/mcp/servers.json (MCP खोज डिस्क्रिप्टर)
Namefi — namefi.io/llms-full.txt (Web3 और आउटबाउंड सहायक फ़ाइलों को इनलाइन करने वाला एकल-फ़ाइल विस्तार)
IETF — RFC 8615, वेल-नोन यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर (.well-known/ प्रथा)

फ़ाइल स्वयं पढ़ें

llms.txt को समझने का सबसे तेज़ तरीका ऐसी किसी फ़ाइल को स्वयं खोलना है। namefi.io/llms.txt सार्वजनिक है, इसके लिए प्रमाणीकरण नहीं चाहिए और यह इतनी छोटी है कि इसे उतने समय में पढ़ा जा सकता है जितना यह लेख पढ़ने में लगा—Namefi से जुड़ने वाला हर AI एजेंट सबसे पहले यही फ़ाइल पढ़ता है। इसके पीछे MCP टूल वास्तव में क्या करते हैं, यह जानने के लिए Namefi MCP सर्वर: AI एजेंटों के लिए डोमेन टूल देखें; एडिटर से जुड़ने के लिए Namefi MCP क्विकस्टार्ट: Claude Code, Cursor और Windsurf देखें; और किसी एजेंट को पूरा प्रवाह चलाते देखने के लिए Namefi पर अपने AI एजेंट से डोमेन कैसे रजिस्टर करें पढ़ें।

योगदानकर्ता

Aileen Wrightलेखक

कला और इतिहास लेखिका • Namefi

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

अक्सर वे हाथ में पेपरबैक लिए सेंट्रल पार्क में मिल जाएँगी, या किसी सार्वजनिक वाचन कक्ष की शांति में यह खोजती हुई कि कोई नाम वास्तव में आया कहाँ से है — न कि नामों की किसी सूची में उसका अर्थ क्या बताया गया है। वे खुद से कोडिंग भी सीख रही हैं, जिसने उन्हें वर्तनी, क्रम और उन छोटी बातों को लेकर असामान्य रूप से सटीक बना दिया है जो तय करती हैं कि कोई नाम समय के साथ भी अच्छा लगेगा या नहीं।

Namefi के लिए वे डोमेन नामों के पीछे के इतिहास और संस्कृति, नाम बदलते समय ब्रांड अपने साथ जो कहानियाँ लेकर चलते हैं, और एक अच्छी कहानी व सत्यापित स्रोत के बीच के अंतर के बारे में लिखती हैं।

Victor Zhouसंपादक

संस्थापक और मानक संपादक • Namefi

Victor Zhou डिजिटल पहचान और भरोसे पर केंद्रित टेक्नोलॉजी उद्यमी और मानक संपादक हैं। उन्होंने Namefi की स्थापना की, Ethereum Improvement Proposals का संपादन करते हैं और इससे पहले Google Labs में स्मार्ट-कॉन्ट्रैक्ट आर्किटेक्चर के काम का नेतृत्व कर चुके हैं।

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

Namefi के लिए Victor टिकाऊ डिजिटल पहचान के रूप में डोमेन पर संपादन और लेखन करते हैं: नाम कैसे मालिकाना हक़ वाले ऑनचेन एसेट बनते हैं, टोकनाइज़ेशन कस्टडी और भरोसे को कैसे बदलता है, और नामकरण उन प्रणालियों से क्या सीख सकता है जिनका उपयोग लोग ऑनलाइन अपनी पहचान स्थापित करने के लिए करते हैं।

Nirmit Buddhirajaअनुवादक

हिंदी लोकलाइज़ेशन अनुवादक • Namefi

Nirmit Buddhiraja (निर्मित बुद्धिराजा) बीसवें दशक के उत्तरार्ध के अनुवादक हैं, जो जयपुर में पले-बढ़े और अब बेंगलुरु से काम करते हैं। मैकेनिकल इंजीनियरिंग में स्नातक होने के बाद वे IT सपोर्ट में गए और फिर अंग्रेज़ी व हिंदी के बीच तकनीकी और संपादकीय सामग्री को लोकलाइज़ करने लगे।

वे उसी हिंग्लिश रजिस्टर में काम करते हैं जिसमें ज़्यादातर भारतीय पाठक सचमुच सोचते हैं। शुद्ध हिंदी या शुद्ध अंग्रेज़ी थोपने के बजाय, जहाँ स्वाभाविक लगे वहाँ वे लिपि बदलते हैं। रविवार का गली क्रिकेट, चाय-समोसे के ब्रेक और सप्ताहांत की ट्रेकिंग उनके लिए ज़रूरी हैं।

Namefi के लिए वे डोमेन और नामकरण से जुड़े लेखों को हिंदी में लोकलाइज़ करते हैं — देवनागरी IDN, .in और .bharat नेमस्पेस, और लिप्यंतरण के उन फैसलों का ध्यान रखते हुए जो तय करते हैं कि कोई ब्रांड नाम एक साथ दो लिपियों में सही दिखेगा या नहीं।

इस लेख पर चर्चा करें

Namefi Discuss पर चर्चा देखें