ऐसे कई tools रहे हैं जो “मेरे ध्यान देने लायक चीज़” चुनकर देने का दावा करते थे, लेकिन मेरे या मेरी टीम के लिए कभी ठीक से काम नहीं किया। Struct में क्या अलग है, यह जानना चाहूंगा
Struct के landing page video को देखते हुए लिखे सवाल: channel threads/feed का शुरुआती point जैसा दिखता है; क्या यह बस users को group करने का concept है, या channel में chat भी हो सकती है? अगर structure ऐसा है कि user सिर्फ real-time feed में दिखने वाले threads ही देखते हैं, तो ऐसे threads जो activity में ज्यादा हैं लेकिन signal कम है, वे जगह घेरकर कम activity वाले लेकिन important threads को धकेल न दें—इसे कैसे handle किया जाता है? Tags filtering के लिए important हैं, लेकिन JIRA tags की तरह मिलते-जुलते मगर अलग text groups से जल्दी messy हो सकते हैं; क्या इन्हें manage करने का कोई तरीका है? अलग-अलग users ने एक ही topic पर independently बनाए threads को कैसे handle किया जाता है? 1:1 private conversations भी video में बहुत संक्षेप में दिखीं, उनके बारे में और जानना चाहूंगा। Tool में definitely potential दिखता है
Struct में channels सिर्फ लोगों के groups हैं, और जैसे आप किसी user को mention करते हैं, वैसे channel को mention करके thread access permission तय की जाती है
Channel में जाकर chat करने वाला structure नहीं है। Feed में हर thread की height fixed होती है, इसलिए ज्यादा active threads अनंत जगह नहीं खाते; threads को कुछ समय के लिए keep या mute करने की सुविधा जोड़ने की भी योजना है। Tags पर हर thread के लिए count limit है और वे context जोड़ने व custom feeds बनाने में इस्तेमाल होते हैं; task priority tracking में भी उनका उपयोग करके इसे हल्के work management system की तरह इस्तेमाल कर रहे हैं। Similar tags को merge करने दिया जाएगा, और नए tags बनाने की अनुमति सिर्फ moderators को देने जैसे controls भी संभव हैं। Similar threads merge किए जा सकते हैं, और thread के अंदर की कुछ chats चुनकर उन्हें नए thread में fork करने की सुविधा भी तैयार हो रही है; threads के बीच links बनाए रखे जाएंगे। Private conversation के लिए जिन users को चाहें mention कर सकते हैं; @struct को mention करने पर bot के साथ DM बनता है, और खुद को mention करने पर TODO या notes के लिए “self DM” बनता है। Chat platforms से भरे market में Struct “एक और chat app” जैसा लग सकता है, लेकिन जिन चीज़ों को दूसरे platforms को obvious रूप से करना चाहिए था, उन्हें सालों इंतजार करने के बाद भी उन्होंने नहीं किया, इसलिए हमें खुद बनाना पड़ा
समस्या यह है कि हर कोई चाहता है कि उसकी अपनी call filter न हो, लेकिन दूसरों की calls filter हो जाएं
अगर कोई मेरा attention चाहता है, तो वह नया thread बनाने जैसे तरीकों से लगातार attention छीनने का तरीका ढूंढ लेगा
पहली बार किसी Slack competitor ने मेरा ध्यान खींचा है, और लगता है direction सही पकड़ी है। Video देखकर overall impression positive है, लेकिन यह कुछ हद तक कम personal tool जैसा लगा
Slack rooms digital “rooms” जैसे महसूस होते थे, जबकि Struct office bulletin board जैसा एहसास देता है। अगर कोई company पूरी तरह Struct पर shift हो चुकी हो और मैं वहां new hire के तौर पर जॉइन करूं, तो colleagues के साथ personal connection बनाना शायद ज्यादा मुश्किल लगेगा—पहला impression यही था। वजह ठीक-ठीक नहीं पता, लेकिन demo देखते हुए ऐसा महसूस हुआ। पहले Silicon Valley में engineering leader के रूप में काम करते समय जो communication chaos झेला था, उसे देखते हुए लगता है कि मेरी पिछली company में ऐसा tool होता तो अच्छा होता
Founder के तौर पर Jason और मैं इस पहलू पर काफी सोच रहे हैं। Left panel में सबके names डालकर clutter बनाना है या same room में होने का feeling देना है—इसका balance मुश्किल है
Feed-based platforms आम तौर पर बहुत asynchronous और लगभग forum जैसे हो जाने की tendency रखते हैं। इसलिए Struct का real-time feed design “अभी इस room में ये लोग हैं, और इसी समय बात कर रहे हैं” वाले feeling पर जोर देने के लिए था। नया thread दिखना या नई chat का feed में appear होना काफी fun और interesting लगता है। Online users की list दिखाने से conversation शुरू करने का मन हो सकता है, और सिर्फ यह दिखाना भी मददगार हो सकता है कि दूसरे लोग participate कर रहे हैं। Conversations बेहतर शुरू हों, इसके लिए optimize करने की गुंजाइश निश्चित रूप से है
New hire onboarding के लिए हमेशा तैयार रहने वाले useful threads बनाए जा सकते हैं
फिर भी new hires को warm welcome महसूस कराना हर organization के लिए important है, और remote work ज्यादा करने वाली organizations में खास तौर पर। @random channel, @club-channels, @annoucements जैसी spaces बनाकर fun links या announcement-type material share करने और colleagues को जानने की जगह के रूप में इस्तेमाल किया जा सकता है। @struct के अंदर माहौल काफी work-focused है और हमें बनाना पसंद है, लेकिन fun भी लाना होगा
वाकई अच्छा है। Channels को बनाए रखते हुए focused threads इस्तेमाल करने का idea पसंद आया और design भी अच्छा है
हालांकि long-term plan जानना चाहूंगा। ऐसे service में बहुत data डालने से पहले यह जानना चाहता हूं कि इसे venture capital funding से बड़ा करके बेच देने और छोड़ देने वाला model नहीं है
Struct को चलते रखने का इरादा है। Backend, designer, frontend—इन 3 लोगों की छोटी team है, इसलिए यह capital-intensive product भी नहीं है
जिस roadmap की उम्मीद है उसमें voice/video calls और webinars, communities के लिए spam control, AI bots और recall features में सुधार व cost reduction, Struct में shared documents की indexing और access control बनाए रखते हुए AI answers शामिल हैं। Struct इसलिए interesting है क्योंकि यह team chat और community chat, work management system, ChatGPT, personal TODO list, और publicly indexable knowledge base—इन सबको एक साथ replace करता है। जब आप भरोसा कर सकते हैं कि system भूलता नहीं है, तो जो संभव होता है वह चौंकाने वाला है
promising लगता है। बस pricing display को फिर से refine कर दें तो अच्छा होगा
खुद calculate करना complex है, और चिंता है कि discussion अचानक explode हो जाए तो cost भी explode न हो जाए। Examples देकर table format में दिखाएं तो अच्छा होगा। Users को सोचने पर मजबूर न करें। Struct name में minimum 6 characters की limit भी समझ नहीं आई। 4 characters से ही काफी नहीं होगा? और 3 characters से ज्यादा वाले international standards भी अब नहीं बचे होंगे। साथ ही macOS app icon को दूसरे apps की तरह single-color बना दें तो अच्छा होगा
हमारे पास असल में इस्तेमाल कर रही organizations का data है। सीधे शब्दों में, Struct Slack से काफी सस्ता है
Monthly base fee $9.97 है, और users की संख्या, threads की संख्या या chats की संख्या पर नहीं, सिर्फ AI usage पर charge लगता है। Base price में 200k tokens शामिल हैं, जो छोटी organizations के लिए काफी है अगर usage सिर्फ thread titles और summaries generate करने तक है। Real users में Typesense का average usage करीब इतना ही है, और Apache Druid महीने में लगभग 400k tokens इस्तेमाल करता है। 1k tokens 3 cents हैं, इसलिए 200k tokens base fee के ऊपर $6 extra के बराबर हैं। दोनों Struct को knowledge base के रूप में इस्तेमाल कर रहे हैं। Billing enforce करना शुरू करते समय monthly spending limit set करने की सुविधा देंगे ताकि unexpected bill न आए, और base fee के बाद cost को आप जितना चाहें कम रख सकेंगे
उत्पाद के लिए बधाई। मेरी उम्र इतनी है कि पुराने forum के दिन याद हैं, और सच कहूँ तो यह forum को फिर से खोज लेने जैसा लगा
मेरा मतलब उस thread structure से है जो update आते ही ऊपर आ जाता है। बड़ा फर्क बस इतना लगा कि UI ज़्यादा chat/Facebook जैसा है, और forums में structure admins static तरीके से बनाते थे, जबकि Struct में कई topics साथ-साथ चलने वाले बड़े organizations के लिए ज़रूरी folder जैसी thread structuring साफ़ नहीं दिखी। दूसरी तरफ mail को कुछ हद तक “conversation” में group किया जा सकता है, और personal folders से भी structure किया जा सकता है। “AI” जुड़ा होना भी आजकल थका देने वाला लगता है। Threads की dynamic summary अपने-आप में meaningful है, लेकिन अगर thread chat जैसा simple है तो summary की ज़रूरत नहीं, और अगर mail/forum जैसा लंबा है तो यह सच में कितना अच्छा काम करेगा, इस पर भरोसा नहीं। इसलिए समझ नहीं आ रहा कि यह AI buzzword लगाया हुआ chat-style marketing app है, या मैं forum threads या email conversations से मूल रूप से अलग कोई चीज़ miss कर रहा हूँ
Struct ने Discourse से काफ़ी inspiration लिया है, और यह forum और chat application का एक अनोखा mix है
email समेत सभी forums में threads और feeds होते हैं, लेकिन forums asynchronous होते हैं और real-time chat को केंद्र में रखकर design नहीं किए गए। Thread और feed concepts को chat platform पर लागू करने में मुश्किल यह है कि उन्हें real-time बनाना पड़ता है, और Struct भी इसी हिस्से को solve करने की कोशिश कर रहा है। “chat है तो summary की ज़रूरत नहीं” वाली बात से मैं थोड़ा असहमत हूँ। मैंने अंतहीन conversations में काफ़ी हिस्सा लिया है, और छोटी teams में भी ऐसे threads होते हैं जिनमें सैकड़ों messages आते-जाते हैं। Summary सच में बहुत मदद करती है, और कम से कम title भर हो तो भी feed समझना बहुत आसान हो जाता है। Tags से threads को structure किया जा सकता है और उन्हीं tags के आधार पर feeds बनाई जा सकती हैं; यही folders के बराबर है। Gmail आने पर लोगों को labels को SMTP folders के equivalent समझना पड़ा था, वह याद आता है। Struct threads और Discourse threads में फर्क यह है कि Struct छोटे, real-time back-and-forth communication पर ज़ोर देता है, जबकि Discourse लंबे, सोच-समझकर लिखे गए one-off posts पर। पहला chat है और दूसरा forum। Struct design कठिन होने की वजह भी structure, knowledge और real-time nature के बीच balance है
Discord में थोड़े समय के लिए मौजूद AI summary feature काफ़ी मज़ेदार था
वह हमेशा discussion का core पूरी तरह miss कर देता था और बेतुकी summaries बनाता था, जिससे घंटों तक हँसने का material मिल जाता था
“CEO के threads से feed बनाकर company के latest vision और goals के साथ aligned रहें। सही reply देकर conversation में कूदें और deserved promotion पाएँ” वाली line ने कड़वी मुस्कान ला दी
आखिरकार फिर समझ आता है कि अहम यह नहीं कि आप क्या करते हैं, बल्कि कौन उसे देखता है
startup बनाते हुए management सीखने वाले engineer के तौर पर कहूँ तो, काम कीजिए, लेकिन यह भी सुनिश्चित कीजिए कि वह काम दिखे
मेरी पहली नौकरी Google में थी, जहाँ मैं बस बनाता ही रहा, और जो बना रहा था वह क्यों important है, यह communicate करने में struggle करता रहा। मेरे पहले manager ने मेरे अलावा पूरी team को promote कर दिया, और वह बात आज भी चुभती है। Team और manager बदलने पर पता चला कि मुझे जिस level पर होना चाहिए था उससे 2 levels नीचे evaluate किया जा रहा था। निष्कर्ष यही है कि ऐसी conversations में शामिल हों। ज़बरदस्ती दिखावा करने की ज़रूरत नहीं, लेकिन अपनी presence ज़रूर पता चलनी चाहिए
मुझे लगता है कि direct reports क्या कर रहे हैं, इसका updated पता रखना भी manager का काम नहीं है क्या
Employees को अपने boss के सामने खुद की marketing करने में समय लगाने के लिए encourage करना company के हित में भी नहीं है। ऐसा अक्सर दिखता है, लेकिन मुझे यह संकेत लगता है कि ज़्यादातर managers इस हिस्से में अपना काम ठीक से नहीं कर रहे
error message को थोड़ा clean करना पड़ेगा। OpenAI को छिपाने की कोशिश नहीं है, बस इसे देखने में बेहतर बनाना है
OpenAI मुझे पसंद है। GPT-4 सच में बहुत अच्छा काम करता है। कुछ सस्ते दूसरे models भी आज़माए, लेकिन quality उतनी अच्छी नहीं थी
कभी-कभी सोचता हूँ कि जब तक यह trend normal न हो जाए, router पर .ai domains block ही कर दूँ
गंभीरता से कहूँ तो, यह product “…और AI” वाली line देखने तक सच में interesting लग रहा था। शायद मैं target customer नहीं हूँ
Summary उन tasks में से एक है जिनमें AI सच में बहुत अच्छा है, इसलिए मुझे यह product बढ़िया लगता है
जानना चाहूँगा कि कौन-सी technology इस्तेमाल की गई है। क्या अंदर dgraph या badger इस्तेमाल हुआ है, hosting big 3 पर है या कहीं और, Kubernetes use होता है या नहीं, Elastic Search use होता है या नहीं। और यह भी कि Struct Slack/Discord को online scrape करने वाला tool है, या अभी/आगे चलकर standalone chat app बनना चाहता है
tech stack है Go, Postgres, OpenAI, React/Next.JS, Loops.so, Imgproxy, Microsoft E5 embeddings, Typesense search, Figma, Framer, Hetzner servers
सबसे बड़ा cost OpenAI से आता है, और embeddings के लिए OpenAI नहीं बल्कि Microsoft E5 इस्तेमाल होता है। Typesense search के लिए है और Struct का user भी है। Postgres के बजाय Badger इस्तेमाल करना सही fit नहीं था, लेकिन दूसरे use cases के लिए Badger पर विचार कर रहे हैं। Internally ristretto और roaring bitmaps का बहुत इस्तेमाल करते हैं। Struct का Slack के साथ काफ़ी अच्छा integration है, इसलिए इसे Slack interface की तरह इस्तेमाल किया जा सकता है। Colleagues Slack use करें और मैं Struct से reply करूँ—Gmail के लिए Superhuman जैसा feel। Discord integration भी अच्छा है, और दोनों का इस्तेमाल open source companies Slack/Discord conversations से public knowledge base बनाने के लिए कर रही हैं। [1]: https://github.com/struct-chat/embedding
कभी-कभी सोचता/सोचती हूँ कि कहीं हम productivity को गलत तरीके से optimize करने की कोशिश तो नहीं कर रहे। communication के शोर को manage करने वाले tools की बजाय, शुरुआत से ही communication कम रखते हुए भी जरूरी काम अच्छे से पूरा करने में शायद ज्यादा फायदा हो सकता है
उदाहरण के लिए, अगर दर्जनों meetings हों, तो मैं meeting notes को बेहतर track करने के लिए optimize नहीं करना चाहूँगा/चाहूँगी। मैं कम, लेकिन ज्यादा effective meetings चाहूँगा/चाहूँगी
पूरी तरह सहमत। industry “magic button” paradigm में फँसी हुई है, और AI तभी कमाल का काम करता है जब वह button दबाया जाए
अगर AI meeting transcript से automatic summary बना सकता है, तो next steps या action items तक follow-up न कर पाने की कोई वजह नहीं है। अगर next step यह है कि Janine, Carlos के साथ meeting schedule करे, तो AI Carlos से contact करके schedule तय करने में मदद क्यों नहीं कर सकता? लगता है अभी हम बहुत छोटे स्तर पर सोच रहे हैं
meetings कम करनी चाहिए, यह बात सही है। chat platforms या Loom जैसे tools का मकसद भी आखिरकार जरूरी meetings की संख्या कम करना ही लगता है
लेकिन Metcalfe's law से भी बचा नहीं जा सकता। आधुनिक कामकाज का ज्यादातर हिस्सा teams में होता है, और अगर team size N है, तो O(N^2) communication cost चुकानी पड़ती है। ऐसा नहीं लगता कि कुल communication घटेगा; उसे ज्यादा effectively handle करने के लिए सही tools चाहिए
शानदार। Discord information search करने और threads follow करने के लिए सबसे खराब है
ऐसा लगता है जैसे उसी सवाल का बार-बार जवाब दे रहा/रही हूँ
Discord भी आखिरकार large language model based search जोड़ देगा, जैसा Slack AI ने announce किया है, और तब वह समस्या खत्म हो जाएगी
यह product Discord की बजाय Slack या Teams को target करता हुआ लगता है
1 टिप्पणियां
Hacker News राय
ऐसे कई tools रहे हैं जो “मेरे ध्यान देने लायक चीज़” चुनकर देने का दावा करते थे, लेकिन मेरे या मेरी टीम के लिए कभी ठीक से काम नहीं किया। Struct में क्या अलग है, यह जानना चाहूंगा
Struct के landing page video को देखते हुए लिखे सवाल: channel threads/feed का शुरुआती point जैसा दिखता है; क्या यह बस users को group करने का concept है, या channel में chat भी हो सकती है? अगर structure ऐसा है कि user सिर्फ real-time feed में दिखने वाले threads ही देखते हैं, तो ऐसे threads जो activity में ज्यादा हैं लेकिन signal कम है, वे जगह घेरकर कम activity वाले लेकिन important threads को धकेल न दें—इसे कैसे handle किया जाता है? Tags filtering के लिए important हैं, लेकिन JIRA tags की तरह मिलते-जुलते मगर अलग text groups से जल्दी messy हो सकते हैं; क्या इन्हें manage करने का कोई तरीका है? अलग-अलग users ने एक ही topic पर independently बनाए threads को कैसे handle किया जाता है? 1:1 private conversations भी video में बहुत संक्षेप में दिखीं, उनके बारे में और जानना चाहूंगा। Tool में definitely potential दिखता है
Channel में जाकर chat करने वाला structure नहीं है। Feed में हर thread की height fixed होती है, इसलिए ज्यादा active threads अनंत जगह नहीं खाते; threads को कुछ समय के लिए keep या mute करने की सुविधा जोड़ने की भी योजना है। Tags पर हर thread के लिए count limit है और वे context जोड़ने व custom feeds बनाने में इस्तेमाल होते हैं; task priority tracking में भी उनका उपयोग करके इसे हल्के work management system की तरह इस्तेमाल कर रहे हैं। Similar tags को merge करने दिया जाएगा, और नए tags बनाने की अनुमति सिर्फ moderators को देने जैसे controls भी संभव हैं। Similar threads merge किए जा सकते हैं, और thread के अंदर की कुछ chats चुनकर उन्हें नए thread में fork करने की सुविधा भी तैयार हो रही है; threads के बीच links बनाए रखे जाएंगे। Private conversation के लिए जिन users को चाहें mention कर सकते हैं; @struct को mention करने पर bot के साथ DM बनता है, और खुद को mention करने पर TODO या notes के लिए “self DM” बनता है। Chat platforms से भरे market में Struct “एक और chat app” जैसा लग सकता है, लेकिन जिन चीज़ों को दूसरे platforms को obvious रूप से करना चाहिए था, उन्हें सालों इंतजार करने के बाद भी उन्होंने नहीं किया, इसलिए हमें खुद बनाना पड़ा
अगर कोई मेरा attention चाहता है, तो वह नया thread बनाने जैसे तरीकों से लगातार attention छीनने का तरीका ढूंढ लेगा
पहली बार किसी Slack competitor ने मेरा ध्यान खींचा है, और लगता है direction सही पकड़ी है। Video देखकर overall impression positive है, लेकिन यह कुछ हद तक कम personal tool जैसा लगा
Slack rooms digital “rooms” जैसे महसूस होते थे, जबकि Struct office bulletin board जैसा एहसास देता है। अगर कोई company पूरी तरह Struct पर shift हो चुकी हो और मैं वहां new hire के तौर पर जॉइन करूं, तो colleagues के साथ personal connection बनाना शायद ज्यादा मुश्किल लगेगा—पहला impression यही था। वजह ठीक-ठीक नहीं पता, लेकिन demo देखते हुए ऐसा महसूस हुआ। पहले Silicon Valley में engineering leader के रूप में काम करते समय जो communication chaos झेला था, उसे देखते हुए लगता है कि मेरी पिछली company में ऐसा tool होता तो अच्छा होता
Feed-based platforms आम तौर पर बहुत asynchronous और लगभग forum जैसे हो जाने की tendency रखते हैं। इसलिए Struct का real-time feed design “अभी इस room में ये लोग हैं, और इसी समय बात कर रहे हैं” वाले feeling पर जोर देने के लिए था। नया thread दिखना या नई chat का feed में appear होना काफी fun और interesting लगता है। Online users की list दिखाने से conversation शुरू करने का मन हो सकता है, और सिर्फ यह दिखाना भी मददगार हो सकता है कि दूसरे लोग participate कर रहे हैं। Conversations बेहतर शुरू हों, इसके लिए optimize करने की गुंजाइश निश्चित रूप से है
फिर भी new hires को warm welcome महसूस कराना हर organization के लिए important है, और remote work ज्यादा करने वाली organizations में खास तौर पर। @random channel, @club-channels, @annoucements जैसी spaces बनाकर fun links या announcement-type material share करने और colleagues को जानने की जगह के रूप में इस्तेमाल किया जा सकता है। @struct के अंदर माहौल काफी work-focused है और हमें बनाना पसंद है, लेकिन fun भी लाना होगा
वाकई अच्छा है। Channels को बनाए रखते हुए focused threads इस्तेमाल करने का idea पसंद आया और design भी अच्छा है
हालांकि long-term plan जानना चाहूंगा। ऐसे service में बहुत data डालने से पहले यह जानना चाहता हूं कि इसे venture capital funding से बड़ा करके बेच देने और छोड़ देने वाला model नहीं है
जिस roadmap की उम्मीद है उसमें voice/video calls और webinars, communities के लिए spam control, AI bots और recall features में सुधार व cost reduction, Struct में shared documents की indexing और access control बनाए रखते हुए AI answers शामिल हैं। Struct इसलिए interesting है क्योंकि यह team chat और community chat, work management system, ChatGPT, personal TODO list, और publicly indexable knowledge base—इन सबको एक साथ replace करता है। जब आप भरोसा कर सकते हैं कि system भूलता नहीं है, तो जो संभव होता है वह चौंकाने वाला है
promising लगता है। बस pricing display को फिर से refine कर दें तो अच्छा होगा
खुद calculate करना complex है, और चिंता है कि discussion अचानक explode हो जाए तो cost भी explode न हो जाए। Examples देकर table format में दिखाएं तो अच्छा होगा। Users को सोचने पर मजबूर न करें। Struct name में minimum 6 characters की limit भी समझ नहीं आई। 4 characters से ही काफी नहीं होगा? और 3 characters से ज्यादा वाले international standards भी अब नहीं बचे होंगे। साथ ही macOS app icon को दूसरे apps की तरह single-color बना दें तो अच्छा होगा
Monthly base fee $9.97 है, और users की संख्या, threads की संख्या या chats की संख्या पर नहीं, सिर्फ AI usage पर charge लगता है। Base price में 200k tokens शामिल हैं, जो छोटी organizations के लिए काफी है अगर usage सिर्फ thread titles और summaries generate करने तक है। Real users में Typesense का average usage करीब इतना ही है, और Apache Druid महीने में लगभग 400k tokens इस्तेमाल करता है। 1k tokens 3 cents हैं, इसलिए 200k tokens base fee के ऊपर $6 extra के बराबर हैं। दोनों Struct को knowledge base के रूप में इस्तेमाल कर रहे हैं। Billing enforce करना शुरू करते समय monthly spending limit set करने की सुविधा देंगे ताकि unexpected bill न आए, और base fee के बाद cost को आप जितना चाहें कम रख सकेंगे
उत्पाद के लिए बधाई। मेरी उम्र इतनी है कि पुराने forum के दिन याद हैं, और सच कहूँ तो यह forum को फिर से खोज लेने जैसा लगा
मेरा मतलब उस thread structure से है जो update आते ही ऊपर आ जाता है। बड़ा फर्क बस इतना लगा कि UI ज़्यादा chat/Facebook जैसा है, और forums में structure admins static तरीके से बनाते थे, जबकि Struct में कई topics साथ-साथ चलने वाले बड़े organizations के लिए ज़रूरी folder जैसी thread structuring साफ़ नहीं दिखी। दूसरी तरफ mail को कुछ हद तक “conversation” में group किया जा सकता है, और personal folders से भी structure किया जा सकता है। “AI” जुड़ा होना भी आजकल थका देने वाला लगता है। Threads की dynamic summary अपने-आप में meaningful है, लेकिन अगर thread chat जैसा simple है तो summary की ज़रूरत नहीं, और अगर mail/forum जैसा लंबा है तो यह सच में कितना अच्छा काम करेगा, इस पर भरोसा नहीं। इसलिए समझ नहीं आ रहा कि यह AI buzzword लगाया हुआ chat-style marketing app है, या मैं forum threads या email conversations से मूल रूप से अलग कोई चीज़ miss कर रहा हूँ
email समेत सभी forums में threads और feeds होते हैं, लेकिन forums asynchronous होते हैं और real-time chat को केंद्र में रखकर design नहीं किए गए। Thread और feed concepts को chat platform पर लागू करने में मुश्किल यह है कि उन्हें real-time बनाना पड़ता है, और Struct भी इसी हिस्से को solve करने की कोशिश कर रहा है। “chat है तो summary की ज़रूरत नहीं” वाली बात से मैं थोड़ा असहमत हूँ। मैंने अंतहीन conversations में काफ़ी हिस्सा लिया है, और छोटी teams में भी ऐसे threads होते हैं जिनमें सैकड़ों messages आते-जाते हैं। Summary सच में बहुत मदद करती है, और कम से कम title भर हो तो भी feed समझना बहुत आसान हो जाता है। Tags से threads को structure किया जा सकता है और उन्हीं tags के आधार पर feeds बनाई जा सकती हैं; यही folders के बराबर है। Gmail आने पर लोगों को labels को SMTP folders के equivalent समझना पड़ा था, वह याद आता है। Struct threads और Discourse threads में फर्क यह है कि Struct छोटे, real-time back-and-forth communication पर ज़ोर देता है, जबकि Discourse लंबे, सोच-समझकर लिखे गए one-off posts पर। पहला chat है और दूसरा forum। Struct design कठिन होने की वजह भी structure, knowledge और real-time nature के बीच balance है
वह हमेशा discussion का core पूरी तरह miss कर देता था और बेतुकी summaries बनाता था, जिससे घंटों तक हँसने का material मिल जाता था
“CEO के threads से feed बनाकर company के latest vision और goals के साथ aligned रहें। सही reply देकर conversation में कूदें और deserved promotion पाएँ” वाली line ने कड़वी मुस्कान ला दी
आखिरकार फिर समझ आता है कि अहम यह नहीं कि आप क्या करते हैं, बल्कि कौन उसे देखता है
मेरी पहली नौकरी Google में थी, जहाँ मैं बस बनाता ही रहा, और जो बना रहा था वह क्यों important है, यह communicate करने में struggle करता रहा। मेरे पहले manager ने मेरे अलावा पूरी team को promote कर दिया, और वह बात आज भी चुभती है। Team और manager बदलने पर पता चला कि मुझे जिस level पर होना चाहिए था उससे 2 levels नीचे evaluate किया जा रहा था। निष्कर्ष यही है कि ऐसी conversations में शामिल हों। ज़बरदस्ती दिखावा करने की ज़रूरत नहीं, लेकिन अपनी presence ज़रूर पता चलनी चाहिए
Employees को अपने boss के सामने खुद की marketing करने में समय लगाने के लिए encourage करना company के हित में भी नहीं है। ऐसा अक्सर दिखता है, लेकिन मुझे यह संकेत लगता है कि ज़्यादातर managers इस हिस्से में अपना काम ठीक से नहीं कर रहे
runForThread.executeReq.Get.messages: executeReq.client.Do: Get "[https://api.openai.com/v1/threads/thread_*******/messages?li...](<https://api.openai.com/v1/threads/…;)": context deadline exceeded (Client.Timeout exceeded while awaiting headers)उम्मीद है कि कभी नए products OpenAI dependency के बिना भी आ पाएँगे
OpenAI मुझे पसंद है। GPT-4 सच में बहुत अच्छा काम करता है। कुछ सस्ते दूसरे models भी आज़माए, लेकिन quality उतनी अच्छी नहीं थी
.aidomains block ही कर दूँगंभीरता से कहूँ तो, यह product “…और AI” वाली line देखने तक सच में interesting लग रहा था। शायद मैं target customer नहीं हूँ
Summary उन tasks में से एक है जिनमें AI सच में बहुत अच्छा है, इसलिए मुझे यह product बढ़िया लगता है
जानना चाहूँगा कि कौन-सी technology इस्तेमाल की गई है। क्या अंदर dgraph या badger इस्तेमाल हुआ है, hosting big 3 पर है या कहीं और, Kubernetes use होता है या नहीं, Elastic Search use होता है या नहीं। और यह भी कि Struct Slack/Discord को online scrape करने वाला tool है, या अभी/आगे चलकर standalone chat app बनना चाहता है
सबसे बड़ा cost OpenAI से आता है, और embeddings के लिए OpenAI नहीं बल्कि Microsoft E5 इस्तेमाल होता है। Typesense search के लिए है और Struct का user भी है। Postgres के बजाय Badger इस्तेमाल करना सही fit नहीं था, लेकिन दूसरे use cases के लिए Badger पर विचार कर रहे हैं। Internally ristretto और roaring bitmaps का बहुत इस्तेमाल करते हैं। Struct का Slack के साथ काफ़ी अच्छा integration है, इसलिए इसे Slack interface की तरह इस्तेमाल किया जा सकता है। Colleagues Slack use करें और मैं Struct से reply करूँ—Gmail के लिए Superhuman जैसा feel। Discord integration भी अच्छा है, और दोनों का इस्तेमाल open source companies Slack/Discord conversations से public knowledge base बनाने के लिए कर रही हैं। [1]: https://github.com/struct-chat/embedding
कभी-कभी सोचता/सोचती हूँ कि कहीं हम productivity को गलत तरीके से optimize करने की कोशिश तो नहीं कर रहे। communication के शोर को manage करने वाले tools की बजाय, शुरुआत से ही communication कम रखते हुए भी जरूरी काम अच्छे से पूरा करने में शायद ज्यादा फायदा हो सकता है
उदाहरण के लिए, अगर दर्जनों meetings हों, तो मैं meeting notes को बेहतर track करने के लिए optimize नहीं करना चाहूँगा/चाहूँगी। मैं कम, लेकिन ज्यादा effective meetings चाहूँगा/चाहूँगी
अगर AI meeting transcript से automatic summary बना सकता है, तो next steps या action items तक follow-up न कर पाने की कोई वजह नहीं है। अगर next step यह है कि Janine, Carlos के साथ meeting schedule करे, तो AI Carlos से contact करके schedule तय करने में मदद क्यों नहीं कर सकता? लगता है अभी हम बहुत छोटे स्तर पर सोच रहे हैं
लेकिन Metcalfe's law से भी बचा नहीं जा सकता। आधुनिक कामकाज का ज्यादातर हिस्सा teams में होता है, और अगर team size N है, तो O(N^2) communication cost चुकानी पड़ती है। ऐसा नहीं लगता कि कुल communication घटेगा; उसे ज्यादा effectively handle करने के लिए सही tools चाहिए
शानदार। Discord information search करने और threads follow करने के लिए सबसे खराब है
ऐसा लगता है जैसे उसी सवाल का बार-बार जवाब दे रहा/रही हूँ