IndieWeb में शामिल होकर मैंने क्या सीखा

 (en.andros.dev)
2 पॉइंट द्वारा GN⁺ 18 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • IndieWeb एक समुदाय और corporate-केंद्रित web का people-केंद्रित विकल्प है, जो personal domain पर content, identity और बातचीत को सुरक्षित रखते हुए ज़रूरत के अनुसार social network से जुड़ने देता है
  • अपने domain को आधार बनाकर microformats2, rel="me", Webmention, IndieAuth, Micropub जैसे छोटे standards को मिलाकर HTML को machine-readable बनाया जाता है और sites के बीच authentication, publishing और बातचीत को support किया जाता है
  • GeoCities के 2.3 करोड़ pages और MySpace के 5 करोड़ से अधिक गाने गायब हो चुके हैं, और 2024 के Pew Research सर्वे में भी 2013 में मौजूद web pages में से 38% दस साल बाद inaccessible पाए गए
  • POSSE में original content पहले अपनी site पर publish किया जाता है और फिर external platforms पर distribute किया जाता है; Backfeed external likes, replies और reposts को Webmention के जरिए original पर वापस भेजकर पूरी बातचीत को personal domain पर सुरक्षित रखता है
  • वास्तविक site पर Webmention, h-entry, h-card, rel="me" लागू किए गए, लेकिन Git·Markdown workflow या 24 घंटे की publishing delay से मेल न खाने वाले Micropub, IndieAuth, WebSub को छोड़ा गया; सभी specs अपनाने से बेहतर है ज़रूरत की तकनीक से धीरे-धीरे शुरुआत करना

IndieWeb जिस web की ओर बढ़ता है

  • IndieWeb खुद को “corporate web का people-focused alternative” कहता है, और यह किसी खास software या framework से अधिक कई approaches और projects को समेटने वाली एक वैचारिक नींव के करीब है
  • 2010 में Aaron Parecki और Tantek Çelik ने Portland के Federated Social Web Summit में भाग लेने के बाद यह माना कि protocol से अधिक creator-centered approach की ज़रूरत है
    • 2011 में Portland में पहला IndieWebCamp हुआ, और उसके बाद यह हर साल दुनिया के अलग-अलग हिस्सों में आयोजित होता रहा
    • Homebrew Website Club में प्रतिभागी मिलकर अपनी personal websites को बेहतर बनाते हैं
  • IndieWeb के तीन मुख्य स्तंभ ये हैं
    • content ownership: web पर डाला गया content किसी company का नहीं, publisher का होना चाहिए
    • बेहतर connectivity: posts को कई platforms पर distribute किया जा सके और external replies व likes को वापस अपनी site पर लाया जा सके
    • control: अपनी पसंद के format में publish और read किया जा सके, और permanent URL बनाए रखे जा सकें
  • यह social networks के इस्तेमाल को मना नहीं करता, लेकिन content और interaction को बंद करके रखने वाले closed ecosystems का विरोध करता है

साइलो और web content का गायब होना

  • साइलो(silo) आम तौर पर एक centralized website होती है, जिसे कोई commercial company चलाती है और जो user-contributed content पर अधिकार मांगती है या access सीमित करती है
    • भाग लेने के लिए हर service का अलग account चाहिए
    • interaction केवल उसी service के accounts के बीच हो सकता है
    • restrictive terms, content licensing demands, search indexing blocks, import-export barriers जैसी चीजें भी जुड़ सकती हैं
  • साइलो बंद होने पर users का content भी साथ में गायब हो सकता है
    • GeoCities को Yahoo ने 26 अक्टूबर 2009 को बंद किया, जिससे 2.3 करोड़ pages गायब हो गए
    • MySpace ने 2019 में server migration के दौरान पहले 12 वर्षों में 1.4 करोड़ artists द्वारा अपलोड किए गए 5 करोड़ से अधिक गाने खो दिए
    • Google+ अप्रैल 2019 में बंद हुआ
    • Posterous, FriendFeed, Vine, Yahoo Groups, TinyLetter, Cohost आदि भी बंद हो चुके हैं
  • साइलो बंद न भी हो, तब भी web content गायब हो सकता है
    • 2024 Pew Research सर्वे के अनुसार 2013 में मौजूद web pages में से 38% दस साल बाद inaccessible थे
  • इसका जवाब social networks का उपयोग बंद करना नहीं, बल्कि content की canonical copy को अपने control वाले domain पर रखना है

समुदाय के 11 सिद्धांत

  • 11 सिद्धांत कोई priority list नहीं हैं, और न ही सबको पूरा करना अनिवार्य है
    1. data ownership: content, metadata और identity को अपने domain पर रखना और लंबे समय तक access बनाए रखना
    2. visible data का उपयोग और publication: पहले इंसानों को, फिर machines को ध्यान में रखना; यदि HTML में data रखा जा सकता है तो अलग API न बनाना
    3. अपने काम की चीज़ बनाना: काल्पनिक users के लिए नहीं, अपने वास्तविक उपयोग के लिए tools बनाना
    4. खुद उपयोग करना: जो बनाया है उसे रोज़ इस्तेमाल करके परखना कि क्या वह भरोसे के लायक है
    5. documentation: process, ideas और code को अपनी site पर दर्ज करके दूसरों और अपने future self की मदद करना
    6. open source बनाना: यह अनिवार्य नहीं, लेकिन दूसरों को independent web में जल्दी शामिल होने में मदद करता है
    7. protocol से पहले UX: पहले user experience तय करना, फिर उसे support करने वाले सबसे simple और छोटे protocols इस्तेमाल करना
    8. modularity: छोटे, loosely coupled components बनाना ताकि वे किसी एक device, language या platform पर निर्भर न रहें
    9. long-term durability: ऐसी web technologies बनाना जिनमें हर कुछ साल बाद पुराने काम को फेंकना न पड़े
    10. pluralism: कई approaches को जानबूझकर बढ़ावा देकर एकल technical culture की बजाय अधिक resilient community बनाना
    11. मज़ा: 1990s के web की तरह अजीब, दिलचस्प और व्यक्तिगत अभिव्यक्ति को जीवित रखना

personal domain से शुरू होने वाली तकनीकी संरचना

  • अपना domain online की primary identity के रूप में इस्तेमाल करना पूरी व्यवस्था की बुनियाद है
    • hosting या CMS बदलने पर भी domain वही रहे तो links, readers और search ranking जारी रह सकते हैं
    • यह community के हिसाब से IndieWeb में भागीदारी की minimum condition भी है
  • IndieWeb किसी single platform की जगह छोटे-छोटे combinable specs का उपयोग करता है, और official spec index उन्हें implementation history और adoption range के आधार पर व्यवस्थित करता है

microformats2: HTML को API की तरह इस्तेमाल करना

  • microformats2 अलग file या API के बिना मौजूदा HTML में CSS classes जोड़कर content को machine-readable बनाता है
    • h-*: root object
    • p-*: plain text
    • u-*: URL
    • dt-*: date
    • e-*: embedded HTML
  • h-card नाम, URL, photo जैसी personal identity को दर्शाता है और applications को post के पास profile दिखाने व user को पहचानने देता है
    • email-based Gravatar के उलट, यह domain-based होता है
  • h-entry post के title, author, publish date, body आदि दिखाने वाला IndieWeb content का मुख्य building block है
  • h-feed कई h-entry को जोड़कर HTML list page को ही subscribable feed बना देता है
  • पढ़ने के लिए microformats और लिखने के लिए Micropub का उपयोग करके “website ही API है” जैसी संरचना बनती है

rel="me" और distributed identity verification

  • rel="me" यह घोषित करता है कि link का target मौजूदा page वाले ही व्यक्ति को दर्शाता है
  • जब website और external profile एक-दूसरे को rel="me" से link करते हैं, तो किसी central authority के बिना mutual identity verification संभव हो जाता है
    • Mastodon इसी संरचना से domain पर green verification mark देता है
    • Threads, PixelFed, GitHub, Keybase, Wikipedia भी इसे support करते हैं
  • RelMeAuth homepage से जुड़े GitHub जैसे OAuth providers को identity proofing सौंपकर personal URL से services में login कराता है
    • IndieLogin जैसी services की यही नींव है

Webmention: websites के बीच बातचीत

  • Webmention 12 जनवरी 2017 से W3C Recommendation है, और Pingback का उत्तराधिकारी होने के नाते platform के बिना sites के बीच comments, likes, replies और reposts भेजता है
  • इसकी sending process इस प्रकार है
    1. source post में target post का link शामिल होता है
    2. source server target post के HTTP Link header या HTML के <link rel="webmention"> में receiving endpoint ढूँढता है
    3. केवल source और target target के साथ POST request भेजी जाती है
    4. receiving server source को fetch करके verify करता है कि उसमें सचमुच target link मौजूद है या नहीं
    5. source के h-entry को parse करके reply, like, repost की पहचान की जाती है, और h-card से author का नाम व photo दिखाया जाता है
  • हर site एक node बनती है और sites के बीच के links social graph बनाते हैं, लेकिन spam और moderation की समस्या बनी रहती है
    • Vouch में receiver एक ऐसे vouching site को तीसरे parameter के रूप में मांग सकता है जिसे वह पहले से जानता हो और जिसने sending domain को link किया हो; इससे filtering cost sender पर चली जाती है
    • Salmention में जब comment पर reply आती है, तो original post participants को updated Webmention फिर से भेजकर conversation thread फैलाता है
  • backend के बिना static sites के लिए webmention.io Webmention की ओर से receive करता है और lookup API देता है
    • इसे Hugo, Jekyll, Eleventy जैसे static site generators के साथ इस्तेमाल किया जा सकता है

domain-based login और publishing

  • IndieAuth Google या Facebook account की जगह personal URL को login identity की तरह उपयोग करता है
    • यह OAuth 2.0 पर आधारित है और users व applications दोनों की पहचान URL से करता है
    • DNS pre-client registration की जगह लेता है, और access token theft रोकने वाली PKCE अनिवार्य है
    • service user page के rel="indieauth-metadata" से auth server ढूँढती है, और authentication पूरा होने पर उस URL पर control verify करती है
    • password, email, RelMeAuth आदि authentication methods के रूप में इस्तेमाल किए जा सकते हैं
  • Micropub मई 2017 से W3C Recommendation है और site software को publishing interface से अलग करता है
    • web, iOS, Android clients personal domain की posts create, edit, delete कर सकते हैं
    • password sharing वाले MetaWeblog और AtomPub की जगह यह IndieAuth से मिले OAuth tokens का उपयोग करता है
    • अलग vocabulary बनाए बिना h=entry, content जैसी h-entry properties को serialize करके भेजता है

real-time feeds और अलग readers

  • WebSub पहले PubSubHubbub कहलाता था और जनवरी 2018 से W3C Recommendation है
    • subscriber के server polling की जगह publisher hub को new post की सूचना देता है, और hub webhook के जरिए subscribers तक उसे तुरंत पहुँचाता है
    • इससे server load कम होता है, update delay खत्म होती है, और Feedly व NewsBlur इसे support करते हैं
  • Microsub सबसे नया spec है, अभी draft में है, और social reading applications को दो layers में बाँटता है
    • server subscription management, feed collection-analysis और data normalization संभालता है
    • client सिर्फ reading interface दिखाता है, इसलिए वह UX पर compete कर सकता है, और subscription data clients के बीच move हो सकता है
    • Micropub की reply publishing और Webmention notifications को जोड़ने पर IndieWeb social reader structure पूरा हो जाता है

POSSE, PESOS और Backfeed

  • POSSE पहले अपनी site पर publish करो, फिर बाहर distribute करो वाली recommended strategy है
    • external copies में original link होता है, इसलिए readers existing platform पर पढ़ना जारी रख सकते हैं और publisher canonical version बनाए रखता है
    • platform बंद हो जाए या account block हो जाए, original बचा रहता है
    • Tantek Çelik ने 2012 में यह term बनाई थी, और Cory Doctorow व Molly White जैसे लोग इसका उपयोग करते हैं
    • spam sites अगर post कॉपी करें, तो वे original link भी साथ कॉपी करती हैं; इस प्रभाव को “internet aikido” कहा जाता है
  • PESOS इसका उल्टा तरीका है, जिसमें पहले साइलो पर publish करके बाद में अपनी site पर कॉपी सुरक्षित रखी जाती है
    • इससे polished silo apps का उपयोग किया जा सकता है और personal site बंद होने पर भी posting जारी रह सकती है
    • लेकिन शुरुआत से ही silo terms लागू होते हैं, personal site की copy canonical नहीं होती, और character limit या t.co links जैसी पाबंदियाँ भी साथ आती हैं
  • Backfeed external copies पर आए likes, replies और reposts को Webmention के जरिए original पर वापस भेजता है
    • Bridgy Mastodon, GitHub, Flickr, Reddit, Bluesky पर मौजूद copies को monitor करता है और हर interaction पर Webmention भेजता है
    • नतीजतन external platforms पर हुई पूरी बातचीत personal domain पर archive की जा सकती है

Fediverse और RSS के साथ संबंध

  • Webmention, Micropub, WebSub और ActivityPub सभी W3C Social Web Working Group से निकले, लेकिन उनकी philosophies अलग हैं
  • Fediverse servers को federate करता है और identity को @user@instance के रूप में दिखाता है, इसलिए अगर आप अपनी instance नहीं चलाते तो किसी और operator पर निर्भर रहते हैं
    • instance चलाने में moderation और maintenance की ऊँची लागत यानी admintax जुड़ी होती है
  • IndieWeb websites को federate करता है और personal domain को identity की तरह इस्तेमाल करता है; federation को कई distribution channels में से एक माना जाता है
  • Bridgy Fed h-card, h-entry, Webmention को ActivityPub और Bluesky के AT Protocol के साथ interconvert करता है
    • personal domain @example.com@example.com जैसे Fediverse account में बदल जाता है
    • Mastodon पर ऐसे account को search और follow किया जा सकता है, और replies Backfeed से original post पर लौट आती हैं
  • IndieWeb का मानना है कि RSS·Atom में HTML से अलग XML copy बनाए रखनी पड़ती है, जिससे maintenance cost और inconsistency की संभावना बढ़ती है
    • कुछ Atom files समान content वाले HTML से 4.5 गुना तक बड़े होते हैं
    • और जब कोई इंसान feed link सीधे खोलता है, तो उसका experience भी अच्छा नहीं होता
  • इसका विकल्प h-feed है, जो HTML को ही feed की तरह इस्तेमाल करता है, लेकिन इसे support करने वाले readers बहुत कम हैं
    • इसलिए सिफारिश यह है कि IndieWeb ecosystem के लिए h-feed और आम readers के लिए RSS·Atom दोनों दिए जाएँ

शुरुआत का क्रम

  • Getting Started यह क्रम सुझाता है
    1. domain लेना: इसे online की primary identity की तरह उपयोग करें, और WHOIS privacy तभी चुनें जब provider पर पूरा भरोसा हो
    2. hosting setup: beginner हों तो GitHub Pages, Netlify, Neocities जैसी managed services लें, अनुभव हो तो self-host करें
    3. page बनाना: static site generator, hand-written HTML, या CMS—कुछ भी इस्तेमाल किया जा सकता है; कोई official technology नहीं है
    4. POSSE लागू करना: original link के साथ दूसरे platforms पर distribute करें
    5. microformats जोड़ना: homepage पर rel="me", posts में h-entry जोड़ें
    6. validation: IndieWebify.me से rel-me, h-card, h-entry को step-by-step verify करें
    7. community में भाग लेना: एक page ही क्यों न हो, जो बनाया है उसे share करें और अगले user के लिए wiki में document करें
  • IndieMark उन developers के लिए staged guidance scale है जो चीजों को धीरे-धीरे अपनाना चाहते हैं

वास्तविक implementation और छोड़ी गई सुविधाएँ

  • वास्तविक site पर ये elements लागू किए गए
    • Webmention भेजना और प्राप्त करना: नए posts के external links को notify करने वाले daily task को automate किया गया, लेकिन typos ठीक करने के लिए 24 घंटे की गुंजाइश रखी गई
    • received Webmentions को हर post के अंत में references list में इस्तेमाल किया गया, और email-managed comments से अलग रखा गया
    • सभी posts में h-entry, homepage पर h-card लागू किया गया, और mf2py से validate किया गया
    • footer में Mastodon, GitHub, Org Social को rel="me" से जोड़कर verification mark लिया गया
  • जिन चीज़ों का मेल ज़रूरत और मौजूदा workflow से नहीं था, उन्हें छोड़ा गया
    • Micropub·IndieAuth: editor और Git ही publishing interface हैं, और posts version-controlled Markdown में लिखी जाती हैं, इसलिए अलग publishing endpoint की ज़रूरत नहीं है
    • WebSub: जानबूझकर publication को 24 घंटे delay किया जाता है, इसलिए real-time delivery अतिरिक्त complexity को justify नहीं करती
    • h-feed: post card template body के recommendation sections जैसी दूसरी जगहों पर भी reuse होता है, जिससे parser उसे ambiguous h-entry समझ सकता है; RSS यह भूमिका पर्याप्त रूप से निभा देता है

तकनीक से अधिक टिकाऊ व्यावहारिक सिद्धांत

  • plain HTML JavaScript के बिना भी पूरा content पढ़ने देने वाला सबसे long-lasting format है
  • “Cool URIs don't change” सिद्धांत के अनुसार ऐसे URL design करने चाहिए जिन्हें हमेशा बनाए रखा जा सके
    • वास्तविक site में post slug बदलने पर भी पुराना URL काम करता रहता है
  • साइलो को एक बार में छोड़ने की ज़रूरत नहीं; content type के हिसाब से पहले अपनी site पर publish करने वाला gradual transition संभव है
  • बहुत लंबी अवधि की durability पर भी विचार करना चाहिए
    • मृत्यु के बाद किसी भरोसेमंद व्यक्ति को site की keys सौंपने वाले “dead man's switch” पर विचार किया जा सकता है
    • operator के गायब हो जाने के बाद domain cost कौन देगा, यह भी तय करना होगा
  • पूरी तरह polished लेकिन बनाए रखना उबाऊ template की तुलना में अपूर्ण लेकिन अनोखी personal website को आनंद से चलाना IndieWeb के सिद्धांतों के अधिक अनुरूप है

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

1 टिप्पणियां

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

  • अगर IndieWeb को कंटेंट चाहिए, तो उसे जटिल तकनीकी ढेर के नीचे दबा देना ठीक उल्टा तरीका है
    यह प्रोटोकॉलों का गुच्छा 90% उपयोगकर्ताओं के लिए व्यावहारिक रूप से इस्तेमाल करने लायक नहीं है, और अगर कंटेंट user experience को प्राथमिकता देनी है तो तुरंत शुरू हो सकने वाला one-click समाधान चाहिए
    जिस क्षण आप command line·Docker·HTML/CSS की सीधे editing की मांग करते हैं, उसी क्षण आप ऐसा अवरोध बना देते हैं जिसे ज़्यादातर लोग पार नहीं कर पाएंगे; अभी यह IndieWeb से ज़्यादा NerdNet जैसा लगता है

    • IndieWeb community और wiki को देखें तो user experience पहले रखने वाली सोच से सहमत लोग काफ़ी हैं
      सबसे प्रमुख one-click entry point, micro.blog, $5 प्रति माह में IndieWeb की आधुनिक सुविधाओं वाला एक personal site देता है
      अभी ज़्यादातर रुचि रखने वाले लोग खुद build करना चाहने वाले developers हैं, इसलिए संबंधित लेख तकनीक से भरे हुए लगते हैं, लेकिन non-developers का आना भी वही बदलाव है जो community चाहती है। David Shanske पिछले 10 वर्षों से ऐसे WordPress plugins बना रहे हैं जो IndieWeb tools को default में देते हैं: https://profiles.wordpress.org/dshanske/#content-plugins
      IndieWeb कहलाने के लिए सारी तकनीकें इस्तेमाल करना भी ज़रूरी नहीं है। अपने डोमेन से शुरू करें, HTML·Markdown·Django आदि से पेज बनाएं, फिर बारी-बारी से microformats और Webmention जोड़ें; किसी भी चरण पर उसे IndieWeb site माना जा सकता है
    • बल्कि अगर इसे सबके लिए खोल दिया जाए तो अच्छी चीज़ बिगड़ जाती है। अनंत सितंबर की तरह घटिया माध्यम और clickbait भर जाते हैं, इसलिए entry barrier और participation limits फायदेमंद हैं
      इंटरनेट तब बेहतर था जब वह वैश्विक Walmart बनने से पहले दिलचस्प लोगों के अपने-आप इकट्ठा होने की जगह था
    • मैं अभी-अभी इससे परिचित हुआ हूँ, लेकिन IndieWeb को दोष देना मुश्किल है। social platforms की बंद दीवारों से निकलना चाहने वाले लोग ज़्यादातर engineers या web से परिचित लोग हैं, और अपने जाने-पहचाने tools से समस्या सुलझाना स्वाभाविक है
      इंटरनेट भी हमेशा सनकियों द्वारा बनाई गई कठिन लेकिन मज़ेदार चीज़ों से शुरू हुआ और धीरे-धीरे आम लोगों के लिए आसान बना। IndieWeb भी शुरुआती चरण में है; अगर यह टिकता है तो mainstream अपनापन स्वाभाविक रूप से आएगा, इसलिए अभी लोगों को और बनाने देना चाहिए
    • 2014 में मैंने IndieWeb movement के हिस्से के रूप में इस लक्ष्य को लागू करने वाला startup Known शुरू किया था, और open source code अभी भी मौजूद है
      समस्या आर्थिक व्यवहार्यता की है। one-click समाधान अच्छा है, लेकिन IndieWeb वैचारिक समस्या हल करता है, उपयोगकर्ताओं की कोई तात्कालिक समस्या नहीं; इसलिए निवेश या service संचालन लागत उठाने वाले ग्राहक जुटाना कठिन है
      micro.blog सबसे क़रीब है, लेकिन यह ऐसी केंद्रीकृत service है जिसे अपनी infrastructure पर नहीं चलाया जा सकता, इसलिए protocol compatibility होने पर भी यह पूरी तरह IndieWeb tool नहीं है
      agent activity logs या sensor·server publishing tools जैसी संभावनाएँ हैं, लेकिन अगर वास्तविक user demand नहीं है तो इसे तैयार product service बनाना मुश्किल लगता है
    • लोगों को पता है कि यह 90% उपयोगकर्ताओं के लिए कठिन है, लेकिन उन्हें इसकी परवाह नहीं है। free software की तरह IndieWeb भी बिना भुगतान के अपनी ज़रूरतें खुद हल करने का दर्शन है, market पर कब्ज़ा करना इसका लक्ष्य नहीं है
      लोकप्रिय चीज़ों के आगे झुकने के बजाय लोगों को वह बनाने के लिए प्रोत्साहित करना चाहिए जो वे चाहते हैं। वास्तविक मूल्य बनाने के बजाय rent-seeking रणनीतियों और lobbying में लगे marketing पेशे समाज को और ख़राब करते हैं, इसलिए उनका कम होना बेहतर है

  • Nostr की सोच Mastodon या AT Protocol की तुलना में POSSE के ज़्यादा क़रीब लगती है, इसलिए मुझे वह पसंद है

    • मुझे Nostr से कहीं ज़्यादा Org Social पसंद है: https://en.andros.dev/blog/8c640241/why-org-social-when-you-...
    • क्या Nostr अब brocoin-केंद्रित संस्कृति से बाहर निकल चुका है, यह जानने की जिज्ञासा है

  • मैं नियमित रूप से ब्लॉग चलाता हूँ और डोमेन व पोस्ट्स का मालिक भी हूँ, लेकिन अगर WordPress इस्तेमाल करने की वजह से उसे IndieWeb नहीं माना जाएगा, तो आखिरकार यह भी किसी कंपनी पर निर्भरता ही हुई। Blogger पर बनाए गए पुराने ब्लॉग भी लगभग 10 साल से वैसे ही पड़े हैं
    server का खुद मालिक होना व्यावहारिक नहीं है। virtual server हो तो वह Amazon या Microsoft cloud में होगा, और physical server हो तो भी किसी कंपनी के datacenter में रखना पड़ेगा; UPS और हमेशा चालू internet connection तक खुद संभालना मुश्किल है

  • मौजूदा विकल्प अक्सर 1990 के दशक की nostalgia तक सीमित रहे हैं, जिनका थोड़ी देर की याद के अलावा उपयोग ढूँढना मुश्किल था, लेकिन यह तरीका अलग लगता है
    यह आधुनिक web को अपनाते हुए creator को अपनी जगह पर पूरा नियंत्रण देता है। समय मिला तो मैं अपने myzopotamia.dev ब्लॉग को IndieWeb में शामिल करना चाहूँगा

  • indiekit वास्तव में IndieWeb सुविधाओं का पूरा सेट default में देता है। मैं इसे https://rmendes.net पर इस्तेमाल कर रहा हूँ और https://textcaster.app में भी लागू करने पर काम कर रहा हूँ

  • RSS feed के DRY सिद्धांत वाली समस्या शायद बढ़ा-चढ़ाकर बताई जाती है। याद नहीं पड़ता कि किसी open source framework में लिखी साइट के लिए RSS feed auto-generate करने में कभी समस्या हुई हो

    • फिर भी RSS की duplication साफ़ है। यह वेबसाइट के list page की सीधी नकल है, और h-entry होने पर उसी कंटेंट के दो versions और XML संभालना पड़ता है, जो अक्सर झुंझलाहट पैदा करता है
      RSS का आविष्कार semantic markup क्रांति से ठीक पहले हुआ था, जब table-based layouts ख़त्म हो रहे थे, इसलिए उसका समय ठीक नहीं था
    • RSS feeds बनाना या पढ़ना पसंद करने वाले लोग बहुत कम लगते हैं। विकल्प बहुत हैं, लेकिन RSS की लोकप्रियता से आगे कुछ नहीं निकल पाया है

  • जब मैं ऐसे साइट देखता हूँ जो खुद को IndieWeb कहती हैं और वहाँ लेखक का résumé, professionally shot face photo, प्रतिष्ठित संस्थानों का अनुभव बताने वाला परिचय, और एक polished blog होता है, तो असहजता होती है
    यह कुछ वैसा है जैसे किसी आलीशान mall की चमकदार कपड़ों की दुकान में हर सामान पर anarchist प्रतीक लगा हो, और पास जाकर देखें तो price tags लगभग चार अंकों में हों

    • मैं ज़्यादा बार ऐसे सादे ब्लॉग देखता हूँ जो ब्लॉग चलाने की खुशी पर बात करते हैं, और वे Substack growth को निशाना बनाने वाले आसपास के उद्योग से कहीं बेहतर लगते हैं
      personal site वह कुछ भी हो सकती है जो आप चाहें। मेरी साइट भी नौकरी ढूँढने की ज़रूरत ख़त्म होने के साथ हर साल और ज़्यादा व्यक्तिगत व hobby-केंद्रित होती जा रही है, लेकिन साइट आखिर उस समाज का उत्पाद भी है जिसमें वह व्यक्ति रहता है, और रोज़ी-रोटी भी चलानी होती है
    • मेरी साइट भी खुद को IndieWeb कहकर पेश नहीं करती, लेकिन वहाँ consulting site का link और मेरा face photo है
      पेशेवर जीवन भी मेरा ही एक हिस्सा है, और self-employed होने के अर्थ में मुझे स्वतंत्र मज़दूर भी कहा जा सकता है; इसमें बुराई क्या है, समझ नहीं आता
    • personal domain पर résumé रखना सबसे IndieWeb-जैसा काम है। क्योंकि इससे अपनी professional identity LinkedIn पर नहीं बल्कि अपने नियंत्रण में रखी जाती है
      IndieWeb professionalism का विरोध नहीं करता; उसका मानना है कि कंटेंट आपका होना चाहिए और platform से ज़्यादा समय तक जीवित रहना चाहिए। face photo·résumé·polished blog ठीक हैं; आलोचना की चीज़ यह है कि इन्हें ऐसे platform में क़ैद कर दिया जाए जो बंद हो सकता है, data बेच सकता है, या ग़ायब हो सकता है

  • बिना किसी parallel file या API के कंटेंट को machine-readable बनाना शुरू से ही शायद ऐसा मसला था जिसे हल करने की बहुत कम ज़रूरत थी
    पहले की ontologies की तरह यह भी मानव आगंतुकों के लिए बेकार है और सिर्फ़ ऐसे पक्षों को data खिलाता है जो उनके प्रति शत्रुतापूर्ण हैं

  • पसंदीदा दूसरे ब्लॉगों को लगातार share करना अच्छा है। IndieWeb word-of-mouth और मानवीय curation पर निर्भर करता है, इसलिए ‘इस महीने मुझे क्या पसंद आया’ जैसे पोस्ट उपयोगी हैं
    खुलकर तारीफ़ करनी चाहिए, email से धन्यवाद भेजना चाहिए, और बातचीत शुरू करनी चाहिए। user tracking के बिना static site कभी-कभी खुद से बात करने जैसी लग सकती है, इसलिए पाठकों के email बहुत हौसला देते हैं
    personal site की तरह अधूरी और थोड़ी अजीब होना भी ठीक है, और हर कंटेंट को समयक्रम वाले feed में होना ज़रूरी नहीं। digital garden की तरह अपनी जगह को जैसे चाहें वैसे व्यवस्थित किया जा सकता है

  • क्या आपको पता था कि .dev domain Google के स्वामित्व में है?

    • हाँ, पता था, और मैं अपना personal top-level domain लेना चाहता था, लेकिन प्रक्रिया काफ़ी जटिल लगी