-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
4 changed files
with
38 additions
and
0 deletions.
There are no files selected for viewing
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
File renamed without changes.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,38 @@ | ||
# Outbox model چیست؟ | ||
|
||
همانطور که میدانید رله ها در پروتکل نوستر به شکل پیشفرض رویداد های ذخیره شده خود را با یکدگیر به اشتراک نمی گذارند. این مساله در مرور زمان ممکن است باعث شود که شما به رویداد هایی برخورد کنید که کلاینت شما توانایی بازیابی انهارا ندارد چرا که این رویداد بر روی رله هایی نوشته شده که شما به هیچ یک از انها متصل نیستید. | ||
|
||
این مشکل میتواند تجربه های بدی از جمله بازیابی ناقص رشته های گفتگو و موارد مشابه باشد. | ||
|
||
در مراحل ابتدایی کاربران دو روش متفاوت را برای حل این مشکل ایجاد کردند که هر دو مشکلاتی داشت: | ||
|
||
۱. اتصال به حداکثر رله های ممکن: این روش اجازه میداد که نویسنده رویداد مطمن باشد که رویدادش توسط حداکثر کاربران قابل دیدن است. اما این روش غیر بهینه است چرا که اتصال به رله های زیاد باعث میشود تمام رله های اکثر رویداد هارا نگهداری کنند که در بلند مدت مدیریت انها سخت میشد. | ||
|
||
> نکته: اتصال به تعداد زیادی از رله ها از دیدگاه کاربر و کلاینت هم غیر بهینه است و میتواند تجربه کاربری بدی داشته باشد. | ||
۲. اتصال اکثر کاربر ها به رله هایی ویژه و شناخته شده: این روش قدرت و ویژگی سانسورناپذیر بودن نوستر را کاهش میداد چرا که نفر حمله کننده با محدود کردن دسترسی به رله های مد نظر بخش زیادی از رویداد هارا از دسترسی خارج میکرد. | ||
|
||
|
||
## مدل Outbox و NIP-65 | ||
|
||
پس از استفاده از روش های مختلف و و معرفی نیپ ۶۵ راه حل اوت باکس مدل استفاده و شناخته شد. این روش اجازده میدهد هر کابر فهرستی از رله هایی که از انها برای `خواندن` (دریافت کردن) و `نوشتن` (فرستادن) استفاده میکند را به رله های مختلف بفرستد. | ||
|
||
در نیپ ۶۵ رله های خواندن را inbox و رله های نوشتن را outbox صدا میزنند. | ||
|
||
هر زمان که یک کلاینت بخواهد رویداد های شمارا دریافت کند فهرست رله های outbox شمارا از یکی از رله ها دریافت میکند و از ان رله ها برای بازیابی رویداد شما استفاده میکند. و اگر کلاینتی بخواهد در رویدادی شما را یاد کند (mention) و یا به یکی از رویداد های شما پاسخ دهد ان را به رله های inbox شما میفرستد. | ||
|
||
|
||
شما فهرست nip-65 خود را روی حداکثر رله ها میفرستید. به همین دلیل کلاینت مدنظر برای دسترسی به رویداد های شما یا فرستادن یک رویداد به شما تنها نیاز به پیدا کردن فهرست نیپ ۶۵ شما دارد. پس از ان میتواند توقع داشته باشد که رویداد های شما روی رله های مشخص شده پیدا شوند و شما از ان رله ها رویداد دریافت کنید. این روش اجازه میدهد که ما نیازی به فرستادن تمام رویداد های خود به تمام رله های موجود نداشته باشیم (راه حل یکم کاربر ها برای این مشکل.). | ||
|
||
|
||
### توضیحات با تصویر | ||
|
||
تصویر زیر اوت باکس مدل را به شکلی بهتر و قابل درک نمیاش میدهد: | ||
|
||
![اوت باکس مدل در پروتکل نوستر](../../.assets/images/guides-outbox.png) | ||
|
||
### منابع | ||
|
||
* https://mikedilger.com/gossip-model | ||
|
||
* https://github.com/nostr-protocol/nips/blob/master/65.md |
File renamed without changes.