Skip to content

Commit

Permalink
add outbox model.
Browse files Browse the repository at this point in the history
  • Loading branch information
kehiy committed Jan 9, 2025
1 parent 852242e commit be786ee
Show file tree
Hide file tree
Showing 4 changed files with 38 additions and 0 deletions.
Binary file added .assets/images/guides-outbox.png
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.
38 changes: 38 additions & 0 deletions src/guides/what-is-outbox-model.rtl.md
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.

0 comments on commit be786ee

Please sign in to comment.