लोकल-फर्स्ट सॉफ़्टवेयर: क्लाउड युग में भी अपने डेटा का स्वामित्व रखना (2019)

 (inkandswitch.com)
2 पॉइंट द्वारा GN⁺ 2025-07-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • क्लाउड ऐप्स ने collaboration और multi-device accessibility को काफी बेहतर बनाया है, लेकिन डेटा की authoritative copy सर्वर पर होने से उपयोगकर्ता का स्वामित्व और नियंत्रण कमज़ोर हो जाता है
  • local-first software में laptop, tablet और phone के local storage को डेटा की मुख्य copy माना जाता है, और server की भूमिका केवल sync और backup में मदद करने तक सीमित रहती है
  • यह approach तेज़ response, offline काम, कई devices के बीच sync, real-time collaboration, long-term preservation, और default security व privacy को एक साथ हासिल करना चाहती है
  • files, email, web apps, Dropbox-जैसी sync services, Git, Firebase, CloudKit, Realm, CouchDB में अपने-अपने कुछ फायदे हैं, लेकिन वे collaboration और data ownership दोनों को साथ में पूरी तरह संतुष्ट नहीं करते
  • CRDT और Automerge आधारित prototypes ने संभावनाएँ दिखाई हैं, लेकिन performance, network communication, P2P stability, और distributed document UI जैसी चुनौतियाँ अभी बाकी हैं

क्लाउड collaboration और data ownership का टकराव

  • Google Docs, Figma, Slack, Trello जैसे क्लाउड ऐप्स browser या mobile app से access किए जाते हैं और डेटा को server पर store करते हैं
  • यह model real-time collaboration और कहीं से भी access की सुविधा देता है, लेकिन हर data access को server से होकर गुजरना पड़ता है
    • केवल वही काम किए जा सकते हैं जिनकी server अनुमति देता है
    • service बंद हो जाए तो सिर्फ software ही नहीं, उस software से बनाए गए data तक की पहुँच भी रुक सकती है
    • data export किया जा सके तब भी server के बिना उसी software को चलाते रहना मुश्किल हो सकता है
  • इसके उलट, पुराने local apps local disk की files को पढ़ते और लिखते हैं, इसलिए user backup, long-term storage, दूसरे programs से manipulation, और deletion को सीधे नियंत्रित कर सकता है
  • मूल तनाव यह है कि क्लाउड collaboration देता है, जबकि local apps ownership देते हैं; local-first इन दोनों को साथ पाने की design direction है

local-first software का मूल model

  • local-first software remote datacenter के servers की तुलना में local storage और local network को प्राथमिकता देता है
  • क्लाउड ऐप्स में server data authoritative original होता है, और client का data server पर निर्भर cache जैसा होता है
  • local-first apps में हर device का local data मुख्य copy होता है, और server कई devices से access व backup में मदद करने वाली secondary copy रखता है
  • यह नज़रिया बदलने से performance, offline use, long-term preservation, privacy, और user control पर सीधा असर पड़ता है

local-first के 7 आदर्श

  • 1. spinner के बिना तुरंत काम

    • क्लाउड ऐप्स में data modification और कई queries के लिए server round-trip चाहिए, इसलिए delay होता है
    • Optimistic UI request पूरी हो चुकी है ऐसा दिखाकर delay छिपाता है, लेकिन network error होने पर वही delay फिर सामने आ जाता है
    • local-first apps में मुख्य data local device पर होता है, इसलिए user input को server response का इंतज़ार कम करना पड़ता है
    • sync background में चलता है, और app input पर लगभग तुरंत प्रतिक्रिया दे सकता है

  • 2. एक device तक सीमित न रहने वाला काम

    • उपयोगकर्ता smartphone पर idea capture करता है, tablet पर उसे व्यवस्थित करता है, और laptop पर documentation करता है — यानी कई devices के बीच आता-जाता है
    • local-first apps में भी हर device पर data रखते हुए सभी working devices के बीच sync ज़रूरी है
    • ज़्यादातर inter-device sync services server पर भी एक copy रखती हैं, ताकि offsite backup का काम हो सके
    • कई लोग एक ही file को एक साथ edit करें तो conflicts हो सकते हैं, इसलिए collaboration design महत्वपूर्ण हो जाती है

  • 3. network एक विकल्प हो

    • airplane, tunnel, elevator, parking garage, unstable WiFi, roaming cost, और developing countries या ग्रामीण इलाकों के अधूरे internet environment offline काम की ज़रूरत पैदा करते हैं
    • क्लाउड ऐप्स आम तौर पर offline में कमज़ोर होते हैं, और server-centric model में बाद में offline support जोड़ना भी कठिन होता है
    • local-first apps हर device के local filesystem में मुख्य data store करते हैं, इसलिए offline में भी पढ़ना और लिखना संभव है
    • बाद में network उपलब्ध होने पर दूसरे devices के साथ sync किया जा सकता है, और sync केवल internet ही नहीं बल्कि Bluetooth या local WiFi से भी हो सकता है
    • अच्छे offline experience के लिए browser tab की तुलना में local installed executable ज़्यादा उपयुक्त होता है

  • 4. साथियों के साथ सहज collaboration

    • पुराने local file-based software में कई लोग एक ही file को साथ edit करें तो conflict होने की संभावना अधिक होती है
    • Google Docs जैसे क्लाउड ऐप्स ने कई users द्वारा एक ही document को एक साथ edit करने और conflict की चिंता न करने वाले अनुभव को लोकप्रिय बनाया
    • local-first का आदर्श यह है कि आज के बेहतरीन क्लाउड ऐप्स जितना या उनसे बेहतर real-time collaboration support किया जाए
    • ऐसा flow भी महत्वपूर्ण है जिसमें एक user बदलाव सुझाए और दूसरा user review करके उन्हें चुनिंदा रूप से लागू करे
      • Google Docs का suggesting mode
      • GitHub का pull request

  • 5. Long Now: दीर्घकालिक accessibility

    • data ownership का एक अहम पहलू यह है कि भविष्य में भी लंबे समय तक उस तक पहुँचा जा सके
    • पुराने local apps में data और executable software की copy हो तो उन्हें इस्तेमाल करते रहना संभव है, और पुराने operating systems या computers भी virtual machine या emulator से चलाए जा सकते हैं
    • storage media बदल जाए तो भी files को नए media में copy किया जा सकता है
    • क्लाउड ऐप्स इस धारणा पर निर्भर करते हैं कि service चलती रहेगी, इसलिए वे service shutdown, data loss, price या feature changes, और unwanted forced upgrades के प्रति संवेदनशील होते हैं
    • local-first software में data और उसे पढ़ने-संशोधित करने वाला software local में store रहता है, इसलिए long-term preservation की संभावना बढ़ जाती है
    • plain text, JPEG, PDF के लंबे समय तक पढ़े जा सकने की संभावना अधिक है, और U.S. Library of Congress dataset preservation formats के रूप में XML, JSON, SQLite की सिफारिश करता है

  • 6. default के रूप में security और privacy

    • क्लाउड ऐप्स सभी users का data एक central database में इकट्ठा करते हैं, इसलिए वे attackers के लिए आकर्षक target बन जाते हैं
    • internal employees या server access पाने वाले hackers data को पढ़ या modify कर सकते हैं, और data breach भी एक आम जोखिम बना रहता है
    • Google Drive की terms बताती हैं कि automated systems customized search results, spam और malware detection के लिए user content का analysis करते हैं
    • healthcare professionals, investigative journalists, और government या diplomatic officials जैसे sensitive data संभालने वाले users के लिए क्लाउड ऐप्स का उपयोग regulations या confidentiality obligations से टकरा सकता है
    • local-first apps हर local device पर केवल user का अपना data store कर सकते हैं, और server पर केवल end-to-end encrypted copies रख सकते हैं
    • iMessage, WhatsApp, Signal, Keybase, Tarsnap को end-to-end encryption या encrypted file sharing व backup के उदाहरण के रूप में प्रस्तुत किया गया है

  • 7. अंतिम स्वामित्व और नियंत्रण

    • क्लाउड ऐप्स में service provider user की access को सीमित कर सकता है
    • अक्टूबर 2017 में कुछ Google Docs users के documents को automated system ने गलती से malicious चिह्नित कर दिया, जिससे document access block हो गई
    • यहाँ ownership का अर्थ intellectual property नहीं, बल्कि user agency, autonomy, और data control है
    • local-first software में data बनाने वाले bytes user के device पर होते हैं, इसलिए उन्हें मनचाहे तरीके से process करने की स्वतंत्रता होती है
    • data ownership के साथ backup बनाए रखना, data loss रोकना, ransomware का सामना करना, और file archive manage करने की ज़िम्मेदारी भी आती है
    • local-first का open source होना अनिवार्य नहीं है; commercial या closed-source software भी files के उपयोग पर कृत्रिम प्रतिबंध न लगाएँ तो इस आदर्श के करीब आ सकते हैं
    • कृत्रिम प्रतिबंधों के उदाहरण के रूप में print रोकने वाले PDF, copy-paste में बाधा डालने वाले eBook readers, और media file DRM का उल्लेख किया गया है

मौजूदा स्टोरेज·शेयरिंग मॉडल की सीमाएँ

  • फ़ाइलें और email attachments

    • पारंपरिक फ़ाइलें offline viewing·editing, user control, backup, long-term preservation, और fast access में मज़बूत होती हैं
    • कई devices से access के लिए email, USB, NAS/NFS/FTP/rsync, Dropbox जैसी file sync, या Git जैसे तरीकों की ज़रूरत होती है
    • email attachments समझने में आसान और भरोसेमंद हैं, और 6 महीने बाद भी attachment अपनी मूल स्थिति में बना रहता है
    • इसकी कमजोरी collaboration है
      • आम तौर पर एक समय में सिर्फ़ एक व्यक्ति ही फ़ाइल को modify कर सकता है
      • कई लोग edit करें तो manual merge की ज़रूरत पड़ती है
      • Budget draft 2 (Jane's version) final final 3.xls जैसे filename confusion पैदा होते हैं
    • local-first विचार अपनाने की कोशिश करने वाले apps plain text, PDF, PNG, JPEG जैसे व्यापक रूप से समर्थित formats में export देना शुरू कर सकते हैं

  • वेब apps

    • Google Docs, Trello, Figma, Pinterest जैसे web apps में browser या mobile app एक thin client होता है और data store server पर होता है
    • web apps ने real-time collaboration का standard स्थापित किया, और team work में latest version को कहीं से भी देखने का बड़ा फ़ायदा दिया
    • इसके उलट ownership और control काफ़ी कम हो जाते हैं
      • server data ही source of truth होता है और client data cache के क़रीब होता है
      • network थोड़ी देर के लिए भी कट जाए तो काम के बीच access रुक सकता है
      • Google Docs offline plugin जैसी सीमित offline support server-centric architecture पर बाद में जोड़ी गई चीज़ के क़रीब है
    • Milanote और Figma जैसे installed desktop clients भी मूल रूप से repackaged browsers ही हैं, इसलिए network failure·server outage·service shutdown की स्थिति में उनकी सीमाएँ सामने आती हैं

  • Dropbox, Google Drive, Box, OneDrive

    • Dropbox, Google Drive, Box, OneDrive desktop पर एक designated folder को monitor करते हैं और बदली हुई files को दूसरे computers पर copy करते हैं
    • local filesystem का उपयोग करने से ये तेज़ होते हैं और offline काम संभव होता है, और sync service बंद हो जाए तब भी local disk पर files बनी रहती हैं
    • hard disk failure होने पर app install करके sync का इंतज़ार कर restore किया जा सकता है, इसलिए long-term use और control के लिहाज़ से इनके फ़ायदे हैं
    • mobile iOS·Android पर ये पूरे folder को sync नहीं करते, बल्कि server से files को एक-एक करके लाने वाले thin client model के ज़्यादा क़रीब होते हैं
    • “Make available offline” option पहले से specify करना पड़ता है, यह झंझटभरा है, और सिर्फ़ app खुले होने पर ही काम करता है
    • सबसे कमज़ोर बिंदु real-time collaboration है
      • एक ही फ़ाइल दो devices पर modify हो जाए तो conflict पैदा होता है, जिसे manual merge से सुलझाना पड़ता है
      • arbitrary file formats को sync कर पाना compatibility का फ़ायदा है, लेकिन format-specific merge न कर पाना इसकी कमजोरी भी है

  • Git और GitHub

    • Git और GitHub मुख्य रूप से source code collaboration के लिए इस्तेमाल होते हैं, और अभी इन्हें local-first के सबसे क़रीब software package माना जाता है
    • Git repository local filesystem में data की मुख्य copy होती है और server पर निर्भर नहीं रहती
    • यह complete offline work, fast performance, user control, और long-term preservation के लिए उपयुक्तता प्रदान करता है
    • GitHub collaboration, multiple device access, backup और archive location देता है, लेकिन repository को encrypt नहीं करता
    • Git की दो बड़ी कमजोरियाँ हैं
      • Google Docs, Trello, Figma जैसी fine-grained real-time auto-merge collaboration इसमें नहीं है
      • यह code और line-based text के लिए optimized है, जबकि दूसरे file formats को अक्सर ऐसे binary blob की तरह handle किया जाता है जिन्हें अर्थपूर्ण तरीके से edit·merge करना कठिन होता है
    • बहुत से software engineers Cloud9, Repl.it, Colaboratory जैसे cloud-based editors·runtime environments को “slow”, “trust नहीं करते”, और “code को local system पर रखना चाहते हैं” जैसे कारणों से पसंद नहीं करते; यह local-first प्रेरणा से जुड़ता है

डेवलपर इन्फ्रास्ट्रक्चर के नज़रिए से विकल्प

  • thin client web apps

    • यह Rails, Django, PHP, Node.js server द्वारा SQL या NoSQL database में data store करने और HTTPS से web pages serve करने वाला model है
    • installation की ज़रूरत नहीं होती, user को बस URL पर जाना होता है, और data management की ज़िम्मेदारी deploy करने वाली engineering·DevOps team पर होती है
    • Meteor, ShareDB, Pusher, Ably, WebSocket web apps में real-time collaboration features जोड़ना आसान बनाते हैं
    • अगर हर user action पर server request चाहिए, तो यह धीमा हो जाता है, और client JavaScript से round-trip time छिपाने पर भी unstable internet में यह आसानी से टूट जाता है
    • manifest, localStorage, service worker, Progressive Web Apps जैसे प्रयासों के बावजूद web app architecture मूल रूप से server-centric ही रहता है
    • browser में cookies delete कर देने पर local storage data भी अक्सर साथ में हट जाता है, इसलिए long-term important data store करने के लिए यह उपयुक्त नहीं है
    • open source web apps को user खुद host करें तो कुछ गुण सुधर सकते हैं, लेकिन ज़्यादातर users system administrator नहीं बनना चाहते, इसलिए self-hosting अधिकांश लोगों के लिए व्यावहारिक विकल्प नहीं है

  • local storage इस्तेमाल करने वाले mobile apps

    • iOS और Android apps binaries download करके local में install होते हैं, लेकिन Twitter, Yelp, Facebook जैसे कई apps server के बिना काम नहीं करते और thin client होते हैं
    • SQLite, Core Data, और सामान्य files जैसी persistence layers के ज़रिए पहले local device पर data store करने वाले apps local-first आदर्श के ज़्यादा क़रीब हैं
    • Clue और Things ऐसे उदाहरण हैं जो single-user app के रूप में शुरू हुए और बाद में device sync या sharing के लिए cloud backend जोड़ा
    • ऐसे thick client apps तेज़ होते हैं और offline भी चलते हैं, क्योंकि server sync background में होती है
    • कई devices या कई collaborating users data को modify करें तो कठिनाई बढ़ जाती है
    • mobile app developers आम तौर पर end-user app development के विशेषज्ञ होते हैं, distributed systems के नहीं
    • ad hoc diff·merge·conflict resolution algorithms अक्सर कम भरोसेमंद और नाज़ुक होते हैं

  • Firebase, CloudKit, Realm

    • Firebase एक mobile BaaS है जो local device database, cloud database service, और दोनों के बीच sync को जोड़ता है
    • Firebase multiple device sharing और offline use को support करता है, लेकिन proprietary hosted service होने की वजह से privacy और long-term viability के मामले में इसका score कम है
    • Parse को Facebook ने acquire करने के बाद 2017 में बंद कर दिया, इसलिए उस पर निर्भर apps को दूसरे backend पर जाना पड़ा
    • Firebase console developers को data देखने, modify करने और delete करने का अच्छा अनुभव देता है, लेकिन users के पास उसके बराबर data access·manipulation·management के साधन नहीं होते
    • Apple CloudKit उन apps के लिए Firebase जैसा अनुभव देता है जिन्हें iOS और Mac तक सीमित रखा जा सकता है
      • key-value store और sync
      • अच्छा offline functionality
      • platform में built-in होने से account creation·login की झंझट कम होती है
    • Realm iOS local persistence library के रूप में लोकप्रिय हुआ, और Realm Object Server open source और self-hosted हो सकता है, जिससे service lock-in का जोखिम कम होता है

  • CouchDB

    • CouchDB ने multi-master replication approach के कारण ध्यान खींचा, जिसमें कई machines database की पूरी copy रख सकती हैं और हर replica स्वतंत्र रूप से changes बना सकता है
    • Cloudant इसका hosted version है, और PouchDB तथा Hoodie उसी sync protocol का उपयोग करते हुए end-user devices पर चलने के लिए design किए गए हैं
    • दार्शनिक रूप से CouchDB local-first principles के क़रीब है, लेकिन एक ही समय में बदले गए data के लिए conflict resolution application code को explicitly करना पड़ता है
    • Google Docs की तरह हर keypress को अलग change बनाने वाले fine-grained collaboration apps में सही conflict resolution code लिखना मुश्किल होता है
    • इसके व्यापक रूप से adopt न हो पाने के कारणों में per-user separate DB scalability, iOS·Android native apps में JavaScript client embed करना, conflict resolution, और MapReduce query model की अपरिचितता शामिल हैं

CRDT और बेहतर आधारभूत तकनीक

  • मौजूदा application development के लिए data layer, local-first आदर्श के सभी पहलुओं को पूरा नहीं करती
  • Ink & Switch ने समाधान खोजने के लिए 3 साल पहले से शोध किया, और एक आशाजनक आधार के रूप में Conflict-free Replicated Data Types या CRDT प्रस्तुत किया
  • CRDT, 2011 के अकादमिक computer science शोध में सामने आया एक सामान्य-उद्देश्य data structure है
  • यह hash map, list जैसी data structures की तरह document state को स्टोर करता है, लेकिन शुरुआत से ही multi-user environment को ध्यान में रखता है
  • text editor, spreadsheet, vector graphics app अपने-अपने document state को data structure के रूप में बनाए रखते हैं, और collaborative multi-user apps में इन्हें CRDT से बदला जा सकता है

  • CRDT का merge तरीका

    • उपयोगकर्ता offline होने पर भी अपने local device पर application state को देख और बदल सकते हैं
    • CRDT changes को track करता है, और network उपलब्ध होने पर background में दूसरे devices के साथ sync करता है
    • अगर अलग-अलग devices पर एक ही समय में नए to-do जोड़े जाएँ, तो merged state में जोड़े गए सभी items एक consistent order में शामिल होते हैं
    • अलग objects पर concurrent changes को आसानी से merge किया जा सकता है
    • जहाँ automatic resolution मुश्किल होती है, वह स्थिति तब होती है जब कई उपयोगकर्ता एक ही object की एक ही property को एक साथ update करते हैं; CRDT conflicting values को track करता है और उन्हें app या उपयोगकर्ता द्वारा सुलझाने के लिए छोड़ देता है
    • CRDT, Git जैसा है, लेकिन text files से अधिक समृद्ध data types पर काम करता है
    • sync channel server, P2P connection, Bluetooth, USB stick आदि कुछ भी हो सकता है
    • change unit एक single keypress जितनी छोटी हो सकती है, जिससे Google Docs शैली का real-time collaboration संभव होता है, और इसे Git pull request की तरह बड़े bundle में भी भेजा जा सकता है

  • Automerge और Hypermerge

    • Ink & Switch ने open source JavaScript CRDT implementation Automerge विकसित किया
    • Automerge, JSON CRDT शोध पर आधारित है
    • Automerge और Dat networking stack को मिलाकर Hypermerge बनाया गया
    • यह कहना मुश्किल है कि ये libraries local-first आदर्श को पूरी तरह साकार करती हैं; अभी और काम की ज़रूरत है
    • CRDT में इंटरनेट के packet switching या smartphone के capacitive touchscreen की तरह, ऐसे collaborative software की आधारभूत तकनीक बनने की क्षमता है जिसमें उपयोगकर्ताओं के पास data ownership हो

Ink & Switch प्रोटोटाइप

  • CRDT algorithm और theory validation में अकादमिक जगत ने प्रगति की है, लेकिन industrial use अभी भी कम है और अधिकतर server-centric computing में ही होता है
  • CRDT का उपयोग करने वाले server-centric systems के उदाहरण के रूप में Azure Cosmos DB, Redis, Riak, Weave Mesh, SoundCloud Roshi, Facebook OpenR दिए गए हैं
  • Ink & Switch ने end-user devices पर CRDT का उपयोग करने वाले creative work के लिए local-first collaborative app prototypes बनाए
  • प्रयोगों में तीन सवालों को देखा गया
    • तकनीकी व्यवहार्यता: CRDT वास्तविक software के कितना करीब है
    • उपयोगकर्ता अनुभव: क्या central authority server के बिना Google Docs जैसा real-time collaboration और Git जैसा offline-friendly asynchronous collaboration संभव है
    • डेवलपर अनुभव: CRDT data layer, SQL DB, filesystem और Core Data से कैसे अलग है
  • तीनों prototypes Electron, JavaScript, React से बनाए गए, और उनका downloadable तथा installable software होना ownership की भावना के लिए महत्वपूर्ण माना गया

  • Trellis

    • Trellis, Trello पर आधारित एक Kanban board है
    • network communication layer के रूप में WebRTC का प्रयोग किया गया
    • Git और Google Docs के “See New Changes” से प्रेरित change history डिज़ाइन की गई
    • उपयोगकर्ता Kanban board के tasks देख सकते हैं और document की पिछली state पर वापस जा सकते हैं

  • Pixelpusher

    • Pixelpusher, Javier Valencia के Pixel Art to CSS में Figma जैसा real-time collaboration अनुभव जोड़ने वाला collaborative drawing program है
    • Dat project की P2P library से network communication का प्रयोग किया गया
    • document sharing URL, Git से प्रेरित visual branch/merge, conflicting pixels को लाल रंग में highlight करने वाला conflict resolution, और उपयोगकर्ता द्वारा बनाए गए avatar पर आधारित basic user identification का प्रयोग किया गया

  • PushPin

    • PushPin, Miro या Milanote जैसा mixed media canvas workspace है
    • Automerge पर आधारित तीसरा project, तीनों prototypes में सबसे अधिक परिपक्व था
    • टीम और बाहरी test users का वास्तविक उपयोग, underlying data layer पर अधिक दबाव डालता था
    • nested और linked shared documents, CRDT documents के लिए विभिन्न renderers, outbox model सहित अधिक उन्नत identity system, और selection highlighting जैसे transient data sharing का प्रयोग किया गया

प्रोटोटाइप से मिले निष्कर्ष

  • तीनों प्रोटोटाइप का लक्ष्य local-first software और CRDT की तकनीकी व्यवहार्यता, user experience, और developer experience का मूल्यांकन करना था
  • 5 सदस्यों वाली development team ने इन्हें नियमित रूप से इस्तेमाल किया, और लगभग 10 बाहरी उपयोगकर्ताओं के साथ अलग-अलग usability test किए गए
    • बाहरी उपयोगकर्ताओं में professional designers, product managers, और software engineers शामिल थे
    • औपचारिक evaluation methodology के बजाय exploratory approach का उपयोग किया गया

  • CRDT तकनीक काम करती है

    • Automerge की reliability अपेक्षा से बेहतर थी
    • टीम के app developers ने library को अपेक्षाकृत आसानी से integrate कर लिया, और data auto-merge लगभग हमेशा सहज और smooth था

  • ऑफलाइन user experience अच्छा था

    • offline होने के बाद मनचाहा काम करना, फिर दोबारा connect होकर सहकर्मियों के बदलावों के साथ merge करना अच्छी तरह काम करता था
    • जब दूसरे apps “offline” warning और errors दिखाकर काम रोक देते थे, तब भी local-first prototypes network state से स्वतंत्र रूप से सामान्य ढंग से चलते रहे
    • browser-based systems के विपरीत, app चलेगा या data उपलब्ध होगा या नहीं, इस चिंता में कमी आई, और tools व काम पर ownership की भावना मिली

  • React के FRP मॉडल के साथ अच्छा मेल

    • React का Functional Reactive Programming मॉडल CRDT के साथ अच्छी तरह फिट बैठता है
    • CRDT-आधारित data layer में document को local user input और network से आए अन्य users व devices के बदलाव एक साथ मिलते हैं
    • FRP मॉडल दिखाई देने वाली application state को shared document की underlying state के साथ विश्वसनीय रूप से sync करता है
    • developers को अन्य users से आए बदलावों को track करने और उन्हें मौजूदा screen के साथ समन्वित करने के झंझट से मुक्ति मिलती है
    • सभी state changes को एक ही reducer function से गुज़ारने पर संबंधित local changes को अन्य users तक भेजना भी आसान हो जाता है

  • टकराव अपेक्षा से कम गंभीर थे

    • collaboration के दौरान users को conflicts कम ही मिले, और सामान्य resolution mechanisms अच्छी तरह काम करते थे
    • Automerge बहुत सूक्ष्म स्तर पर changes को track करता है और data type semantics को ध्यान में रखता है
    • यदि दो users एक ही समय में array की एक ही position पर items insert करें, तो दोनों items को deterministic order में जोड़ दिया जाता है
    • Git जैसे text version control systems इसे ऐसा conflict मान सकते हैं जिसे manually resolve करना पड़े
    • users के पास collaboration को लेकर सहज समझ होती है, इसलिए वे कभी-कभी implicit रूप से काम के क्षेत्र बांट लेते हैं ताकि एक ही section को एक साथ edit न करें
    • Kanban app में अगर एक user किसी card पर comment जोड़ता है और दूसरा user उसी card को दूसरी column में ले जाता है, तो दोनों बदलाव लागू हो जाते हैं
    • conflict केवल तब होता है जब एक ही object की एक ही property को एक ही समय में बदला जाए; उदाहरण के तौर पर, जब दो users एक ही image object की position एक साथ बदलें
    • prototypes में Automerge की default merge semantics ही पर्याप्त रही, और custom semantics की ज़रूरत वाले उदाहरण नहीं मिले

  • document history का visualization महत्वपूर्ण है

    • distributed collaboration systems में अन्य users के बदलाव किसी भी समय बड़ी संख्या में आ सकते हैं
    • क्योंकि central server बदलावों को mediate नहीं करता, इसलिए यह समझने के लिए tools चाहिए कि document अपनी वर्तमान स्थिति तक कैसे पहुँचा, कौन-कौन से versions मौजूद हैं, और योगदान कहाँ से आया
    • Trellis ने ऐसा “time travel” interface आज़माया जिसमें user merged document की पुरानी states पर जाकर देख सकता था
    • नए प्राप्त हुए change elements को अपने-आप highlight करने का तरीका भी आज़माया गया

  • URL sharing स्वाभाविक लगता है

    • कई document sharing mechanisms में web से प्रेरित URL model users और developers दोनों को सबसे स्वाभाविक लगा
    • URL को copy-paste किया जा सकता है और email या chat जैसे communication channels के माध्यम से साझा किया जा सकता है
    • secret URL से आगे document access permissions अभी भी एक खुला research question है

  • P2P systems साधारण online/offline में नहीं बँटते

    • centralized systems आम तौर पर server से stable connection के आधार पर “up” या “down” स्थिति तय करते हैं
    • distributed systems में हर user के पास कौन-सा data है, वह क्या share करता है, और क्या स्वीकार करता है, इसके आधार पर उसकी अलग दृष्टि हो सकती है
    • विमान में laptop पर किए गए edits landing के बाद connect होने पर अन्य users तक पहुँचाए जा सकते हैं
    • अन्य users उन बदलावों में से सब, कुछ, या कुछ भी नहीं, अपने document version में स्वीकार कर सकते हैं
    • Git repository की तरह, किसी विशेष user का “master” इस बात का function बन जाता है कि उसने आख़िरी बार अन्य users से कब communication किया था
    • distributed documents data control users को देते हैं, लेकिन वास्तविक UI के नज़रिए से इसका क्या अर्थ है, इस पर और research की ज़रूरत है

  • लंबी change history performance समस्या पैदा करती है

    • PushPin को sprint planning जैसे वास्तविक documents पर इस्तेमाल करने पर performance और memory/disk usage जल्दी ही समस्या बनने लगे
    • CRDT character-level text editing समेत पूरी history को store करता है
    • क्योंकि 6 महीने बाद कोई फिर document से connect होकर उसी बिंदु से changes merge कर सकता है, इसलिए history को आसानी से truncate नहीं किया जा सकता
    • Automerge optimization जारी है और यह अभी भी काम के प्रमुख क्षेत्रों में से एक है

  • network communication अभी हल नहीं हुआ है

    • CRDT algorithms केवल data merge से संबंधित हैं; वे यह नहीं बताते कि दूसरे users के edits भौतिक रूप से उसी computer तक कैसे पहुँचते हैं
    • प्रयोगों में WebRTC, Dropbox और USB key के माध्यम से files copy करने वाला sneakernet implementation, IPFS protocol की संभावना, और Dat की Hypercore P2P library को आज़माया गया
    • CRDT के लिए P2P network layer अनिवार्य नहीं है; server के माध्यम से communication भी संभव है
    • local-first के दीर्घकालिक लक्ष्य को पूरी तरह हासिल करने के लिए vendor के backend services से अधिक समय तक टिकने वाला decentralized समाधान तार्किक अंतिम लक्ष्य है
    • P2P तकनीक production-ready नहीं थी, और खासकर NAT traversal की reliability router या network topology के अनुसार कम थी
    • internet access के बिना computers के बीच सीधे real-time collaboration का अनुभव, central API पर निर्भर दुनिया में बड़ी संभावनाएँ दिखाता है

  • cloud server सहायक भूमिका में रहते हैं

    • PushPin जैसे real-time collaboration prototypes मध्यस्थ server के बिना documents share कर सकते हैं, जो privacy और ownership के लिए अच्छा है
    • लेकिन यदि user document share करने के बाद दूसरे व्यक्ति के connect होने से पहले laptop बंद कर दे, तो दोनों users एक ही समय online न होने के कारण connect नहीं कर पाते
    • local-first दुनिया में server central authority नहीं, बल्कि cloud peer की भूमिका निभा सकता है
      • document की copy store करके रखना और अन्य peer के online होने पर उसे पहुँचाना
      • archive/backup location उपलब्ध कराना
      • weather forecast या stock price जैसे पारंपरिक server APIs के लिए bridge बनना
      • शक्तिशाली GPU के साथ video rendering जैसे burst computing उपलब्ध कराना
    • पारंपरिक systems और local-first systems के बीच अंतर server की मौजूदगी में नहीं, बल्कि इस बात में है कि server source of truth नहीं बल्कि सहायक भूमिका निभाता है

आगे ज़रूरी काम

  • वितरित सिस्टम·प्रोग्रामिंग भाषा शोधकर्ता

    • CRDT और P2P तकनीक पर शोध लोकल-फर्स्ट सॉफ़्टवेयर में बड़ा योगदान दे सकता है
    • मौजूदा CRDT शोध आम तौर पर यह मानता है कि सभी सहयोगी एक ही दस्तावेज़ संस्करण पर संपादन तुरंत लागू करते हैं
    • वास्तविक लोकल-फर्स्ट ऐप्स को दूसरे सहयोगियों के संपादन अस्वीकार करने या साझा न किए गए दस्तावेज़ संस्करण पर निजी बदलाव बनाने में सक्षम होना चाहिए
    • branch, fork, rebase जैसे distributed source control विचारों को ऐसे सहयोगी मॉडल तक विस्तारित करने पर शोध की कमी है, जहाँ कई दस्तावेज़ संस्करण और branch साथ-साथ मौजूद हों
    • type, schema migration और compatibility भी महत्वपूर्ण मुद्दे हैं
      • हर सहयोगी अलग-अलग ऐप version और features इस्तेमाल कर सकता है
      • केंद्रीय DB server न होने के कारण डेटा का कोई आधिकारिक “current” schema नहीं होता
      • डेटा format के विकसित होने के दौरान कई ऐप versions को सुरक्षित रूप से interoperable होना चाहिए

  • HCI शोधकर्ता

    • केंद्रीकृत सिस्टमों में server के साथ sync स्थिति दिखाने के कई उदाहरण हैं, लेकिन decentralized सिस्टम नए UI प्रश्न पैदा करते हैं
    • ऐसे सिस्टम में, जहाँ हर उपयोगकर्ता के पास डेटा की अलग copy हो सकती है, online·offline और available·unavailable स्थिति कैसे बताई जाए, इस पर शोध की ज़रूरत है
    • जब व्यापक इंटरनेट के बिना दूसरे nodes के साथ सीधे सहयोग किया जा सकता हो, तब “online” का मतलब भी बदल जाता है
    • चूँकि हर दस्तावेज़ में सिर्फ़ रोज़मर्रा के उपयोग से भी जटिल version history बन सकती है, इसलिए ऐसा UI चाहिए जो उपयोगकर्ताओं को version, बदलाव स्वीकार करने और दस्तावेज़ के बनने की प्रक्रिया समझने में मदद करे
    • मौजूदा change management में source code शैली के diff·patch मॉडल और Google Docs शैली के suggestion·comment मॉडल मुख्यधारा में हैं
    • इन विचारों को non-text डेटा formats तक सामान्यीकृत करने का तरीका अब भी खुला प्रश्न है
    • लोकल-फर्स्ट में डेटा रखने वाले उपयोगकर्ता को local पर बदलाव करने से रोका नहीं जा सकता, और अनुमति की अवधारणा इस तरह बदलती है कि दूसरे उपयोगकर्ता चुनते हैं कि वे उन बदलावों को subscribe करेंगे या नहीं

  • प्रैक्टिशनर

    • production सॉफ़्टवेयर बनाने वाले engineers, designers, product managers और independent developers लोकल-फर्स्ट भविष्य की ओर क्रमिक कदम उठा सकते हैं
    • तेज़ ऐप के लिए आक्रामक caching और pre-download से दस्तावेज़ खोलते समय spinner कम किए जा सकते हैं, और डिफ़ॉल्ट रूप से local cache पर भरोसा किया जा सकता है
    • multi-device support को Firebase और iCloud जैसी sync infrastructure से अपेक्षाकृत आसानी से जोड़ा जा सकता है, लेकिन इससे दीर्घकालिकता और privacy को लेकर चिंताएँ हैं
    • offline support के लिए web पर Progressive Web Apps, Service Workers और app manifest मददगार हो सकते हैं
    • ऐप testing WiFi बंद करके या Chrome DevTools network condition simulator, iOS network link conditioner जैसे tools से network conditions बदलकर की जा सकती है
    • collaboration के लिए CRDT के अलावा ShareDB आदि में implemented Operational Transformation अधिक स्थापित तकनीक है
    • दीर्घकालिक संरक्षण के लिए JSON, PDF जैसे स्थिर formats में आसानी से export किया जा सकना चाहिए
      • Google Takeout जैसा bulk export
      • GoodNotes का स्थिर file format आधारित continuous backup
      • Trello के JSON documents download
    • privacy के लिहाज़ से उपयोगकर्ता को स्पष्ट रूप से बताया जाना चाहिए कि डेटा केवल device पर संग्रहीत है या backend को भेजा जाता है
    • user control के लिए ऐप के भीतर दस्तावेज़ का backup, duplication और deletion आसान होना चाहिए, और Google Docs का उदाहरण दिया गया है, जिसने Google Drive के ऊपर बुनियादी filesystem कार्यों को फिर से लागू किया

स्टार्टअप अवसर और निष्कर्ष

  • developer infrastructure बनाने की सोच रहे संस्थापकों के लिए “Firebase for CRDTs” एक दिलचस्प बाज़ार अवसर के रूप में प्रस्तुत किया गया है
  • ऐसे startup को अच्छा developer experience और SQLite या Realm जैसी local persistence libraries देनी चाहिए
  • iOS, Android, Windows, Mac, Linux, Electron, Progressive Web Apps का support होना चाहिए
  • user control, privacy, multi-device support और collaboration डिफ़ॉल्ट रूप से शामिल होने चाहिए
  • सफलता की litmus test यह है कि सभी servers बंद हो जाने पर भी क्या ग्राहक का ऐप स्थायी रूप से चलता रहे
  • cloud software ने collaboration और कहीं से भी सुलभ modern apps दिए, लेकिन डेटा का स्वामित्व server पर रखकर उपयोगकर्ताओं को अपने ही डेटा का किरायेदार बना दिया
  • लोकल-फर्स्ट approach दिखाता है कि उपयोगकर्ता डेटा ownership और control बनाए रखते हुए भी cloud-जैसा collaboration और accessibility पा सकते हैं
  • वास्तविक implementation के लिए offline support, on-device storage का उपयोग, algorithms·programming models·user interfaces में सुधार, और CRDT व P2P networking के productization की अब भी ज़रूरत है

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

1 टिप्पणियां

 
GN⁺ 2025-07-06
Hacker News की टिप्पणियां

  • पूरी तरह सहमत। मैं इस ट्रेंड से तंग आ गया हूं कि हर सेवा मेरा डेटा अपने cloud में ले जाती है, और उसे ठीक से इस्तेमाल करने के लिए मुझसे subscription fee दिलवाती है
    अभी जो fitness tracking app बना रहा हूं, उसके लिए मॉडल यह रखना चाहता हूं: “एक बार खरीदें, X साल तक updates पाएं, सभी devices के साथ sync करें, और उसके बाद भी हमेशा इस्तेमाल करते रहें।” X साल बाद अगर updates चाहिए हों तो नया version फिर से खरीद लें, और अगर मौजूदा features पर्याप्त हों तो उसी को इस्तेमाल करते रहें
    मेरी इच्छा है कि ज़्यादातर software इसी तरह उचित कीमत पर खरीदे जा सकें, product खुद अच्छा हो, और cloud के बिना इस्तेमाल न कर पाने वाली मजबूरी में न बांधे जाएं। local-first software की सबसे अच्छी बात यह है कि यह ads, tracking और engagement को maximize करने के बजाय product quality के लिए पैसे लेने वाले healthy incentives को वापस लाता है

    • Obsidian भी参考 के लिए अच्छा model है। client पूरी तरह free है, और सिर्फ optional sync service बेची जाती है
      notes सभी Markdown files हैं, इसलिए client खुद भी optional हो जाता है
    • जानना चाहूंगा कि cloud infrastructure के बिना sync करने की आपकी योजना क्या है
    • “X साल updates + device sync + perpetual use” अच्छा लगता है, लेकिन इस तरीके में 1–2 साल की subscription की कुल लागत एक साथ लेनी पड़ेगी
      sync servers भी लगातार चलाने होंगे, और ऐसे मामलों को भी सोचना होगा जहां user एक साल का data एक ही दिन में bulk में sync करे। future development संभालने वाले लोगों को भी salary देते रहनी होगी, इसलिए सिर्फ developer के नजरिए से देखें तो कुछ बातें छूट जाती हैं
    • कुछ साल पहले एक स्थानीय factory ने IT supplier के server outage की वजह से दो दिन तक production रोक दिया था; उसके बाद worst-case सोचते हुए मैंने भी ऐसा ही सोचा था
      https://rodyne.com/?p=1439
    • backend real-time collaboration या sync जैसे features का हिस्सा हो सकता है। लेकिन अगर cloud से ejectable हो और कभी भी self-hosting पर switch किया जा सके या वापस लौटा जा सके, तो data और service दोनों पर ownership और long-term viability सुनिश्चित की जा सकती है
      हम जो notes/tasks IDE बना रहे हैं, वह भी इसी तरीके का है: https://thymer.com/local-first-ejectable

  • Berlin में Ink and Switch द्वारा आयोजित वार्षिक Local-first Software Conference होती है, और इस साल नवंबर में SF में Sync Conf नाम का एक spin-off event भी होगा
    https://www.localfirstconf.com/
    https://syncconf.dev/
    इस साल original paper के co-authors का एक panel अच्छा था, जिसमें development tools के संदर्भ में local-first software क्या है और original paper के बाद क्या सीखा गया, इस पर बात हुई: https://youtu.be/86NmEerklTs?si=Kodd7kD39337CTbf
    community अब “sync” को local-first का एक component, लेकिन उससे कहीं व्यापक रूप से लागू होने वाली technology के रूप में देखने की ओर बढ़ रही है। local-first end-user software की property है, और sync engine जैसे development tools इसे संभव बनाने वाले tools हैं; वे अपने आप में जरूरी नहीं कि local-first हों
    पिछले कुछ वर्षों की सभी talks यहां हैं: https://youtube.com/@localfirstconf?si=uHHi5Tsy60ewhQTQ
    local-first/sync engine community के लिए यह दिलचस्प समय है। वे real-time collaboration और asynchronous collaboration experiences को संभव बनाने वाले tools बनाते रहे हैं, और AI के आने से यह market बढ़ रहा है। हर AI app मूल रूप से एक multi-user collaboration system है जिसमें agents actors के रूप में भाग लेते हैं, इसलिए sync engine community जिन technologies पर काम करती रही है, उनकी जरूरत पड़ती है

    • local-first apps और infrastructure बनाने वाले engineers के interviews वाला एक शानदार Local First podcast भी है
      https://www.localfirst.fm/

  • पढ़ने लायक है, और पहले भी इस पर कई बार सक्रिय चर्चा हुई है
    https://news.ycombinator.com/item?id=19804478 - मई 2019, 191 comments
    https://news.ycombinator.com/item?id=21581444 - नवंबर 2019, 241 comments
    https://news.ycombinator.com/item?id=23985816 - जुलाई 2020, 9 comments
    https://news.ycombinator.com/item?id=24027663 - अगस्त 2020, 134 comments
    https://news.ycombinator.com/item?id=26266881 - फरवरी 2021, 90 comments
    https://news.ycombinator.com/item?id=31594613 - जून 2022, 30 comments
    https://news.ycombinator.com/item?id=37743517 - अक्टूबर 2023, 50 comments

  • जिन चीज़ों में ऑनलाइन dependency होती है, उनमें अनिवार्य रूप से लगातार maintenance और लागत लगती है। अगर कोई सिस्टम local-first नहीं है—और संभव हो तो सिर्फ local-only—तो वह लंबी अवधि की reliability के लिए design किया गया नहीं है
    connected appliances और cars व्यावहारिक नज़रिए से लगभग सबसे मूर्खतापूर्ण engineering हैं

    • यह सब subscription revenue की वजह से है
      subscription revenue पाने वाली कंपनियों का revenue भी ज़्यादा होता है और valuation भी ऊँची होती है, जिससे अतिरिक्त funding जुटाना आसान हो जाता है, और वे इस model का पालन न करने वाली कंपनियों को हरा देती हैं। इस self-reinforcing structure की वजह से मुझे लगता है कि local-first software मर चुका है
    • Dropbox या Apple जैसी जगहों के free/paid storage को देखें तो वास्तविक लागत दिखती है। मोटे तौर पर 2TB के लिए महीने के 10 डॉलर के स्तर पर है
      Cloudflare static file hosting लगभग मुफ्त में कर देता है, और लागत rounding error जैसी है। अगर 1000 local-first apps Dropbox में sync करें, तब भी महीने के 10 डॉलर वाले storage पर चल सकते हैं। यह storage S3 जैसे low-level raw tool नहीं, बल्कि authentication, support और sync program तक वाला consumer service है। ज़्यादातर cloud costs असल में ज़रूरी नहीं हैं
    • Stop Killing Games initiative का विरोध करने वाले किसी भी व्यक्ति को यह comment पढ़ना चाहिए
      कोई भी game को सिर्फ online service पर निर्भर रहने के लिए मजबूर नहीं करता। यह कोई कानूनी मांग भी नहीं, regulatory मांग भी नहीं। software की बहुत-सी चीज़ों की तरह यह सिर्फ एक choice है। online service पर निर्भर रहने का चुनाव करके बाद में “इसे वापस बदलने में पैसा लगेगा” कहना short-sighted और दयनीय है, और इसे स्वीकार नहीं किया जाना चाहिए

  • और ज़्यादा apps local-first होने चाहिए। अगर user अपना data cloud में sync नहीं करना चाहता, तो उसके पास वह विकल्प होना चाहिए
    मैं कुछ समय से offline-first या local-first app Brisqi बना रहा हूँ, और इसे शुरुआत से ही offline-first philosophy के साथ design किया है
    https://brisqi.com
    local-first app को अनिश्चित काल तक पूरी तरह offline चलने के लिए design किया जाना चाहिए। local experience आधार होना चाहिए, fallback नहीं; और cloud sync requirement नहीं बल्कि सहायक feature होना चाहिए
    जो apps temporary cache पर निर्भर करते हैं, उन्हें मैं offline-first नहीं मानता। सच्चे offline-first app को local database में data persist करना चाहिए। “offline-first” कहे जाने वाले कई apps असल में सिर्फ सीमित offline functionality देते हैं और अंततः internet reconnect पर निर्भर रहते हैं—यानी वे offline-tolerant के ज़्यादा करीब हैं
    offline-first app बनाना online-only web app की तुलना में निश्चित रूप से कठिन है, और sync mechanism इतना भरोसेमंद होना चाहिए कि offline/online transition के दौरान भी data लगातार cloud में sync हो और lost न हो। approach के बारे में blog में और लिखा है: https://blog.brisqi.com/posts/how-i-designed-an-offline-first-app-an-outline

    • मुझे चिंता है कि क्या यह model business के तौर पर sustainable रहना और मुश्किल नहीं होगा; जानना चाहूँगा कि असल में चीज़ें कैसी चल रही हैं

  • यह दिलचस्प है कि इस principle को consumer क्षेत्र के हिसाब से समझाया गया है, लेकिन हम अभी industrial assets/industrial data की तरफ यही काम कर रहे हैं
    www.sentineldevices.com पर learning, analysis और decision-making सब कुछ customer के equipment पर ही होता है। data भेजने के लिए server तक नहीं है; model साफ़ तौर पर ऐसा है कि सब कुछ device के अंदर चलता है
    SCADA/industrial automation में ऐसे बहुत-से use cases हैं जहाँ data बाहर नहीं ले जाया जा सकता। data/AI कंपनियाँ सिर्फ इसलिए विशाल customer base और use cases को ignore कर देती हैं कि customer जहाँ है वहाँ service देना मुश्किल है, और इसके बजाय data को अपने पास लाकर vendor lock-in बनाए रखना चाहती हैं
    customers से बात करते समय उल्टा हमें “नहीं, यह local है और इसका कोई external connection नहीं है” पर बहुत ज़ोर देना पड़ता है। लोगों ने ऐसी बात लगभग कभी सुनी नहीं होती, इसलिए अक्सर step-by-step समझाना पड़ता है ताकि वे समझें कि सब कुछ local में हो रहा है, और software vendors इस concept को अच्छी तरह स्वीकार नहीं कर पाते। अच्छा होगा अगर consumer क्षेत्र में local-first software और जमे, ताकि industrial क्षेत्र में भी यह परिचित हो जाए

    • यह भी मददगार नहीं है कि सभी SCADA vendors cloud trend पर सवार होकर उसी दिशा में धकेल रहे हैं
      “अपने smartphone से factory चलाइए!”—अब बस एक zero-day फूटे और कोई script kiddie मेरे pumps से खेल सकेगा
    • यह एक रोचक क्षेत्र है, और अच्छा लगा कि आप इस पर काम कर रहे हैं
      hiring page देखा तो सभी positions non-remote थीं; क्या local-first software बनाने के लिए आमने-सामने मिलना ज़रूरी होने की कोई limitation है, या यह मुख्यतः management-related कारणों से है

  • मैं व्यक्तिगत रूप से इस approach से सहमत नहीं हूँ। “cloud provider पर भरोसा नहीं किया जा सकता” जैसी business problem को “centralized architecture से बचना” जैसे technical trade-off से हल करने की कोशिश लगती है
    closed-source software में control और reliability की कमी open source development जैसे नए business model, नए licenses, और license fees की जगह maintenance contracts जैसे revenue models से हल हुई थी
    इसी तरह cloud providers की समस्या के लिए भी business model के स्तर का solution चाहिए। उदाहरण के लिए, users cloud provider के साथ अपने relation पर भरोसा कर सकें, इसके लिए rights define करने वाला standard contract/license बनाया जा सकता है। समय के साथ users शायद सिर्फ ऐसे license वाले providers से ही deal करें
    इसमें end-of-life contracts, data portability guarantees, data access को audit करने और किसने/क्या/कब पढ़ा यह बताने वाली data privacy transparency जैसी clauses शामिल हो सकती हैं। समस्या adoption की है। cloud providers इसे क्यों स्वीकार करेंगे, यही मुख्य सवाल है; और अगर उन्हें churn का डर है, तो वे ऐसे contracts केवल annual subscription पर दे सकते हैं या अधिक कीमत ले सकते हैं

    • अगर business या political problems को technical solution से हल किया जा सके, तो वह आमतौर पर मजबूत approach होता है। ऐसी problems adversarial actors पैदा करते हैं, और technical solution उन actors की betrayal करने की क्षमता ही खत्म कर देता है
      cloud services इस्तेमाल करते समय encryption इसका अच्छा उदाहरण है। privacy policy और bureaucratic rules से data की रक्षा करने की कोशिश लगभग बेकार है। data valuable होता है, customers या governments के लिए यह जानना मुश्किल होता है कि company उसे चुपके से बेच रही है या नहीं, और security पर पैसे बचाए गए हैं या नहीं, यह भी बहुत देर होने से पहले पता लगाना मुश्किल होता है
      लेकिन अगर data client device पर encrypt होता है और mathematically prove किया जा सकता है कि server plaintext तक access नहीं कर सकता, तो ऐसी चिंताएँ नहीं करनी पड़तीं। समस्या तब है जब server को data सिर्फ store नहीं बल्कि process भी करना हो; तब technical solution अपने servers इस्तेमाल करना बन जाता है
    • मुझे शक है कि ऐसा contract सच में problem solve करता है। भले ही cloud service document करे कि shutdown से X महीने पहले notice देगी और data export करने देगी, actual shutdown के बाद आपके हाथ में शायद एक बहुत बड़ी, practically useless JSON file ही बचे
      जब तक आप खुद app न बनाएँ या कोई मददगार व्यक्ति आपके लिए न बना दे, उसका उपयोग करना कठिन है। यह कुछ न होने से बेहतर है, लेकिन ऐसे local app जितना अच्छा नहीं है जो company बंद हो जाने या support रोक देने के बाद भी वर्षों या दशकों तक चल सके
    • यह model cloud providers को banks जैसा बना सकता है। cloud provider user account में एक तरह की property रखता है, और user के पास उस property पर clear rights और account से उसे recover करने की legal ability होती है
      finance में recovery का मतलब money या property की delivery लेना होता है, और cloud में इसका मतलब account की पूरी contents वाली बड़ी Zip file पाना हो सकता है
      लेकिन delivery लेना हमेशा practical या desirable नहीं होता। finance में account को दूसरे provider पर transfer किया जा सकता है, और cloud services में भी कई cases में account transfer कहीं अधिक useful होने की संभावना है
      यहाँ कठिनाई portability है। cloud account पर user की property rights और rights अच्छी तरह define कर भी दिए जाएँ, तो Facebook friends को delivery में लेने का मतलब क्या है, या Facebook account को कहीं और transfer करने का क्या अर्थ है, यह unclear है
    • मुझे लगता है वह interpretation सही नहीं है। authors ने यह पर्याप्त रूप से माना है कि local-first का business case पूरी तरह solve नहीं हुआ है और यह closely related problem है
      इस problem के लिए business solutions और technical solutions दोनों चाहिए, और paper suggest करता है कि solution में किस तरह की properties होनी चाहिए
      यह भी सही नहीं कि local-first decentralization की वकालत करता है। Martin Kleppmann ने साफ कहा है कि वे decentralization technology को इस problem का ऐसा solution नहीं मानते जो mass market तक जा सके। वे local-first ideals को संभव बनाने वाले centralized standard sync engine का समर्थन करते हैं
      पिछले साल की Local-first conf talk देखें: https://youtu.be/NMq0vncHJvU?si=ilsQqIAncq0sBW95
    • data portability guarantee कुछ scale वाले data के लिए practical नहीं है। production environment database को नए database में migrate करना smoothly करना हो तो महीनों से वर्षों तक लग सकते हैं
      crisis situation में यह कुछ हफ्तों में भी संभव है, लेकिन बहुत messy हो सकता है। same version के open source databases के बीच move करने पर भी cloud services में कई differences होते हैं, इसलिए स्थिति वैसी ही रहती है
      सबसे अच्छा solution यह है कि data शुरुआत से ही अपने environment में रखा जाए और जरूरत पड़े तो connection काट दिया जाए। BYOC management को open source के साथ combine करके यह संभव है। हमारी company भी BYOC data product चलाती है, इसलिए इस approach में हमारा economic interest है, लेकिन हमने इसे सच में काम करते देखा है, इसलिए पता है कि यह संभव है

  • मेरे प्रोजेक्ट https://github.com/ibizaman/selfhostblocks और https://github.com/ibizaman/skarabox से मैं यही चीज़ बड़े पैमाने पर संभव बनाने की कोशिश कर रहा हूँ
    साझा लक्ष्य self-hosting को आम लोगों के लिए अधिक सुलभ बनाना है
    NixOS पर आधारित होकर https, SSO, LDAP, backups, snapshots वाले ZFS आदि को जितना हो सके declarative तरीके से built-in देना चाहता हूँ
    Vaultwarden और Nextcloud को package करके ज़्यादातर data store किया जा सकता है, इसलिए यह cloud hosting का competitor है, और Home Assistant जैसी services भी देता है
    यह YUNoHost का भी competitor है, लेकिन SelfHostBlocks जो components देता है उनसे आप अपनी पसंद के packages खुद self-host कर सकते हैं, इसलिए यह बेहतर है या ऐसा बनने की कोशिश कर रहा है। यह framework से ज़्यादा library जैसा है
    यह NAS से भी compete करता है, लेकिन मेरा मानना है कि सब कुछ open source होने की वजह से यह बेहतर है। अभी users का technical होना ज़रूरी है, लेकिन हम यह बाधा हटाते जा रहे हैं, और लक्ष्यों में से एक यह है कि लोग Nix जाने बिना या command line छुए बिना अपने hardware पर इसे install कर सकें

    • सचमुच बढ़िया। आजकल मैं इस बारे में बहुत सोच रहा हूँ। इतने सारे शानदार free open-source alternatives मौजूद हैं, फिर भी यह अजीब है कि तकनीकी लोगों के लिए “docker compose up” जितना अपेक्षाकृत आसान होने पर भी गैर-तकनीकी लोगों की पहुँच से यह अब भी दूर है
      self-host की जा सकने वाली कई apps database, server और frontend वाली web applications होती हैं, लेकिन कई use cases में उन्हें सिर्फ एक computer पर इस्तेमाल करना होता है और hosted version या दूसरे devices के साथ sync की ज़रूरत नहीं होती। उदाहरण के लिए personal accounting महीने में एक बार computer पर कर लेने वाली चीज़ है, इसलिए कहीं 24/7 web app चलाने की ज़रूरत नहीं। program खोलो, काम करो, फिर बंद कर दो
      high-quality self-hostable free open-source alternatives की संख्या और वास्तव में उन्हें इस्तेमाल कर सकने वाले लोगों की संख्या के बीच बड़ा mismatch है। इस gap को कम करने वाले और projects की ज़रूरत है। selfhostblocks को कुछ चीज़ों में आज़माकर contribute करने की कोशिश करूँगा
    • इसमें hledger शामिल करना अच्छा लगा। plain-text accounting से परिचित न लोगों को यह थोड़ा अजनबी लग सकता है, लेकिन यह वाकई शानदार software है

  • हर application के पास अपना sync platform होने की कोई वजह नहीं है। ऐसा framing शायद उन mobile apps से आया है जिनमें programs के बीच composability या modularity नहीं होती
    अगर “local-first” को गंभीरता से लिया जाए, तो बस file system इस्तेमाल किया जा सकता है, और user git, Box आदि कई समाधानों में से चुन सकता है
    अपनी sync subscription की मांग करना दूसरे SaaS जितना ही नापसंद है, बल्कि यह और भी opaque और fragile है

    • मैं मानता हूँ कि हर app को अपना sync engine ज़रूरी नहीं, लेकिन इस framing से सहमत नहीं कि file system local-first अपनाने का universal तरीका है
      पहला, मुझे local-first भी चाहिए और concurrency भी चाहिए। अगर बस simple local-first हो तो कोई भी sync चलेगा, लेकिन मुझे उससे ज़्यादा चाहिए। मैं चाहता हूँ कि Dropbox की तरह बिना ध्यान दिए smooth चले, और network न होने वाले इलाके में भी मैं और मेरी पत्नी अपने-अपने phones पर अलग-अलग edits कर सकें
      दूसरा, sync तब कहीं बेहतर काम करता है जब उसे data structures और semantics की गहरी जानकारी हो। git और Box दोनों की काफी सीमाएँ हैं, और concurrency की ज़रूरत हो तो वे सीमाएँ और बढ़ जाती हैं
    • मोटे तौर पर सहमत हूँ, लेकिन व्यवहार में यह हमेशा इतना simple नहीं होता। मैंने ठीक इसी तरह काम करने वाली app बनाई थी, पर यह coordinate नहीं कर पाया कि कब कौन-सा client file edit करने की अनुमति पाए, इसलिए आखिरकार file conflicts अपरिहार्य हो गए

  • सैद्धांतिक रूप से मुझे local-first तरीके का development पसंद है। यह privacy और data ownership को default मानने वाली small tech philosophy से अच्छी तरह मेल खाता है
    लेकिन व्यवहार में यह कठिन है। असल में आपको sync engine बनाना, conflict resolution संभालना, और schema migration manage करना पड़ता है
    फिर भी पिछले कुछ सालों में local-first software development tools बेहतर हुए लगते हैं। मैं jazz.tools, electric-sql, और Rocicorp के Zero पर नज़र रख रहा हूँ, और जानना चाहता हूँ कि क्या और भी विकल्प हैं

    • server पर CouchDB और client पर PouchDB ऐसा environment बनाने की कोशिश थे
      https://couchdb.apache.org/
      https://pouchdb.com/
      करीब 10 साल पहले local-first application development पर और विचार यहाँ भी देखे जा सकते हैं: https://unhosted.org/
    • पिछले लगभग एक महीने से मैंने personal budgeting app side project में instantdb को काफी गंभीरता से इस्तेमाल किया है
      इस पर blog post लिखनी चाहिए, लेकिन इससे पहले मैंने PowerSync, electricSQL, LiveStore, PowerSync की जाँच की थी और jazz.tools को भी थोड़ी देर देखा था, मगर मुझे कुछ अधिक structured चाहिए था
      अब तक यह काफी impressive है। मैं इसे Vue और community library के साथ लिख रहा हूँ, और permissions थोड़ी tricky थीं, लेकिन समझ आने के बाद simple थीं। magic email login भी पसंद है, और dashboard/response features भी अच्छे हैं, लेकिन इसे कम झंझट वाला बनाने के लिए कुछ बड़े बदलावों की जरूरत लगती है
      अच्छी बात यह है कि यह open source है और चाहें तो self-host कर सकते हैं। jazz में structure की कमी थी, और LiveStore में event store बहुत झंझट वाला लगा, हालांकि उसमें आकर्षण था। developer tools का paid wall के पीछे होना अफसोसजनक था, लेकिन समझ में आता है। electricSQL solution का आधा हिस्सा देता था, यानी सिर्फ reads, और write model की कमी थी। CouchDB/PouchDB में भी मेरे लिए structure की कमी थी, और मैं चाहता था कि documents के बीच support ज्यादा स्पष्ट रूप से built-in हो। Zero की मैंने ठीक से जाँच नहीं की
    • सोच रहा हूँ क्या आप इस site को जानते हैं: https://www.localfirst.fm
      दरअसल मैं top menu में “landscape” link की ओर इशारा करना चाहता था, लेकिन URL काफी असुविधाजनक है
    • कुछ समय पहले मैंने किसी को Automerge का ज़िक्र करते देखा था
      https://automerge.org/
      Rust और JavaScript implementations हैं, और कुछ networking strategies भी देता है। jazz.tools जैसी free/paid product setup साथ में नहीं आती, लेकिन यह काफी अच्छा है
    • Ditto भी देखने लायक है
      https://www.ditto.com
      यह CRDT को core में रखकर real-time sync support करने वाला local-first platform है, इसलिए conflict resolution manage करना काफी आसान हो जाता है। इसे offline-first use cases और peer-to-peer sync को default रूप से संभालने के लिए design किया गया है, इसलिए आपको खुद शुरुआत से sync engine बनाने की जरूरत नहीं पड़ती
      यह Swift, Kotlin(Android), Flutter/Dart, React Native, JavaScript(Web/Node), .NET(C#), C++, Java, Rust जैसी कई platforms को support करता है। documentation यहाँ और देख सकते हैं: https://docs.ditto.live/home/about-ditto