मैं "ब्राउज़र में पहला नोड; एक कार्डानो USP" प्रस्ताव पर नहीं मतदान कर रहा हूँ। एक सीमित खजाने का उपयोग करने के लिए, बजट को वास्तविक परितंत्र विकास की आवश्यकताओं के आधार पर प्राथमिकता के अनुसार आवंटित किया जाना चाहिए। अगर यह प्रस्ताव पारित हो जाता है और एक नया TypeScript-आधारित ब्राउज़र नोड एक अन्य क्लाइंट इम्प्लीमेंटेशन के रूप में जोड़ दिया जाता है, तो यह स्वयं में एक सकारात्मक बात है, लेकिन मुझे ऐसा नहीं लगता कि यह परितंत्र विकास को रोकने वाली कोई मूलभूत समस्या का समाधान करता है। दूसरे शब्दों में, इसे पाना अच्छा होगा, लेकिन इस चक्र की प्राथमिकता स्तर पर यह आवश्यक नहीं है। 1. प्रस्ताव Cardano परितंत्र को हल करने की वास्तविक समस्या को प्रदर्शित नहीं करता। वर्तमान में Cardano dapp और वॉलेट परितंत्र Mesh, Lucid Evolution, Blockfrost, Maestro और Koios जैसे बुनियादी ढांचे पर स्थिरता से चल रहा है। पूर्ण-वैधीकरण वाले ब्राउज़र-आधारित नोड के अभाव से dApp निर्माताओं या उपयोगकर्ताओं को कोई वास्तविक समस्या नहीं हो रही है। इसके अलावा, IOG पहले से ही Mithril के माध्यम से हल्की पुष्टि का विकल्प प्रदान करता है। "≥3 वॉलेट/dApp समाकलन" का 12-महीने का स्वीकृति लक्ष्य भी प्रस्ताव स्वयं के माध्यम से माना जा रहा है कि बाज़ार की मांग बड़ी नहीं है। 2. खजाने की प्राथमिकता के लिए मजबूत मामला नहीं है। वर्तमान NCL-सीमित परिस्थिति में, ₳4.6M एक छोटी रकम नहीं है। क्लाइंट विविधता का लक्ष्य पहले से ही कई प्रोजेक्ट्स के माध्यम से पूरा हो रहा है, और "ब्राउज़र-आधारित TypeScript नोड" का इसके साथ अलग मूल्य स्पष्ट रूप से प्रस्तुत नहीं किया गया है। HLabs, इसी चक्र में Pebble और TypeScript टूलिंग के लिए ₹4.6M का पृथक्‍यन माँग कर रहा है, जिसका मतलब है कि अगर दोनों प्रस्ताव पारित होते हैं, तो एक ही टीम को 9.2M ₳ मिलेंगे। मुझे लगता है कि इस चक्र के लिए सबसे समझदारी से प्रयुक्त होने वाला खजाना, प्रोटोकॉल-स्तरीय बुनियादी सुविधाओं, पुष्टि प्रदर्शन के साथ मुख्य साधनों के संरक्षण, और सचमुच मांग साबित हुई builder कार्यों में संचलित होना है।