Navigating the Future of the Web with Solid

Navigating the Future of the Web with Solid

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

בהרצאה של יותם בלום, Frontend Engineer ב-Melio, הוא מציג את Solid - לא SolidJS ולא SOLID principles - כאקוסיסטם של ווב מבוזר. הרעיון פשוט, וההשלכות גדולות: הדאטה שייך למשתמש ונמצא ב-pod אישי; אפליקציות מבקשות רשות להשתמש בו במקום לאסוף ולהחזיק אותו בעצמן.

זה אינו עוד הבטחה על blockchain או Web3. יותם מבדיל במפורש בין Solid לבין Web3, ומחבר את הכיוון ל-Web 3.0 ולחזון של טים ברנרס-לי: פחות data silos, יותר סטנדרטים משותפים והרשאות שהמשתמש שולט בהן.

כשהמידע נעול בתוך האפליקציה, המשתמש משלם

המודל המוכר הוא שכל אפליקציה מנהלת API, database וסכמות משלה. זה נשמע טבעי עד שמסתכלים על הכפילויות. לכל שירות יש profile, תמונה, שם, אנשי קשר והעדפות. כל שינוי דורש migration קטן של המשתמש: לעדכן כאן, לייצא שם, להתחבר לעוד מערכת כדי לסנכרן calendar.

יותם מתאר זאת גם כבעיית פיתוח. ככל שהמערכות גדלות, צוותים מבלים זמן על scaling, sharding, תחזוקת data ועל אופטימיזציות. הפיצ’רים עצמם נתקעים מאחורי העבודה על תשתית המידע. אין כאן טענה ש-database הוא דבר רע. הטענה היא שהאפליקציה לא חייבת להיות גם הבעלים היחיד של כל פיסת מידע אישית.

Solid מנסה להפריד בין השניים. אפליקציה יכולה להתמקד בחוויה ובערך שהיא נותנת, בעוד שהמשתמש נותן לה גישה לנתונים שלו לפי בחירה. אם מחליפים אפליקציית photo gallery, אין צורך להעביר manually את כל התמונות. נותנים הרשאה לאפליקציה החדשה לאותו מידע. אם פלטפורמת social media כבר לא מתאימה, אפשר עקרונית להעביר את התוכן והקשרים למקום אחר בלי להתחיל מאפס.

Pod הוא חנות הנתונים של המשתמש

Solid Server הוא Web Server רגיל, אבל תפקידו הוא לארח pods ולהחזיק את ההרשאות סביבם. pod הוא מקום שבו המשתמש יכול להחזיק פרופיל, agenda, contact list, media ומידע אישי נוסף. הוא יכול להיות מקומי, כמו בדמו של יותם, או hosted במקום אחר שהמשתמש בחר.

העיקרון החשוב הוא שהאפליקציה מקבלת reference והרשאה. היא אינה חייבת לשמור עותק נוסף של כל הנתונים אצלה. אם המשתמש מחליף את תמונת הפרופיל בתוך ה-pod, כל resource שקיבל הרשאה ומפנה אליה יכול לקבל את הערך החדש. בדמו, יותם יוצר pod מקומי, נותן authorization לאפליקציה, משנה את התמונה, ומרענן. האפליקציה קוראת את אותו מקור ומקבלת את העדכון.

זה יכול להתאים ל-social media, payments, e-commerce ו-video sharing. בדוגמת הקניות, חנות חדשה אינה חייבת ללמוד מאפס את העדפות המשתמש אם המשתמש בוחר לשתף אותן. בדוגמת payments, פרטי חיוב יכולים להיות מנוהלים במקום אחד במקום לעבור בין אינספור טפסים. אלו אפשרויות, לא קסם: מי שמקבל הרשאה, לאיזו מטרה ולכמה זמן, הם בדיוק ההחלטות שמודל כזה חייב לנהל היטב.

בלי שפה משותפת, ביזור הופך לברדק

אחרי שמפזרים נתונים בין pods, נוצרת בעיית interoperability. אפליקציה אחת צריכה לדבר עם הרבה resources, ואי אפשר להניח שכל אחד מהם מגדיר user אחרת. כאן נכנס RDF, Resource Description Framework. הוא נותן vocabulary וסכמות שאפשר להבין בצורה אוניברסלית.

הדוגמה שיותם נותן היא טבלת משתמשים. כמה פעמים כל צוות מגדיר שם, שם משפחה ותמונה? אם יש סכמה מוכרת לפרופיל, client יכול לקרוא אותה במקום להמציא עוד table ועוד database. זה אינו מונע יצירת vocabulary חדש לפי צורך, אבל נותן בסיס משותף למידע שחוזר על עצמו.

בדמו הוא משתמש ב-Linked Data Objects וב-JSON-LD כדי לקחת את ההגדרות האלה אל עולם TypeScript. הגדרת profile מציינת אילו attributes צפויים, ו-LDO יוצר types ומאפשר לפרסר תגובה מה-WebID לאובייקט שאפשר לעבוד איתו. עבור מפתח, זה הגשר בין הנתונים המבוזרים לבין הקוד הרגיל של client.

זהות, הרשאה ו-aggregators

כדי שאפליקציה תדבר עם pod היא צריכה להיות compatible ל-Solid. היא עובדת מול identity profile, מבקשת authorization, ומקבלת WebID שמייצג את הזהות והגישה המותרת לה. WebID אינו רק פרופיל נחמד. הוא נקודת הכניסה לאפשרות לקרוא את הנתונים שהמשתמש אישר.

במערכת עם הרבה pods עולה אתגר אחר: performance. אם post אחד מקבל 100 likes, אפשר לחשוב על aggregator שמחזיק references ל-100 pods שונים. אם אדם מבטל גישה, הוא פשוט נעלם מהקישור. הבעיה זזה מניהול data מרכזי לדרך שבה קוראים, מאחדים ומציגים מידע מבוזר. זה אינו בחינם, אבל זו בעיה של קוד וביצועים שאפשר להתמודד איתה בלי להפוך כל אפליקציה למחסן של כל הנתונים בעולם.

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

שליטה בדאטה אינה פותרת אבטחה

מהקהל עולה השאלה המתבקשת: אם כל הדאטה יושב במקום אחד, האם זה לא יעד פריצה גדול יותר? יותם לא מבטל את החשש. הוא מדבר על authorization, על two-factor authentication, על הצפנה ועל התראות או ניתוק גישה במקרה חשוד. אבל עצם השאלה חשובה: pod אינו פטור מבחירת hosting, מהגנת credentials או מהבנה של מי מנהל את השרת.

Solid גם אינו מבטל את שאלת הכוח. אם כל המשתמשים ישימו pods אצל ספק אחד, אפשר לייצר ריכוזיות חדשה. ההבטחה של המודל תלויה בכך שהסטנדרטים וההרשאות באמת מאפשרים ניידות בין providers, ולא רק מחליפים data silo אחד באחר. יותם מציין שימוש של ממשלת בלגיה ב-pods לשירותים ממשלתיים כדוגמה לכך שהכיוון כבר נבחן מחוץ לדמו.

השורה התחתונה

Solid מציע שינוי בעלות, לא רק ספריית client חדשה:

• הנתונים האישיים יכולים לשבת ב-pod שהמשתמש שולט בו.
• אפליקציות מבקשות הרשאה במקום לצבור עוד עותק של כל פרופיל.
• RDF ו-vocabulary משותף נותנים לנתונים המבוזרים שפה משותפת.
• WebID ו-authorization מחברים בין זהות, הרשאה וגישה למשאבים.
• הביזור מחליף חלק מבעיות data בבעיות ביצועים, אבטחה ו-governance שצריך לנהל בגלוי.

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