रोज़ 15 वॉन में पूरी तरह स्वतंत्र वेबसाइट चलाना

 (neatnik.net)
3 पॉइंट द्वारा GN⁺ 22 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Hardcore IndieWeb एक ऐसा तरीका है जिसमें कंटेंट के मूल स्रोत और प्रकाशित किए जा सकने वाले HTML·वेब एसेट्स अपनी ही डिवाइस पर रखे जाते हैं, ताकि पहचान और कंटेंट पर नियंत्रण किसी सेवा प्रदाता को न सौंपना पड़े
  • ब्राउज़र में HTML का प्रीव्यू देखने के बाद उसे होस्ट पर अपलोड करने वाली 1990 के दशक की प्रकाशन प्रक्रिया अपनाने पर CMS·SSG·framework·CLI·मासिक subscription के बिना भी साइट चलाई जा सकती है
  • सिर्फ़ एक text editor, SFTP tool और web host काफी हैं, और NearlyFreeSpeech.net पर static site रोज़ $0.01 में चलाई जा सकती है तथा $0.25 से बैलेंस जोड़ा जा सकता है
  • landing page, अलग-अलग posts, archive और Atom feed को फ़ाइलों के रूप में सीधे मैनेज करके हर पेज की संरचना और design बदली जा सकती है और सिर्फ़ बदली हुई फ़ाइलें ही ट्रांसफ़र की जा सकती हैं
  • host गायब हो जाए तब भी पूरी बनी हुई साइट को कहीं और उसी तरह अपलोड किया जा सकता है, लेकिन जितने ज़्यादा tools जोड़ेंगे उतनी dependencies बढ़ेंगी, इसलिए स्थानीय source और published version को अपने पास रखना ही स्वतंत्रता बनाए रखने की शर्त है

Hardcore IndieWeb की माँगी हुई स्वतंत्रता

  • IndieWeb वेब पर अपनी पहचान और कंटेंट का सीधा स्वामित्व रखने और कंपनियों के बाहरी नियंत्रण से बाहर निकलने का एक व्यावहारिक तरीका है
  • subscription-आधारित blog services भी IndieWeb में भागीदारी में मदद कर सकती हैं, लेकिन अगर कंटेंट मुख्य रूप से किसी और के database और server पर मौजूद है, तो वह पूरी तरह स्वतंत्र नहीं है
    • चाहे उसे खुले format में export किया जा सके, फिर भी सेवा इस्तेमाल करते समय कंटेंट पर पूरा नियंत्रण नहीं होता
    • यह तरीका मौजूदा services से संतुष्ट लोगों की तुलना में उन लोगों के लिए ज़्यादा उपयुक्त है जो अपने कंटेंट पर पूर्ण स्वतंत्रता और नियंत्रण चाहते हैं
  • Hardcore IndieWeb मौजूदा IndieWeb सिद्धांतों पर नियंत्रण और portability जैसे ठोस मानदंड लागू करता है
    • अगर कंटेंट मुख्य रूप से आपकी hard drive पर नहीं है, तो यह कहना मुश्किल है कि आप उसे पूरी तरह नियंत्रित करते हैं
    • अगर प्रकाशित HTML और web assets की कॉपी आपकी hard drive पर नहीं है, तो साइट पूरी तरह portable नहीं मानी जा सकती
  • अगर सेवा बंद हो जाए और data export करना संभव न रहे, तो नाममात्र का ownership होने पर भी कंटेंट तक पहुँचना या उसे कहीं और ले जाना संभव नहीं होगा
  • सेवा संचालक के व्यवहार की वजह से आप सेवा छोड़ना चाहें, तब भी export format को support करने वाली दूसरी सेवा ढूँढनी पड़ सकती है, या कंटेंट बदलना और tools व प्रक्रियाएँ बदलनी पड़ सकती हैं
  • अगर स्थानीय रूप से कंटेंट का source और पूरा published version आपके पास है, तो ऐसी स्थिति में भी नियंत्रण और portability बनाए रखी जा सकती है

1990 के दशक वाली वेब publishing प्रक्रिया

  • Hardcore IndieWeb वेब के शुरुआती दौर की एक सरल publishing पद्धति अपनाता है
    1. hard drive पर कंटेंट लिखें
    2. web browser में उसका preview देखें
    3. संतुष्ट होने पर web host पर upload करें और ज़रूरत पड़ने पर यही दोहराएँ
  • domain के अलावा ज़रूरी चीज़ें सिर्फ़ text editor, file transfer tool, web host हैं
  • programming environment या IDE, framework, shell, CLI tools, मासिक subscription की ज़रूरत नहीं है
  • HTML का ज्ञान चाहिए, लेकिन HTML for People जैसी सामग्री से सीखा जा सकता है, और कुछ tags व copy-paste से भी शुरुआत हो सकती है
  • जटिल SaaS·CMS·SSG·markup language·template systems वैकल्पिक हैं, और फ़ाइलों को सीधे publish करने का सरल तरीका आज भी काम करता है

ज़रूरी tools और hosting

  • text editor के लिए कुछ भी इस्तेमाल किया जा सकता है, बस वह disk पर files save कर सके
    • Adam Newbold Nova का उपयोग करते हैं, जो file transfer भी support करता है
    • दूसरे विकल्प text editors की सूची में मिल सकते हैं
  • file transfer के लिए SSH या SFTP support करने वाला tool चाहिए
    • FileZilla कई operating systems पर चलने वाला एक विकल्प है
  • static site host के रूप में NearlyFreeSpeech.net की सिफारिश की जाती है, जहाँ इसे रोज़ $0.01 में चलाया जा सकता है
    • Adam Newbold 2008 से इस सेवा का उपयोग कर रहे हैं
    • $0.25 से account में balance जोड़कर static, non-production site जोड़ी जा सकती है
    • Sites tab में site name चुनने पर file transfer के लिए login जानकारी देखी जा सकती है
    • free subdomain दिया जाता है, और Domains tab में personal domain जोड़ा जा सकता है
  • NearlyFreeSpeech अनिवार्य नहीं है; कोई भी दूसरा web host चुना जा सकता है जो basic static file hosting देता हो

मौजूदा site और HTML की तैयारी

  • अगर आपकी मौजूदा site या blog पहले से HTML format में है, तो तुरंत शुरू करना आसान है
  • अगर वह किसी दूसरे format में है, तो सेवा के अनुसार HTML में export या convert किया जा सकता है
    • बड़े blog के लिए conversion tools का उपयोग अधिक उपयुक्त है
    • छोटा blog हो तो posts को फिर से देखते हुए HTML files हाथ से बनाई जा सकती हैं
  • आप Markdown पसंद कर सकते हैं, लेकिन HTML वेब की भाषा है, और कई बार Markdown parser से जूझने की बजाय शुद्ध HTML संभालना ज़्यादा सरल होता है
  • अगर शुरू से design बनाना कठिन लगे, तो HTML5 UP जैसी free designs और templates डाउनलोड करके संपादित किए जा सकते हैं

blog बनाने वाली files

  • एक सामान्य blog landing page, posts, archive page, feed से बनता है, और इन्हें किसी dedicated blog service के बिना सीधे मैनेज किया जा सकता है

  • Landing page

    • इसमें नवीनतम post पूरी या आंशिक रूप में, कई posts, या posts के अलावा दूसरा कंटेंट भी अपनी मर्ज़ी से रखा जा सकता है
    • latest post दिखाने के लिए उसका कंटेंट copy करें और उसकी स्वतंत्र page से जुड़ा link जोड़ें
    • हाल की 5 posts बनाए रखनी हों तो नई post को ऊपर जोड़ें और सबसे पुरानी post को नीचे से हटा दें
    • CMS·SSG·template engine की सीमाएँ न होने से हर page की संरचना और प्रस्तुति बदली जा सकती है
    • landing page की file का नाम index.html होना चाहिए और उसे web root में रखना चाहिए
    • NearlyFreeSpeech का web root /home/public है

  • Blog posts

    • एक post को एक webpage बनाया जाता है, और पुरानी post file की copy लेकर उसमें नया unique file name और नया कंटेंट डालकर नई post लिखी जा सकती है
    • disk की file structure URL में दिखाई देती है, इसलिए अपनी पसंद की address scheme के अनुसार folders व्यवस्थित करें
    • /blog/ path उपयोग करना हो तो web root में blog folder बनाएँ
    • the-best-lunch-i-ever-had.html जैसा slug-आधारित file name इस्तेमाल किया जा सकता है
    • post-विशेष folder के अंदर index.html रखने पर URL में .html extension छिपाया जा सकता है
    • posts को Markdown या database entries की बजाय स्वतंत्र HTML files के रूप में मैनेज करने पर हर लेख को अलग style, रूप, layout और व्यक्तित्व दिया जा सकता है
    • सभी posts एक जैसी दिखनी चाहिए—यह परंपरा आधुनिक publishing tools से आई है; हाथ से बने HTML में इसे मानना ज़रूरी नहीं

  • Archive page

    • archive जैसे नाम का folder बनाएँ, उसके अंदर index.html रखें, और posts की सूची लिखें
    • sorting और संरचना आपकी मर्ज़ी पर है; चाहें तो पसंदीदा posts को page के ऊपर अलग से उभार सकते हैं

Atom feed को सीधे मैनेज करना

  • RSS feed कोई विशेष system नहीं, बल्कि disk पर रखी जाने वाली file है, इसलिए उसे text editor में सीधे बदला जा सकता है
  • Wikipedia के Atom page) पर दिया गया example feed copy करके feed.xml file से शुरुआत की जा सकती है
    • Atom RSS के साथ compatible है और आम तौर पर व्यापक support पाता है
    • example.com, <title>, <subtitle> जैसे values को अपने domain और जानकारी से बदलें
    • feed में शामिल हर post के लिए एक <entry> बनाएँ और उसमें date·time·title·summary आदि भरें
    • <id> के लिए UUID Generator से नया UUID लेकर इस्तेमाल करें
  • तैयार feed को W3C Feed Validation Service में paste करके जाँचा जा सकता है कि वह parse हो रही है या नहीं
    • अगर errors मिलें तो validation service बताएगी कि क्या सुधारना है

publishing और updates

  • पहली बार publish करते समय file transfer program से server में connect होकर पूरी site को web host पर copy करें
  • उसके बाद सिर्फ़ नई या बदली हुई files ही ट्रांसफ़र करनी होती हैं
    • सामान्य update targets में landing page, नई post, feed और archive page शामिल हैं
  • publishing प्रक्रिया को स्थानीय files को remote server पर drag-and-drop करने जितना आसान रखा जा सकता है

portability और अतिरिक्त tools की सीमा

  • क्योंकि पूरी बनी हुई site आपके अपने computer पर है, इसलिए मौजूदा host गायब हो जाने पर भी उसे किसी दूसरे host पर उसी तरह upload किया जा सकता है
  • blog software की गंभीर security vulnerabilities या SSG dependencies को manage करने की ज़रूरत नहीं पड़ती, और कंटेंट के हर पहलू पर आपका सीधा नियंत्रण रहता है
  • केवल इसी प्रक्रिया को बनाए रखकर भी पूरी तरह स्वतंत्र website लगातार चलाई जा सकती है
  • workflow में मदद के लिए tools और प्रक्रियाएँ जोड़ी जा सकती हैं, लेकिन हर अतिरिक्त tool के साथ नई dependency भी जुड़ती है
  • अगर कंटेंट का source आपकी अपनी device पर है और पूरी publishable site की कॉपी आपके पास है, तो Hardcore IndieWeb की शर्तें पूरी होती हैं

सीधे HTML संभालने की स्वायत्तता

  • मूल प्रक्रिया HTML को सीधे लिखकर web server पर upload करने की है
  • पिछले 30 वर्षों में जुड़े अतिरिक्त technology layers, procedures और expectations ने web कार्य को जटिल बनाया है और नियंत्रण व स्वतंत्रता दूसरों को सौंप दी है
  • आप IndieWeb services का उपयोग करें, फिर भी अगर अपनी पूरी web presence की एकमात्र कॉपी service operator के पास छोड़ देते हैं, तो आप पूरी तरह स्वतंत्र नहीं हैं
  • Hardcore IndieWeb हर किसी के लिए नहीं है, लेकिन यह उन लोगों के लिए उपयुक्त है जो इस बात को महत्व देते हैं कि उनके लेख किसके पास रहें, कहाँ प्रकाशित हों और किस रूप में प्रकाशित हों
  • HTML को सीधे संभालना और files को अपने web host space में copy करना शुरुआती web के आनंद से दोबारा जुड़ने वाला सीधा और स्वायत्त अनुभव देता है

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

1 टिप्पणियां

 
GN⁺ 22 시간 전
Hacker News की राय

  • मैं static साइट्स को GitHub Pages और Cloudflare Pages पर मुफ्त में होस्ट करता आया हूं और इससे बहुत संतुष्ट हूं। NearlyFreeSpeech को पैसे देने पर भी आखिरकार third-party hosting पर निर्भरता वही रहती है, इसलिए self-hosting में तकनीकी संतुष्टि के अलावा कोई बहुत बड़ा मूल्य नहीं दिखता
    अहम बात यह है कि HTML और images जैसी assets को disk पर साधारण files के रूप में सीधे manage किया जाता है। Git integration की वजह से external backup भी बन जाता है, और VS Code से master पर push करने पर 30 सेकंड के भीतर publish हो जाता है, जो पुराने FTP/SFTP से कहीं ज्यादा सुविधाजनक है

    • GitHub Pages और Cloudflare Pages का फायदा यह है कि साइट के operator से ज्यादा लंबे समय तक जीवित रहने की संभावना बड़ी होती है। Self-hosting में succession plan न हो तो domain expiry या card cancellation के कारण किसी न किसी दिन जरूर बंद हो जाएगा, जबकि free services के मामले में यह सिर्फ संभावना है कि वे गायब हो सकती हैं
    • पैसे देने पर आप product नहीं, customer बन जाते हैं—यह फर्क काफी बड़ा है
    • मेरा blog भी इसी तरीके से चलता है: https://gigatexal.blog

  • NearlyFreeSpeech भी अच्छी service है, लेकिन पूरी तरह independent नहीं है। अपनी internet infrastructure के बिना independence के सबसे करीब जाना हो तो घर से port forwarding करके या Tor hidden service के रूप में साइट चला सकते हैं
    torrc में ports set करना मुश्किल नहीं है, लेकिन visitors को भी Tor Browser चाहिए, और यह समझाना कठिन है कि साइट ‘dark web’ पर है। अपने hardware पर घर से चलाया जा सकता है और server IP भी छिपाया जा सकता है, इसलिए हैरानी है कि independent web समुदाय में इसका ज्यादा उपयोग नहीं होता। सामान्य domain को .onion address पर redirect भी किया जा सकता है
    Browser में ही साइट बनाकर host करने वाला Beaker Browser बंद हो चुका है, लेकिन Tor के लिए site-creation plugin जैसे tools आएं तो adoption में मदद मिल सकती है

    • .onion service आसानी से शुरू की जा सकती है, general web से ज्यादा सुरक्षित है, और mobile phone पर भी चल सकती है
      Nanogram: https://gitlab.com/here_forawhile/nanogram
      Spreadsheet Server: https://gitlab.com/here_forawhile/spreadsheet
      Library Server: https://gitlab.com/here_forawhile/libraryserver
      Torum: https://gitlab.com/here_forawhile/torum
    • Tor Browser सामान्य internet पर .onion addresses खोजने के लिए Onion-Location और Alt-Svc को support करता है। Onion-Location में सामान्य HTTPS site Onion service की जानकारी देती है, जबकि Alt-Svc बिना अलग user action के automatically discover करके switch करता है
      भविष्य में DNS या DNSSEC आधारित Onion connection की भी संभावना है: https://onionservices.torproject.org/research/proposals/usab...
    • Perfect, good का दुश्मन है। Telecom companies और device manufacturers पर भी निर्भर रहने की वास्तविकता में NearlyFreeSpeech एक कम-risk वाला compromise है; इसने users के trust का दुरुपयोग भी नहीं किया है और cost भी लगभग नगण्य है
    • Tor कोई browser नहीं, बल्कि service है। Tor Browser सिर्फ privacy-focused browser और Tor service को मिलाने वाला convenience package है, इसलिए headless server पर browser के बिना भी Tor site चलाई जा सकती है
    • Hidden services के कम होने की वजह यह है कि वे visitors से बहुत ज्यादा effort मांगती हैं। myfirstnamelastname.com बताने और 56-character random .onion address भेजकर phone में Tor Browser तक install करवाने के बीच accessibility का बहुत बड़ा अंतर है

  • इस trend में सबसे बड़ी बाधा content ownership के लिए जरूरी domain name है, जिसकी कीमत सस्ती होने पर भी सालाना करीब 6 डॉलर पड़ती है। Static sites को ढेरों जगहों पर मुफ्त में host किया जा सकता है, और individuals के लिए CDN free tier काफी है
    Server self-hosting से ज्यादा जरूरी domain नाम जैसे unique identifier का ownership है; वह domain किस ओर point करता है, यह बहुत कम महत्वपूर्ण है

    • Software engineering को ऐसे समझदार लोगों ने आगे बढ़ाया है जो जरूरत से नहीं, बल्कि curiosity के कारण कुछ आजमाते रहे। Hiring करते समय भी degree से ज्यादा curiosity और drive को सबसे अहम माना
    • सालाना 6 डॉलर यानी रोज करीब 0.016 डॉलर है; ज्यादा महंगा तो है, फिर भी सस्ता है
    • सच कहूं तो लेख के किस हिस्से में direct server hosting करने को कहा गया था, यह समझ नहीं आया

  • Web server पर अपनी files upload करना जैसे कोई नई concept हो, ऐसा treat किया जाना हास्यास्पद है

    • ऐसे दौर में, जहां बहुत से लोगों को यह भी नहीं पता कि file क्या होती है, उस spirit को आगे बढ़ाना जरूरी है
    • दुख की बात है कि पूरा internet कुछ बड़ी कंपनियों द्वारा host और control किए जाने वाले monster में बदल गया है, यहां तक कि IndieWeb जैसा नया concept जरूरी हो गया। File hosting कोई privilege नहीं, बल्कि शुरुआत से ही लगभग human right जैसा होना चाहिए था
      खुद host करने की technology अब भी मौजूद है, लेकिन सोच cloud-only की तरफ बदल गई है
    • पहले public_html folder में files डालते ही तुरंत personal website बन जाती थी। इसका मतलब यह नहीं कि HTML हमेशा हाथ से ही लिखना पड़े, लेकिन उस समय web में शामिल होने का यह तेज और स्वाभाविक तरीका था
      Unix account finger से दोस्तों के online होने की जानकारी देता था और talk या ytalk से person-to-person chat भी उपलब्ध कराता था; बगल वाले terminal पर दोस्त बैठा हो तब भी यह जादू जैसा लगता था
    • बच्चों के hardware समझने तक इंतजार कीजिए

  • अगर रोज़ 0.01 डॉलर लेने वाली NearlyFreeSpeech को ‘100% स्वतंत्र रूप से चलाना’ कहा जाए, तो यह Vercel, Netlify, GitHub और Cloudflare की static hosting से बहुत अलग नहीं लगती।
    जब database, feedback form, social media preview और search engine optimization की ज़रूरत पड़े तो क्या करना है, यह लेख में नहीं है; शायद इन्हीं चीज़ों की गैर-मौजूदगी ही ‘indie web’ की शर्त हो, कहना मुश्किल है।

    • NearlyFreeSpeech पर PHP और database इस्तेमाल किए जा सकते हैं
    • अगर NFS और Vercel में बड़ा फर्क नहीं है, तो users आधे-आधे होने चाहिए; फिर ज़्यादातर लोग Vercel क्यों चुनते हैं, यह जानना दिलचस्प है
    • NFS कई programming languages के साथ पूरा Linux environment देता है, इसलिए dynamic websites भी support करता है, लेकिन खर्च ज़्यादा आता है
    • free plan पर भी किसी को 100,000 डॉलर का Netlify bill मिला था

  • एक event website के लिए domain चाहिए था, और Infomaniak ने domain के साथ 10MB storage भी दिया। सालाना करीब 5 euro में domain और site दोनों मिल जाना बुरा नहीं है

  • मैंने comments के लिए एक JavaScript plugin https://github.com/est/req4cmt बनाया है, जो सारा data Git repository के अंदर रखता है। अगर Git service HTTP support करती है तो इसे इस्तेमाल किया जा सकता है; यह free Cloudflare Worker पर चलता है, और backup व migration बस git clone और push से हो जाते हैं।
    Git-based Twitter alternative project भी है: https://github.com/est/gitweets
    Demo https://f.est.im/ पर है और Git notes का इस्तेमाल करने वाले comments भी support करता है। Cloudflare Workers और GitHub Pages की वजह से यह सब पूरी तरह मुफ्त है

  • sdf.org उन developers के लिए उपयोगी है जो Unix systems को खुद सीखना चाहते हैं। यह NetBSD Unix का free shell account देता है, और मुझे याद है कि थोड़े-से one-time donation पर web space और extra features भी मिल जाते थे।
    login name ही web space का subdomain बन जाता है, इसलिए सोच-समझकर चुनना चाहिए

  • अच्छा लगा कि ऐसा दावा करने वाली site Cloudflare या GitHub Pages पर host नहीं है

    • GitHub Pages domain और SSL देने वाली free hosting है, कोई billing नहीं होती, और long-term outlook भी अच्छा है। अगर static site की चिंता नहीं करना चाहते, तो GitHub और Cloudflare जैसे बड़े providers सबसे उपयुक्त लगते हैं
    • मैं अक्सर GitHub Pages recommend करता हूँ, लेकिन bedroom में Raspberry Pi से hosting करने का तरीका भी लिखा है: https://joeldare.com/private-analytics-and-my-raspberry-pi-4...
    • Cloudflare pirate sites को चलते रहने देता है, इसके लिए आभार
    • Vercel या Netlify भी ऐसे ही हैं

  • किसी खास tool की बजाय process को सीखना और उसका ownership रखना मुझे बेहतर लगता है। Markdown जैसे पढ़ने-लिखने में आसान format से Pandoc जैसे tools के जरिए HTML बनाना, HTML·CSS·JavaScript को hosting service पर upload या sync करना, domain own करना और DNS को GitHub Pages या Cloudflare Pages से जोड़ना—बस यह सब सीखना है।
    इससे किसी खास tool, service, platform या company पर lock-in नहीं होता, इसलिए content files कभी भी कहीं और ले जाई जा सकती हैं। source Markdown को HTML में बदलने की प्रक्रिया static site generator से automate की जा सकती है।
    HTML जानना उपयोगी और मज़ेदार है, लेकिन ‘site को 100% स्वतंत्र रूप से चलाने’ की अनिवार्य शर्त होना ज़रूरी नहीं। GitHub और Cloudflare पर 0 डॉलर प्रति माह में चलाइए; अगर service बंद हो जाए या paid हो जाए, तो कहीं और move कर दीजिए

    • लेख का मुख्य point यह है कि posts को Markdown या database entries की जगह अलग-अलग HTML files के रूप में रखने से हर page को अपनी अलग style, look, layout और personality दी जा सकती है। आधुनिक publishing tools से बने एक जैसे blog template से बाहर निकलकर हर post को अलग बनाया जा सकता है
    • HTML ऐसा format है जिसे इंसान आसानी से पढ़ और लिख सकते हैं। सही tools आने से पहले भी computer science के छात्र न होने वाले लोग तक text editor में सीधे HTML, JavaScript और CSS संभालते थे, और simple sites के लिए यह मुश्किल नहीं है।
      अगर process का ownership और पूरी independence चाहिए, तो web languages को खुद समझना और इस्तेमाल करना आना चाहिए। Nikola जैसे static site generators सुविधाजनक हैं, लेकिन अगर आप उनके output को समझ या सीधे edit नहीं कर सकते, तो आप अब भी third-party tool पर निर्भर हैं