परवानगीहीन सार्वजनिक RPC

हे पृष्ठ सार्वजनिक RPC ला उत्पादन-स्तरीय बिटसोशियल प्रस्ताव म्हणून अंमलबजावणी तपशिलांची भिंत न ठेवता फ्रेम करते.

साध्या भाषेचे ध्येय

Bitsocial Forge सार्वजनिक RPC सेवा चालवू शकते जी अनेक वापरकर्त्यांना त्यांचे स्वतःचे Bitsocial समुदाय दूरस्थपणे व्यवस्थापित करू देते, ऑपरेटरला त्या समुदायांच्या संरक्षकात न बदलता.

सेवेने तीन मर्यादा जपून मोबाइल आणि हलके ग्राहकांना व्यावहारिक बनवले पाहिजे:

1. वापरकर्ते डीफॉल्टनुसार एकमेकांपासून वेगळे राहतात.
2. परवानग्या स्पष्ट आणि बारीक राहतात.
3. वर्तमान RPC विनंतीशी सुसंगतता आणि प्रतिसाद आकार रोलआउट दरम्यान संरक्षित केला जाऊ शकतो.

ती कोणती समस्या सोडवते

आज, सर्वात सोपा RPC मॉडेल सामान्यतः सर्व-किंवा-काहीही नाही: एक प्रमाणीकरण की, एक प्राधिकरण डोमेन, पूर्ण प्रवेश. ते एकाच ऑपरेटरसाठी कार्य करते परंतु सार्वजनिक बहु-वापरकर्ता सेवेसाठी नाही.

परवानगी नसलेल्या सार्वजनिक RPC ला अधिक मजबूत मॉडेलची आवश्यकता आहे:

• एक सेवा अनेक वापरकर्ते होस्ट करू शकते
• प्रत्येक वापरकर्त्याला त्यांचे स्वतःचे समुदाय आणि मर्यादा मिळतात
• ऑपरेटर-परिभाषित धोरणे दुरुपयोग टाळू शकतात
• वापरकर्ता तरीही दूर जाऊ शकतो किंवा नंतर स्वत: होस्ट करू शकतो

कोर मॉडेल

वापरकर्ते

प्रत्येक वापरकर्त्याला प्रमाणीकरण क्रेडेंशियल आणि परवानगी बंडल मिळते.

समुदाय

सेवेद्वारे तयार केलेले समुदाय मालकाच्या रेकॉर्डला नियुक्त केले जातात. मालकी स्पष्टपणे ट्रॅक केली जाते जेणेकरून व्यवस्थापन पद्धती योग्य वापरकर्त्यापर्यंत पोहोचवता येतील.

परवानग्या

परवानग्या क्षमता-आधारित आहेत. "RPC वापरू शकतो" साठी एका बुलियनऐवजी, सर्व्हर नियंत्रित करू शकतो:

• वापरकर्ता किती समुदाय तयार करू शकतो
• कोणत्या व्यवस्थापन पद्धती उपलब्ध आहेत
• कोणत्या प्रकाशन ऑपरेशन्सना परवानगी आहे
• कोणत्या दर मर्यादा लागू होतात
• कोणते प्रशासक पृष्ठभाग दृश्यमान आहेत

प्रशासन पृष्ठभाग

सार्वजनिक RPC ने स्वतः वापरकर्त्याच्या RPC वर्तनावर लक्ष केंद्रित केले पाहिजे. वापरकर्ता निर्मिती, मालकी हस्तांतरण आणि ऑडिट पुनरावलोकन यासारखी प्रशासकीय कार्ये वेगळ्या ऑपरेटर API आणि डॅशबोर्डमध्ये आहेत.

सुसंगतता स्थिती

वापरकर्ता-फेसिंग डॉक्युमेंटेशनमध्ये समुदाय आणि प्रोफाइल सारख्या बिटसोशल संज्ञा वापरल्या पाहिजेत.

वायर स्तरावर, पहिले रोलआउट अजूनही वर्तमान 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 द्वारे कधीही लीक होऊ नये.

सूचित ऑपरेटर पृष्ठभाग

प्रशासक API कंटाळवाणे आणि स्पष्ट राहू शकते:

• वापरकर्त्यांची यादी करा
• एका वापरकर्त्याची तपासणी करा
• वापरकर्ते तयार करा किंवा अपडेट करा
• वापरकर्ते हटवा
• समुदाय मालकी हस्तांतरित करा
• ऑडिट लॉगची तपासणी करा

या ऑपरेटर API साठी प्रमाणीकरण अंतिम-वापरकर्ता RPC प्रमाणीकरणापासून पूर्णपणे वेगळे असावे.

रोलआउटचे टप्पे

टप्पा 1

• सार्वजनिक RPC प्रकल्प संरचना स्थापित करा
• वापरकर्ता रेकॉर्ड आणि मालकी ट्रॅकिंग जोडा
• वर्तमान RPC सर्व्हरला काटा किंवा विस्तारित करा

टप्पा 2

• परवानगी बंडल लागू करा
• त्यांना RPC पद्धत स्तरावर लागू करा
• कनेक्टवर परवानग्या मेटाडेटा परत करा

टप्पा 3

• ऑपरेटर API जोडा
• ऑडिट लॉगिंग जोडा
• प्रशासक प्रमाणीकरण जोडा

टप्पा 4

• प्रशासक डॅशबोर्ड पाठवा
• दुरुपयोग नियंत्रण चाचणी
• दर मर्यादा आणि स्टोरेज कोटा घट्ट करा

प्रश्न उघडा

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

प्रमाणीकरण निर्मिती स्वस्त असल्यास, सार्वजनिक सेवांना क्रेडेन्शियल जारी करण्यापूर्वी आव्हानात्मक स्तराची आवश्यकता असू शकते. एक संभाव्य मार्ग म्हणजे सामुदायिक आव्हान मॉडेलचाच पुनर्वापर करणे जेणेकरून क्रेडेन्शियल जारी करणे बाकीच्या नेटवर्कप्रमाणेच गैरवापरविरोधी तत्त्वज्ञानाचा वारसा घेते.

स्थलांतर तपशील

काही सुरुवातीच्या अंमलबजावणीमुळे सुसंगतता-देणारं पद्धतीची नावे आंतरिकरित्या उघड होऊ शकतात. ते स्थलांतर तपशील म्हणून मानले जावे, बिटसोशियल डॉक्सचे कायमस्वरूपी सार्वजनिक शब्दसंग्रह म्हणून नाही.

सारांश

हा प्रस्ताव खरोखरच एका गोष्टीबद्दल आहे: सार्वजनिक RPC पायाभूत सुविधांना ताब्यात न ठेवता उपयुक्त बनवणे. चांगल्या सार्वजनिक बिटसोशियल आरपीसीला समुदाय चालवण्यासाठी पर्यायी सहाय्य वाटले पाहिजे, नवीन केंद्रीय प्लॅटफॉर्मसारखे नाही जे मागील दाराने मालकी पुन्हा दावा करते.