आपका डिक्टेशन यूँ ही ग़ायब नहीं होना चाहिए

नब्बे सेकंड ठीक-वैसा-जैसा-मैं-कहना-चाहता-था — एक पूरा PR विवरण, किसी क्लाइंट को सोच-समझकर दिया जवाब — और फिर insertion के ऐन मौक़े पर कोई छोटी-सी चीज़ बिगड़ जाती है। मंज़िल वाली window focus में नहीं थी। Paste टिका नहीं। ऐप ने हिचकी ले ली। और text बस ग़ायब है। कहीं सहेजा हुआ नहीं। किसी buffer में पड़ा हुआ नहीं। ग़ायब। जो भी डिक्टेशन pipeline insertion को transcript की इकलौती प्रति मानती है, उसमें यह नाकामी मौजूद है।

इसके बाद जो आता है वह एक ख़ास, बेतहाशा क़िस्म का ग़ुस्सा है, और मुझे लगता है वह जायज़ है। बात खोए हुए सेकंडों की नहीं है। बात यह है कि काम आपने किया — आपने ख़याल गढ़ा, आपने उसे अच्छी तरह कहा, मशीन ने तो उसे सही transcribe भी कर लिया — और टूल ने डिलीवरी की एक दिक़्क़त पर पूरा नतीजा ही नष्ट कर दिया। दूसरा take कभी पहले जैसा नहीं होता। जिसने भी कभी याददाश्त से कोई पैराग्राफ़ दोबारा डिक्टेट किया है वह जानता है कि आप उसे दोहराते नहीं; आप उसका एक फीका चचेरा भाई बनाते हैं।

मैंने ख़ुद इस तरह डिक्टेशन खोए हैं, दूसरे टूल्स में, Keebye के होने से पहले। यह उन छोटे आपातकालों में से एक है जिनके इर्द-गिर्द यह ऐप बना।

डिक्टेट किया हुआ text यूँ ही ग़ायब क्यों हो जाता है?

यह किसी एक vendor का बग नहीं है। यह category-स्तर का design फ़ैसला है, और यह समझने लायक़ है कि category ने वह फ़ैसला क्यों किया।

डिक्टेशन ऐप एक पाइप है, editor नहीं। Speech एक सिरे से जाती है; text दूसरे सिरे से निकलकर किसी और की window में जाता है — कोई terminal, कोई Slack बॉक्स, कोई Google Doc। उसका अपना कोई document नहीं होता, और ठीक यही इन टूल्स को अदृश्य और तेज़ बनाता है। पर इसका मतलब है कि transcript अक्सर ठीक एक ही पल के लिए मौजूद होता है: insert का पल। और insert पूरी pipeline का सबसे नाज़ुक क़दम है। वह इस पर निर्भर है कि डिलीवरी के मिलीसेकंड पर किस window का focus है, इस पर कि clipboard के साथ कोई दूसरा ऐप दौड़ नहीं लगा रहा, इस पर कि accessibility की अनुमतियाँ मूड में हैं, और इस पर कि मंज़िल वाला application बनावटी इनपुट स्वीकार करता भी है या नहीं। जब इसमें से कुछ भी नाकाम होता है, तो एक ख़ालिस पाइप के पीछे कुछ नहीं होता। पानी फ़र्श पर है।

टूल्स के प्रतियाँ रखने से हिचकने की एक उसूली वजह भी है: आपने जो कुछ डिक्टेट किया उसका पूरा लेखा संवेदनशील होता है। आपके डिक्टेशन आपके मैसेज हैं, आपके prompts हैं, आपके आधे-बने फ़ैसले हैं। जो vendor उन्हें सहेजता है — ख़ासकर किसी cloud के आसपास कहीं — वह एक ज़िम्मेदारी खड़ी कर लेता है, और उससे बचने का आसान रास्ता है कुछ भी न रखना। Users को वह सावधानी क्षणभंगुरता के रूप में मिलती है: vendor की नज़र से सबसे सुरक्षित डिक्टेशन वही है जो कभी था ही नहीं।

तर्क मैं समझता हूँ। मुझे बस लगता है कि वह ग़लत पक्ष के हक़ में optimize करता है। लोकल हिस्ट्री रखने की नाकामी आपकी अपनी डिस्क पर एक फ़ाइल है। कुछ न रखने की नाकामी यह है कि किसी window का focus हटते ही आपका काम भाप बन जाए।

Keebye क्या रखता है, और कहाँ

तो Keebye एक हिस्ट्री रखता है, डिफ़ॉल्ट रूप से चालू, और इसका ठीक-ठीक मतलब यह है — न इससे ज़्यादा, न कम।

हिस्ट्री चालू होने पर हर पूरा हुआ डिक्टेशन आपके Mac पर एक लोकल SQLite database में लिख दिया जाता है (rusqlite, WAL mode, उनके लिए जिन्हें भीतरी बनावट की परवाह है)। फ़ाइल app-support डायरेक्टरी में रहती है — com.keebye.app/keebye.db — और वह कभी मशीन से बाहर नहीं जाती। कोई sync नहीं, कोई upload नहीं, कोई अकाउंट नहीं जिससे वह जुड़ी हो। वह एक फ़ाइल है, आपकी डिस्क पर, आपकी अपनी।

Recovery उन्हीं दो तरीक़ों के इर्द-गिर्द design की गई है जिनसे आप सचमुच text खोते हैं। आम मामला — insert अभी-अभी, एक सेकंड पहले नाकाम हुआ — का सबसे तेज़ रास्ता है: tray menu में Copy Last Dictation नाम की एक चीज़ है। उस पर क्लिक करें, आपका सबसे हालिया डिक्टेशन clipboard पर आ जाता है, उसे वहाँ paste करें जहाँ उसे जाना था, और आगे बढ़ें। दुर्लभ मामला — “मैंने मंगलवार को कुछ डिक्टेट किया था और मुझे वह वापस चाहिए” — Dictation History… से होकर जाता है, एक ऐसी window जिसमें पूरी सूची है: खोजी जा सकने वाली, हर entry को अलग से डिलीट करने की सुविधा और तब के लिए एक clear-all जब आप स्लेट पूरी पोंछना चाहें।

Retention 30 दिन की है, अपने-आप लागू होती हुई। छँटाई तब चलती है जब database खुलता है और हर insert के बाद फिर से, इसलिए खिड़की सचमुच 30 दिन की है, “30 दिन, क़रीब-क़रीब, जब हमें फ़ुर्सत मिले” वाली नहीं। और अगर आपको पुराना क्षणभंगुर व्यवहार चाहिए — कुछ लोगों को चाहिए ही, और मैं बताऊँगा किन्हें — तो हिस्ट्री एक setting है (history_enabled), और उसे बंद करने का मतलब है कि कुछ भी लिखा ही नहीं जाता।

सिर्फ़ text। ऑडियो कभी नहीं।

जिस बात की मुझे सबसे ज़्यादा परवाह है वह यह है कि यह हिस्ट्री क्या नहीं है। यह सिर्फ़ text है। Keebye की हिस्ट्री schema में ऑडियो का कोई column ही नहीं है — बंद पर सेट कोई ऑडियो-रखने वाली setting नहीं, column ही नहीं। रिकॉर्डिंग्स ख़ुद कभी सहेजी नहीं जातीं। यह ढाँचागत है, design से: “Andrei को जवाब दो कि migration एक हफ़्ता खिसक रहा है” का transcript ही काफ़ी संवेदनशील है; उसे कहती हुई आपकी आवाज़ की ध्वनि, समय की मुहर के साथ, बिलकुल दूसरी क़िस्म की चीज़ है, और मैं नहीं चाहता था कि ऐप उसे जमा करने के क़ाबिल भी हो।

एक और बारीकी, जो अपने शब्दों की गिनती से ज़्यादा मायने रखती है: अगर आप किसी secure field में डिक्टेट करते हैं — password जैसा कोई input — तो हिस्ट्री उसे दर्ज नहीं करती। जिस इकलौती जगह पर text का निशान भी ग़लत है, वही इकलौती जगह है जहाँ हम कोई निशान नहीं रखते।

यह वही मुद्रा है जो बाक़ी ऐप की है — speech-to-text on-device चलता है, जिस पर हमने अपनी भाषा में डिक्टेट करने के संदर्भ में लिखा है — पर हिस्ट्री वही जगह है जहाँ यह मुद्रा परखी जाती है, क्योंकि हिस्ट्री ही इकलौती जगह है जहाँ Keebye आपके शब्दों को टिकाकर रखता है। लोकल, सिर्फ़-text, ख़ुद मिट जाने वाली — यही वह शक्ल लगी जो डिफ़ॉल्ट-चालू होने का हक़ कमाती है।

ईमानदार सीमाएँ

ईमानदारी वाला हिस्सा, हमेशा की तरह।

आप दोबारा सुन नहीं सकते। सिर्फ़-text की धार दोनों तरफ़ चलती है। अगर ट्रांसक्रिप्शन ग़लत था — मॉडल ने कोई नाम ग़लत सुना, कोई नंबर बिगाड़ दिया — तो हिस्ट्री वफ़ादारी से वही ग़लत text बचा लेती है, और वह ऑडियो जो बहस निपटा सकता था, design से ही जा चुका है। ज़्यादातर recovery मामलों में इससे फ़र्क़ नहीं पड़ता; नाकामी insert में थी, transcript में नहीं। पर अगर आप डिक्टेशन हिस्ट्री को voice-memo का संग्रह मानकर चाहते थे, तो यह वह नहीं है, जान-बूझकर।

तीस दिन तीस दिन ही हैं। हिस्ट्री सुरक्षा जाल है, संग्रह नहीं। अगर कोई डिक्टेशन एक महीने से आगे भी मायने रखता है, तो उसका घर वह document है जिसमें आपने उसे डिक्टेट किया, ऐप का database नहीं। छँटाई पूछती नहीं।

सिर्फ़-लोकल का मतलब सिर्फ़-लोकल। आपकी हिस्ट्री मशीनों के आर-पार आपके पीछे नहीं आती। जो डिक्टेशन आपने desktop पर किया वह laptop से वापस नहीं मिलेगा। मैं इसे प्राइवेसी फ़ीचर की तरह पेश कर रहा हूँ, और यह है भी — कुछ sync नहीं होता क्योंकि कुछ भेजा ही नहीं जाता — पर मैं यह दिखावा नहीं करूँगा कि यह एक सीमा भी नहीं है। यह दोनों है। इस पर भरोसा करने से पहले आपको पता होना चाहिए कि आपके लिए यह कौन-सी है।

और सरहद वाला मामला: अगर आप वह इंसान हैं जिसके threat model में कोई निशान बिलकुल नहीं लिखा है, तो हिस्ट्री बंद कर दें। यह एक setting है, और ऐप उसका पूरा लिहाज़ करता है। ज़्यादातर users के लिए डिफ़ॉल्ट-चालू सही फ़ैसला है, जो पिछले मंगलवार का पैराग्राफ़ वापस पाना पसंद करेंगे; बाक़ियों के लिए वह जाल नहीं बनना चाहिए।

काम में कोई एक अकेली नाकामी की जगह नहीं होनी चाहिए

यह फ़ीचर मौजूद होने की गहरी वजह: मैं अपना दिन पैरलल lanes की तरह चलाता हूँ — कुछ windows में agents बना रहे हैं, दूसरों में इंसान इंतज़ार कर रहे हैं — और आवाज़ वही channel है जो उन सबको खिलाता है। वह workflow अपनी आवाज़ से Claude Code चलाना की पूरी बुनियाद है। जो channel कभी-कभी अपना ही सामान नष्ट कर देता है, उस पर आप कार्यदिवस नहीं खड़ा करते। Developers recovery के रास्तों की उम्मीद करते हैं — undo, logs, reflogs, कूड़ेदान — फिर भी बहुत सारे डिक्टेशन प्रवाह insertion नाकाम होने पर इसके बराबर कुछ नहीं देते।

अगर आप इस category में टूल तौल रहे हैं, तो हमारी तुलनाएँ इस बारे में भी ईमानदार हैं कि दूसरे कहाँ चमकते हैं: Keebye vs Superwhisper और Keebye vs Wispr Flow। और ग़ायब होते text की एक सगी शिकायत भी है — mic के जागने से पहले आपके डिक्टेशन का पहला शब्द खा लिया जाना — जिस पर हमने डिक्टेशन ऐप्स आपका पहला शब्द क्यों खा जाते हैं में लिखा है।

Keebye macOS के लिए अर्ली ऐक्सेस में है। नीचे अपना फ़्री ट्रायल शुरू करें, एक पैराग्राफ़ डिक्टेट करें, जान-बूझकर मंज़िल वाली window चूक जाएँ, फिर text वापस पाने के लिए Copy Last Dictation इस्तेमाल करें। ग़लत focus अब भी एक recovery क़दम का ख़र्च लेता है; उसे अब उस ख़याल का ख़र्च नहीं लेना पड़ता।