דלג לתוכן הראשי

RPC ציבורי ללא רשות

דף זה ממסגר RPC ציבורי כהצעה Bitsocial ברמת המוצר במקום חומה של פירוט יישום.

מטרה בשפה פשוטה​

Bitsocial Forge יכול להפעיל שירות RPC ציבורי המאפשר למשתמשים רבים לנהל את קהילות Bitsocial משלהם מרחוק, מבלי להפוך את המפעיל לאפוטרופוס של הקהילות הללו.

השירות אמור להפוך לקוחות ניידים וקלים למעשיים תוך שמירה על שלושה אילוצים:

  1. משתמשים נשארים מבודדים זה מזה כברירת מחדל.
  2. ההרשאות נשארות מפורשות ומפורטות.
  3. ניתן לשמור על תאימות עם בקשת ה-RPC הנוכחית וצורת התגובה במהלך ההפצה.

איזו בעיה זה פותר​

כיום, מודל ה-RPC הפשוט ביותר הוא בדרך כלל הכל או כלום: מפתח אישור אחד, תחום סמכות אחד, גישה מלאה. זה עובד עבור מפעיל יחיד אבל לא עבור שירות רב-משתמש ציבורי.

RPC ציבורי חסר רשות צריך מודל חזק יותר:

  • שירות אחד יכול לארח משתמשים רבים
  • כל משתמש מקבל את הקהילות והגבולות שלו
  • מדיניות מוגדרת על ידי מפעיל יכולה למנוע שימוש לרעה
  • המשתמש עדיין יכול להתרחק או לארח בעצמו מאוחר יותר

דגם ליבה​

משתמשים​

כל משתמש מקבל אישור אישור בתוספת חבילת הרשאות.

קהילות​

קהילות שנוצרו באמצעות השירות מוקצות לרשומת בעלים. מעקב אחר הבעלות מתבצע באופן מפורש כך שניתן להגדיר את שיטות הניהול למשתמש הנכון.

הרשאות​

ההרשאות מבוססות על יכולות. במקום בוליאני אחד עבור "יכול להשתמש ב-RPC", השרת יכול לשלוט ב:

  • כמה קהילות משתמש יכול ליצור
  • אילו שיטות ניהול קיימות
  • אילו פעולות פרסום מותרות
  • אילו מגבלות תעריפים חלות
  • אילו משטחי ניהול גלויים

משטח ניהול​

ה-RPC הציבורי עצמו צריך להישאר ממוקד בהתנהגות RPC מול המשתמש. משימות ניהוליות כגון יצירת משתמשים, העברת בעלות ובדיקת ביקורת שייכות ל-API נפרד של מפעיל וללוח מחוונים.

עמדת תאימות​

תיעוד הפונה למשתמש צריך להשתמש במונחים של Bitsocial כגון קהילה ופרופיל.

ברמת החוט, ההפצה הראשונה עדיין יכולה לשמר את צורת ההעברה והמטען הנוכחי של JSON-RPC במקום שבו זה שימושי לתאימות. במילים אחרות: המסמכים יכולים להישאר Bitsocial-native גם אם תקופת המעבר שומרת על כמה שמות של שיטות מוכוונות תאימות או צורות בקשה מאחורי הקלעים.

חבילת הרשאות מוצעת​

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​

  • לשלוח את לוח המחוונים לניהול
  • בדיקת בקרות ניצול לרעה
  • להדק את הגבלת התעריפים ומכסות האחסון

שאלות פתוחות​

אישור ספאם של אישור​

אם יצירת ההסמכה זולה, ייתכן ששירותים ציבוריים יזדקקו לשכבת אתגר לפני הנפקת אישורים. מסלול אפשרי אחד הוא שימוש חוזר במודל האתגר הקהילתי עצמו, כך שהנפקת אישורים יורשת את אותה פילוסופיה נגד שימוש לרעה כמו שאר הרשת.

פרטי הגירה​

כמה יישומים מוקדמים עדיין עשויים לחשוף שמות שיטות מוכווני תאימות באופן פנימי. יש להתייחס לזה כאל פרט הגירה, לא כאל אוצר המילים הציבורי הקבוע של Bitsocial docs.

סיכום​

ההצעה הזו עוסקת באמת בדבר אחד: הפיכת תשתית RPC ציבורית לשימושית מבלי להפוך אותה למשמורת. RPC ציבורי טוב של Bitsocial צריך להרגיש כמו סיוע אופציונלי להפעלת קהילות, לא כמו פלטפורמה מרכזית חדשה שתובעת בחזרה בעלות דרך הדלת האחורית.