Tailscale के मुताबिक नया इंटरनेट
(tailscale.com)- Tailscale एक नई OSI Layer 3 बनाना चाहता है, ताकि developers अनावश्यक scalability-केंद्रित संरचनाओं में न फँसें और सभी devices सुरक्षित रूप से सीधे connect हो सकें
- उसका मानना है कि कई programs को असल में large-scale scaling की जरूरत नहीं होती, लेकिन Kubernetes, container deployment और cloud log collection default बन जाने से development और operations धीमे हो गए हैं
- IPv4 की कमी, NAT, firewalls, dynamic IP और TLS certificate structure clients और servers को अलग कर देते हैं, और AWS जैसे central cloud providers को connectivity के केंद्र में ला खड़ा करते हैं
- Tailscale हर device को certificate, IP address, DNS name, end-to-end encryption और identity देकर firewall के पीछे भी सुरक्षित रूप से connect करना चाहता है, और सभी devices को peers बनाना चाहता है
- Taildrop का HTTP PUT-आधारित file transfer दिखाता है कि बीच की cloud layer घटाई जा सकती है, लेकिन ऐसा app ecosystem बनने के लिए पहले पर्याप्त adoption जरूरी है
Tailscale vision की शुरुआत
- Tailscale ने short-term features से बड़ी vision के बारे में सार्वजनिक रूप से बहुत ज्यादा नहीं कहा है, लेकिन कुछ companies Tailscale को सिर्फ मौजूदा features के लिए नहीं, बल्कि भविष्य में संभव होने वाली connectivity के कारण खरीद रही हैं
- शुरुआती problem statement networking company बनने का नहीं था; मुद्दा यह था कि developers उन चीजों को भी scale करने की कोशिश कर रहे थे जिन्हें scale करने की जरूरत नहीं थी, और इससे developer experience खराब हो रहा था
- 1990s का LAN experience याद रखने वाली पीढ़ी Tailscale की स्थापना के संदर्भ में मौजूद है, और वही experience आज की technical complexity की तुलना का आधार बनता है
- कंप्यूटर performance, programming accessibility, app stores, payment systems और graphics बेहतर हुए हैं, लेकिन developers के रोज़मर्रा के कामों में पहले जो कई चीजें आसान थीं, वे उल्टा कठिन हो गई हैं—ऐसा Tailscale मानता है
अनावश्यक scalability से बना development overhead
- आधुनिक developers को पहला code लिखने से पहले ही 1 अरब users के scale के बारे में सोचने के लिए train किया जाता है, और algorithms व architecture choices में भी scalability को प्राथमिकता देने की प्रवृत्ति होती है
- big-O notation को गलत तरीके से लागू करने पर hash table हमेशा array से तेज दिख सकता है, लेकिन 10 items के स्तर पर array ज्यादा तेज और सरल हो सकता है
- scalable structure चुनने पर, अगर वास्तव में scale नहीं करना है, तो system ज्यादा धीमा और बनाना कठिन हो सकता है
- महीने में 500,000 pageviews को Kubernetes से handle करने का उदाहरण लगभग 0.2 requests per second के स्तर का है; तुलना में कहा गया है कि 1990s के धीमे computers पर भी Perl या Python programs milliseconds में start होकर इससे ज्यादा requests handle कर सकते थे
- लंबी builds, Docker builds, container repository uploads, दर्जनों seconds से minutes तक deployments और देर से आने वाले logs—ये सब “हर चीज को scale करना चाहिए” वाली धारणा से पैदा हुए overhead के रूप में देखे जाते हैं
- Tailscale खुद को ऐसे tools के रूप में स्थापित करता है जिनसे dashboards, meme generators जैसे long-tail tasks जिन्हें scale करने की जरूरत नहीं—जिन पर सभी developers अपने समय का बड़ा हिस्सा खर्च करते हैं—आसानी से बनाए जा सकें
मौजूदा इंटरनेट complexity कैसे बढ़ाता है
- बहुत-सी complexity intrinsic complexity नहीं मानी जाती, बल्कि सरलता से हल हो सकने वाली समस्याओं पर complex solutions चढ़ाने का नतीजा मानी जाती है
- Log system का काम एक जगह से दूसरी जगह text stream करना है, फिर भी परिणाम 5 minutes बाद दिख सकता है
- Orchestration system वह program है जो दूसरे programs चलाता है, जबकि Unix kernel दशकों से यह काम milliseconds में करता आया है
- Networking आधुनिक software के लिए जरूरी है, लेकिन मौजूदा internet कई समस्याओं को कठिन बना देता है
- Tailscale मौजूदा OSI stack के सबसे ऊपर एक और layer जोड़कर समस्या छिपाने के बजाय, अलग assumptions पर नई OSI Layer 3 बनाना चाहता है
Cloud centralization और connectivity का rent
- Tech industry में कौन rent वसूल सकता है यह देखने से bottleneck दिखता है, और मौजूदा software deployment में AWS को ऐसी ही position में माना गया है
- Cloud scalable computing resources देता है, लेकिन तुलना में कहा गया है कि एक mid-range MacBook भी अपने SSD पर cloud local disk की तुलना में 10 गुना या 100 गुना ज्यादा transactions per second संभाल सकता है
- अपने computer का server बनना कठिन होने की वजह location और connectivity है
- Firewalls, NAT, dynamic IP और asymmetric network links होते हैं
- Port forwarding, static IP और redundant internet links खुद configure किए जा सकते हैं, लेकिन इसके लिए बहुत काम और expertise चाहिए
- अंत में IP address और bandwidth वाले hosting provider को payment करना पड़ता है, और कोई serious company equipment access पर भरोसा करने के लिए बड़े provider को चुनेगी
- “AWS खरीदने पर किसी को नौकरी से नहीं निकाला जाता” वाली स्थिति अतीत में IBM के लिए कही जाने वाली अभिव्यक्ति से जुड़ती है
Gatekeeper का operating system से HTTPS की ओर जाना
- IBM centralized computing से rent ले सकता था, और Microsoft ने PC-आधारित distributed computing से उस ढांचे को हिला दिया
- आज cloud और phones-केंद्रित दुनिया फिर से centralized हो गई है—ऐसा माना गया है
- desk और pocket में मौजूद devices 20 साल पहले के मानकों से supercomputer-class हैं, लेकिन AWS बंद हो जाए तो वे बेकार ईंटों जैसे हो जाते हैं
- server की multiple instances और distributed consensus systems होने पर भी, ज्यादातर central cloud providers के ऊपर ही चलते हैं
- 1990s में operating system programs के बीच compatibility और connection तय करता था, लेकिन web के बाद JavaScript और HTTPS connectivity ज्यादा महत्वपूर्ण हो गए
- HTTPS में मूल रूप से client-server का centralized structure होता है
- Server के पास static IP, DNS name, TLS certificate और open ports होते हैं
- Client के पास आम तौर पर ऐसे elements नहीं होते
- Server गायब हो जाए तो client कुछ नहीं कर पाता
- Security problems और IPv4 addresses की कमी के कारण firewalls और NAT जोड़े गए, और connection client से server की ओर जाने वाला one-way structure बन गया
Tailscale का New Internet
- Tailscale ने पिछले 5 सालों में इस समस्या के समाधान के रूप में product बनाया है
- हर device के पास certificate, IP address, DNS name, end-to-end encryption और identity होती है, और वह firewalls को सुरक्षित रूप से bypass करता है
- सभी devices server और client की fixed roles में बंधे रहने के बजाय आपस में connect होने वाले peers बन सकते हैं
- Tailscale मानता है कि वह यह सब latency या overhead जोड़े बिना करता है
- Tailscale users पहले से ही कई layers वाली complex संरचना हटे हुए environment का अनुभव कर रहे हैं, और internet अपेक्षित मूल तरीके के ज्यादा करीब काम करता है
Taildrop से दिखती सरलता
- Taildrop Tailscale द्वारा संभव की गई structure का छोटा उदाहरण है
- Tailscale पहले से installed होने पर Taildrop का core सिर्फ एक HTTP PUT है
- भेजने वाला प्राप्त करने वाले को HTTP request भेजता है
- बताता है कि “X नाम की file भेज रहा हूँ”
- file transfer करता है
- मौजूदा internet में receiving device firewall के पीछे होता है और उसके पास open port और ID नहीं होती, इसलिए cloud पर upload करके फिर download करने वाला तरीका जरूरी था
- Cloud के जरिए जाने वाला तरीका कई extra layers बनाता है
- Network egress cost, storage cost और server CPU cost लगती है
- यह तय करना पड़ता है कि download न हुई files कब delete करनी हैं
- इस्तेमाल न होने पर भी servers को online रखना पड़ता है
- Cloud employees theoretical रूप से files access कर सकते हैं, इसलिए encryption चाहिए
- Encryption के लिए sender और receiver के बीच key exchange चाहिए
- Receiver को यह बताने के लिए कि file waiting में है, platform-specific push notification system की जरूरत हो सकती है
- Taildrop में ये cost overhead खत्म हो जाते हैं, इसलिए free file transfer संभव होता है, और यह Tailscale के free plan के context से जुड़ता है
Adoption जरूरी क्यों है
- Taildrop छोटा उदाहरण है, लेकिन यह उन categories के programs का proof of existence है जो Tailscale होने पर 10 गुना आसान हो सकते हैं
- Connectivity की कमी centralization पैदा करती है, और centralization छोटे programs से भी rent वसूलता है, साथ ही धीमी, complex और debug करने में कठिन structures बनाता है
- Tailscale के ऊपर ही चलने वाले apps बनने के लिए पर्याप्त लोगों का Tailscale इस्तेमाल करना जरूरी है
- Adoption पर्याप्त न हो तो कोई ऐसे apps नहीं बनाता—यह chicken-and-egg problem बन जाती है
- इसी कारण Tailscale free offering पर काफी मेहनत करता है, और साथ ही workplace adoption व Fortune 500 companies में पूरी deployment को आसान बनाने वाली enterprise features पर भी जोर देता है
लक्ष्य और मौजूदा स्थिति
- Internet सभी के लिए है, और अतीत में कई internetworks थे, लेकिन सबसे विविध और inclusive Internet जीता—ऐसा माना गया है
- New Internet भी घर के developers, universities के developers, enterprise employees और अंततः हर व्यक्ति के उपयोग के लिए होना चाहिए
- आज दुनिया भर के लोगों में लगभग 30,000 में 1 व्यक्ति New Internet, यानी Tailscale, इस्तेमाल करता है
- Tailscale का लक्ष्य है कि जब तक हर कोई इसे इस्तेमाल न करे, वह रुकेगा नहीं
- Microsoft को हर desk पर computer रखने के लक्ष्य के लिए मजाक बनाया जाता था, और TCP/IP कभी third-party से खरीदने वाला optional add-on था—इन बातों को याद करते हुए यह जोर दिया गया है कि tech दुनिया 30 साल के भीतर भी तेजी से बदल सकती है
1 टिप्पणियां
Hacker News की राय
Tailscale, Cloudflare, Google जैसी कंपनियों की स्थायी समस्या यह है कि वे उन समस्याओं को हल करती हैं जिन्हें इंटरनेट को मूल रूप से खुद हल कर लेना चाहिए था, जैसे सरल end-to-end secure connection, और इससे यह प्रोत्साहन बनता है कि वह समस्या बनी रहे
इंटरनेट को जो चाहिए वह DNSSEC द्वारा दी जाने वाली public key-based structure और IPsec automatic encryption वाला IPv6 जैसा कुछ है, लेकिन अगर वैसी चीज़ व्यापक compatibility के साथ लागू हो जाए, तो Tailscale का business ढह जाएगा
अंततः उनका business इसी पर निर्भर है कि समस्या मौजूद बनी रहे
फिर से पोस्ट: https://news.ycombinator.com/item?id=38570370
IPv6 1998 में आया था, और Tailscale के 2019 में लॉन्च होने तक 21 वर्षों में भी बताई गई पद्धति लागू नहीं हुई थी
तब किसने रोका था, और अब कौन रोक रहा है? Google, Cloudflare, Tailscale ने असली समस्या हल की, इसलिए उन्हें पैसे या privacy जैसे पैसे के बराबर मूल्य के रूप में भुगतान मिला
इस तरह के reverse accelerationism से सहमत होना मुश्किल है कि इंटरनेट को सभी के लिए और खराब बनाना होगा तभी सच में अच्छा solution आएगा
ऐसा नहीं है कि Tailscale की वजह से वह solution नहीं आ रहा; वजह उसे बनाने के लिए लगने वाला भारी काम है, और अगर WireGuard नहीं होता तो शायद Tailscale भी नहीं होता
Tailscale के आने से Headscale भी बना, और यह बताए गए “कुछ” को बनाने की दिशा में एक और आधार बन गया
लंबी बात का सार यह है कि devices के एक-दूसरे को खोजने के बीच में Tailscale बैठता है
दूसरे तरीके भी हैं। केवल temporary IP रखने वाले device को permanent name देने वाला dynamic DNS दशकों से मौजूद है, हालांकि उसकी reputation बहुत अच्छी नहीं है
एक-दूसरे को जानने वाले कई coordination nodes और public node list इस्तेमाल करने का तरीका भी संभव है। list पुरानी हो जाए तब भी अगर कोई एक live node मिल जाए तो उससे connect करके update किया जा सकता है, और Ethereum network तथा कुछ file-sharing systems का आधार Kademlia इसी तरह काम करता है
search और transfer को अलग करने वाला compromise भी संभव है। Peertube में सामान्य web search से मिले server पर HTTP के जरिए stream होने वाली file खोजी जाती है, और असली transfer distributed तरीके से होता है जिसमें मौजूदा viewers blocks एक-दूसरे को भेजते हैं, इसलिए video viral होने पर भी अच्छी तरह scale करता है
इसलिए यह भी पूरी तरह संभव है कि बीच में कोई oxygen line काट न सके
पुराने VPN protocols या RADIUS जैसे authentication methods में गंभीर security holes हों, तब भी compatibility की वजह से उन्हें ठीक करना मुश्किल होता है, और वे भी पूरे इंटरनेट की तुलना में बहुत छोटे scale पर चलते हैं
industry TCP ossification की समस्या को TCP छोड़कर UDP के ऊपर फिर से implement करने के तरीके से हल कर रही है, यह अपने-आप में बहुत कुछ बताता है
location service भी चाहें तो self-host कर सकते हैं, इसलिए service का इस्तेमाल करना अनिवार्य नहीं है
DNSSEC को छोड़ दें तो यह मांगी गई चीज़ से काफी मिलता-जुलता है
यह value IPsec आने से गायब नहीं होती
शुरुआत centralized control के जरिए rent extracting पर एक बहुत लंबी शिकायत से होती है, और अपने-आप में यह एक जायज शिकायत है
लेकिन फिर यह अलग बहसों में भटक जाती है कि client-server computing समझ में आती है या नहीं, या क्या वही rent-seeking की वजह है, और आखिर में इस निष्कर्ष पर पहुंचती है कि “कल Tailscale वाले और बिना Tailscale वाले लोगों में फर्क होगा”
राजा मर गया, नए राजा की जय जैसा एहसास है
यह इतना छोटा और सरल है कि programmer न होते हुए भी मैं इसे ठीक कर सकता हूं
सबके पास इंटरनेट पर सीधे access किए जा सकने वाले firewall-less IP नहीं होते, इसलिए peer-to-peer हासिल करने के लिए client-server का इस्तेमाल भी किया जा सकता है
hosting company के server पर “supernode” चलाना पड़ सकता है, लेकिन अगर उसे केवल rendezvous server की तरह इस्तेमाल करें तो traffic उससे नहीं गुजरता, इसलिए लागत कम रहती है
“free” से competition करने की कोशिश करने वाली company पर मुझे हमेशा गहरा शक होता है। जैसे, free software इस्तेमाल करना बंद करो और हमें पैसे दो, बदले में हमने 100 अनावश्यक features जोड़ दिए हैं
Slack की तरह ऐसी corporate strategy short term में सफल हो सकती है, लेकिन ऐसी subscription मेरे taste की नहीं है
मेरे हिसाब से असली मुद्दा client-server बनाम peer-to-peer नहीं, बल्कि proprietary बनाम non-proprietary है
अगर 10 साल के भीतर Microsoft जितना बड़ा दिग्गज नहीं बनता, तो इसे सकारात्मक रूप से स्वीकार कराना मुश्किल होगा
उस समय personal private network design और setup करने के लिए यह सच में शानदार और आसान tool था। file sharing, local game LAN, development collaboration, यहां तक कि media streaming भी आसानी से संभव थी
peer-to-peer का भविष्य Tailscale से ज्यादा शायद self-hosted Hamachi variant जैसा होगा, जो अलग-अलग NAT और ASN के पार nodes को सामान्य रूप से जोड़ता हो और NAT traversal techniques, STUN/TURN, turtle routing को समझता हो
अगर कोई tool remote users को central VPN gateway के बिना आसानी से join करने दे, तो modern environment में यह बहुत powerful feature होगा
अच्छा होगा कि हम सब Iceberg Articles सीखें और लागू करें: https://john.kozubik.com/pub/IcebergArticle/tip.html
असल में Tailscale को production system में इस्तेमाल कर रहा हूँ। सर्वर भौतिक रूप से पास की जगह या किसी दूसरे नियंत्रित स्थान पर हैं, और सैकड़ों किलोमीटर दूर मौजूद सैकड़ों users सब Tailscale से काम करते हैं
दो बातें कहनी होंगी। Tailscale कमाल का है और वाकई अच्छा है। यह system Tailscale के बिना मौजूद नहीं हो सकता था, या 24 घंटे operation के लिए team में कम-से-कम 10 लोग और चाहिए होते
हालांकि expectations कम रखनी चाहिए। यह “internet” जितना अच्छा नहीं है। latency समय-समय पर उछलती है, connection कभी-कभी टूट जाता है, और MagicDNS सचमुच जादू की तरह बंद हो जाता है या system से टकरा जाता है
users ज़्यादा होने की वजह से जितनी समस्याएँ आ सकती थीं, लगभग सब झेल चुके हैं, और कल फिर कोई नई समस्या आ सकती है
फिर भी Tailscale और उसके vision पर भरोसा है। hardware का control देते हुए cost घटाने और security बढ़ाने का यह बिल्कुल नया approach है
पहला बड़ा production server एक 4-core Linux laptop था
मैं भी internal self-hosting के लिए Tailscale अच्छे से इस्तेमाल करता हूँ, लेकिन public production service के लिए इस्तेमाल करने के बारे में नहीं सोचा था, इसलिए setup जानना चाहता हूँ
Tailscale पसंद है, लेकिन यह लेख डरावना लगता है
internet इसलिए सफल हुआ क्योंकि यह standards पर बना था और पूरी तरह खुला था
Tailscale में WireGuard open source है और Headscale जैसी चीज़ें भी हैं, लेकिन “सबके पास IP हो” वाली संरचना क्या इस बात पर निर्भर नहीं करती कि Tailscale एक बहुत बड़ा IP address space own करे?
अगर हमें पूरी तरह IPv6 adoption का इंतज़ार करना पड़े, या centralized IPv4, servers और proprietary चीज़ों पर निर्भर रहना पड़े, तो यह थोड़ा पाखंडी लगता है
यह Tailscale के साथ पूरी feature parity नहीं रखता, लेकिन अभी ज़्यादातर features support करता है और रोज़ बेहतर हो रहा है
अगर मुझे सही याद है, तो core developers में से एक Tailscale से भुगतान लेकर इस पर काम करता है
मैं इसे अपनी personal self-hosted infrastructure में इस्तेमाल कर रहा हूँ और यह बहुत अच्छी तरह चलता है। custom control server URL set करना भी Windows और Android पर अपेक्षाकृत आसान था
taildrop भी इस्तेमाल करता हूँ, Docker containers को tailnet में उपलब्ध कराता हूँ, आदि; Headscale काफी अच्छे से काम करता है, इसलिए इसे आज़माने लायक है
जितना IP space चाहिए, वह सबसे बड़े moat जितना ही है, और एक समय में केवल एक moat से connect हो सकते हैं
Tailscale पसंद है, लेकिन यह लेख बहुत self-congratulatory लगता है
यह अतिरिक्त services के साथ mesh VPN product है, और अपने आप में शानदार है, लेकिन यह कोई नया या unique idea नहीं है
यह solution दूसरे alternatives के बजाय new internet क्यों होना चाहिए?
किसी भी हाल में मैं पूरी internet infrastructure के लिए एक company पर depend नहीं करना चाहता। इसलिए भले ही complex हो, traditional internet का इस्तेमाल जारी रखूँगा
बड़ी समस्याएँ technology से ज़्यादा social हैं, और नई technology उन्हें solve नहीं कर पाएगी
social media को example मानें, तो एक ऐसी दुनिया की कल्पना की जा सकती है जहाँ Facebook/Twitter/TikTok/YouTube/Reddit/HN वगैरह BitTorrent की तरह seamless तरीके से काम करें
मेरे computer पर app “Facebook” network में participate करे, friends अपने-अपने app instances के जरिए देखें कि मैं online हूँ, और feed व wall सीधे मेरी device से serve हों
यह central server के बिना 2 लोगों, 1000 लोगों या करोड़ों लोगों के सीधे communicate करने की संरचना है
BitTorrent, Soulseek, Bitcoin आदि कई peer-to-peer networks पहले ही संभावना दिखा चुके हैं
लेकिन इसे facebook.com पर जाने जितना seamless बनाने के लिए हर तरह की technical problems सामने आ जाती हैं। port forwarding, dynamic DNS, advanced network/security/system administration knowledge के बिना होने वाला seamless peer-to-peer connection पहली बड़ी बाधा है
node offline हो तो क्या करें, feed लाने के लिए जब हजारों/लाखों/करोड़ों machines से connect करना पड़े तो latency और load क्या होंगे, cache कैसे करेंगे, updates और notifications कैसे push करेंगे, बहुत पुराने nodes आपस में कैसे communicate करेंगे, data कहाँ store होगा, discoverability और security कैसे होंगे—ये सब technical problems हैं
इनमें से ज़्यादातर solve किए जा सकते हैं, लेकिन centralized service जैसी बेहद आसान experience तक पहुँचने के लिए problems को एक-एक करके solve करने की भारी मेहनत चाहिए
Fediverse भी इस problem के एक छोटे हिस्से को 10 साल से ज़्यादा समय से solve कर रहा है, लेकिन अभी भी twitter.com जैसा या उससे थोड़ा खराब experience देने के लिए काफी सक्षम system administrator चाहिए
क्या Yggdrasil ही नया internet बनने वाला नहीं था? https://yggdrasil-network.github.io
अगर नहीं, तो खास तौर पर Tailscale ही क्यों, Netbird, Nebula, Netmaker या कोई और competitor क्यों नहीं?
लेख बहुत अच्छी तरह लिखा है, लेकिन इससे अजीब-सा एहसास होता है कि acquisition, transition, spin-off या shutdown जैसा कुछ आने वाला है। “यह तो बस शुरुआत है” वाली बात भी मशहूर आखिरी शब्दों जैसी लगती है
balance के लिए जोड़ दूँ कि Tailscale user के तौर पर मैं संतुष्ट हूँ, और इस बात से प्रभावित हूँ कि ज़्यादा ध्यान दिए बिना यह बस काम करता रहता है
हालांकि यह अच्छी तरह काम करता है, फिर भी यह अभी research project है—यह बात ध्यान में रखनी चाहिए
Tailscale सेवा का मैं सच में आनंद लेता हूँ और आभारी होकर इस्तेमाल करता हूँ, लेकिन यह लेख मुझसे जुड़ नहीं पाया
प्रेरित करने वाले CEO की rallying speech भी मुझे पसंद है, और मैं मानता हूँ कि computing में developer friction और complexity बेहिसाब है, लेकिन Tailscale की अपनी friction भी है और यह बड़े-picture वाली समस्या को हल करने की दिशा में बिल्कुल नहीं जा रहा
कुछ हफ्ते पहले मैंने अपने पिता को अपने tailnet में invite किया था ताकि remote desktop से उनके computer की समस्या ठीक कर सकूँ। उन्होंने invitation accept किया और TS domain web interface में device दिख रही थी, लेकिन ping नहीं हो रहा था
अब मेरे पिता Tailscale से नफरत करते हैं, और क्योंकि मैंने उन्हें बताया था कि यह कितना बढ़िया है, मेरी credibility भी घट गई। उनकी नजर में यह समय की बर्बादी थी और ऐसी चीज थी जो “ठीक से काम नहीं करती”
यह काफी counterintuitive है। organization feature उस काम के लिए नहीं है; इसके बजाय हर व्यक्ति को अपना tailnet बनाकर उन्हें आपस में connect करना चाहिए
संदर्भ: https://github.com/tailscale/tailscale/issues/10731
इस use case के लिए TeamViewer, AnyDesk जैसे tools सही हैं
मेरे हिसाब से लेखक ने समस्या का diagnosis गलत किया है, और सुझाया गया solution centralization को हटाने के बजाय सिर्फ छिपाता है
AWS महंगा इसलिए नहीं है कि IPv4 या datacenter महंगे हैं, बल्कि मुख्य रूप से software, managed services और servers को जल्दी add करने की क्षमता की वजह से है
अगर कोई “serious company” AWS या वैसी ही company को पैसे नहीं देना चाहती, तो rack rent करना और अपने servers को colocation में रखना संभव है, और कई companies सच में ऐसा करती हैं
मैं इससे सहमत नहीं कि certificates ने centralization पैदा की। certificates लोगों को haves और have-nots में नहीं बांटते, और न ही इसे mainframe ownership से तुलना की जा सकती है
HTTPS के practically अनिवार्य हो जाने की वजह से लोग अपने domain या subdomain रखने लगे, ऐसा नहीं है; सुविधा के कारण वे पहले से ही ऐसा कर रहे थे
centralization का एक और point DNS है, लेकिन Tailscale DNS से बिल्कुल नहीं बचता। MagicDNS भी ICANN root पर निर्भर है, और Tailscale control plane भी ऐसा ही है
अगर बस free subdomain चाहिए, तो ऐसे कई providers हैं
अगर आप CGNAT के पीछे हैं, तो tailnet भी खास तौर पर कम centralized नहीं है, क्योंकि traffic को DERP servers से होकर गुजरना पड़ता है
जब traffic scale Gbps नहीं बल्कि Tbps हो जाएगा, तो संदेह है कि Tailscale इसे free में लगातार provide कर पाएगा
मैं मानता हूँ कि Tailscale-जैसे solutions NAT के पीछे computers तक access करने वाले बचे हुए आखिरी मामलों में मददगार हैं, और यह करोड़ों users तक भी जा सकता है
लेकिन सिर्फ इसी आधार पर नए इंटरनेट का दावा करना काफी नहीं है
लेख में भी बताया गया है कि यह assumption गलत है
ऐसे ideas जाहिर है नए नहीं हैं
IPv6 का मकसद सभी को end-to-end connectivity देना था, और मूल रूप से IPsec IPv6 का आवश्यक component था ताकि हर internet host को cryptographic identity दी जा सके
IPv6 और WireGuard को साथ इस्तेमाल करने पर privacy, security और performance मिल सकते हैं। downside configuration complexity है
Tailscale दिग्गजों के कंधों पर खड़ा है। IPv4, WireGuard, Samy Kamkar की NAT punching, OpenSSH और शायद और भी बहुत कुछ
इसका फायदा यह है कि इसने इन्हें combine किया है और management interface आम तौर पर आसान है
हालांकि certificate authorities के बारे में कही गई बात Tailscale पर भी लागू होती है। दोनों free open source software का इस्तेमाल करके आखिरकार proprietary service provide करते हैं
फिर भी लगभग सब कुछ free open source पर बना है, Headscale भी है, और Tailscale इसे ठीक मानता है, इसलिए यह कोई बड़ी समस्या नहीं है
यह downside तो है, लेकिन मुख्य downside नहीं; practically vendor lock-in भी लगभग नहीं है। business और support के नजरिए से यह उल्टा advantage भी हो सकता है
लेख का premise आखिरी paragraph तक सच में अच्छा था, लेकिन वहीं मुझे दोबारा पढ़ना पड़ा
Tailscale इंटरनेट को फिर से आसान बना देता है, यह सही है, लेकिन फिर भी आपको landlord पर निर्भर रहना पड़ता है
इंटरनेट पर इसकी जरूरत नहीं थी और आज भी जरूरी नहीं है। भले ही बहुत कुछ centralized हो गया हो, आज भी केवल एक link से दुनिया के किसी भी server से connect किया जा सकता है
counterargument है, जैसा दूसरी जगह भी कहा गया है, Headscale self-hosting: https://github.com/juanfont/headscale
बस कुछ settings बदलने पर यह default Tailscale client के साथ काम करता है, और मैं खुद इसे इस्तेमाल कर रहा हूँ