Show HN: अंतर्मुखी लोगों के लिए 1-FPS एन्क्रिप्टेड स्क्रीन शेयरिंग

 (1fps.video)
1 पॉइंट द्वारा GN⁺ 2024-08-08 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 1fps.video एक link-आधारित screen sharing tool है जो single binary से तुरंत शुरू हो जाता है, और डेवलपर्स, IT teams, security professionals जैसे उन सहयोगी कामों के लिए उपयुक्त है जहाँ मीटिंग से ज़्यादा स्क्रीन देखना ज़रूरी होता है
  • इस मान्यता के आधार पर कि coding collaboration में कम FPS भी अक्सर पर्याप्त होता है, यह CPU·memory·network usage कम करता है और पुराने laptops पर बोझ घटाता है
  • स्क्रीन 1 FPS पर share होती है, लेकिन WebSocket-आधारित cursor tracking pointer movement को लगभग 30 FPS के करीब दिखाती है, जिससे सटीक demo देना आसान होता है
  • यह end-to-end encryption प्रदान करता है, और client पर बनी key URL के # के बाद जाती है, इसलिए backend को भेजी नहीं जाती
  • multi-monitor, image quality·capture size adjustment, और बिना बदलाव वाली स्क्रीन के transmission को छोड़ने जैसी सुविधाओं के साथ इसका फोकस लंबे sessions और low-traffic sharing पर है

1 FPS स्क्रीन शेयरिंग का तरीका

  • 1fps.video एक ऐसा tool है जिससे screen sharing जल्दी शुरू की जा सकती है, और Download से binary डाउनलोड की जा सकती है
  • इसके मुख्य उपयोगकर्ता डेवलपर्स, IT teams, security professionals, और वे लोग हैं जो बिना मीटिंग वाले collaboration को पसंद करते हैं
  • इसका आधार यह है कि low-FPS screen sharing ज़्यादातर collaborative tasks के लिए, खासकर उन डेवलपर्स के लिए जो ज़्यादा समय code लिखने में बिताते हैं, अक्सर पर्याप्त होती है
  • यह तरीका resources और traffic कम करने पर केंद्रित है
    • audio की ज़रूरत नहीं होती, जिससे meeting-free culture को बढ़ावा मिलता है
    • CPU, memory, और network usage काफ़ी कम हो जाता है
    • पुराने laptops भी screen sharing के दौरान बेहतर चल सकते हैं
    • कम resource usage के कारण यह पर्यावरण के लिए भी अधिक अनुकूल है
  • sharing environment को network conditions के अनुसार समायोजित किया जा सकता है
    • multi-monitor sharing को support करता है
    • image quality को adjust करके traffic usage को optimize किया जा सकता है
    • बड़े displays पर screen capture size को adjust करके traffic और कम किया जा सकता है
    • स्क्रीन में बदलाव न होने पर अनावश्यक data transmission से बचने के लिए intelligent screen comparison का उपयोग करता है

सुरक्षा, प्राइवेसी, और sharing model

  • इसका मानना है कि ज़्यादातर coding और development work के लिए 1 FPS पर्याप्त है, जबकि cursor movement WebSocket-आधारित tracking के ज़रिए लगभग 30 FPS के करीब उपलब्ध होती है
  • यह उन अंतर्मुखी users और remote workers के लिए उपयुक्त है जो audio या video calls के बिना सिर्फ़ स्क्रीन share करना चाहते हैं
  • इसे मौजूदा team chat applications के साथ इस्तेमाल किया जा सकता है, और multi-monitor, image quality, तथा screen size adjustment options के ज़रिए sharing experience को network स्थिति के अनुसार बदला जा सकता है
  • इसकी privacy और security संरचना link और client-side key management पर आधारित है
    • सारा data end-to-end encrypted होता है
    • encryption key client side पर बनती है और server को भेजी नहीं जाती
    • key URL के # के बाद शामिल होती है, इसलिए backend तक नहीं पहुँचती
    • केवल वही व्यक्ति shared screen तक पहुँच सकता है जिसके पास पूरा link हो
    • screen comparison data transmission को न्यूनतम करके privacy को और मज़बूत करता है
  • अभी cursor coordinate encryption पर काम चल रहा है
  • source code Source Code पर उपलब्ध है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-08-08
Hacker News की राय

  • प्रोजेक्ट को अच्छी तरह पेश किया गया है। आइडिया शानदार है और हैरान करने वाली हद तक minimal है, लेकिन source में कई cryptographic flaws दिख रहे हैं, इसलिए जहाँ encryption मुख्य बात हो वहाँ इसका इस्तेमाल नहीं करना चाहिए

    1. एक random key बनाकर उसे [0] PBKDF2 में डालकर [1] 32-byte AES-GCM key बनाई जा रही है, लेकिन अगर 10 सीमित ASCII characters और key stretching का उपयोग किया जा सकता है, तो सीधे 32-byte random value बना लेनी चाहिए। PBKDF2 का उपयोग password को key में बदलने के लिए होता है, और यह आज के recommended algorithms से काफ़ी दूर है, इसलिए अगर ऐसा कुछ करना ही हो तो scrypt बेहतर होगा
    2. AES-GCM में 12-byte random nonce इस्तेमाल किया जा रहा है। GCM में random IV नहीं इस्तेमाल करना चाहिए, क्योंकि authentication टूट सकता है [2] [3]। random nonce से जुड़े AES-GCM के pitfalls से बचने के लिए XSalsa20+Poly1305 पर जाना बेहतर हो सकता है। XSalsa का फ़ायदा यह है कि इसकी nonce length बड़ी होती है, इसलिए random nonce को सुरक्षित तरीके से इस्तेमाल किया जा सकता है
    3. सीमित character set से random key derive करने पर brute-force attack आसान हो सकता है। आपके पास 256-bit random key होनी चाहिए, और अगर उस key को किसी specific character set में रखना है, तो cryptographic RNG के byte output को उसी character set में encode करना चाहिए
    4. 1fps URL के fragment identifier ("#") के ज़रिए symmetric key बाँटता है, और मेरी याद के मुताबिक यह हिस्सा server को नहीं भेजा जाता। इसलिए यह एक सुरक्षित key distribution channel मानकर चलता है। क्योंकि key लिंक में है, "#" के बाद का हिस्सा सिर्फ़ intended recipient ही देख पाए, यह ज़रूरी है। अगर server सचमुच malicious हो, तो वह client JavaScript serve करके fragment को server पर भेज सकता है, और तब server को key और plaintext communication, दोनों तक पहुँच मिल जाएगी
      [0]: https://github.com/1fpsvideo/1fps/blob/main/1fps.go#L99
      [1]: https://github.com/1fpsvideo/1fps/blob/main/1fps.go#L287
      [2]: https://eprint.iacr.org/2016/475.pdf
      [3]: https://soatok.blog/2020/05/13/why-aes-gcm-sucks/
    • मैं यहाँ इसी तरह की सलाह पाने के लिए आया था, इसलिए यह अच्छा लगा। मैं जितनी जल्दी हो सके इन बदलावों को लागू करूँगा
    • papers थोड़े मुश्किल लग रहे हैं। क्या आप समझा सकते हैं कि यहाँ random IV इस्तेमाल करने में ठीक-ठीक समस्या क्या है? अगर मैं chacha पर switch नहीं कर सकता और केवल GCM ही इस्तेमाल कर सकता हूँ, तो उसके बदले क्या करना चाहिए?
    • ऐसी चीज़ डिज़ाइन करते समय लगता है कि traps बहुत ज़्यादा हैं। क्या कोई standard और भरोसेमंद foundation है जिसके ऊपर application बनाई जा सके? यह भी सोच रहा हूँ कि शायद TLS इस्तेमाल किया जा सकता है
    • XSalsa20+Poly1305 recommend करने के लिए धन्यवाद। मुझे हमेशा से cryptography में रुचि रही है, इसलिए यह सीखना दिलचस्प है कि खुद cipher और protocol क्यों नहीं बनाने चाहिए
      इस मामले में nonce वाली समस्या को खुद ठीक करने की सलाह न देने की मुख्य वजह implementation के दौरान होने वाले traps हैं, या यह ऊपर दिए गए लेखों में बताए गए general issues से किसी ज़्यादा subtle तरीके से जुड़ा है?
      सीधी नज़र से देखें तो AES-GCM का उपयोग TLS या SRTP जैसी कई जगहों पर होता है, इसलिए जिसे cryptography की ज़्यादा समझ न हो वह इसे अच्छा विकल्प मान सकता है
    • point 4 को हल करने का कोई recommended तरीका है? यह web app की एक मूलभूत समस्या लगती है, और ProtonMail भी कुछ ऐसा ही दिखता है

  • कोड देखकर लगता है कि यह हर सेकंड screenshot (.jpg) लेकर भेजता है। मैं जानना चाहता हूँ कि क्या यह तरीका पिछली frames की जानकारी reuse करने वाले modern video compression से सच में bandwidth बचाता है
    मैंने VS Code में code edit करते हुए 1 मिनट का video 1440p 10fps, AV1 encoding पर रिकॉर्ड किया, और वह उसी स्क्रीन के 60 JPEG screenshots की तुलना में लगभग आधा size का था। अगर आपने कुछ benchmark किए हों तो जानना चाहूँगा

    • 10 साल पहले Windows के लिए एक free utility TimeSnapper Classic के साथ प्रयोग किया था, जो हर 5 सेकंड में screenshot लेती थी और पूरे दिन को timelapse की तरह देखने देती थी
      screenshots बहुत disk space ले रहे थे, और यह देखकर कि तस्वीरों के बीच लगभग कुछ बदलता ही नहीं, मेरे मन में बाद की image से सिर्फ़ difference save करने वाला algorithm आया। कुछ मिनट बाद समझ आया कि मैं video compression को फिर से invent कर रहा हूँ
      इसलिए मैंने ffmpeg से image sequence को mp4 में बदला, और file size लगभग 95% कम हो गया। ImageMagick से timestamp वाले filename को image पर जला दिया, और इस तरह शायद 2 commands में ही TimeSnapper Classic की functionality दोबारा बना ली
    • यह सिर्फ़ bandwidth का नहीं बल्कि CPU usage का भी सवाल है। मैंने screenshots को ffmpeg और दूसरे tools में डालकर देखा है; काम तो करता है, लेकिन resources इतना खाता है कि practically इस्तेमाल करना मुश्किल हो जाता है। कम से कम मेरे 2019 MacBook 13-inch पर तो ऐसा ही था
      एक तरफ CPU usage है और दूसरी तरफ network। मेरा मानना है कि network सस्ता है लेकिन encoding महँगी। मेरे पास कोई ठोस सबूत नहीं, सिर्फ़ local experiments हैं, लेकिन measurement शुरू करना वाकई अच्छा विचार है
      एक और idea यह है कि screen scan करके सिर्फ़ बदले हुए हिस्से भेजे जाएँ। अगर स्क्रीन का सिर्फ़ आधा हिस्सा भी भेजना पड़े, तो network के हिसाब से शायद यह video encoding से बेहतर हो सकता है। लेकिन diff algorithm बहुत तेज़ होना चाहिए। 1280x720 पर 914400 pixels होते हैं, और 4 bytes प्रति pixel मानें तो 1 सेकंड में 3.49MB जानकारी process करनी होगी
      video encoding efficiency और 60 JPEG बनाने की cost के बीच तुलना भी दिलचस्प होगी। क्या दोनों लगभग बराबर हैं?
    • मेरे दिमाग में भी सबसे पहले यही आया था। standard codec इस्तेमाल करते हुए उसे 1fps पर सेट न करने की कोई वजह नहीं दिखती
    • ऐसा लगता है कि bandwidth को कम करने से ज़्यादा फोकस data persistence रोकने पर है, यानी replacement और deletion को चुना गया है
      चाहें तो दोनों चीज़ें आसानी से की जा सकती हैं, लेकिन यह अतिरिक्त झंझट उठाने लायक है या नहीं, इस पर भरोसा नहीं। हालांकि मैं मानता हूँ कि एक ही IP पर scale बढ़ने पर यह तरीका भारी पड़ सकता है

  • पसंद आया
    हमारा workflow इस तरह बनाया गया है कि दफ़्तर और तकनीकी infrastructure की ज़रूरत ही न पड़े। timeline output, यानी video editing result, को real-time में stream करते हैं और communication channel खुला रखते हैं। टीम के ज़्यादातर लोग काफ़ी introverted हैं, इसलिए push-to-talk इस्तेमाल करते हैं, और जब पूरी discussion की ज़रूरत नहीं होती तो आम तौर पर chat में सिर्फ़ notes छोड़ देते हैं
    कई बार यही सीधा-सादा समाधान अपनाया जाता है

    • यह सुनकर खुशी हुई। मैंने अभी server side को open source के रूप में जारी किया है, इसलिए आप इसके साथ थोड़ा और खेल सकते हैं। docs को समय के साथ बेहतर बनाऊँगा ताकि इसे follow करना आसान हो

  • audio के बिना screen sharing के use cases क्या हैं? समझ नहीं आ रहा कि यह कब काम आएगा। वैसे भी, किसी न किसी तरह सामने वाले से communicate तो करना ही होगा, है न?

    • बहुत हैं। उदाहरण के लिए, घर के computer को छोड़कर office जाते समय link save करके रख सकते हैं और देख सकते हैं कि घर पर क्या हो रहा है। remote desktop भी ऐसा ही है
      लंबी meetings में भी कई बार screen sharing लगातार चाहिए होती है। 1~2 घंटे की meeting में बैठकर सुनने के बजाय कभी-कभी coding करना बेहतर लगता है
      और यह मेरे जैसे लोगों के लिए भी ठीक है जिन्हें audio पसंद नहीं है। बहुत से students हैं जिनकी मदद करना चाहता हूँ, लेकिन audio तक शामिल नहीं होना चाहता। मेरी voice chat ऐसा resource नहीं है जिसे अच्छी तरह parallelize किया जा सके
    • पोस्ट के मुताबिक 1fps.video introverted लोगों और remote workers के लिए है जो audio या video call के दबाव के बिना screen share करना चाहते हैं, और यह उन team chat apps के साथ काम करने वाला एक बहुउद्देश्यीय समाधान है जिन्हें वे पहले से इस्तेमाल करते हैं
      यह “voice call के दौरान screen sharing” से ज़्यादा screenshots भेजते हुए text chat जैसा लगता है। समझ आता है कि कुछ लोग इसे क्यों पसंद करेंगे
    • scammers भी target के साथ phone call पर रहते हुए audio के बिना screen sharing का इस्तेमाल करते हैं
    • सीधे phone क्यों नहीं कर लेते? सबके पास हमेशा mobile phone होता है, तो इस wheel को फिर से invent करने की ज़रूरत नहीं है

  • “Google Meet में 1 घंटे की limit है, Zoom में 40 मिनट की limit है, इसलिए मैं screen sharing से थक गया” वाली बात पर, jitsi[0] WebRTC-आधारित open source[1] video conferencing alternative है। यह Zoom, Google Meet, Slack जैसी चीज़ों के विकल्प के रूप में काफ़ी feature-complete है
    इसे main site पर भी इस्तेमाल कर सकते हैं, और चाहें तो self-host भी कर सकते हैं
    [0]: https://meet.jit.si/
    [1]: https://github.com/jitsi

    • Nextcloud Talk भी एक option है। हालाँकि, अगर एक साथ 3 से ज़्यादा लोग इस्तेमाल करेंगे तो Golang High-Performance backend [1] की ज़रूरत पड़ सकती है
      [1] https://github.com/strukturag/nextcloud-spreed-signaling
    • मुझे jitsi से ज़्यादा https://talk.brave.com/ पसंद है। विचार वही है, लेकिन मुझे यह jitsi से बेहतर लगता है

  • यह दिलचस्प हो सकता है कि कौन-सा frame इस्तेमाल करना है, इसके लिए कोई heuristic बनाई जाए। हर बार बस सबसे नया frame चुन लेना शायद आदर्श न हो; कम movement वाले, ongoing animation न होने वाले, या ऐसे ही किसी metric वाले frame चुनना बेहतर हो सकता है
    और अगर इसे ज़्यादा fancy बनाना हो, तो window level पर analysis करके पूरे frame के लिए aggregated form भी बनाई जा सकती है

    • window level analysis के बाद पूरे frame का aggregate बनाना शायद smartphone “camera” वाले उस क्षेत्र जैसा हो जाएगा जहाँ light sensor output पर इतनी ज़्यादा computation लागू हो जाती है कि उसे लगभग photo कहना मुश्किल हो जाता है [0]
      बढ़िया idea है, और chess में मैंने सुना है कि इसी तरह की सोच को quiescence search[1] कहते हैं, लेकिन शायद यह मेहनत के लायक न हो
      [0] https://old.reddit.com/r/Android/comments/11nzrb0/samsung_sp...
      [1] https://en.wikipedia.org/wiki/Quiescence_search
    • इससे कम से कम computational resources के उपयोग को न्यूनतम रखने वाले लक्ष्य के खिलाफ़ जा सकता है
      फिर भी यह शानदार idea और दिलचस्प समस्या लगती है
    • सच कहूँ तो मुझे यह idea पसंद है। पहले मैंने सोचा था कि जहाँ बदलाव मिला था उसके आसपास 5~10 pixel के अंतर पर sparse 100x100 matrix scan करके संभावित screen changes detect किए जाएँ

  • github.com/go-vgo/robotgo में X11/extensions/XTest.h missing होने की compile error आ रही है
    https://github.com/go-vgo/robotgo?tab=readme-ov-file#require...
    page पर न लिखी गई एक prerequisite है। Mint 22 में मुझे libxtst-dev package install करना पड़ा

    • मैं docs update करूँगा। robotgo में Windows पर कुछ issues हैं, इसलिए अभी उसके कुछ हिस्से देख रहा हूँ

  • मैं आज इसी तरह की कोई चीज़ ढूँढ रहा था। मैं physical test event की remote monitoring कर रहा हूँ, लेकिन recording on करके Google Meet खुला छोड़ना बेकार है, और फिर भी interface के लिए text chat चाहिए था
    यह बहुत अच्छा minimal interface लगता है। अगर मन हुआ तो किसी तरह chat persistence भी जोड़कर देख सकता हूँ
    क्या अतिरिक्त synchronized text या voice को phone call या Slack text explanation जैसी किसी दूसरी जगह संभाला जाता है?

    • मैं कभी-कभी दोस्त के साथ ऐसा करता हूँ। WhatsApp phone call और मेरे laptop व दोस्त के PC के बीच simple screen sharing साथ में इस्तेमाल करते हैं
    • आपने कहा कि आप आज यही ढूँढ रहे थे, तो क्या आज सुबह आपने सचमुच सोचा था कि आपको ठीक 1fps चाहिए?

  • मेरे use case में Moonlight Game Streaming ने लगभग VNC की जगह ले ली है। बस file transfer, clipboard sharing जैसी features थोड़ी और बेहतर हो जाएँ तो अच्छा होगा

    • सच कहूँ तो मुझे सिर्फ़ clipboard चाहिए, और अच्छा होगा अगर NAT traversal करवाने वाली कोई service भी हो

  • cursor tracking में दिक्कत है। पता नहीं multiple monitors की वजह से है या नहीं
    इस image में ring ही actual cursor position है https://i.imgur.com/TvzskjS.png

    • मैं वादा करता हूँ कि हर प्रमुख use case के हिसाब से fixes जोड़ूँगा। बाद में फिर आकर देख सकते हैं कि यह ठीक हुआ या नहीं। feedback के लिए धन्यवाद