مرکزی مواد پر جائیں۔

بغیر اجازت عوامی RPC

اصل عوامی RPC تجویز پرانی plebbit اصطلاحات میں لکھے گئے GitHub مسئلے کے طور پر رہتی تھی۔ یہ صفحہ بٹسوشل زبان میں اس خیال کو دوبارہ لکھتا ہے اور اسے عمل درآمد کی تفصیل کی دیوار کے بجائے مصنوعات کی سطح کی تجویز کے طور پر تیار کرتا ہے۔

سادہ زبان کا مقصد​

بٹسوشل فورج ایک عوامی RPC سروس چلا سکتا ہے جو بہت سے صارفین کو آپریٹر کو ان کمیونٹیز کے نگراں میں تبدیل کیے بغیر، اپنی بٹسوشل کمیونٹیز کو دور سے منظم کرنے دیتا ہے۔

سروس کو تین رکاوٹوں کو برقرار رکھتے ہوئے موبائل اور ہلکے وزن والے کلائنٹس کو عملی بنانا چاہیے:

  1. صارف بطور ڈیفالٹ ایک دوسرے سے الگ تھلگ رہتے ہیں۔
  2. اجازتیں واضح اور دانے دار رہیں۔
  3. موجودہ RPC درخواست کے ساتھ مطابقت اور ردعمل کی شکل کو رول آؤٹ کے دوران محفوظ کیا جا سکتا ہے۔

یہ کونسا مسئلہ حل کرتا ہے۔​

آج، سب سے آسان RPC ماڈل عام طور پر سب یا کچھ بھی نہیں ہے: ایک تصدیق کلید، ایک اتھارٹی ڈومین، مکمل رسائی۔ یہ ایک آپریٹر کے لیے کام کرتا ہے لیکن عوامی کثیر صارف کی خدمت کے لیے نہیں۔

بغیر اجازت عوامی RPC کو مضبوط ماڈل کی ضرورت ہے:

  • ایک سروس بہت سے صارفین کی میزبانی کر سکتی ہے۔
  • ہر صارف کو اپنی برادریاں اور حدود ملتی ہیں۔
  • آپریٹر کی طے شدہ پالیسیاں غلط استعمال کو روک سکتی ہیں۔
  • صارف اب بھی دور جا سکتا ہے یا بعد میں خود میزبانی کر سکتا ہے۔

بنیادی ماڈل​

صارفین​

ہر صارف کو توثیق کی سند کے علاوہ اجازت کا بنڈل ملتا ہے۔

کمیونٹیز​

سروس کے ذریعے بنائی گئی کمیونٹیز مالک کے ریکارڈ کو تفویض کی جاتی ہیں۔ ملکیت کو واضح طور پر ٹریک کیا جاتا ہے تاکہ انتظامی طریقوں کو صحیح صارف تک پہنچایا جا سکے۔

اجازتیں​

اجازتیں اہلیت پر مبنی ہیں۔ "RPC استعمال کر سکتے ہیں" کے لیے ایک بولین کے بجائے، سرور کنٹرول کر سکتا ہے:

  • ایک صارف کتنی کمیونٹیز بنا سکتا ہے۔
  • جو انتظامی طریقے دستیاب ہیں۔
  • کیا اشاعتی کارروائیوں کی اجازت ہے۔
  • کیا شرح کی حدیں لاگو ہوتی ہیں۔
  • کون سی ایڈمن کی سطحیں نظر آتی ہیں۔

ایڈمن کی سطح​

عوامی RPC کو خود صارف کا سامنا کرنے والے RPC رویے پر توجہ مرکوز رکھنی چاہیے۔ انتظامی کام جیسے کہ صارف کی تخلیق، ملکیت کی منتقلی، اور آڈٹ کا جائزہ علیحدہ آپریٹر API اور ڈیش بورڈ میں ہے۔

مطابقت کا موقف​

صارف کا سامنا کرنے والی دستاویزات میں بٹسوشل اصطلاحات جیسے کمیونٹی اور پروفائل کا استعمال کرنا چاہیے۔

تار کی سطح پر، پہلا رول آؤٹ اب بھی موجودہ JSON-RPC ٹرانسپورٹ اور پے لوڈ کی شکل کو محفوظ رکھ سکتا ہے جہاں یہ مطابقت کے لیے مفید ہے۔ دوسرے الفاظ میں: دستاویزات کو اب پرانے plebbit docs کی طرح بات کرنے کی ضرورت نہیں ہے، یہاں تک کہ اگر منتقلی کی مدت کچھ میراثی طریقہ کے نام یا درخواست کی شکلیں پردے کے پیچھے رکھتی ہے۔

مجوزہ اجازت کا بنڈل​

type PermissionBundle = {
  maxCommunities: number; // 0 = unlimited
  methods: {
    createCommunity: boolean;
    startCommunity: boolean;
    stopCommunity: boolean;
    editCommunity: boolean;
    deleteCommunity: boolean;
    publishComment: boolean;
    publishVote: boolean;
    publishCommentEdit: boolean;
    publishCommentModeration: boolean;
    publishCommunityEdit: boolean;
    getComment: boolean;
    getCommentPage: boolean;
    getCommunityPage: boolean;
    fetchContent: boolean;
    resolveAuthorAddress: boolean;
    commentUpdateSubscribe: boolean;
    communityUpdateSubscribe: boolean;
    communityListSubscribe: boolean;
    settingsSubscribe: boolean;
  };
  rateLimits: {
    requestsPerMinute: number;
    publishesPerHour: number;
  };
  storage: {
    maxTotalSize: number;
  };
  scope: {
    canPublishExternal: boolean;
    canReadExternal: boolean;
  };
  admin: {
    canTransferOwnership: boolean;
    canManageUsers: boolean;
    canViewAuditLogs: boolean;
    canViewAllCommunities: boolean;
  };
};

صحیح طریقے کے نام مثالی ہیں۔ اہم حصہ پالیسی کی شکل ہے: انفرادی صلاحیتوں کو ایک سپر یوزر ٹوکن میں بنڈل کرنے کے بجائے آزادانہ طور پر کنٹرول کیا جاتا ہے۔

کنکشن کا بہاؤ​

client connects with auth credential
-> server validates the credential
-> server loads the user's permission bundle
-> server returns a permissions notification
-> client proceeds with the subset of actions it is allowed to use

اجازت کی آگاہی اختیاری رہنا چاہیے۔ ایک کلائنٹ جو نوٹیفکیشن کو نظر انداز کرتا ہے وہ پھر بھی سرور سے معیاری اجازت کی ناکامیوں کو سنبھال کر صحیح برتاؤ کر سکتا ہے۔

ملکیت کا نفاذ​

جب سروس ایک کمیونٹی بناتی ہے، تو اسے خودکار طور پر کال کرنے والے صارف کو ملکیت تفویض کر دینی چاہیے۔ وہاں سے:

  • کمیونٹی کی شروعات، روک، ترمیم، اور حذف کی کارروائیاں مالک کے دائرہ کار میں ہیں۔
  • فہرست اور سبسکرپشن کے جوابات کال کرنے والے کی اپنی کمیونٹیز کے لیے پہلے سے طے شدہ ہیں۔
  • وسیع تر مرئیت ایڈمن کی ایک واضح اجازت ہے، ڈیفالٹ نہیں۔

ایک کنارے کا معاملہ بہت اہمیت رکھتا ہے: اگر کوئی صارف کسی ایسی کمیونٹی کو سبسکرائب کرتا ہے جس کی وہ اپنی نہیں ہے، تو سرور کو صرف اس عوامی حالت کو بے نقاب کرنا چاہیے جسے کسی بھی بیرونی مبصر کو دیکھنا چاہیے۔ صرف اونر کنفیگریشن یا اندرونی رن ٹائم ڈیٹا کبھی بھی سبسکرپشن API کے ذریعے لیک نہیں ہونا چاہیے۔

تجویز کردہ آپریٹر سطح​

ایڈمن API بورنگ اور واضح رہ سکتا ہے:

  • فہرست صارفین
  • ایک صارف کا معائنہ کریں۔
  • صارفین بنائیں یا اپ ڈیٹ کریں۔
  • صارفین کو حذف کریں
  • کمیونٹی کی ملکیت کی منتقلی
  • آڈٹ لاگز کا معائنہ کریں۔

اس آپریٹر API کی توثیق اختتامی صارف RPC کی توثیق سے مکمل طور پر الگ ہونی چاہیے۔

رول آؤٹ کے مراحل​

فیز 1​

  • عوامی RPC منصوبے کا ڈھانچہ قائم کریں۔
  • صارف کے ریکارڈ اور ملکیت سے باخبر رہنا شامل کریں۔
  • موجودہ RPC سرور کو فورک یا توسیع دیں۔

فیز 2​

  • اجازت کے بنڈلز کو لاگو کریں۔
  • انہیں RPC طریقہ پرت پر نافذ کریں۔
  • کنیکٹ پر اجازتوں کا میٹا ڈیٹا واپس کریں۔

فیز 3​

  • آپریٹر API شامل کریں۔
  • آڈٹ لاگنگ شامل کریں۔
  • ایڈمن کی توثیق شامل کریں۔

فیز 4​

  • ایڈمن ڈیش بورڈ بھیجیں۔
  • غلط استعمال کے کنٹرول کی جانچ کریں۔
  • شرح کو محدود کرنے اور ذخیرہ کرنے کے کوٹے کو سخت کریں۔

سوالات کھولیں۔​

تصدیقی اسناد سپیم​

اگر توثیق کی تخلیق سستی ہے، تو عوامی خدمات کو اسناد جاری کرنے سے پہلے چیلنج لیئر کی ضرورت پڑ سکتی ہے۔ ایک ممکنہ راستہ خود کمیونٹی چیلنج ماڈل کو دوبارہ استعمال کرنا ہے تاکہ اسناد کا اجراء وہی اینٹی ابیوز فلسفہ وراثت میں ملے جیسا کہ نیٹ ورک کے باقی حصوں میں ہے۔

میراثی نام دینا​

کچھ ابتدائی نفاذ اب بھی مطابقت کے لیے وراثتی طریقہ کے ناموں کو اندرونی طور پر ظاہر کر سکتے ہیں۔ اسے منتقلی کی تفصیل کے طور پر سمجھا جانا چاہئے، نہ کہ بٹسوشل دستاویزات کی مستقل عوامی ذخیرہ الفاظ کے طور پر۔

خلاصہ​

یہ تجویز واقعی ایک چیز کے بارے میں ہے: عوامی RPC انفراسٹرکچر کو اس کی تحویل میں رکھے بغیر مفید بنانا۔ ایک اچھی عوامی Bitsocial RPC کو کمیونٹیز چلانے کے لیے اختیاری مدد کی طرح محسوس کرنا چاہیے، نہ کہ ایک نئے مرکزی پلیٹ فارم کی طرح جو پچھلے دروازے سے ملکیت کا دعویٰ کرتا ہے۔