मुख्य कंटेंट तक स्किप करें

अनुमति रहित सार्वजनिक आरपीसी

यह पृष्ठ कार्यान्वयन विवरण की दीवार के बजाय सार्वजनिक आरपीसी को उत्पाद-स्तरीय बिटसोशल प्रस्ताव के रूप में तैयार करता है।

सरल भाषा लक्ष्य

बिटसोशल फोर्ज एक सार्वजनिक आरपीसी सेवा चला सकता है जो कई उपयोगकर्ताओं को ऑपरेटर को उन समुदायों के संरक्षक में बदले बिना, अपने स्वयं के बिटसोशल समुदायों को दूरस्थ रूप से प्रबंधित करने देता है।

सेवा को तीन बाधाओं को बरकरार रखते हुए मोबाइल और हल्के ग्राहकों को व्यावहारिक बनाना चाहिए:

  1. उपयोगकर्ता डिफ़ॉल्ट रूप से एक दूसरे से अलग-थलग रहते हैं।
  2. अनुमतियाँ स्पष्ट और विस्तृत रहती हैं।
  3. रोलआउट के दौरान वर्तमान आरपीसी अनुरोध और प्रतिक्रिया आकार के साथ संगतता को संरक्षित किया जा सकता है।

यह किस समस्या का समाधान करता है

आज, सबसे सरल आरपीसी मॉडल आम तौर पर ऑल-ऑर-नथिंग है: एक प्राधिकरण कुंजी, एक प्राधिकरण डोमेन, पूर्ण पहुंच। यह एकल ऑपरेटर के लिए काम करता है लेकिन सार्वजनिक बहु-उपयोगकर्ता सेवा के लिए नहीं।

एक अनुमति रहित सार्वजनिक आरपीसी को एक मजबूत मॉडल की आवश्यकता है:

  • एक सेवा कई उपयोगकर्ताओं को होस्ट कर सकती है
  • प्रत्येक उपयोगकर्ता को अपने स्वयं के समुदाय और सीमाएँ मिलती हैं
  • ऑपरेटर-परिभाषित नीतियां दुरुपयोग को रोक सकती हैं
  • उपयोगकर्ता अभी भी दूर जा सकता है या बाद में स्वयं-होस्ट कर सकता है

कोर मॉडल

उपयोगकर्ताओं

प्रत्येक उपयोगकर्ता को एक प्रमाणीकरण क्रेडेंशियल और एक अनुमति बंडल मिलता है।

समुदाय

सेवा के माध्यम से बनाए गए समुदायों को एक स्वामी रिकॉर्ड को सौंपा गया है। स्वामित्व को स्पष्ट रूप से ट्रैक किया जाता है ताकि प्रबंधन विधियों को सही उपयोगकर्ता तक सीमित किया जा सके।

अनुमतियां

अनुमतियाँ क्षमता-आधारित हैं। "आरपीसी का उपयोग कर सकते हैं" के लिए एक बूलियन के बजाय, सर्वर नियंत्रित कर सकता है:

  • एक उपयोगकर्ता कितने समुदाय बना सकता है
  • कौन सी प्रबंधन विधियाँ उपलब्ध हैं
  • किन प्रकाशन कार्यों की अनुमति है
  • कौन सी दर सीमा लागू होती है
  • कौन सी व्यवस्थापक सतहें दिखाई दे रही हैं

व्यवस्थापक सतह

सार्वजनिक आरपीसी को स्वयं उपयोगकर्ता-सामना वाले आरपीसी व्यवहार पर केंद्रित रहना चाहिए। उपयोगकर्ता निर्माण, स्वामित्व हस्तांतरण और ऑडिट समीक्षा जैसे प्रशासनिक कार्य एक अलग ऑपरेटर एपीआई और डैशबोर्ड में होते हैं।

अनुकूलता रुख

उपयोगकर्ता-सामना वाले दस्तावेज़ में समुदाय और प्रोफ़ाइल जैसे बिटसोशल शब्दों का उपयोग करना चाहिए।

तार स्तर पर, पहला रोलआउट अभी भी वर्तमान JSON-RPC परिवहन और पेलोड आकार को संरक्षित कर सकता है जहां यह अनुकूलता के लिए उपयोगी है। दूसरे शब्दों में: दस्तावेज़ बिटसोशल-मूल बने रह सकते हैं, भले ही संक्रमण अवधि कुछ संगतता-उन्मुख विधि नाम रखती हो या पर्दे के पीछे आकृतियों का अनुरोध करती हो।

प्रस्तावित अनुमति बंडल

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 उबाऊ और स्पष्ट रह सकता है:

  • उपयोगकर्ताओं की सूची बनाएं
  • एक उपयोगकर्ता का निरीक्षण करें
  • उपयोगकर्ता बनाएं या अपडेट करें
  • उपयोगकर्ताओं को हटाएं
  • सामुदायिक स्वामित्व स्थानांतरित करें
  • ऑडिट लॉग का निरीक्षण करें

इस ऑपरेटर एपीआई के लिए प्रमाणीकरण एंड-यूज़र आरपीसी ऑथेंटिकेशन से पूरी तरह से अलग होना चाहिए।

रोलआउट चरण

चरण एक

  • सार्वजनिक आरपीसी परियोजना संरचना स्थापित करें
  • उपयोगकर्ता रिकॉर्ड और स्वामित्व ट्रैकिंग जोड़ें
  • वर्तमान आरपीसी सर्वर को फोर्क या विस्तारित करें

2 चरण

  • अनुमति बंडल लागू करें
  • उन्हें RPC विधि परत पर लागू करें
  • कनेक्ट पर अनुमतियाँ मेटाडेटा लौटाएँ

चरण 3

  • ऑपरेटर एपीआई जोड़ें
  • ऑडिट लॉगिंग जोड़ें
  • व्यवस्थापक प्रमाणीकरण जोड़ें

चरण 4

  • व्यवस्थापक डैशबोर्ड शिप करें
  • दुरुपयोग नियंत्रण का परीक्षण करें
  • दर सीमित करने और भंडारण कोटा सख्त करें

खुले प्रश्न

प्रामाणिक क्रेडेंशियल स्पैम

यदि प्रमाणीकरण सस्ता है, तो सार्वजनिक सेवाओं को क्रेडेंशियल जारी करने से पहले एक चुनौती परत की आवश्यकता हो सकती है। एक संभावित मार्ग सामुदायिक चुनौती मॉडल का पुन: उपयोग करना है ताकि क्रेडेंशियल जारी करना बाकी नेटवर्क के समान दुरुपयोग-विरोधी दर्शन को प्राप्त कर सके।

प्रवासन विवरण

कुछ प्रारंभिक कार्यान्वयन अभी भी संगतता-उन्मुख विधि नामों को आंतरिक रूप से उजागर कर सकते हैं। इसे माइग्रेशन विवरण के रूप में माना जाना चाहिए, न कि बिटसोशल दस्तावेज़ों की स्थायी सार्वजनिक शब्दावली के रूप में।

सारांश

This proposal is really about one thing: making public RPC infrastructure useful without making it custodial. A good public Bitsocial RPC should feel like optional assistance for running communities, not like a new central platform that reclaims ownership through the back door.