Show HN: แชร์หน้าจอแบบเข้ารหัส 1-FPS สำหรับคนอินโทรเวิร์ต

 (1fps.video)
1 คะแนน โดย GN⁺ 2024-08-08 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • 1fps.video เป็นเครื่องมือแชร์หน้าจอแบบลิงก์ที่เริ่มใช้งานได้ทันทีจากไบนารีไฟล์เดียว เหมาะกับการทำงานร่วมกันที่ต้องการดูหน้าจอมากกว่าประชุม เช่น นักพัฒนา ทีมไอที และผู้เชี่ยวชาญด้านความปลอดภัย
  • ตั้งอยู่บนแนวคิดว่าการทำงานร่วมกันด้านการเขียนโค้ดจำนวนมากไม่จำเป็นต้องใช้ FPS สูง จึงช่วยลดการใช้ CPU·หน่วยความจำ·เครือข่าย และลดภาระของโน้ตบุ๊กเก่า
  • แชร์หน้าจอที่ 1 FPS แต่ใช้การติดตามเคอร์เซอร์บน WebSocket ทำให้การเคลื่อนไหวของตัวชี้ดูได้ลื่นใกล้เคียง 30 FPS เพื่อชดเชยการสาธิตที่ต้องการความแม่นยำ
  • รองรับ การเข้ารหัสแบบต้นทางถึงปลายทาง โดยคีย์ที่สร้างบนไคลเอนต์จะอยู่หลัง # ใน URL และไม่ถูกส่งไปยังแบ็กเอนด์
  • รองรับหลายจอภาพ ปรับคุณภาพภาพและขนาดการจับภาพได้ และข้ามการส่งหน้าจอเมื่อไม่มีการเปลี่ยนแปลง เพื่อเน้นการใช้งานระยะยาวและ การแชร์แบบใช้ทราฟฟิกต่ำ

วิธีแชร์หน้าจอแบบ 1 FPS

  • 1fps.video เป็นเครื่องมือที่ช่วยให้เริ่มแชร์หน้าจอได้อย่างรวดเร็ว โดยดาวน์โหลดไบนารีได้จาก Download
  • กลุ่มเป้าหมายหลักคือ นักพัฒนา ทีมไอที ผู้เชี่ยวชาญด้านความปลอดภัย และผู้ใช้ที่ชอบการทำงานร่วมกันโดยไม่ต้องประชุม
  • แนวคิดคือการแชร์หน้าจอด้วย FPS ต่ำมักเพียงพอสำหรับงานร่วมกันส่วนใหญ่ โดยเฉพาะนักพัฒนาที่ใช้เวลาส่วนมากไปกับการเขียนโค้ด
  • แนวทางนี้มุ่งเน้นการลดการใช้ทรัพยากรและทราฟฟิก
    • ไม่ต้องใช้ออดิโอ จึงส่งเสริม วัฒนธรรมที่ไม่ต้องประชุม
    • ลดการใช้ CPU, หน่วยความจำ และเครือข่ายได้อย่างมาก
    • โน้ตบุ๊กเก่าก็สามารถทำงานระหว่างแชร์หน้าจอได้ดีขึ้น
    • การใช้ทรัพยากรต่ำทำให้เป็นมิตรต่อสิ่งแวดล้อมมากขึ้น
  • สภาพแวดล้อมการแชร์สามารถปรับให้เหมาะกับเงื่อนไขเครือข่ายได้
    • รองรับการแชร์หลายจอภาพ
    • ปรับคุณภาพภาพเพื่อเพิ่มประสิทธิภาพการใช้ทราฟฟิกได้
    • สำหรับจอขนาดใหญ่ สามารถปรับขนาดการจับภาพหน้าจอเพื่อลดทราฟฟิกได้อีก
    • ใช้ การเปรียบเทียบหน้าจออัจฉริยะ เพื่อหลีกเลี่ยงการส่งข้อมูลที่ไม่จำเป็นเมื่อหน้าจอไม่มีการเปลี่ยนแปลง

ความปลอดภัย ความเป็นส่วนตัว และโมเดลการแชร์

  • มองว่า 1 FPS เพียงพอสำหรับงานเขียนโค้ดและพัฒนาส่วนใหญ่ ขณะที่การเคลื่อนไหวของเคอร์เซอร์แสดงได้ใกล้เคียง 30 FPS ผ่านการติดตามบน WebSocket
  • เหมาะกับผู้ใช้สายอินโทรเวิร์ตและผู้ทำงานทางไกลที่ต้องการแชร์เฉพาะหน้าจอโดยไม่ต้องโทรด้วยเสียงหรือวิดีโอ
  • สามารถใช้ร่วมกับแอปแชตของทีมที่มีอยู่เดิมได้ และปรับประสบการณ์การแชร์ให้เหมาะกับสภาพเครือข่ายผ่านตัวเลือกหลายจอภาพ คุณภาพภาพ และขนาดหน้าจอ
  • โครงสร้างด้านความเป็นส่วนตัวและความปลอดภัยอิงกับลิงก์และการจัดการคีย์ฝั่งไคลเอนต์
    • ข้อมูลทั้งหมดถูก เข้ารหัสแบบต้นทางถึงปลายทาง
    • คีย์เข้ารหัสถูกสร้างที่ฝั่งไคลเอนต์และไม่ถูกส่งไปยังเซิร์ฟเวอร์
    • คีย์จะรวมอยู่หลัง # ใน URL จึงไม่ถูกส่งต่อไปยังแบ็กเอนด์
    • มีเพียงผู้ที่มีลิงก์เต็มเท่านั้นที่เข้าถึงหน้าจอที่แชร์ได้
    • การเปรียบเทียบหน้าจอช่วยลดการส่งข้อมูลให้น้อยที่สุดและเสริมความเป็นส่วนตัว
  • ขณะนี้กำลังพัฒนา การเข้ารหัสพิกัดเคอร์เซอร์
  • ซอร์สโค้ดมีให้ที่ Source Code

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-08-08
ความเห็นจาก Hacker News

  • ดีแล้วที่เปิดเผยโปรเจกต์นี้ ไอเดียเท่และมินิมอลอย่างน่าทึ่ง แต่ในซอร์สเห็น ข้อบกพร่องด้านวิทยาการเข้ารหัสลับ หลายจุด จึงไม่ควรใช้ในสถานการณ์ที่การเข้ารหัสเป็นแกนสำคัญ

    1. หลังจากสร้างคีย์แบบสุ่มแล้ว [0] ก็นำไปใส่ใน PBKDF2 เพื่อสร้างคีย์ AES-GCM ขนาด 32 ไบต์ [1] แต่ถ้าสามารถใช้อักขระ ASCII ที่จำกัดไว้ 10 ตัวกับ key stretching ได้ ก็สร้างค่าสุ่ม 32 ไบต์ไปเลยก็พอ PBKDF2 มีไว้แปลงรหัสผ่านเป็นคีย์ และค่อนข้างห่างจากอัลกอริทึมที่แนะนำในปัจจุบัน ถ้าต้องทำงานแบบนี้ scrypt จะดีกว่า
    2. ใช้ nonce แบบสุ่มขนาด 12 ไบต์กับ AES-GCM อยู่ ใน GCM ไม่ควรใช้ IV แบบสุ่ม เพราะอาจทำให้การพิสูจน์ความถูกต้องเสียหายได้ [2] [3] ถ้าต้องการหลีกเลี่ยงกับดักของ AES-GCM ที่เกี่ยวกับ nonce แบบสุ่ม อาจดีกว่าที่จะเปลี่ยนไปใช้ XSalsa20+Poly1305 ข้อดีของ XSalsa คือมีความยาว nonce ที่ขยายออกไป จึงใช้ nonce แบบสุ่มได้อย่างสบายใจ
    3. การ derive คีย์สุ่มจากชุดอักขระที่จำกัดอาจทำให้การโจมตีแบบ brute force ง่ายขึ้น ควรมีคีย์สุ่ม 256 บิต และถ้าต้องการให้คีย์นั้นอยู่ในชุดอักขระเฉพาะ ก็ควรเข้ารหัสเอาต์พุตไบต์จากตัวสร้างเลขสุ่มเชิงเข้ารหัสลับให้อยู่ในชุดอักขระนั้น
    4. 1fps แจกจ่ายคีย์สมมาตรผ่าน fragment identifier ("#") ของ URL ซึ่งจำได้ว่าส่วนนี้จะไม่ถูกส่งไปยังเซิร์ฟเวอร์ ดังนั้นจึงตั้งอยู่บนสมมติฐานว่ามีช่องทางแจกจ่ายคีย์ที่ปลอดภัย เนื่องจากคีย์อยู่ในลิงก์ จึงต้องทำให้มีเพียงผู้รับที่ตั้งใจไว้เท่านั้นที่เห็นส่วนหลัง "#" ได้ หากเซิร์ฟเวอร์ประสงค์ร้ายจริง ๆ ก็สามารถแจกจ่าย JavaScript ฝั่งไคลเอนต์ที่ส่ง fragment กลับไปยังเซิร์ฟเวอร์ได้ และเมื่อนั้นเซิร์ฟเวอร์ก็จะเข้าถึงคีย์และการสื่อสารแบบ plaintext ได้
      [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/
    • ดีเลยที่มาที่นี่เพื่อรับคำแนะนำแบบนี้ จะนำการเปลี่ยนแปลงเหล่านี้ไปปรับใช้ให้เร็วที่สุดเท่าที่ทำได้
    • รู้สึกว่าบทความวิชาการพวกนั้นค่อนข้างยาก ช่วยอธิบายได้ไหมว่าการใช้ IV แบบสุ่ม ตรงนี้มีปัญหาอะไรแน่ ๆ? ถ้าเปลี่ยนไปใช้ chacha ไม่ได้และใช้ได้แค่ GCM ควรทำอย่างไรแทน?
    • รู้สึกว่าตอนออกแบบอะไรแบบนี้มีกับดักเยอะมาก มี ฐานมาตรฐานที่เชื่อถือได้ ซึ่งนำไปสร้างแอปพลิเคชันทับได้ไหม? สงสัยด้วยว่า TLS อาจใช้ได้หรือเปล่า
    • ขอบคุณที่แนะนำ XSalsa20+Poly1305 ผมสนใจวิทยาการเข้ารหัสลับมาตลอด เลยน่าสนใจที่ได้เรียนรู้เหตุผลต่าง ๆ ว่าทำไมไม่ควรสร้าง cipher และโปรโตคอลเอง
      ในกรณีนี้ สาเหตุหลักที่ไม่แนะนำให้แก้ปัญหา nonce เป็นเพราะกับดักระหว่างการ implement หรือว่ามันเชื่อมโยงกับปัญหาทั่วไปในบทความข้างต้นอย่างละเอียดอ่อนกว่านั้น?
      ถ้ามองแบบซื่อ ๆ AES-GCM ถูกใช้ในหลายที่อย่าง TLS หรือ SRTP คนที่ไม่ค่อยรู้เรื่องวิทยาการเข้ารหัสลับก็อาจคิดว่านี่เป็นตัวเลือกที่ดี
    • มีวิธีแนะนำในการแก้ปัญหาข้อ 4 ไหม? ดูเหมือนเป็นปัญหาโดยเนื้อแท้ของเว็บแอป และ ProtonMail ก็ดูคล้ายกัน

  • ดูจากโค้ด เหมือนเป็นวิธีถ่ายภาพหน้าจอ (.jpg) ทุกวินาทีแล้วส่งไป สงสัยว่าวิธีนี้ประหยัดแบนด์วิดท์ได้จริงเมื่อเทียบกับ การบีบอัดวิดีโอสมัยใหม่ ที่นำข้อมูลเฟรมก่อนหน้ามาใช้ซ้ำหรือไม่
    ลองบันทึกวิดีโอ 1 นาทีตอนแก้โค้ดใน VS Code ที่ 1440p 10fps เข้ารหัสด้วย AV1 แล้วขนาดประมาณครึ่งหนึ่งของภาพหน้าจอ JPEG 60 ภาพของหน้าจอเดียวกัน ถ้ามีตัวเลขที่ทดสอบไว้ก็อยากรู้

    • เมื่อ 10 ปีก่อนเคยลองใช้ TimeSnapper Classic ซึ่งเป็นยูทิลิตีฟรีสำหรับ Windows ชอบฟีเจอร์ที่จับภาพหน้าจอทุก 5 วินาทีแล้วให้ดูทั้งวันเป็นไทม์แลปส์ได้
      ภาพหน้าจอกินพื้นที่ดิสก์เยอะ และเมื่อเห็นว่าระหว่างภาพแทบไม่มีส่วนที่เปลี่ยนไปเลย ก็เลยนึกถึงอัลกอริทึมที่บันทึกเฉพาะส่วนต่างจากภาพถัดไป ไม่กี่นาทีต่อมาก็รู้ตัวว่ากำลัง คิดค้นการบีบอัดวิดีโอขึ้นมาใหม่
      ดังนั้นจึงใช้ ffmpeg แปลงลำดับภาพเป็น mp4 และขนาดไฟล์ลดลงประมาณ 95% ใช้ ImageMagick ฝังชื่อไฟล์ timestamp ลงในภาพด้วย ซึ่งเหมือนกับทำฟีเจอร์ของ TimeSnapper Classic ขึ้นมาใหม่ได้ด้วยคำสั่ง 2 คำสั่ง
    • ไม่ใช่แค่เรื่องแบนด์วิดท์ แต่เป็นเรื่อง การใช้ CPU ด้วย เคยลองป้อนภาพหน้าจอเข้า ffmpeg หรือเครื่องมืออื่น ๆ แม้มันจะทำงานได้ แต่กินทรัพยากรมากเกินไปจนแทบใช้งานจริงไม่ได้ อย่างน้อยก็เป็นแบบนั้นบนคอมพิวเตอร์ของผมคือ MacBook 13 นิ้ว รุ่นปี 2019
      ด้านหนึ่งคือการใช้ CPU อีกด้านคือเครือข่าย ผมคิดว่าเครือข่ายราคาถูก แต่การเข้ารหัสวิดีโอมีต้นทุนแพง ไม่มีหลักฐาน มีแค่การทดลองในเครื่อง แต่การเริ่มวัดผลเป็นไอเดียที่ดีจริง ๆ
      ยังมีอีกไอเดียคือสแกนหน้าจอแล้วส่งเฉพาะส่วนที่เปลี่ยนไป แค่ส่งครึ่งหน้าจอก็น่าจะชนะการเข้ารหัสวิดีโอในแง่เครือข่ายได้แล้ว แต่ diff algorithm ต้องเร็วมาก ถ้าเป็น 1280x720 ก็มี 914400 พิกเซล และถ้าพิกเซลละ 4 ไบต์ ก็ต้องประมวลผลข้อมูล 3.49MB ต่อวินาที
      ก็สงสัยเหมือนกันว่าประสิทธิภาพของการเข้ารหัสวิดีโอกับต้นทุนการสร้าง JPEG 60 ภาพเป็นอย่างไร ใกล้เคียงกันไหม?
    • ผมก็คิดเรื่องนี้เป็นอย่างแรกเหมือนกัน ดูไม่มีเหตุผลที่จะไม่ใช้ codec มาตรฐานแล้วตั้งค่าเป็น 1fps
    • ดูเหมือนเลือกป้องกันการคงอยู่ของข้อมูล คือการแทนที่และลบ มากกว่าการลดแบนด์วิดท์ให้ต่ำสุด
      ถ้าต้องการก็น่าจะทำทั้งสองอย่างได้ง่าย แต่ไม่แน่ใจว่าคุ้มกับความยุ่งยากไหม เห็นด้วยว่าถ้าขยายขนาดจาก IP เดียวกัน วิธีนี้อาจรับภาระไม่ไหว

  • ชอบมาก
    เวิร์กโฟลว์ของเราถูกออกแบบมาเพื่อตัดความจำเป็นของออฟฟิศและโครงสร้างพื้นฐานด้านเทคนิคออกไป เราสตรีมเอาต์พุตไทม์ไลน์ หรือก็คือผลงานตัดต่อวิดีโอแบบเรียลไทม์ และมีช่องทางสื่อสารที่เปิดไว้ สมาชิกทีมส่วนใหญ่ค่อนข้างอินโทรเวิร์ต เลยใช้แบบ push-to-talk และถ้าไม่จำเป็นต้องถกกันทั้งทีม ก็มักจะทิ้งโน้ตไว้ในแชตเท่านั้น
    วิธีแก้แบบหยาบ ๆ มักกลับถูกนำไปใช้จริงบ่อย ๆ

    • ดีใจที่ได้ยินแบบนั้น เพิ่งเปิดซอร์สฝั่งเซิร์ฟเวอร์ไปเมื่อกี้นี้เอง จะได้ลองเล่นได้มากขึ้น เอกสารจะค่อย ๆ ปรับปรุงให้ทำตามได้ง่ายขึ้น

  • กรณีใช้งาน ของการแชร์หน้าจอแบบไม่มีเสียงคืออะไร? ไม่ค่อยแน่ใจว่าจะมีประโยชน์ตอนไหน ยังไงก็ต้องสื่อสารกับอีกฝ่ายอยู่ดีไม่ใช่หรือ?

    • มีเยอะ เช่น เวลาออกไปทำงานโดยทิ้งคอมที่บ้านไว้ ก็เซฟลิงก์ไว้แล้วดูได้ว่าที่บ้านเกิดอะไรขึ้น เดสก์ท็อประยะไกลก็ทำนองเดียวกัน
      ระหว่างประชุมยาว ๆ บางทีก็ยังต้องเปิดแชร์หน้าจอต่อเนื่องอยู่ แทนที่จะนั่งฟังประชุม 1–2 ชั่วโมง บางทีก็อยากเขียนโค้ดมากกว่า
      และยังเหมาะกับคนที่ไม่ชอบเสียงอย่างผมด้วย มีนักเรียนหลายคนที่อยากช่วย แต่ไม่อยากต้องมีเสียงเข้ามาด้วย แชตเสียงของผมไม่ใช่ทรัพยากรที่ทำแบบขนานได้ดี
    • ตามบทความ 1fps.video เป็นโซลูชันอเนกประสงค์ที่เหมาะกับคนอินโทรเวิร์ตและคนทำงานรีโมตที่อยากแชร์หน้าจอโดยไม่ต้องรับภาระจากการโทรเสียงหรือวิดีโอ และทำงานร่วมกับแอปแชตทีมที่ใช้อยู่แล้ว
      ดูเหมือนจะใกล้เคียงกับการ ส่งสกรีนช็อตไปพร้อมกับแชตข้อความ มากกว่า “แชร์หน้าจอระหว่างคุยเสียง” เข้าใจได้ว่าทำไมถึงมีคนชอบ
    • พวกมิจฉาชีพบางทีก็ใช้ การแชร์หน้าจอแบบไม่มีเสียง ขณะคุยโทรศัพท์กับเป้าหมาย
    • ก็แค่โทรศัพท์ไม่ได้หรือ? ทุกคนก็พกมือถืออยู่ตลอดอยู่แล้ว ไม่จำเป็นต้องประดิษฐ์ล้อขึ้นมาใหม่

  • เกี่ยวกับประโยคที่ว่า “เบื่อการแชร์หน้าจอเพราะ Google Meet จำกัด 1 ชั่วโมง ส่วน Zoom จำกัด 40 นาที” นั้น jitsi[0] เป็นทางเลือกประชุมวิดีโอแบบโอเพนซอร์ส[1] ที่ใช้ WebRTC ฟีเจอร์ค่อนข้างครบสำหรับใช้แทน Zoom, Google Meet, Slack อะไรพวกนั้น
    จะใช้จากเว็บหลักก็ได้ หรือถ้าต้องการก็โฮสต์เองได้
    [0]: https://meet.jit.si/
    [1]: https://github.com/jitsi

    • Nextcloud Talk ก็เป็นอีกตัวเลือก แต่ถ้าจะใช้พร้อมกันเกิน 3 คน มีโอกาสสูงว่าจะต้องใช้แบ็กเอนด์ Golang High-Performance [1]
      [1] https://github.com/strukturag/nextcloud-spreed-signaling
    • ผมชอบ https://talk.brave.com/ มากกว่า jitsi แนวคิดเดียวกัน แต่รู้สึกว่าดีกว่า jitsi

  • การสร้าง ฮิวริสติก เพื่อเลือกว่าจะใช้เฟรมไหนน่าจะน่าสนใจ การเลือกเฟรมล่าสุดแบบสุ่มสี่สุ่มห้าตลอดไม่น่าจะเป็นอุดมคติ และอาจดีกว่าถ้าเลือกเฟรมที่มีการเคลื่อนไหวน้อย ไม่มีแอนิเมชันที่กำลังเล่นอยู่ หรือมีตัวชี้วัดคล้าย ๆ กัน
    ถ้าอยากทำให้หรูขึ้น ก็อาจวิเคราะห์เป็นรายหน้าต่างก่อน แล้วค่อยสร้างเป็นรูปแบบการรวมผลสำหรับทั้งเฟรม

    • การวิเคราะห์เป็นรายหน้าต่างแล้วทำผลรวมของทั้งเฟรม อาจไปอยู่ในโซนเดียวกับที่ “กล้อง” สมาร์ตโฟนใส่การคำนวณกับเอาต์พุตจากเซ็นเซอร์แสงมากเกินไป จนแทบเรียกว่ารูปถ่ายไม่ได้แล้ว [0]
      เป็นไอเดียที่เจ๋ง และได้ยินว่าในหมากรุกมีแนวคิดคล้ายกันเรียกว่า quiescence search[1] แต่คงไม่น่าคุ้มกับแรงที่ต้องลง
      [0] https://old.reddit.com/r/Android/comments/11nzrb0/samsung_sp...
      [1] https://en.wikipedia.org/wiki/Quiescence_search
    • แบบนี้อาจขัดกับเป้าหมายเรื่องการใช้ ทรัพยากรประมวลผล ให้น้อยที่สุด
      ถึงอย่างนั้นก็ฟังดูเป็นไอเดียที่ยอดเยี่ยมและเป็นปัญหาที่น่าสนใจ
    • จริง ๆ แล้วชอบไอเดียนี้นะ ก่อนหน้านี้เคยคิดว่าจะสแกนเมทริกซ์ 100x100 แบบ sparse โดยเว้นช่วง 5–10 พิกเซลรอบ ๆ จุดที่เคยพบการเปลี่ยนแปลง เพื่อตรวจจับการเปลี่ยนแปลงของหน้าจอที่เป็นไปได้

  • มีข้อผิดพลาดตอนคอมไพล์จาก github.com/go-vgo/robotgo ว่าไม่มี X11/extensions/XTest.h
    https://github.com/go-vgo/robotgo?tab=readme-ov-file#require...
    มี prerequisite ที่ไม่ได้เขียนไว้ในหน้า บน Mint 22 ต้องติดตั้งแพ็กเกจ libxtst-dev

    • จะอัปเดตเอกสารให้ robotgo มีปัญหาบางอย่างบน Windows อยู่ ตอนนี้กำลังดูบางส่วนอยู่

  • วันนี้กำลังมองหาอะไรแบบนี้พอดี กำลังมอนิเตอร์อีเวนต์ทดสอบทางกายภาพจากระยะไกลอยู่ การเปิด Google Meet พร้อมบันทึกไว้เละเทะมาก แต่ก็ยังต้องมี แชตข้อความ สำหรับอินเทอร์เฟซอยู่
    ดูเป็นอินเทอร์เฟซแบบมินิมอลที่ดีมาก ถ้าเกิดมีอารมณ์ก็อาจลองเพิ่ม persistence ให้แชตสักรูปแบบหนึ่ง
    เพิ่มเติมคือ ข้อความหรือเสียงที่ซิงก์กันให้ไปทำที่อื่น เช่น โทรศัพท์หรือคำอธิบายข้อความใน Slack ใช่ไหม?

    • บางครั้งผมก็ทำแบบนี้กับเพื่อน ใช้โทร WhatsApp คู่กับการแชร์หน้าจอแบบง่าย ๆ ระหว่างแล็ปท็อปผมกับพีซีของเพื่อน
    • ที่บอกว่าวันนี้กำลังมองหาอะไรแบบนี้ คือก่อนหน้านี้วันนี้คุณคิดว่าต้องการ 1fps เป๊ะ ๆ เลยหรือ?

  • สำหรับการใช้งานของผม Moonlight Game Streaming แทบจะแทน VNC ไปแล้ว เหลือแค่ฟีเจอร์อย่างโอนไฟล์กับแชร์คลิปบอร์ดที่อยากให้ดีขึ้นอีกหน่อย

    • พูดตรง ๆ แค่มีคลิปบอร์ดก็พอแล้ว และถ้ามีบริการที่ช่วยทำ NAT traversal ให้ได้ก็ดี

  • การติดตามเคอร์เซอร์มีปัญหา ไม่รู้ว่าเพราะมีหลายจอหรือเปล่า
    ในภาพนี้ วงแหวนคือตำแหน่งเคอร์เซอร์จริง https://i.imgur.com/TvzskjS.png

    • สัญญาว่าจะปรับแก้ตามกรณีใช้งานหลัก ๆ ให้ ลองกลับมาตรวจดูภายหลังก็ได้ว่าแก้แล้วหรือยัง ขอบคุณสำหรับฟีดแบ็ก