گروه‌های رله‌محور نوستر به زیرگروه و سنجاق‌کردن پیام مجهز شدند

استاندارد گروه‌های رله‌محور نوستر، یعنی NIP-29، دو سازوکار آشنا برای کاربران پلتفرم‌های اجتماعی معمول را به دست آورده است: فضاهای تو در تو و محتوای سنجاق‌شده.

در ۱۶ ژوئیه، مخزن NIPها مشخصات زیرگروه‌ها را ادغام کرد. اکنون یک گروه می‌تواند در فرادادهٔ خود والد و فرزند تعریف کند تا کلاینت‌ها سلسله‌مراتبی را روی یک رله بسازند. در عمل، یک جامعه می‌تواند اتاق‌هایی مجزا برای موضوع‌ها، پروژه‌ها یا شاخه‌های محلی نشان دهد، بدون آن‌که آن‌ها را گروه‌هایی کاملاً نامرتبط جلوه دهد.

این طراحی عمداً محدود است. یک زیرگروه همچنان یک گروه عادی NIP-29 با فراداده، رویدادهای تعدیل و شناسهٔ گروهِ خودش است. عضویت از والد به فرزند منتقل نمی‌شود و مدیر یک گروه والد نیز خودبه‌خود در زیرگروه اختیار ندارد. این جداسازی برای جامعه‌هایی مهم است که اتاق‌های کوچک‌تر را برای گفت‌وگوهای حساس، هماهنگی مشارکت‌کنندگان یا دسترسی محدود به کار می‌گیرند.

سنجاق‌کردن پیام با ادغامی در ۱۵ ژوئیه وارد شد. استاندارد یک اقدام تعدیلی با نام kind:9010 اضافه می‌کند که فهرست کامل و مرتب‌شدهٔ سنجاق‌ها را ارسال می‌کند، و یک رویداد تولیدشده توسط رله با نام kind:39005 که آخرین فهرست پذیرفته‌شده را بازتاب می‌دهد. بنابراین یک به‌روزرسانی می‌تواند محتوا را سنجاق، از سنجاق خارج، مرتب یا پاک کند. یک ادغام تکمیلی در ۱۷ ژوئیه نیز رویدادهای دارای نشانی را در این فهرست مجاز کرد؛ در نتیجه سنجاق‌ها به شناسهٔ پیام‌های عادی محدود نیستند.

برای سازندگان، نکتهٔ مهم نه یک اپ اجتماعی تازه، بلکه یک هدف روشن‌تر برای تعامل‌پذیری است. رله‌ای که از زیرگروه‌ها پشتیبانی می‌کند باید این قابلیت را در سند اطلاعات NIP-11 خود اعلام کند. سپس کلاینت‌ها می‌توانند درخت یک جامعه را نمایش دهند و، در صورت پشتیبانی، محتوای سنجاق‌شدهٔ رله را به جای ساختن قراردادهای محلی ناسازگار ارائه کنند.

دو محدودیت اساسی وجود دارد. نخست، NIP-29 استانداردی پیش‌نویس و اختیاری است؛ رله‌ها و کلاینت‌ها می‌توانند از رفتار جدید زیرگروه و سنجاق‌کردن پشتیبانی نکنند. دوم، NIP-29 برای اعمال عضویت و تعدیل به رلهٔ میزبان تکیه دارد؛ یک گروه مبتنی بر رله بدون نیاز به اعتماد نیست و مهاجرت یا فورک می‌تواند تاریخچه‌های رقیب گروه ایجاد کند.

پس این یک پیشرفت مفید در سطح پروتکل است، نه تضمینی برای تجربه‌ای یکسان در همهٔ اپ‌ها. تیم‌هایی که آن را می‌پذیرند باید ترکیب مشخص رله و کلاینت مورد استفادهٔ خود را آزمایش کنند، رلهٔ میزبان را به‌روشنی نشان دهند و القا نکنند که عضویت یا اختیارات مدیر به‌طور خودکار در سراسر درخت یک جامعه منتقل می‌شود.