सरल Unix चैट

 (the-dam.org)
3 पॉइंट द्वारा GN⁺ 2023-07-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • suc Simple Unix Chat है, जो Slack/Mattermost जैसी चैट के कुछ मुख्य फीचर्स को UNIX के बुनियादी घटकों और Bash के संयोजन से लागू करता है; इसका core loop 5 लाइनों का है, हालांकि वास्तविक script इससे लंबी है
  • संदेश standard input से एक-एक line पढ़े जाते हैं, उन पर तारीख और user name जोड़ा जाता है, फिर /var/lib/suc/ में channel file में append किया जाता है; authentication और access control SSH और UNIX permission model पर छोड़े जाते हैं
  • Mattermost server में सिर्फ Go code ही करीब 5 लाख lines का है, जबकि suc यह दिखाता है कि समान core behavior कहीं कम code से बनाया जा सकता है
  • usuc tail -f, rlwrap, pygmentize, और : command prefix को मिलाकर channel reading, Markdown-style output, और command results sharing संभालता है
  • channel एक simple text file होने के कारण इसे grep, tail, bat, lnav, Git hook, bot scripts जैसे UNIX tools से आसानी से जोड़ा जा सकता है

suc जिस complexity को घटाना चाहता है

  • suc Simple Unix Chat का संक्षेप है; इसमें Slack, Mattermost, IRC से कम features हैं और कुल lines 5 से ज्यादा हैं, लेकिन message लिखने वाला core loop 5-line Bash से बना है
  • लक्षित features हैं real-time rich-text chat, file sharing, fine-grained access control, automation और external tools integration, transit में encryption, वैकल्पिक encryption at rest, और user authentication
  • छोटा implementation इसलिए संभव है क्योंकि यह modern UNIX implementations द्वारा दिए गए consistent और composable basic primitives का उपयोग करता है
  • तुलना में Mattermost server में सिर्फ Go code ही करीब 5 लाख lines है, और suc का दावा है कि Mattermost की core functionality उसके 0.005% code में लागू की जा सकती है

5-line message-writing loop

  • suc का core Bash loop standard input से एक line पढ़ता है, date और real user name जोड़ता है, और उसे /var/lib/suc/"$1" file में append करता है
  • वास्तविक script security pre-processing और user name color calculation की वजह से लंबी है, लेकिन chat history लिखने का core behavior तीन चीजों में सिमटता है
    • standard input से एक line पढ़ना
    • date और real user name जोड़ना
    • /var/lib/suc/ के नीचे channel file में append करना
  • authentication, access control, encryption, और rich text को suc के internal code के बजाय SSH, UNIX access-control APIs, और text-based modularity संभालते हैं

authentication SSH संभालता है

  • suc process पहले से authenticated user द्वारा चलाया जाता है, इसलिए suc में खुद authentication code नहीं है
  • remote authentication को सामान्य UNIX server की तरह ssh संभालता है
    • password जैसे shared secrets
    • cryptographic challenge
    • one-time password (OTP) बनाने वाला device
    • कई तरीकों को मिलाने वाला MFA
  • ssh server को भी client के सामने authenticate करता है ताकि man-in-the-middle attacks रोके जा सकें, और client व server के बीच सभी data को encrypt करता है
  • suc installation UNIX host और ssh server configuration पर निर्भर करता है
    • user system में मौजूद होना चाहिए
    • ssh server को उस user का remote login allow करना चाहिए
  • GNU Guix में declarative configuration से user और SSH key को एक line में जोड़ा जा सकता है, और configuration line हटते ही reconfiguration के दौरान user हटा दिया जाता है

access control UNIX permission model संभालता है

  • suc authentication के साथ-साथ access-control code भी शामिल नहीं करता, और इस approach को security agnosticism कहा जाता है
  • UNIX kernel users, groups, processes, और files को जानता है, और process के effective owner के आधार पर file read/write permissions तय करता है
  • /var/lib/suc की channel files suc user के स्वामित्व में होती हैं, और group-wise read permissions के जरिए users को कुछ channels पढ़ने की अनुमति दी जाती है
  • सामान्य users सीधे file में नहीं लिखते, बल्कि suc चलाते हैं; permission matching और blocking kernel संभालता है
  • ज्यादा restricted community में group-wise setuid binaries रखी जा सकती हैं
    • उदाहरण के लिए suc_blue का owner blue user होता है और इसे केवल blue group चला सकता है
    • blue group के users suc_blue के जरिए blue channel में लिख सकते हैं
    • red group users blue channel को न पढ़ सकते हैं, न लिख सकते हैं
  • channel creation helper script suc_channel.sh करीब 80 lines की है, और GNU Guix users (suc-private-channel "red" "red") की एक line से जरूरी setuid binary, user, group, और channel file बना सकते हैं
  • GNU Guix के transactional updates यह सुनिश्चित करते हैं कि configuration changes या तो पूरी तरह लागू हों या बिल्कुल न हों, और पहले की working state पर rollback किया जा सके

rich text और usuc

  • कई chat apps text render करने के लिए HTML engine इस्तेमाल करती हैं, और Mattermost desktop client Electron का इस्तेमाल करता है
  • suc हर channel के लिए एक text file इस्तेमाल करता है, और users इसे tail या cat जैसे command-line tools से देख सकते हैं
  • terminal के ANSI escape codes और UTF-8 support का उपयोग करके colors, emoji, और basic rich-text experience बनाया जा सकता है
  • suc सिर्फ channel file में लिखता है, और पढ़ने का काम usuc करता है
    • suc privileged binary है, इसलिए logic और external dependencies को न्यूनतम रखना चाहिए
    • usuc calling user permissions के साथ चलता है, इसलिए इसमें features ज्यादा स्वतंत्रता से जोड़े जा सकते हैं
  • usuc कई छोटे tools को जोड़कर chat client की भूमिका निभाता है
    • rlwrap से history और line-editing features देता है
    • channel file owner के अनुसार सही setuid suc binary चुनता है
    • tail -f -n 20 से आखिरी 20 lines और उसके बाद जुड़ने वाली lines दिखाता है
    • input line : से शुरू होती है या नहीं, यह check करता है
    • user-entered text को pygmentize से process करता है
  • pygmentize standard input को Markdown मानकर ANSI colored text output करता है, इसलिए **bold** जैसे markup को एक line के code से support किया जा सकता है

chat commands और shell integration

  • अगर message : से शुरू होता है, तो usuc उसे सामान्य message के रूप में नहीं भेजता; वह उस command को चलाकर output result को suc में भेजता है
  • उदाहरण के लिए gum style --border=rounded --bold --foreground=#F00 "Hello World !" चलाने पर border और style वाला text channel में दिखता है
  • commands उस user के namespace में चलते हैं जिसने usuc call किया है, इसलिए user दूसरे users को प्रभावित किए बिना अपने chat macros रख सकता है
  • the dam में tabletop RPG के दौरान roll 2d6 जैसे commands से dice roll करने के लिए इसका उपयोग किया जाता है

text pipes और external tools integration

  • user usuc की command-execution functionality के बजाय shell से command output को सीधे suc में pipe कर सकता है
  • bat का colored output suc में भेजने पर code snippets को syntax-highlighted रूप में channel में share किया जा सकता है
  • make test > testlog || (suc devops < testlog ; exit 1) test fail होने पर logs को devops channel में भेजने वाली Bash one-liner का उदाहरण है
  • यह one-liner Git repository के update hook में डाली जा सकती है; push के समय tests चलाकर failure पर update reject किया जा सकता है और DevOps team को notify किया जा सकता है
  • Slack या Mattermost की integration features जैसे काम UNIX text pipes और scripts से बनाए जा सकते हैं

channel reading, notifications, bots

  • suc channels लगातार update होने वाली text files हैं, इसलिए tail -f से नई lines पढ़कर process की जा सकती हैं
  • नया message आते ही notify-send से notification दिखाने वाली pipeline बनाई जा सकती है, और grep से names या “build failure” जैसे keywords ही filter किए जा सकते हैं
  • कई channels को एक feed में मिलाने के लिए tail -f /var/lib/suc/* इस्तेमाल किया जा सकता है
  • lnav इस्तेमाल करने पर read position याद रखना, bookmarks, per-channel colors, date/user name/custom fields parsing, filtering, और SQL queries का उपयोग किया जा सकता है
  • bot तब implement किया जा सकता है जब वह channel पढ़ भी सके और साथ में लिख भी सके
    • उदाहरण channel में 33000 ft जैसी length expressions ढूंढता है
    • units command से meters में convert करता है
    • उसी channel में [metric_bot] 33000 ft is 10058.4 meters. जैसा response लिखता है

comparison targets और निष्कर्ष

  • तुलना के लिए Slack, Mattermost, Discord जैसे बड़े systems का जिक्र है, लेकिन ज्यादा fair comparison targets में IRC, talk, write भी शामिल माने जाते हैं
  • IRC को suc से कम feature-rich माना गया है, क्योंकि पुराने chat logs पढ़ने के लिए bouncer की जरूरत होती है
  • कहा गया है कि talk, ytalk, wall को modern Linux distributions पर चलाने लायक नहीं बनाया जा सका
  • suc authentication SSH को, access control और composability UNIX को सौंपता है, और channels को text files के रूप में रखता है
  • tools किसी भी language में लिखे जा सकते हैं, बस वे text पढ़ और लिख सकें

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

1 टिप्पणियां

 
GN⁺ 2023-07-06
Hacker News की राय

  • “Master Foo and the Ten Thousand Lines” तुरंत याद आ गया: http://catb.org/~esr/writings/unix-koans/ten-thousand.html
    यह उस कहानी की याद दिलाता है जिसमें Master Foo एक आने वाले programmer से कहता है, “shell script की एक line में C की 10,000 lines से भी ज़्यादा Unix स्वभाव होता है”

  • अगर किसी चीज़ की तय मुख्य functionality को बहुत आसानी और मामूली तरीके से दोहराया जा सकता है, तो हो सकता है कि वही functionality उसके असली value का केंद्र या स्रोत न हो
    यह सोचने वाली बात है कि 1980 के दशक के बाद से UI development का कितना हिस्सा software engineering ने अपने भीतर समेट लिया और automate कर दिया, और कितना अब भी शुद्ध मानवीय कला के दायरे में है

    • सही बात है। उदाहरण के लिए Slack की मुख्य अतिरिक्त value यह नहीं है कि “authenticated users आपस में messages भेजते हैं”
      Slack के आने और बाकी चीज़ों को पीछे छोड़ने से पहले भी, commercial और open source दोनों तरफ़ ऐसे काम करने वाले दर्जनों apps पहले से मौजूद थे
      Slack की असली value उसके अगले स्तर पर है। यह देखने में अच्छा और बेहद intuitive UI/UX देता है, इसलिए लगभग कोई भी व्यक्ति बिना पढ़ाई, setup, manual या training के बैठते ही इसका इस्तेमाल शुरू कर सकता है। किसी technical knowledge की ज़रूरत नहीं होती, और “username और password डालना” से आगे कुछ समझना भी न पड़े तो बाकी सब अपने-आप स्पष्ट दिखता है
    • यह बहुत पैनी नज़र है। तो फिर Slack की value user-friendliness है, और suc निश्चित रूप से आम users के लिए नहीं है
      लेकिन इससे एक और कठिन सवाल उठता है। जो user बहुत बुनियादी command-line invocation करना सीख सकता है, उसे थोड़ा और train करने के विकल्प की तुलना में क्या Slack अपनी कीमत के लायक है? और यह भी जोड़ें कि Slack data को अपने पास रोके रखता है और आसानी से वापस नहीं देता, तब क्या? Slack छोड़ने की लागत कितनी महंगी है?
      suc असुविधाजनक ज़रूर है, लेकिन शायद यह Slack की तुलना में कम bloated और कम proprietary किसी चीज़ की ओर जा सकता है

  • उपलब्धि अपने-आप में पसंद आई। Composability से क्या बनाया जा सकता है, यह देखना शानदार है
    लेकिन Slack वगैरह से इसकी तुलना ज़्यादा असरदार नहीं लगती। कोई भी engineer production में इस तरह जोड़-तोड़कर बनाई चीज़ की ज़िम्मेदारी लेना नहीं चाहेगा। hiring कैसे होगी, testing और debugging कैसे होंगे, logging और analytics कैसे होंगे?
    यह लेख Slack जैसी apps की chat functionality के कुछ हिस्से की नकल करता है, लेकिन chat functionality ऐसी apps का 100% नहीं है। ये पूरी तरह अलग माहौल में बनी चीज़ें हैं, इसलिए मौजूदा स्थिति को bloated कहकर निशाना बनाना कुछ Stockton Rush-जैसी टेढ़ी व्याख्या जैसा लगता है। software में bloat है, यह सही है, लेकिन “माँ देखो, मैंने कबाड़ से submarine बना ली। इसलिए महंगी submarine बेवकूफ़ी है” — यह लेखक की मंशा वाला rebuttal नहीं लगता

    • मुद्दा यह है कि codebase का सतही दायरा छोटा हो जाए तो इन बातों में से काफ़ी कुछ कम महत्वपूर्ण हो जाता है
      अलग-अलग utilities को आमतौर पर अलग unit के रूप में समझना, test करना और debug करना आसान होता है, और logging तो system में पहले से मौजूद है। syslog है ही, नहीं? और analytics की ज़रूरत क्यों है?
    • पढ़ते समय मुझे भी ऐसा ही लगा। engineering शानदार थी और पढ़ने में मज़ा भी आया, लेकिन अगर इसकी तुलना Slack की जगह सिर्फ़ IRC से की जाती तो ज़्यादा ईमानदार लगता
      फिर भी, यह सोचना सचमुच दिलचस्प है कि अगर Slack जैसे tools नई features से ज़्यादा सरलता को आक्रामक रूप से प्राथमिकता देते, तो वे कैसे दिखते। लगता है कि पूँजीवाद कुल मिलाकर ऐसे development को बढ़ावा नहीं देता, इसलिए तर्कसंगत रूप से जितना संभव हो उतना सरल enterprise software के उदाहरण बहुत कम हैं। फिर भी, यह एक दिलचस्प thought experiment है

  • इसी तरह एक ii भी है जो सीधे IRC पर चलता है: https://tools.suckless.org/ii/
    यह हर conversation के लिए एक single standard file इस्तेमाल करता है, और authentication व access control को IRC network खुद संभालता है, साथ ही पहले से बहुत-से UI मौजूद हैं। इस लेख की तरह, plugin कोई भी चीज़ हो सकती है जो किसी file को पढ़े और किसी दूसरी file में लिखे

  • craigslist diagram की तरह, अगर Unix functionality के टुकड़ों को काटकर बने startups का spawn of unix diagram बनाया जाए तो मज़ेदार होगा
    https://thegongshow.tumblr.com/post/345941486/the-spawn-of-craigslist-like-most-vcs-that-focus
    ftp/rsync => Dropbox
    suc => Slack
    ...

  • अगर शीर्षक clickbait जैसा लगने की वजह से आप इसे छोड़ने वाले हैं, तो मानना पड़ेगा कि इसमें थोड़ा-बहुत clickbait है, लेकिन असल में यह काफ़ी अच्छा लेख था
    यह suc(Simple Unix Chat) नाम की utility पर बात करता है, जो बहुत छोटे codebase के साथ Slack, Discord जैसे server features लागू करती है
    नई बात यह है कि यह मौजूदा Unix tools और methodology को दोबारा invent नहीं करता, बल्कि उनका इस्तेमाल करता है। authentication को SSH संभालता है, channels बस files हैं, और admin/moderator control user groups और file permissions से होता है। formatted text या file upload जैसी चीज़ें channel में मनचाहा data लिखकर और client को उसे interpret करने देकर की जा सकती हैं। bots भी channel file से pipe जोड़कर बहुत आसानी से बनाए जा सकते हैं
    लेख में दिखी सिर्फ़ 5 lines से channel में message लिखकर कोई परफेक्ट Slack clone नहीं बन जाएगा, लेकिन यह वाकई प्रभावशाली है कि सिर्फ़ साधारण Unix tools से कितनी दूर तक जाया जा सकता है

    • मौजूदा chat platforms ने Unix tools को “फिर से invent” नहीं किया; उन्होंने उन्हें इसलिए नहीं इस्तेमाल किया क्योंकि उनके ऊपर बनाना उपयुक्त नहीं था
      “everything is a file” paradigm और shell script में लिखे बड़े production systems लगभग न के बराबर होने की वजह है। असल दुनिया में इस्तेमाल होने वाले किसी भी गैर-तुच्छ system के लिए यह स्वीकार्य तरीका नहीं है
    • ज़्यादातर end users के लिए Slack एक client है
      इसमें admin UI, user management UI, extensibility, webhooks वगैरह शामिल हैं। “अगर सब लोग उस box में login कर लें तो Linux पर दूसरे users के साथ chat कर सकते हैं” — इससे इनमें से कुछ भी हल नहीं होता। ऐसी सुविधाएँ तो यहाँ के ज़्यादातर पाठकों के पैदा होने से पहले से हर *nix में थीं
    • यहाँ append-only files काफ़ी उपयुक्त लगती हैं। इससे यह सुनिश्चित किया जा सकता है कि सामान्य users और bots दूसरे लोगों की posts बदल न सकें
      अफ़सोस कि Plan 9 की यह सुविधा अभी तक Linux पर port नहीं हुई है। यह “read” या “write” जैसे permission bits की तरह है, लेकिन कहीं ज़्यादा specific है
    • “मौजूदा Unix tools और methodology का उपयोग” लगभग हमेशा “X को अविश्वसनीय रूप से कम lines of code में implement किया” के रूप में समझाया जाता है
      मैं लेखक को दोष नहीं दे रहा; लेख में भी यह बात बहुत ईमानदारी से स्वीकार की गई है

  • Slack और Discord में screen sharing और voice chat हैं। ये अतिरिक्त features नहीं, बल्कि market dominance के काफ़ी निर्णायक factors हैं

    • निर्णायक तो हैं, लेकिन इनकी quality लगातार गिरती हुई लगती है

  • यह blog post suc के बारे में है, और शुरुआत से ईमानदारी से मानती है कि शीर्षक थोड़ा misleading हो सकता है, लेकिन अंततः इसमें suc से सीधे जुड़ा न होते हुए भी एक महत्वपूर्ण संदेश है
    लगभग सारा आधुनिक software बेहिसाब bloated है। यह सोचना ही बेतुका है कि एक feature-rich chat server के लिए 17 लाख lines चाहिए होंगी। Bill Gates वाली शैली में कहूँ तो, कोशिश करूँ तब भी chat server पर मैं इतनी lines of code “खर्च” नहीं कर पाऊँगा
    सिर्फ़ समस्या की ओर ध्यान दिलाने या कोई alternative सुझाने के लिए नहीं, बल्कि यह याद दिलाने के लिए भी सराहना बनती है कि हर बार wheel को फिर से invent करने की ज़रूरत नहीं होती। मौजूदा systems और subsystems की properties का चतुराई से इस्तेमाल करना—जैसे authentication और encryption के लिए SSH का उपयोग—भले ही उनके मूल कल्पित उद्देश्य से अलग हो, लेकिन उनकी properties के इरादे के अनुरूप हो, यह hacker spirit का अच्छा उदाहरण है
    काश software दुनिया इस विचार से बहुत कुछ सीख सके। कम लागत, कम development time, और functionally वही code फिर से लिखने में बर्बाद होने वाले engineering time में कमी—ये सब developers, companies, end users, और आख़िरकार पूरी मानवता के लिए अच्छे हैं। आगे और ऐसी creative destruction देखने की इच्छा है, और मैं भी भविष्य के projects में ऐसी चतुर techniques आज़माना चाहूँगा

    • वैसे TypeScript lines of code का ज़्यादातर हिस्सा E2E tests[0] और webapp directory[1] में है। जैसा नाम से पता चलता है, webapp में “Mattermost web app का client code” है
      इसलिए असल में सिर्फ़ Go code lines गिनना ज़्यादा उचित होगा
      [0] https://github.com/mattermost/mattermost/tree/master/e2e-tests
      [1] https://github.com/mattermost/mattermost/tree/master/webapp
    • मैं एक ऐसी meeting में था जहाँ किसी site के लिए web authentication framework चुनना था, लेकिन bikeshedding की वजह से बात इतनी लंबी खिंच गई कि मैंने meeting के दौरान ही HTTP की पहले से उपलब्ध authentication functionality के आधार पर खुद implementation कर दी और meeting ख़त्म होने तक demo भी दिखा दिया
    • सिद्धांततः मैं सहमत हूँ, लेकिन इस bloating का बड़ा हिस्सा कई platforms को एक ही codebase से support करने की कोशिश से आता है
      यह आम तौर पर release speed बढ़ाता है और organization का आकार छोटा रखता है, इसलिए यह अच्छा विचार है। लेकिन इसके साथ complexity और abstraction का बड़ा trade-off आता है। abstraction level जितना ऊँचा होता है, चीज़ें उतनी बिगड़ सकती हैं। इसलिए इसके पीछे कोई वजह नहीं है, ऐसा भी नहीं है

  • सुरक्षा कारणों से आजकल ज़्यादातर distributions setuid bash scripts बनाने की अनुमति नहीं देते
    लेकिन किसी खास sudoers entry से लगभग वही असर हासिल किया जा सकता है

    • असल में सिर्फ bash नहीं, लगभग सभी shebang scripts के साथ यही बात लागू होती है; अपवाद के तौर पर Perl scripts को गिना जा सकता है। ऐसा इसलिए है क्योंकि Perl में uid != euid होने पर taint mode अपने-आप चालू हो जाता है
      https://perldoc.perl.org/perlsec#Taint-mode
      कुछ systems में एक बुनियादी race condition हो सकती है:
      https://perldoc.perl.org/perlsec#Shebang-Race-Condition
      sudo -T का इस्तेमाल भी देखने लायक है:
      https://perldoc.perl.org/perlsec#Using-Sudo
      Ruby में हाल में taint mode हटाया जाना अफ़सोस की बात है। taint tracking एक बहुत शक्तिशाली mechanism है, जो scripts से कहीं आगे तक काम आ सकता है। उदाहरण के लिए, अगर Rack/Rails के #html_safe को taint tracking से संभाला गया होता, तो यह और सख्ती से काम करता, और जिस क्षण कोई दूषित user string किसी SQL fragment से जोड़ी/इंटरपोलेट/फ़ॉर्मैट की जाती, उसी समय फेल हो जाता, जिससे SQL injection की एक श्रेणी को design के स्तर पर रोका जा सकता था
      पहले CGI/mod_perl में taint tracking का बहुत प्रभावी इस्तेमाल करने वाले लोग भी थे। यह कभी भी कोई सर्व-समाधान नहीं रहा, लेकिन आज भी काफ़ी उपयोगी tool है
    • shell script को कॉल करने वाला C wrapper इस्तेमाल करें। देखने में थोड़ा बदसूरत है और script को कुछ और harden करना पड़ेगा, लेकिन यह काम करता है :)
      https://gitlab.com/edouardklein/suc/-/blob/master/suc_wrapper.c
    • क्या सच में कोई distribution ऐसा करने देता भी है? जब मैंने खुद इसे करने की कोशिश की थी, तब जो भी पढ़ा उसमें यही था कि setuid लागू नहीं होगा। क्योंकि जो execute होता है वह फ़ाइल खुद नहीं, बल्कि shebang में दिया गया interpreter होता है
      GitLab repository में wrapper file देखने से पहले, इसे पढ़ते समय मैं उम्मीद कर रहा था कि शायद कोई तरीका हो

  • यह अलग बात है, लेकिन talk(1) का ज़िक्र न होना हैरान करने वाला है: https://man.netbsd.org/talk.1

    • या फिर write(2) भी है[1]। मेरे दिमाग में तो तुरंत ntalk आया, क्योंकि उसी मशीन पर मैंने आख़िरी बार ऐसा कुछ उसी दौर में इस्तेमाल किया था। उस समय IRC encrypted नहीं था
      अच्छी बात यह है कि इसे सिर्फ local receive तक सीमित किया जा सकता है, और तब उस मशीन पर user account होना ज़रूरी हो जाता है। इसलिए यह SDF जैसी जगहों या बड़े clusters के लिए अच्छा फिट है। authentication खुद करने की बजाय उसे PAM या BSD_Auth पर छोड़ा जा सकता है। sockets या encryption भी खुद संभालने की बजाय TLS पर छोड़ी जा सकती है। SSH से secure shell में जाकर tmux और (n)talk का इस्तेमाल करना भी संभव है
      बेशक, (n)talk C में लिखा गया है, इसलिए यह bash की 5 लाइनें नहीं है
      [1] https://man7.org/linux/man-pages/man2/write.2.html