अगर आप अपने ही प्रोजेक्ट की security मजबूत करने को कहें, तब भी उस बेकार safety guardrail की वजह से वह रोक देता है.
मुझे लगता है कि इस हालत में इसे लॉन्च करना बस stock listing के लिए किया गया एक तकनीकी दिखावा भर है.
इस प्रोजेक्ट की रिलीज़ से ठीक पहले का एक दिन ठीक वैसा ही था जैसा सहयोग का तरीका यह टूल लक्ष्य करता है। मैंने एजेंट के साथ यह डिज़ाइन चर्चा की कि "memory classification में tag सही है या नहीं, जबकि दिमाग में तो tag नहीं होते", फिर सहमति GitHub Discussions और issues में स्थायी रूप से दर्ज हुई, implementation PR merge हुआ, और यहाँ तक भी verify किया कि एजेंट ने खुद को ही (claude -p) extractor की तरह इस्तेमाल करके वास्तविक work logs को long-term memory में integrate किया — यानी dogfooding तक देखने के बाद मैंने deploy बटन दबाया। उस प्रक्रिया के डिज़ाइन विवाद repository Discussions में सभी के लिए खुले हैं.
मुख्य लेख में जो नहीं लिखा, उसमें सबसे ज़्यादा पूछा जाने वाला सवाल शायद यह होगा कि "क्या यह धीमा नहीं होगा या extra cost नहीं आएगी?" उसका जवाब पहले ही दे दूँ — काम के दौरान LLM बिल्कुल भी मदद नहीं करता। Capture नियम-आधारित filter है, इसलिए महसूस होने वाली latency 0 है, और LLM केवल session boundary पर एक बार integration के लिए चलता है; वह भी अलग background process में, इसलिए एजेंट को 1 सेकंड के लिए भी block नहीं करता। यहाँ तक कि वह call भी आपके पहले से इस्तेमाल हो रहे claude/codex subscription से ही जाती है, इसलिए अलग API billing नहीं होती। आज के dogfooding के आधार पर, एक session के 44 observations एक background call (लगभग 30 सेकंड) में integrate हुए, और session start injection भी 4,000-character budget के भीतर का text है, इसलिए token load लगभग नहीं के बराबर है। लक्ष्य यह था कि आप इसे install करें और फिर भूल जाएँ।
रिलीज़ से पहले real-device verification में पकड़ी गई चीज़ों में से एक ही साझा करूँ — README में verification command npx memorize दी हुई थी, लेकिन npm में बिना scope वाला memorize किसी और का package निकला। इस तरह की चीज़ें, जो "सिर्फ real device पर ही दिखती हैं", और भी हो सकती हैं, इसलिए ऐसी reports वाकई बहुत मूल्यवान हैं।
अनुरोध: Windows और WSL/Linux पर मैंने सीधे real-device verification किया है, लेकिन मेरे पास macOS की real machine नहीं है। CI में macOS test suite पूरी तरह pass हो रही है, लेकिन one-line install → hook → session start injection तक का full cycle मैं real device पर नहीं चला पाया। अगर macOS इस्तेमाल करने वाले आपमें से कोई एक भी इसे install करके बता दे कि यह चलता है या टूटता है, comment या issue में, तो बहुत मदद होगी।
डिज़ाइन से जुड़े सवाल भी स्वागत योग्य हैं (जैसे embedding को decision में क्यों नहीं इस्तेमाल करते, deletion क्यों नहीं है, clock के बिना cross-machine convergence कैसे होता है) — मैं सबका जवाब दूँगा।
कहा तो जा रहा है कि नियमों के मुताबिक हर साल audit हो रहा है, लेकिन WebTrust certification साइट तो 2023 पर ही अटकी हुई दिखती है.
मुझे शक है कि 2024 और 2025 में audit ठीक से हुआ भी है या नहीं. https://www.gpki.go.kr/pds/WebTrustAction.action
CPS दस्तावेज़ में भी इसी तरह की बातें हैं, जैसे ऐसा प्रावधान कि उसे कभी भी बार-बार बदला जा सकता है,
या फिर यह लिख देना कि कानून का पालन करने के कारण दस्तावेज़ के स्तर पर उनकी कोई ज़िम्मेदारी नहीं है.
कई बातें कुछ अस्पष्ट-सी लगती हैं, इसलिए भले ही अतीत की सारी बातों को नज़रअंदाज़ कर दें, इसकी विश्वसनीयता फिर भी कम लगती है.
मैंने Bugzilla पर अपनी निजी राय लिखी थी, लेकिन लगता है कि अभी मंज़िल काफी दूर है.
CRL/OCSP के मामले में तो ऐसा होना चाहिए कि कई सेवाएँ कभी भी इन्हें जाँच सकें,
लेकिन विदेशी IP से कई बार कनेक्शन की कोशिश करनी पड़े तभी कनेक्शन बनता है — ऐसा एक bug दिख रहा है.
लगता है शायद firewall या WAF में समस्या हो रही है.
(दूसरे लोगों की टिप्पणियाँ देखें तो घरेलू IP पर भी कुछ ऐसा ही लगता है..)
मैंने पुरानी सामग्री से लेकर क्रम से सब पढ़ा, तो CA certificate का audit करने वाली संस्था वही है जिसने 2016-2017 में भी audit किया था..
अगर पहले ऐसी समस्या हुई थी, तो audit कंपनी को बहुत पहले बदल दिया जाना चाहिए था, लेकिन उसे वैसे ही बनाए रखना भी थोड़ा हैरान करने वाला है..
कई प्रयासों के बावजूद अंग्रेज़ी दस्तावेज़ों में छोटी-छोटी तार्किक गलतियाँ या टाइपो काफ़ी दिखते हैं,
और certificate खुद भी standard नियमों के अपडेट हो जाने के कारण नए सिरे से बनाए जाने की ज़रूरत लगती है.
(लगता है CPS दस्तावेज़ काफ़ी बार अपडेट किए जाते हैं, तो अगर इतने स्तर का अपडेट हो सकता है, तो certificate भी फिर से बनाए जा सकते हैं.)
ज़िम्मेदार सरकारी अधिकारियों को भी काफ़ी मेहनत करनी पड़ रही होगी,
लेकिन अतीत में एक बार गलती हो चुकी है, इसलिए आलोचना झेलना तो शायद टाला नहीं जा सकता.
लगता है आप इतने होशियार हैं कि सरकारी कर्मचारी बने बिना भी काम चला सकते हैं।
समर्थन करता हूँ
ऐसी बात लापरवाही से नहीं कहनी चाहिए।
सही है। इसलिए केवल वही बैंक संभव हैं जो quick inquiry को support करते हैं।
लगता है हर बैंक में अलग होता है, लेकिन यह Selenium से जमा बैलेंस-चेक साइट को क्रॉल करता हुआ लगता है।
वाह, कमाल है!
अगर आप अपने ही प्रोजेक्ट की security मजबूत करने को कहें, तब भी उस बेकार safety guardrail की वजह से वह रोक देता है.
मुझे लगता है कि इस हालत में इसे लॉन्च करना बस stock listing के लिए किया गया एक तकनीकी दिखावा भर है.
पोस्ट में असल में ज़रूरी लिंक ही नहीं है।
https://corp.tossinvest.com/ko/open-api यहाँ प्री-रजिस्ट्रेशन किया जा सकता है।
डॉक्यूमेंटेशन लिंक यहाँ है: https://developers.tossinvest.com/docs
लगता है कि इसे सिर्फ वही लोग इस्तेमाल कर सकते हैं जिन्होंने पहले से आवेदन किया था और जिन्हें मंज़ूरी मिल गई है।
लगता है हर दिन एक नया agent system आ रहा है.. क्या यह vibe coding का सकारात्मक असर है या दुष्प्रभाव?
नहीं, थोड़ा और महंगा भी होता तो चलता, बस limit थोड़ी और दे देते..
मैं इसे बनाने वाला हूँ।
इस प्रोजेक्ट की रिलीज़ से ठीक पहले का एक दिन ठीक वैसा ही था जैसा सहयोग का तरीका यह टूल लक्ष्य करता है। मैंने एजेंट के साथ यह डिज़ाइन चर्चा की कि "memory classification में tag सही है या नहीं, जबकि दिमाग में तो tag नहीं होते", फिर सहमति GitHub Discussions और issues में स्थायी रूप से दर्ज हुई, implementation PR merge हुआ, और यहाँ तक भी verify किया कि एजेंट ने खुद को ही (
claude -p) extractor की तरह इस्तेमाल करके वास्तविक work logs को long-term memory में integrate किया — यानी dogfooding तक देखने के बाद मैंने deploy बटन दबाया। उस प्रक्रिया के डिज़ाइन विवाद repository Discussions में सभी के लिए खुले हैं.मुख्य लेख में जो नहीं लिखा, उसमें सबसे ज़्यादा पूछा जाने वाला सवाल शायद यह होगा कि "क्या यह धीमा नहीं होगा या extra cost नहीं आएगी?" उसका जवाब पहले ही दे दूँ — काम के दौरान LLM बिल्कुल भी मदद नहीं करता। Capture नियम-आधारित filter है, इसलिए महसूस होने वाली latency 0 है, और LLM केवल session boundary पर एक बार integration के लिए चलता है; वह भी अलग background process में, इसलिए एजेंट को 1 सेकंड के लिए भी block नहीं करता। यहाँ तक कि वह call भी आपके पहले से इस्तेमाल हो रहे claude/codex subscription से ही जाती है, इसलिए अलग API billing नहीं होती। आज के dogfooding के आधार पर, एक session के 44 observations एक background call (लगभग 30 सेकंड) में integrate हुए, और session start injection भी 4,000-character budget के भीतर का text है, इसलिए token load लगभग नहीं के बराबर है। लक्ष्य यह था कि आप इसे install करें और फिर भूल जाएँ।
रिलीज़ से पहले real-device verification में पकड़ी गई चीज़ों में से एक ही साझा करूँ — README में verification command
npx memorizeदी हुई थी, लेकिन npm में बिना scope वालाmemorizeकिसी और का package निकला। इस तरह की चीज़ें, जो "सिर्फ real device पर ही दिखती हैं", और भी हो सकती हैं, इसलिए ऐसी reports वाकई बहुत मूल्यवान हैं।अनुरोध: Windows और WSL/Linux पर मैंने सीधे real-device verification किया है, लेकिन मेरे पास macOS की real machine नहीं है। CI में macOS test suite पूरी तरह pass हो रही है, लेकिन one-line install → hook → session start injection तक का full cycle मैं real device पर नहीं चला पाया। अगर macOS इस्तेमाल करने वाले आपमें से कोई एक भी इसे install करके बता दे कि यह चलता है या टूटता है, comment या issue में, तो बहुत मदद होगी।
डिज़ाइन से जुड़े सवाल भी स्वागत योग्य हैं (जैसे embedding को decision में क्यों नहीं इस्तेमाल करते, deletion क्यों नहीं है, clock के बिना cross-machine convergence कैसे होता है) — मैं सबका जवाब दूँगा।
Linear अच्छा है, लेकिन पुरानी कंपनियों को अपना डेटा या प्रोसेस बनाए रखना पड़ता है, इसलिए वे Jira पर ही बनी रहती हैं
पढ़ने के लिए और टिप्पणी छोड़ने के लिए बहुत-बहुत धन्यवाद!!! 🙇
कहा तो जा रहा है कि नियमों के मुताबिक हर साल audit हो रहा है, लेकिन WebTrust certification साइट तो 2023 पर ही अटकी हुई दिखती है.
मुझे शक है कि 2024 और 2025 में audit ठीक से हुआ भी है या नहीं.
https://www.gpki.go.kr/pds/WebTrustAction.action
CPS दस्तावेज़ में भी इसी तरह की बातें हैं, जैसे ऐसा प्रावधान कि उसे कभी भी बार-बार बदला जा सकता है,
या फिर यह लिख देना कि कानून का पालन करने के कारण दस्तावेज़ के स्तर पर उनकी कोई ज़िम्मेदारी नहीं है.
कई बातें कुछ अस्पष्ट-सी लगती हैं, इसलिए भले ही अतीत की सारी बातों को नज़रअंदाज़ कर दें, इसकी विश्वसनीयता फिर भी कम लगती है.
मैंने Bugzilla पर अपनी निजी राय लिखी थी, लेकिन लगता है कि अभी मंज़िल काफी दूर है.
CRL/OCSP के मामले में तो ऐसा होना चाहिए कि कई सेवाएँ कभी भी इन्हें जाँच सकें,
लेकिन विदेशी IP से कई बार कनेक्शन की कोशिश करनी पड़े तभी कनेक्शन बनता है — ऐसा एक bug दिख रहा है.
लगता है शायद firewall या WAF में समस्या हो रही है.
(दूसरे लोगों की टिप्पणियाँ देखें तो घरेलू IP पर भी कुछ ऐसा ही लगता है..)
मैंने पुरानी सामग्री से लेकर क्रम से सब पढ़ा, तो CA certificate का audit करने वाली संस्था वही है जिसने 2016-2017 में भी audit किया था..
अगर पहले ऐसी समस्या हुई थी, तो audit कंपनी को बहुत पहले बदल दिया जाना चाहिए था, लेकिन उसे वैसे ही बनाए रखना भी थोड़ा हैरान करने वाला है..
कई प्रयासों के बावजूद अंग्रेज़ी दस्तावेज़ों में छोटी-छोटी तार्किक गलतियाँ या टाइपो काफ़ी दिखते हैं,
और certificate खुद भी standard नियमों के अपडेट हो जाने के कारण नए सिरे से बनाए जाने की ज़रूरत लगती है.
(लगता है CPS दस्तावेज़ काफ़ी बार अपडेट किए जाते हैं, तो अगर इतने स्तर का अपडेट हो सकता है, तो certificate भी फिर से बनाए जा सकते हैं.)
ज़िम्मेदार सरकारी अधिकारियों को भी काफ़ी मेहनत करनी पड़ रही होगी,
लेकिन अतीत में एक बार गलती हो चुकी है, इसलिए आलोचना झेलना तो शायद टाला नहीं जा सकता.
लगता है कि Azure Functions से जुड़े Repo में समस्या आने की वजह से उन्हें निष्क्रिय किया गया था, इसलिए शायद वजह वह नहीं होगी। (संबंधित लिंक)
क्या इससे पर्याप्त प्रदर्शन मिल पाएगा?
इंट्यूशन भी ठीक लग रही है।
मानता हूँ..