ActivityPub को लागू करना कठिन क्यों है, और इसकी ज़रूरत क्यों नहीं है

 (hackers.pub)
2 पॉइंट द्वारा GN⁺ 5 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • अगर आप सीधे अपना ActivityPub सर्वर बनाते हैं, तो पहली Follow request पर ही बिना किसी explanation वाले 401 Unauthorized से अटक जाना आसान है, और Fedify एक TypeScript framework है जो signature·JSON-LD·delivery·security का बोझ application code के बाहर ले जाता है
  • फेडिवर्स authentication में expired draft draft-cavage-http-signatures-12 और standard RFC 9421 दोनों साथ इस्तेमाल होते हैं, और document signature तक शामिल करें तो चार तरह के signing mechanisms और RSA·Ed25519 keys संभालनी पड़ती हैं
  • वही ActivityPub activity JSON-LD में string, array, inline object, URI reference जैसी कई forms में आ सकती है, इसलिए direct implementation करने पर defensive code पूरे codebase में फैल जाता है
  • distributed delivery में “zombie post” जैसी समस्या होती है, जहाँ Delete, Create से पहले पहुँच जाता है; इसलिए queue·retry·idempotency·ordering guarantee·circuit breaker की ज़रूरत पड़ती है
  • Fedify 13 web frameworks के integration, KV·message queue adapters, CLI·linter·debugger·OpenTelemetry देता है, जिससे ActivityPub की गहरी details जाने बिना federated app development शुरू किया जा सकता है

सीधे ActivityPub लागू करते समय आने वाली समस्याएँ

  • Mastodon को पहली Follow activity भेजने के लिए JSON बनाना, HTTP request sign करना, और POST तक संभालना पड़ता है, लेकिन failure होने पर सिर्फ 401 Unauthorized की एक लाइन लौट सकती है
    • वजह Date header की clock skew, Digest hash error, (request-target) का uppercase/lowercase, public key के representation जैसे कारण हो सकते हैं
    • अगर remote server वजह न बताए, तो debugging के लिए दूसरे servers का code पढ़ना पड़ सकता है
  • Fedify की शुरुआत single-user microblog server Hollo बनाते समय हुई थी
    • जब ActivityPub implementation का बोझ product development पर हावी हो गया, तो इसे app से पहले ज़रूरी framework के रूप में बनाया गया
  • मुश्किलें मुख्य रूप से signing standards, JSON-LD document shapes, distributed delivery, implementation-specific conventions, और default security settings में केंद्रित हैं

signing standard एक ही नहीं है

  • server-to-server authentication के लिए HTTP signatures इस्तेमाल होते हैं, लेकिन असली फेडिवर्स में expired draft draft-cavage-http-signatures-12 और standard RFC 9421 दोनों मौजूद हैं
  • कौन-सा server कौन-सा signature स्वीकार करेगा, यह कोशिश किए बिना पता नहीं चलता; इसलिए पहले एक तरीके से sign करना, reject होने पर दूसरे तरीके से फिर sign करना, और जो तरीका सफल हो उसे server-wise याद रखना पड़ता है
    • इस प्रक्रिया को double-knocking कहा जाता है
  • HTTP signature सिर्फ request sender को prove करता है, इसलिए inbox forwarding जैसी स्थिति में, जहाँ मिली हुई activity को किसी तीसरे पक्ष तक भेजना हो, document पर लगी signature भी चाहिए
    • ज़रूरी mechanisms कुल चार हैं, जिनमें Linked Data Signatures और Object Integrity Proofs शामिल हैं
    • keys के लिए RSA और Ed25519 दोनों को साथ manage करना पड़ता है

JSON-LD document shape बार-बार बदलती रहती है

  • ActivityPub का transport format JSON-LD है, और एक ही अर्थ वाली Create activity भी कई रूपों में व्यक्त हो सकती है
    • actor एक URI string भी हो सकता है और inline Person object भी
    • to एक single string भी हो सकता है, या array भी
    • object inline object भी हो सकता है और URI भी
  • public audience बताने वाला address भी https://www.w3.org/ns/activitystreams#Public, as:Public, Public — इन तीनों रूपों में valid है
  • spec के मुताबिक process करने के लिए JSON-LD processor से expansion के बाद compaction करके normalize करना पड़ता है
    • कई implementations इसे “सिर्फ JSON” की तरह handle करती हैं, और फिर किसी specific server के निकाले हुए shape पर चुपचाप टूट जाती हैं
  • direct implementation में हर जगह यह जाँचने वाला defensive code उग आता है कि value string है, array है, object है, या fetch की जाने वाली URI है

distributed delivery और “zombie post”

  • अगर user पोस्ट करने के तुरंत बाद typo देखकर उसे delete कर दे, तो server Create के बाद Delete भेजता है, लेकिन network की स्थिति के अनुसार receiving server को Delete पहले मिल सकता है
    • अगर वह अभी मौजूद न होने वाली पोस्ट के delete को ignore कर दे और बाद में Create process करे, तो author जिसे deleted मान रहा है, वह पोस्ट उस server पर बनी रह जाती है
  • अगर followers 5,000 हों, तो एक पोस्ट हजारों HTTP deliveries बनाती है; request handler के अंदर यह सब process करने पर publish button का response धीमा हो सकता है या server गिर सकता है
  • queue इस्तेमाल करने पर भी failed deliveries के retry schedule, exponential backoff, retry count, 500 Internal Server Error और 410 Gone का फर्क, गायब हो चुके server के followers की सफाई, और लंबे समय से down hosts को कैसे handle करना है — यह सब तय करना पड़ता है
  • यह हिस्सा simple protocol implementation से ज़्यादा distributed systems engineering के करीब है

सिर्फ spec से interoperability पूरी नहीं होती

  • spec को पूरी तरह follow करने पर भी वास्तविक फेडिवर्स implementations के साथ interoperability issues बने रहते हैं
  • Mastodon का secure mode authorized fetch इस्तेमाल करता है, जो GET requests पर भी HTTP signature मांगता है
    • अगर दोनों servers secure mode में हों, तो सामने वाले की public key लाने के लिए sign करना पड़ता है, और signature verify करने के लिए सामने वाले को पहले मेरी public key लानी पड़ती है — इससे deadlock बन जाता है
    • community इसे server खुद को दर्शाने वाले instance actor से sign करके bypass करती है, लेकिन यह spec में नहीं है
  • Threads actor के inline object के रूप में आने वाली activities को parse नहीं कर पाता, इसलिए Threads को भेजते समय actor को URI के रूप में भेजना पड़ता है
  • Lemmy, Mastodon द्वारा न मांगे जाने वाले Group actor fields न हों तो चुपचाप reject कर देता है
    • उदाहरण हैं attributedTo से जुड़ी moderators collection और featured collection
  • Misskey की अपनी vocabulary extensions हैं, और सिर्फ quote post के लिए भी implementations के बीच तीन अलग property names इस्तेमाल होते हैं
  • interoperability एक बार मिलाकर खत्म हो जाने वाला काम नहीं, बल्कि लगातार बनाए रखने वाला क्षेत्र है

direct implementation की default स्थिति सुरक्षित नहीं होती

  • incoming activities के signature verification को skip कर दें, तो कोई भी forged Follow या Delete inject कर सकता है
  • document loader को restrict न करें, तो malicious activity http://169.254.169.254/ या internal network की ओर इशारा करके server को SSRF proxy बना सकती है
  • embedded objects के source check को छोड़ दें, तो कोई भी server ऐसा document निकाल सकता है जो किसी खास व्यक्ति के कहे हुए जैसा लगे
  • ये traps तुरंत नजर नहीं आते, और exploit होने से पहले तक सब कुछ ठीक से काम करता हुआ लग सकता है

जिन हिस्सों को Fedify संभालता है

  • Fedify ActivityPub और उससे जुड़े standards के लिए federated server apps बनाने की एक TypeScript library है
  • यह Deno, Node.js, Bun पर चलती है और Cloudflare Workers जैसे edge runtimes को भी support करती है
  • इसका design goal signatures, JSON-LD, delivery, implementation-specific differences, और security details को application code से हटाना है

  • Signature handling

    • actor dispatcher और key pair dispatcher register करने पर एक actor को fediverse पर publish किया जा सकता है
    • बाहर जाने वाली हर request पर signature लगाया जाता है
    • RSA keys के लिए HTTP Signatures और Linked Data Signatures बनाए जाते हैं
    • Ed25519 key जोड़ने पर Object Integrity Proofs भी लगाए जाते हैं
    • ये चारों mechanisms एक ही activity पर साथ मौजूद हो सकते हैं, और receiver अपनी समझ के अनुसार सबसे मजबूत तरीके से verification करता है
    • Fedify double-knocking को सीधे संभालता है
      • पहला संपर्क RFC 9421 के साथ जाता है, और reject होने पर draft-cavage से फिर कोशिश की जाती है
      • जो तरीका सफल होता है, उसे server के हिसाब से cache किया जाता है
      • अगर reject response में Accept-Signature challenge हो, तो server द्वारा मांगे गए components के साथ दोबारा sign किया जाता है
    • आने वाले signatures application code तक पहुंचने से पहले verify कर लिए जाते हैं, और verification fail होने वाली activities listener तक नहीं पहुंचतीं
    • सिर्फ actor dispatcher register करने से WebFinger RFC 7033 server भी बन जाता है, जिससे Mastodon search box में @alice@example.com जैसे रूप में actor को खोजा जा सकता है

  • JSON-LD की जगह types के साथ काम

    • Fedify Activity Vocabulary के पूरे सेट और प्रमुख vendor extensions को cover करने वाली लगभग 80 classes देता है
    • ये classes typed और immutable हैं, और accessors JSON-LD द्वारा अनुमति दी गई document shape की भिन्नताओं को absorb कर लेते हैं
    • lookupObject() handle लेकर WebFinger discovery सहित पूरी lookup प्रक्रिया चलाता है
    • getFollowers() जैसे accessors value चाहे URI reference हो या inline object, एक ही तरह से काम करते हैं, और fetch किए गए values cache हो जाते हैं
    • vendor-specific differences भी API के पीछे छिपे रहते हैं
      • quoteUri, _misskey_quote, quoteUrl ये तीन quote properties, नए FEP-044f के quote के साथ, एक ही API के पीछे unify की गई हैं
      • Misskey की isCat property भी type के रूप में मौजूद है, इसलिए इसे type-safe तरीके से handle किया जा सकता है

  • Delivery infrastructure और ordering guarantee

    • createFederation() से message queue जोड़ने पर delivery background में चली जाती है, और failure होने पर default रूप से अधिकतम 10 बार तक exponential backoff के साथ auto-retry होता है
    • जब एक post हजारों followers तक पहुंचाई जाती है, तब two-stage fan-out काम करता है
      • queue में एक consolidated message डाला जाता है
      • background worker इसे server-wise delivery jobs में बांट देता है
      • publish button तुरंत response देता है
    • retries के कारण एक ही activity दो बार पहुंच सकती है, इसलिए Fedify idempotency cache में processed activities को 24 घंटे तक रखकर duplicate को handler से पहले ही skip कर देता है
    • sendActivity() call में { orderingKey: post.id } देने पर, एक ही orderingKey साझा करने वाली activities हर receiving server को भेजे जाने के क्रम में deliver होती हैं
      • Delete, Create से पहले नहीं पहुंच सकता
      • अलग key वाली activities parallel में भेजी जाती हैं ताकि throughput बना रहे
    • 404 Not Found या 410 Gone मिलने पर retry रोक दी जाती है और registered permanent delivery failure handler को call किया जाता है
    • shared inbox पर भेजे जाने की स्थिति में उसके पीछे की followers list भी ली जा सकती है, ताकि गायब हो चुके accounts को साफ किया जा सके
    • बार-बार fail होने वाले hosts के लिए default रूप से enabled circuit breaker delivery को hold पर रखता है और समय-समय पर recovery check करता है

Implementation-specific practices और security defaults

  • authorized fetch में Fedify .authorize() को dispatcher से जोड़कर verified requester identity को callback में देता है
    • blocklist, private collections जैसी handling application logic में लिखी जा सकती है
    • instance actor deadlock problem के लिए भी supported pattern मौजूद है
  • Threads की inline actor समस्या को default-enabled activity transformer outgoing activities के inline actor को URI में बदलकर संभालता है
  • Lemmy को चाहिए moderators collection, जिसे custom collection API से कुछ पंक्तियों में expose किया जा सकता है, और Lemmy का JSON-LD context पहले से शामिल है
  • जब नया interoperability issue मिलता है, तो fix हर application में नहीं बल्कि Fedify में जोड़ा जाता है
  • security defaults सुरक्षित दिशा में रखे गए हैं
    • signature verification कोई ऐसा feature नहीं है जिसे on करना पड़े, बल्कि testing के लिए off करना पड़ता है
    • document loader private address ranges और loopback को default रूप से block करता है, और DNS rebinding को भी ध्यान में रखता है
    • SSRF के संपर्क में आने के लिए testing को साफ दिखाने वाले नाम वाला option explicit रूप से enable करना पड़ता है
    • अगर embedded object का origin parent document से अलग हो, तो accessor उस पर भरोसा नहीं करता और origin से फिर fetch करता है
    • यह origin-based security model FEP-fe34 पर आधारित है

मौजूदा स्टैक और डेवलपर टूल्स

  • Fedify को मौजूदा web stack के अनुरूप डिज़ाइन किया गया है और यह 13 web framework integrations प्रदान करता है
    • Express, Hono, Fastify, Koa, NestJS, Elysia
    • Next.js, Nuxt, SvelteKit, Astro, SolidStart, Fresh
  • Middleware content negotiation को संभालता है, इसलिए वही URL ब्राउज़र को HTML और fediverse को JSON-LD दे सकता है
  • Fedify के अपने storage में केवल एक key-value interface की आवश्यकता होती है
    • Redis, PostgreSQL, MySQL/MariaDB, SQLite, Deno KV, Cloudflare Workers KV, in-memory adapter उपलब्ध हैं
  • Message queue के लिए PostgreSQL, Redis, AMQP/RabbitMQ आदि सहित 8 विकल्प दिए गए हैं, और अगर इनमें उपयुक्त कुछ न हो तो interface को सीधे implement किया जा सकता है
  • Domain data को मौजूदा database और ORM में वैसे ही रखा जा सकता है
  • अगर आप पहले से किसी दूसरी library से federation चला रहे हैं, तो migration guide और data migration script की मदद से activitypub-express आदि से मौजूदा followers खोए बिना migration किया जा सकता है
  • Upper-level packages भी उपलब्ध हैं
    • @fedify/relay एक function call में पूरा ActivityPub relay server उपलब्ध कराता है
    • @fedify/backfill fediverse को ट्रैक करते हुए अधूरे conversation thread को पुनर्स्थापित करता है

  • डेवलपमेंट लूप के लिए टूल्स

    • fedify init एक लाइन में project scaffold करता है
    • fedify tunnel local server को HTTPS पर expose करता है ताकि वास्तविक Mastodon के साथ test किया जा सके
    • fedify inbox server द्वारा भेजी जाने वाली activities प्राप्त करने के लिए एक अस्थायी inbox server चलाता है
    • fedify lookup दूसरे server द्वारा पोस्ट किए गए objects की जांच करने देता है
    • fedify lookup --authorized-fetch एक बार इस्तेमाल होने वाली key pair बनाता है और अस्थायी ActivityPub server खड़ा करके secure mode के पीछे मौजूद objects पर signed requests भेजता है
    • @fedify/lint ActivityPub-विशेष linter है जो actor में inbox न होने जैसे 20 interoperability bugs पकड़ता है
    • @fedify/testing के mock से network के बिना tests चलाए जा सकते हैं
    • @fedify/debugger एक लाइन में debug dashboard जोड़ देता है, जिससे browser में activities और signature verification के नतीजे real time में देखे जा सकते हैं
    • प्रोडक्शन environment के लिए OpenTelemetry instrumentation built-in है और यह 28 span type और 37 metrics प्रदान करता है
    • Monitoring guide और ActivityPub के लिए load testing tool fedify bench भी दिए गए हैं
    • आधिकारिक documentation में 30 manual chapters और 5 tutorials शामिल हैं, और इसमें queue backlog देखने के लिए PromQL queries, alert rules, तथा Mastodon में avatar दिखाने वाले properties जैसी वास्तविक प्रथाएँ शामिल हैं

पहले से उपयोग में आने वाले उदाहरण और शुरुआत कैसे करें

  • Fedify का उपयोग वास्तविक services में किया जा रहा है
    • Ghost की ActivityPub service
    • ORCID researcher records को fediverse से जोड़ने वाला Encyclia
    • Cloudflare Workers पर serverless रूप में चलने वाला SiliconBeest
    • कोरिया का blogging platform Typo Blue
    • single-user microblogging platform Hollo
    • community द्वारा संचालित Hackers' Pub
  • Tutorials अलग-अलग scale के उदाहरण प्रदान करते हैं
  • Fedify का लक्ष्य अधिक ActivityPub experts बनाना नहीं, बल्कि developers को ActivityPub की बारीकियाँ जाने बिना federated apps बनाने लायक बनाना है
  • शुरुआत का command npm init @fedify है
  • मदद चाहिए तो Matrix room या GitHub Discussions का उपयोग किया जा सकता है

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

1 टिप्पणियां

 
GN⁺ 5 시간 전
Lobste.rs टिप्पणियाँ

  • यही वजह है कि ActivityPub प्रोजेक्ट्स में एक-दूसरे के इतने सारे fork हैं: सब कुछ खुद implement करने से आसान है किसी और के approach को समझ लेना
    लेखक जो propose कर रहा है, वह असल में अक्सर दिखने वाले Misskey या Pleroma forks से बहुत अलग नहीं लगता। Libraries की भी अपनी नज़र और approach होती है, और वे शायद ज़्यादा control नहीं देतीं। फिर भी, पूरे server को fork करने की तरह UI तक थोपती नहीं हैं, यह एक फ़ायदा है
    AP implement करने वाले के नज़रिए से सबसे मुश्किल हिस्सा यह है कि JSON-LD को ठीक से इस्तेमाल करने का कोई अच्छा तरीका नहीं है। अगर objects को standard representation में आसानी से बदला जा सके, तो interoperability अपने-आप आ जाएगी, लेकिन इसे सचमुच linked documents की तरह इस्तेमाल करना बहुत inefficient है, और raw JSON documents की तरह इस्तेमाल करो तो अनगिनत edge cases मार डालते हैं। अभी तक मैंने दूसरा approach चुना था और बुरी तरह फँस गया

    • खासकर signatures को सोचें तो “object की standard representation” वाली समस्या और भी महत्वपूर्ण हो जाती है। पुराना XML canonicalization इसी signature समस्या के लिए था, यानी यह सुनिश्चित करने के लिए कि receiver की byte serialization sender वाली से match करे
      यह JSON-LD world की बिल्कुल वही समस्या नहीं है, लेकिन पूरी तरह असंबंधित भी नहीं है
      वैसे मुझे लगता है कि JSON के आसपास की काफ़ी technologies इसी तरह की समस्या झेलती हैं। एक ही logical schema को express करने के JSON Schema के बहुत ज़्यादा तरीके हैं, और इसी वजह से JSON Schema के आसपास की technologies के साथ interact करना हास्यास्पद रूप से डरावना हो जाता है। खासकर OpenAPI schema एक मिलता-जुलता लेकिन अलग horror show है, और schema draft versions की गिनती किए बिना भी हालत पहले से काफी खराब है
    • मैं AP server implementation के बारे में सोचता रहा हूँ, लेकिन अभी शुरू नहीं किया है, इसलिए मेरी बात को छाँटकर सुनना चाहिए। एक चीज़ मददगार हो सकती है: application को छोटे services में बाँटना, और actor model पर ज़्यादा निर्भर रहना ताकि वह एक “integrated” interface जैसा दिखे। उदाहरण के लिए email server में MTA और MUA के separation से सीखा जा सकता है
      AP का “MTA” service outbox से message भेजने और inbox में message लेने का काम करता है। JSON-LD documents इस service के नज़रिए से लगभग blob data जैसे हैं। Sender और receiver को पता करने के लिए थोड़ा parsing चाहिए, लेकिन उससे ज़्यादा नहीं। Storage file-based भी हो सकती है, और अगर मुझे सही याद है तो go-ap ऐसा ही करता है
      AP का “MUA” असल application है। JSON-LD semantics को समझना इसी का काम है। PostgreSQL जैसी किसी चीज़ का इस्तेमाल करके documents को jsonb में store किया जा सकता है, और generated columns व views से SQL-friendly रूप दिया जा सकता है। फिर object type के हिसाब से तय किया जा सकता है कि document को किस तरह सबसे ठीक से represent किया जाए
      एक और उदाहरण के तौर पर search service को भी actor की तरह model किया जा सकता है, ताकि वह results को temporary outbox में वापस दे

  • यह अलग-अलग implementations के अजीब व्यवहार और उनके mitigations की बेहद क़ीमती सूची है
    अफ़सोस कि GoActivityPub में उनमें से आधे भी अभी तक implement नहीं हुए हैं

  • शुरू में लेख technical बातों से शुरू हुआ तो अच्छा लगा, लेकिन बीच में जाकर यह अपने framework promotion की तरफ मुड़ गया, जिससे पढ़ने का मज़ा कम हो गया
    TypeScript इस्तेमाल करने वाली कुछ दुनिया के लिए यह अच्छी बात है कि शायद उन्हें implementation के इन quirks को फिर से discover न करना पड़े। लेकिन अगर दिमाग़ी मॉडल के तौर पर “इन conditions और situations में यह result आता है, और यह fix चाहिए” जैसी कोई record हो, तो TypeScript के बाहर की स्थितियों में भी, जैसे sibling project GoActivityPub के लेखक को, उस मेहनत का फ़ायदा मिल सकता है। यहाँ ऐसी कुछ बातें हैं, लेकिन लेख एक खास समय का snapshot है, और project समय के साथ ऐसे लगता है जैसे हर interoperability bug को जमा करने की कोशिश कर रहा हो
    अभी जो विकल्प दिखता है, वह है ऐसे commit messages पढ़ते जाना जो इंसान ने लिखे हुए नहीं लगते, और Fedify के अपने bugs और interoperability bugs में फ़र्क करना
    खास तौर पर यह विडंबना है कि repository AI पर “all-in” दिखती है, फिर भी ऐसा ledger maintenance नहीं करती। LLM के बारे में जो प्रचार सुना है वह यही है कि वे repetitive busywork को automate करते हैं। तो फिर Claude से GitHub issues बनवाओ, या और बेहतर यह कि repository के अंदर .md files में observed results और Fedify उन्हें कैसे fix करता है, यह document करवाओ। इसका अपना debugger भी है और कुछ “best practices” भी हैं जिनका मतलब साफ़ नहीं, तो यह उसके लिए एकदम सही काम लगता है

    • बहुत ही मामूली समस्याओं को बढ़ा-चढ़ाकर ActivityPub की विफलता की तरह पेश किया गया है। उदाहरण के लिए, अगर 5 हज़ार followers हैं तो एक post के लिए हज़ारों HTTP deliveries होंगी, और अगर इन्हें request handler के अंदर सीधे किया जाए तो post button के response में 30 सेकंड लगेंगे या server गिर जाएगा, इसलिए queue इस्तेमाल करो
      भला third-party services को जाने वाले requests inline क्यों किए जा रहे हैं? यह तो web application की बुनियादी समझ है। अगर third-party services से बात करनी है, तो उसे background jobs में भेजना चाहिए। अगर कोई जानकारी request का जवाब देने के लिए ज़रूरी नहीं है, तो उसे background jobs में भेजना चाहिए। Request handler के अंदर ऐसे requests करके जो समस्याएँ पैदा होती हैं, वे खुद बुलाई हुई मुसीबत हैं, ActivityPub से उनका कोई लेना-देना नहीं
      Delivery fail हो जाए तो retry करना होगा, schedule कैसे होगा, exponential backoff इस्तेमाल करना है या नहीं, कितनी बार करना है, 500 Internal Server Error और 410 Gone को एक जैसा failure मानना है या नहीं — ये सब बस सामान्य web application development की समस्याएँ हैं। ये job queue से third-party services को requests भेजने पर होने वाली समस्याएँ हैं, ActivityPub से असंबंधित। ज़्यादातर web frameworks में reasonable defaults होते हैं। केवल वहीं फैसला लेना पड़ता है जहाँ error के प्रकार के आधार पर retry करना है या नहीं तय करना हो। 410 पर retry करना बेकार है, लेकिन कोई तुरंत सुलझाने लायक संकट भी नहीं। इससे job queue पर memory pressure बढ़ेगा, लेकिन कुछ घंटों में application गिर जाने की संभावना कम है

  • “देखो reject होता है या नहीं, फिर दूसरे तरीके से दोबारा sign करो, और server के हिसाब से याद रखो कि कौन-सा तरीका काम आया” — यह आखिर मैं क्या पढ़ रहा हूँ? क्या इसी वजह से Mastodon development धीमा है?
    “एक post हज़ारों HTTP deliveries बन जाती है,” वह भी Ruby में, जो network systems programming और queueing में महान भाषा के तौर पर मशहूर है
    यक़ीन करना मुश्किल है, और अच्छा है कि इसे library में wrap किया गया है, लेकिन फिर भी थोड़ा अजीब लगता है

  • Java में ActivityPub implement करके, मैं इस नतीजे पर पहुँचा कि ऐसे server-to-server protocols को बस git के ऊपर बनाना बेहतर होगा
    Complexity का बड़ा हिस्सा उन समस्याओं को फिर से हल करने के लिए मौजूद है जिन्हें git पहले से बेहतर तरीके से हल करता है। अगर इसे git repository के अंदर JSON documents के रूप में model किया जाए, तो pagination से निपटना नहीं पड़ेगा। Protocol पहले से यह सुनिश्चित करेगा कि केवल missing data ही भेजा जाए, commit signatures भी मिलेंगी, event ordering की guarantee भी मिलेगी, इस लेख में बताई गई समस्याएँ भी सुलझेंगी, और history मुफ़्त में मिल जाएगी। ऐसे protocols के लिए शायद Greenspun’s tenth law जैसी कोई बात बनाई जा सकती है कि इनमें git का buggy और slow half-implementation छिपा होता है

    • git कोई शानदार विकल्प नहीं है, क्योंकि इसकी history parent commits पर निर्भर करती है। लेकिन इसी तरह की negotiation strategy पर चलने वाला Merkle tree gossip protocol अच्छी तरह फिट हो सकता है

  • यह लेख AI द्वारा बनाया गया low-quality लेख लगता है
    और ज़्यादा specific कहूँ तो समझ नहीं आता कि इसे narrative style में क्यों लिखा गया। यहाँ जो तथ्य दिए गए हैं उन्हें कहीं ज़्यादा संक्षेप में और कम पक्षपाती ढंग से लिखा जा सकता था, और narrative भी convincing नहीं है। खासकर इसमें AI-विशेष तरह की बहुत-सी अभिव्यक्तियाँ हैं
    पढ़ने में मज़ा नहीं आया। फिर भी, समस्याओं की ओर इशारा करने के लिए धन्यवाद, और उम्मीद है कि इन्हें किसी और रूप में पढ़ा और सुधारा जा सकेगा