نیپ شماره 5

نگاشت کلیدهای Nostr به شناسه های اینترنتی مبتنی بر DNS

نهایی دلبخواهی

در رویداد های گونه ۰ (متادیتا کاربر) یک کلید به نام nip05 (https://datatracker.ietf.org/doc/html/rfc5322#section-3.4.1)[میتواند ادرس شناسه گر اینترنتی] (ادرسی ایمیل مانند) را به عنوان مقدار داشته باشد. هرچند که لینک به مشخصات شناسه گر اینترنتی در بالا وجود دارد اما نیپ ۵ تصور میکند که <local-part> به کاراکتر های a-z0-9-_. حساس است و حساستی به کوچکی و بزرگی کاراکتر ها ندارد.

با دیدن این ادرس کلاینت ادرس را به دو قسمت domain و <local-part> تقسیم میکند و از این مقادیر برای ایجاد یک درخواست GET به https://<domain>/.well-known/nostr.json?name=<local-part> استفاده میکند.

خروجی باید یک شی جیسان با کلید به نام "names" داشته باشد که به کلید های عمومی ای در مبنای ۱۶ اشاره کند. اگر کلید عمومی مربوط به <name> با کلید عمومی کاربری که این شناسه در رویداد متادیتا او قرارداشته برابر باشد کلاینت میتواند نتیجه بگیرد که کلید عمومی با این شناسه هم میتواند شناخته شود.

نمونه

اگر کلاینت رویدادی همچون رویداد زیر دید:

{
  "pubkey": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9",
  "kind": 0,
  "content": "{\"name\": \"bob\", \"nip05\": \"bob@example.com\"}"
  ...
}

یک درخواست GET به ادرس https://example.com/.well-known/nostr.json?name=bob ایجاد میکند و چنین پاسخی میگیرد:

{
  "names": {
    "bob": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"
  }
}

یا به همراه ویژگی رله ها پیشنهاد شده:

{
  "names": {
    "bob": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"
  },
  "relays": {
    "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9": [ "wss://relay.example.com", "wss://relay2.example.com" ]
  }
}

اگر کلید عمومی با کلید عمومی داده شده در "names" برابر بود به این معنا است که وابستگی معتبر است و نشانی نیپ ۵ میتواند نمایش داده شود.

ویژگی رله های پیشنهادی میتواند شامل کلید های عمومی به عنوان کلید و ارایه ای از ادرس رله ها به عنوان مقدار باشد. اگر این مقدار وجود داشت میتواند به کلاینت کمک کند تا بفهمد در کدام رله ها میتواند رویداد های مربوط به کلید عمومی داده شده را پیدا کند. وب سرور هایی که .well-known/nostr.json را بصورت پویا اراعه میکنند باید فهرست رله های پیشنهادی را هم در صورت وجود در همان درخواست برگردانند.

پیدا کردن کاربر ها با استفاده از شناسه نیپ ۵

یک کلاینت ممکن است پشتیبانی از یافتن کاربران با استفاده از شناسه گر اینترنتی را پیاده سازی کند. روند همچون پیش است اما برعکس: نخست کلاینت ادرس well-known را میگیرد سپس از خروجی کلید عمومی کاربر را بدست می اورد و کوشش میکند تا رویداد گونه ۰ کاربر را پیدا کند و بررسی کند که ادرس نیپ ۵ با ادرس نیپ ۵ در رویداد گونه ۰ کاربر برابر است یا نه.

یادداشت ها

کلاینت همیشه باید کلید های عمومی را دنبال کند نه ادرس های نیپ ۵ را

برای نمونه بعد از یافتن نشانی bob@bob.com که کلید عمومی abc...def را دارد کاربر بر روی دکمه دنبال کردن در آن پروفایل کلیک میکند. کلاینت باید مرجع اولیه و اصلی abc...def را نگهدارد و نه نشانی bob@bob.com را. اگر بنا به هر دلیلی در اینده ادرس https://bob.com/.well-known/nostr.json?name=bob شروع به بازگرداندن کلید عمومی 1d2...e3fکرد کلاینت نباید در فهرست دنبال شوندگان خود کلید عمومی abc...def را برای برای ان کاربر جایگزین کند. (اما باید از نمایش دادن ادرس bob@bob.com برای ان کاربر دست نگه دارد زیرا این دیگر به یک ویژگی "nip05" نامعتبر تبدیل شده است.)

کلید عمومی باید در مبنای ۱۶ (hex) باشد

کلید ها باید در مبنای ۱۶ (hex) برگردانده شوند. کلید های NIP-19 در فرمت npub برای نمایش در رابط کاربری کلاینت ها به وجود امده اند نه برای استفاده در این نیپ.

پیشنهاد پیاده سازی کاوش/کشف کاربر

یک کلاینت همچنین میتواند از این استفاده کند تا به کاربر اجازه دهند پروفایل کاربران را جستجو کند. اگر یک کلاینت سرچ باکس ای داشت کاربر میتواند "bob@bob.com"را انجا جستجو کند و کلاینت میتواند این را تشخیص دهد و درخواست های لازم برای بدست اوردن کلید عمومی را ایجاد کند و ان را به کاربر پیشنهاد دهد.

نشان دادن دامنه تنها به عنوان نشانی

کلاینت ها ممکن است شناسه _@domain را به عنوان شناسه ریشه در نظر بگیرند. و بخواهند که ان را بصورت <domain> نمایش دهند. برای نمونه اگر bob مالک دامنه bob.com است او شاید نخواهد نشانی به صورت bob@bob.comداشته باشد زیرا بخشی اضافی دارد. بجای این باب میتواند از شناسه "_@bob.com" استفاده کنید و توقع داشته باشد که کلاینت های نوستر از "bob.com" برای نمایش استفاده کنند و برای همه استفاده ها از این استفاده کنند.

دلیل استفاده از ساختار /.well-known/nostr.json?name=<local-part>

با افزودن <local-part> به صورت یک رشته پرس و جو (query string) بجای بخشی از مسیر ادرس پروتکل میتواند بصورت همزمان از سرور هایی که بصورت پویا و برحسب تقاضا JSON تولید میکنند و هم از سرور هایی که بصورت ایستا JSON ای که شامل چند نام میباشد را داشته باشند پشتبانی کند.

اجازه دسترسی از برنامه های جاوا اسکریپت

برنامه های نوستر جاوااسکریپتی ممکن است به دلیل سیاست های(https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS)[CORS] مرورگر از دسترسی به مسیر /.well-known/nostr.json در دامنه کاربر محدود شده باشند. زمانی که جاوااسکریپت به دلیل CORS نمیتواند منبعی را بارگیری کند برنامه ان را خطایی مربوط به شبکه میشناسد میگویید منبع وجود ندارد. پس برنامه نمیتواند به کاربر بگویید که خطا به دلیل مشکل CORS است. برنامه های جاوااسکریپتی نوستر که خطا های مربوط به شبکه در گرفتن فایل موجود در مسیر /.well-known/nostr.json بر میخورند میتوانند به کاربر پیشنهاد دهند که سیاست های CORS سرور خود را مورد بررسی قرار دهند. برای نمونه:

$ curl -sI https://example.com/.well-known/nostr.json?name=bob | grep -i ^Access-Control
Access-Control-Allow-Origin: *

کاربر باید مطمن شوند که مسیر /.well-known/nostr.json با HTTP header Access-Control-Allow-Origin: * سرو میشود تا مطمن باشند که برنامه های جاوااسکریپتی که بر روی مرورگر های به روز اجرا میشوند میتوانند ان را اعتبارسنجی کنند.

محدودیت های امنیتی

مسیر /.well-known/nostr.json نباید هیچ گونه تغییر مسیر HTTP ای را برگرداند. صدا زنندگان این ادرس باید هرگونه تغییر مسیر مربوط به /.well-known/nostr.json را نادیده بگیرند.