Bluesky ATProto ट्रेडमार्क्स
Bluesky द्वारा “AT Protocol” ट्रेडमार्क हासिल करने, कथित रूप से दूसरी कंपनी को समुदाय के उपयोग को सीमित करने से रोकने के लिए, ने AT Protocol ecosystem कितना decentralized है, इस पर फिर से scrutiny बढ़ा दी है। टिप्पणीकार इस बात पर बहस करते हैं कि PLC identity directory, प्रमुख relays, और dominant client app जैसे key components पर Bluesky का नियंत्रण नेटवर्क को, protocol की independent hosting और apps के लिए डिज़ाइन के बावजूद, प्रभावी रूप से centralized छोड़ देता है या नहीं। अन्य लोग alternative implementations, चल रहे IETF standardization work, और third-party infrastructure की ओर इशारा करते हैं, यह तर्क देते हुए कि governance और migration tools में सुधार होने पर ecosystem एक single corporate steward से आगे बढ़ सकता है।
ट्रेडमार्क की उत्पत्ति और उद्देश्य
- एक अन्य कंपनी (Atsign, Inc.) ने “ATPROTOCOL” के लिए आवेदन किया था और कथित तौर पर दूसरों द्वारा इसके उपयोग पर कानूनी कार्रवाई की धमकी दे रही थी।
- Bluesky ने इस चिह्न को इसलिए हासिल किया ताकि वह संस्था समुदाय के उपयोग को प्रतिबंधित न कर सके, और अब वह इसे अन्य परियोजनाओं को लाइसेंस पर देता है।
- कुछ लोग इसे एक व्यावहारिक रक्षात्मक कदम मानते हैं; अन्य लोग दीर्घकालिक नियंत्रण को लेकर चिंतित हैं, भले ही संकेत हों कि इसे बाद में किसी तटस्थ संगठन को स्थानांतरित किया जा सकता है।
शासन, PLC, और स्वतंत्रता
- ATProto को IETF कार्यसमूह के माध्यम से मानकीकृत किया जा रहा है; कुछ लोग शुरू में इस बारे में अनिश्चित थे कि क्या IETF या कार्यसमूह ट्रेडमार्क के मालिक हो सकते हैं।
- Bluesky एक public benefit corporation है, लेकिन टिप्पणीकारों का कहना है कि इससे उपयोगकर्ता-प्रथम निर्णयों की गारंटी नहीं मिलती।
- PLC पहचान निर्देशिका को अभी भी नियंत्रण के एक केंद्रीय बिंदु के रूप में देखा जाता है; इसे एक अलग शासन संगठन को सौंपना अब बहुत देर से किया गया कदम माना जा रहा है।
- यह चिंता है कि अमेरिकी प्रतिबंध या इसी तरह के दबाव पहचान-स्तर के deplatforming तक ले जा सकते हैं।
“Instances”, टोपोलॉजी, और केंद्रीकरण
- एक प्रमुख चर्चा इस बात पर बहस करती है कि क्या यह कहना सही है कि Bluesky “केवल व्यवहार्य instance” चलाता है।
- ATProto के समर्थक पक्ष का तर्क: Mastodon के अर्थ में कोई “instances” नहीं हैं; होस्टिंग (PDS), indexing/relays, और apps अलग-अलग हैं; कोई भी प्रत्येक हिस्से को चला सकता है, और कई स्वतंत्र stacks पहले से मौजूद हैं।
- आलोचकों का कहना है: व्यवहार में, अधिकांश डेटा और ट्रैफ़िक अभी भी Bluesky के infrastructure से होकर गुजरते हैं, इसलिए प्रभावी केंद्रीकरण अभी भी बहुत अधिक है।
Self-hosting, DIDs, और migration
- उपयोगकर्ता PDSs को self-host कर सकते हैं और PLC से बचने के लिए
did:webका उपयोग कर सकते हैं, लेकिन DIDs अपरिवर्तनीय हैं: आप अपनी graph खोए बिनाdid:plcसेdid:webपर migrate नहीं कर सकते। - इसे उन लोगों के लिए एक बड़ी सीमा माना जा रहा है जिन्होंने Bluesky की default setup पर शुरुआत की थी।
- PDS migration के लिए GUI tools बेहतर हुए हैं, लेकिन DID migration अभी भी अनसुलझी है।
Wsocial और rate limiting
- Wsocial के कठिन launch को केंद्रीय नियंत्रण के प्रमाण के रूप में उद्धृत किया जाता है: उनका traffic relay rate limits से टकराया और coordination के बिना वे प्रभावी रूप से भाग नहीं ले सके।
- अन्य लोग जवाब देते हैं कि rate limiting और operator coordination federated systems में सामान्य हैं (Mastodon और email से तुलना करते हुए) और कि अन्य relays और indexes भी मौजूद हैं।
ActivityPub और Nostr के साथ तुलना
- कुछ लोगों का तर्क है कि ActivityPub/Nostr अधिक सीधे तौर पर decentralized हैं और तैनात करने में आसान/सस्ते हैं।
- ATProto समर्थक जवाब देते हैं कि ATProto एक अलग समस्या-समूह को लक्षित करता है (उच्च-स्तरीय, साझा डेटा layer, app portability), “typed RSS” के करीब, और कि कई गैर-Bluesky apps और services पहले से ही इस stack पर चल रही हैं।
Legacy “AT protocol” भ्रम
- एक उप-चर्चा पुराने modem “AT command set” की ओर इशारा करती है, जिसे कभी-कभी अनौपचारिक रूप से “AT protocol” कहा जाता था, लेकिन अधिकांश लोग सहमत हैं कि यह व्यवहार में ट्रेडमार्क को प्रभावित नहीं करता।