fedify से अलगाव – दूर जाने के बाद समझ में आईं fedify की अच्छी बातें

 (blog.atfedi.de)
2 पॉइंट द्वारा nyanrus 4 시간 전 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें

(यह मेरे द्वारा चलाए जा रहे ब्लॉग की पोस्ट है। मुख्य लेख मैंने अपने साथ काम करने वाले AI assistant Shiro की मदद से लिखा है, और यदि कहीं गलत पढ़ा या समझा गया हो तो बताने के लिए आभारी रहूँगा)

छोटा fediverse (Mastodon की तरह सर्वरों के बीच आपस में जुड़े SNS नेटवर्क) सर्वर sukhi-fedi ने fedify (Bun worker पर चलने वाली लाइब्रेरी), जो JSON-LD असेंबली (मैसेज को सर्वरों के बीच समझ में आने वाले फ़ॉर्मैट में बनाने का काम) और HTTP signatures (मैसेज असली है या नहीं, यह जाँचने की signature प्रक्रिया) संभाल रही थी, को हटाकर सब कुछ सीधे Elixir में लागू करने का यह रिकॉर्ड है। यह बुराई करने वाला लेख नहीं है; इसका आधा हिस्सा तो वास्तव में "दूर जाने के बाद समझ में आईं fedify की अच्छी बातें" है।

  • शुरुआत से ही fedify की framework सुविधाएँ (createFederation, inbox listener, dispatcher आदि — federation की पूरी क्षमता अपने-आप संभालने वाले उच्च-स्तरीय टूल) इस्तेमाल नहीं की गईं; सिर्फ सबसे निचली परत के हिस्से उधार लिए गए थे:

    • vocab classes
    • toJsonLd/fromJsonLd (मैसेज फ़ॉर्मैट को एक-दूसरे में बदलने वाला converter)
    • signRequest/verifyRequest, जो draft-cavage और RFC 9421 दोनों signature तरीकों को जानते हैं
    • LD signatures, document loader
    • key/JWK (public key रखने का मानक फ़ॉर्मैट) input/output

  • हटाने के तीन कारण थे:

    1. जैसे ही framework का उपयोग न करने का फैसला किया, fedify जो चीज़ें मुफ्त में संभाल देता था (Follow के लिए Accept reply, idempotency, authorized fetch, instance actor) वे सब वैसे भी सीधे खुद ही संभालनी पड़ रही थीं। आखिर में सिर्फ बुनियादी हिस्से बचे थे, इसलिए migration की मात्रा तय थी
    2. लक्ष्य 512~768MB memory वाले छोटे सर्वर का है, लेकिन durability test में Elixir 130MB पर स्थिर रूप से पूरा चला गया, जबकि सिर्फ Bun worker ही 120MB पर OOM (memory की कमी से क्रैश) हो गया। सिस्टम में जो अकेला हिस्सा दूसरी भाषा में चल रहा था, वही सबसे भारी और सबसे कमज़ोर निकला
    3. भाषा और process की सीमा खुद समस्याएँ पैदा कर रही थी। signature verification के लिए ज़रूरी raw data को बचाकर रखना, tunnel द्वारा बदल दिए गए addresses को restore करना, DB में मौजूद keys को JWK में पैक करके दूसरे process तक पहुँचाना — यह fedify की गलती नहीं थी, लेकिन plumbing का काम लगातार बढ़ता जा रहा था

  • replacement का काम 12 files, लगभग 2,100 lines में खत्म हो गया। message queue structure को वैसे ही रखा गया, उसे उसी group में शामिल किया गया, और switch-over बस "Bun container को रोक देना" भर था

  • safety net देने वाला भी खुद fedify ही था। Ed25519 signatures और URDNA2015 normalization (दस्तावेज़ को हमेशा एक ही क्रम में व्यवस्थित करने का नियम) एक ही input पर हमेशा एक जैसा result देते हैं, इसलिए असली fedify code से पहले से "सही डेटा" निकालकर रखा जा सकता था और Elixir में बदले गए नतीजे को एक भी अक्षर चूके बिना verify किया जा सका

  • Bun worker रिटायर हो गया है, लेकिन हटाया नहीं गया। आज भी development environment में सही डेटा बनाने की भूमिका में मौजूद है

  • fedify टीम ActivityPub debugging tool DrFed(https://drfed.org/) बना रही है। इसमें federation किस चरण (DNS/TLS/HTTP/signature/JSON-LD) पर टूटा है, यह बताने वाली diagnostic सुविधा और दोनों signature तरीकों को step-by-step देखकर समझने वाला debugger आदि शामिल होने वाले हैं (NLnet NGI0 समर्थन, AGPL-3.0 open source, फिलहाल development में)

  • निष्कर्ष यह भी है: अगर आप TypeScript/JavaScript में पूरा framework इस्तेमाल कर रहे हैं, तो fedify अब भी सबसे अच्छा विकल्प है। Ghost की ActivityPub सुविधा, hackers.pub, और Hollo सभी उसी पर चल रहे हैं

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.