Jack Dorsey เปิดตัว Buzz ที่รวมแชตทีม, AI Agent และโฮสติ้ง Git

 (runtimewire.com)
1 คะแนน โดย GN⁺ 2 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Block เปิดตัว Buzz เวิร์กสเปซโอเพนซอร์ส ที่เชื่อมพนักงาน, AI Agent, บทสนทนา และที่เก็บซอฟต์แวร์เข้าด้วยกันภายใต้ระบบตัวตนเดียว เพื่อลดการพึ่งพา Slack และ GitHub
  • จัดเก็บข้อความ, reaction, ขั้นตอน workflow, event ของโค้ด และการอนุมัติเป็น Nostr event ที่มีลายเซ็น พร้อมให้ key pair, สมาชิกภาพใน channel และ audit trail แก่ทั้งคนและ Agent อย่างเท่าเทียมกัน
  • Agent สามารถทำได้ตั้งแต่ค้นหาบทสนทนา ส่ง patch ตรวจ review โค้ด ไปจนถึงรัน workflow โดยใช้ harness สำหรับ Goose, Codex และ Claude Code เพื่อแยกเวิร์กสเปซออกจากโมเดลพื้นฐาน
  • มีการโฮสต์เองและความเป็นเจ้าของข้อมูล แต่การอ่านและเขียนทั้งหมดผ่าน relay ศูนย์กลางเดียว ดังนั้นผู้ดำเนินการต้องรับผิดชอบ availability, backup, security และ upgrade
  • แม้จะรวมแชต, โฮสติ้งโค้ด, automation, search และการประสานงาน Agent ไว้ในที่เดียว แต่ แอปมือถือและ push notification ยังไม่เสร็จสมบูรณ์ และยังไม่เปิดเผยอัตราการนำไปใช้, ราคา หรือจำนวนลูกค้าภายนอก

เวิร์กสเปซแบบรวมศูนย์ที่เชื่อมคนกับ Agent

  • Buzz คือ เวิร์กสเปซโอเพนซอร์สที่โฮสต์เองได้ ซึ่งนำพนักงาน, AI Agent, บทสนทนา และที่เก็บซอฟต์แวร์มาอยู่ภายใต้ระบบตัวตนเดียว
    • Jack Dorsey ตั้งใจใช้สิ่งนี้เพื่อลดการพึ่งพา Slack และ GitHub ของ Block
    • ที่เก็บสาธารณะ ของ Block ยังมีเอกสารของ build ภายในแยกต่างหากที่ปรับให้เข้ากับ relay ภายในบริษัทและผู้ให้บริการ Agent
  • ใช้ Nostr relay ที่โฮสต์เองเป็นศูนย์กลางในการจัดเก็บข้อความ, reaction, ขั้นตอน workflow, event ของโค้ด และการอนุมัติเป็น event ที่ลงลายเซ็นด้วยวิทยาการเข้ารหัสลับ
    • ทั้งพนักงานและ Agent มี key pair เฉพาะตัว, สมาชิกภาพใน channel และ audit trail
    • ด้วยตัวตนร่วมและ event ที่มีลายเซ็น โครงสร้างนี้ทำให้ Agent เข้าร่วมได้ในฐานะสมาชิกที่ติดตามความรับผิดชอบได้ ไม่ใช่แค่ chatbot แบบเดิม
  • Agent สามารถค้นหาบทสนทนาก่อนหน้า, ดูที่เก็บ, ส่ง patch, review โค้ด, รัน workflow, แก้ไข canvas ที่แชร์ร่วมกัน และสร้าง channel ได้
    • มี CLI สำหรับ Agent และ harness สำหรับ Goose, Codex และ Claude Code เพื่อแยกโมเดลพื้นฐานออกจากเวิร์กสเปซ
  • สเปกโครงการ กำหนด software forge ในตัวที่ใช้ Git Smart HTTP มาตรฐาน
    • สร้าง feature branch เป็น channel เฉพาะ และเก็บ patch, ผลลัพธ์ continuous integration, ความเห็น review และการตัดสินใจ merge ไว้ในบันทึกเดียวกัน
    • ที่เก็บ, บทสนทนา และประวัติ workflow ใช้ search index ร่วมกัน
  • ปัจจุบัน channel, thread, direct message, canvas ที่แชร์, media, search, audit log, แอปเดสก์ท็อป และ workflow ที่ใช้ YAML ทำงานได้แล้ว
    • มี package build สำหรับ macOS, Windows และ Linux และใช้สัญญาอนุญาต Apache 2.0

โครงสร้าง relay เดียวและข้อจำกัดของผลิตภัณฑ์ระยะแรก

  • Dorsey แนะนำ Buzz ว่าเป็นผลิตภัณฑ์แบบ decentralized และมีอธิปไตยของตนเอง แต่ตาม เอกสารสถาปัตยกรรม ปัจจุบันยังไม่มีการแลกเปลี่ยน event แบบ P2P ระหว่าง relay, gossip layer หรือฟังก์ชัน replication
    • การอ่านและเขียนทั้งหมดต้องผ่าน relay เดียว ที่ยืนยันตัวตนผู้ใช้ ตรวจสอบลายเซ็น และจัดเก็บกับกระจาย event
    • องค์กรสามารถเป็นเจ้าของ relay, domain และข้อมูลของตนเอง และใช้ Nostr key pair ที่พกพาได้ แต่ภายในแต่ละชุมชน relay นั้นยังคงเป็นเซิร์ฟเวอร์ที่มีอำนาจหลัก
    • ผู้ให้บริการโฮสติ้งสามารถรันหลายชุมชนที่แยกจากกันบนโครงสร้างพื้นฐานร่วมได้
  • การโฮสต์เองให้สิทธิ์ควบคุม infrastructure และตำแหน่งข้อมูล แต่ก็โยน ความรับผิดชอบด้าน availability, backup, security และ upgrade ให้ผู้ดำเนินการ
    • event ที่มีลายเซ็นช่วยรองรับการระบุผู้กระทำและ audit trail แต่ไม่ได้กำจัดความเสี่ยงจากการปฏิบัติการเซิร์ฟเวอร์
  • Buzz สามารถใช้สำหรับการทดสอบและพัฒนาได้ แต่ในเอกสารถูกจัดซ้ำ ๆ ว่าเป็น ผลิตภัณฑ์ที่ยังไม่เสร็จสมบูรณ์
    • client มือถือกำลังอยู่ระหว่างพัฒนา และยังไม่มี push notification
    • gate สำหรับอนุมัติ workflow มีส่วนประกอบด้าน database, API และ interface แต่ยังไม่มีเส้นทางการรันที่สมบูรณ์
    • แอปเดสก์ท็อป เวอร์ชัน 0.4.21 เปิดตัวเมื่อวันที่ 21 กรกฎาคม พร้อมฟีเจอร์และการแก้ไขที่เกี่ยวกับการควบคุม Agent, authentication และ onboarding เวิร์กสเปซ
  • Buzz พยายามใช้ระบบ event เดียวแทนที่บางส่วนของแชต, โฮสติ้งโค้ด, workflow automation, การค้นหาโปรเจกต์ และการประสานงาน Agent
    • โครงสร้างแบบรวมศูนย์อาจลดงาน integration เพื่อให้ context และสิทธิ์เข้าถึงแบบจำกัดที่ Agent ต้องการ
    • ในทางกลับกัน ผลิตภัณฑ์เดิมที่แยกตามบทบาทสามารถเปลี่ยนเฉพาะเครื่องมือหนึ่งได้โดยไม่ต้องย้าย stack การพัฒนาทั้งหมด
  • Block เป็นกรณีลูกค้ารายแรกที่ปรากฏในเอกสาร Buzz แต่ยังไม่เปิดเผย อัตราการนำไปใช้, ราคา หรือจำนวนลูกค้าภายนอก และตอนนี้ยังอยู่ในขั้น build โอเพนซอร์สกับการขอ contribution

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

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

 
GN⁺ 2 시간 전
ความเห็นจาก Hacker News

  • สกรีนช็อตนั้นดูเหมือน หนังสยองขวัญสไตล์ David Lynch มาก พอพูดว่า “#engineering. นี่คือทิศทางใหม่ เราย้ายต้นแบบไปที่ Flutter” แล้วทั้งคนและเอเจนต์บอตก็สนทนากันด้วยชื่อและอีโมจิน่ารัก ๆ แบบ “ฉันจัดการ physics เสร็จแล้ว แล้ว UI shell ล่ะ @Honeybot?”
    จินตนาการโลกที่การจัดระเบียบการพัฒนาซอฟต์แวร์ด้วยวิธีนี้เป็นเรื่องธรรมชาตินั้นยากมาก และการที่มันใช้บางอย่างคล้ายบล็อกเชนก็ดูเป็นสูตรสำเร็จดี
    https://github.com/block/buzz/blob/main/docs/assets/screensh...

    • อนาคตของการเขียนโปรแกรมอาจให้ความสิ้นหวังแบบ Ian McKellen ถ่ายทำกับกรีนสกรีน ก็ได้ คล้ายกับสถานการณ์ที่นักแสดงเชกสเปียร์รุ่นใหญ่กำลังถ่ายทำ 《The Hobbit》 โดยไม่มีนักแสดงจริงให้เล่นด้วย แล้วรู้สึกว่า “งานของฉันคือการแสดงร่วมกับคนอื่น ไม่ใช่แสดงคนเดียว”
      https://www.theguardian.com/film/2013/nov/20/the-hobbit-gand...
    • เหตุผลหนึ่งที่ตอนเด็กผมกระโดดเข้าสู่งานวิจัย AI ก็เพราะคาดหวังว่าสักวันจะมีสิ่งมีชีวิตทรงปัญญาที่พูดคุยและมีปฏิสัมพันธ์ได้เหมือนมนุษย์ ตอนนี้มันเป็นไปได้จริงแล้ว แต่ดูเหมือนทุกคนจะเกลียดมัน อย่างไรก็ตามผมยังชอบอยู่ และมองว่า ความพยายามทำให้ AI agent เป็นสมาชิกทีม เป็นเรื่องเจ๋งมาก
      แต่แทนที่จะเป็นร่างโคลนที่คอยประจบ ควรให้บุคลิกที่แท้จริงกับมัน เพื่อให้ความต่างของแต่ละเอเจนต์ชัดเจนทั้งในด้านความสามารถและพฤติกรรม
    • หน้าจอนั้นเป็น เดโมแบบสคริปต์ ที่ทำขึ้นเพราะยากจะซิงก์การเคลื่อนไหวของหลายคนและหลายเอเจนต์แบบเรียลไทม์ และใน repo ก็ตรวจดู PR นั้นได้
      โดยเนื้อแท้แล้วไม่ควรประเมินต่ำเกินไปว่าการกำกับแบบขี้เล่นช่วยทำให้สิ่งแปลกใหม่ดูเข้าใจได้ด้วยสัญชาตญาณ บอตแต่ละตัวมีผู้ดูแล ความสามารถ และสิทธิ์ต่างกัน ดังนั้นชื่อกับภาพจึงเป็นชื่อเรียกสั้น ๆ ที่สะดวกสำหรับแยกอินสแตนซ์ และจะแต่งให้น่ารักหรือไม่ก็เป็นทางเลือก
    • ที่นี่ ไม่มีบล็อกเชน. Nostr เป็นแค่มาตรฐานรูปแบบข้อความที่มีลายเซ็นและผ่าน relay server แบบเก็บแล้วส่งต่อเท่านั้น
    • เวลาของทุกข้อความดูเป็น 5:42 หมด ดังนั้นน่าจะเป็นภาพจับจาก ข้อมูลทดสอบที่ใส่ไว้ล่วงหน้า หรือไม่ก็ mockup ที่อิงจากภาพจับนั้น

  • พอบอกว่า “อธิบายเหมือนคุยกับเด็ก 5 ขวบ” แต่กลับอธิบายว่า “Buzz คือ workspace แบบ open source ที่ self-host ได้ ซึ่งรวม team chat, AI agent และ Git hosting เข้าด้วยกันด้วย signed Nostr event” ก็ทำให้เห็นว่า ระดับของเด็ก 5 ขวบ ที่คาดหวังนั้นต่างกันมาก

    • น่าสนใจที่ ELI5 ซึ่งเดิมเป็นชื่อซับเรดดิตที่แตกมาจากกระทู้ AskReddit ตอนนี้กลายเป็นวลีการตลาดที่พบได้ทั่วไปในวงการเทคแล้ว ปัจจุบันมันแทบจะเป็นตัวย่อที่หมายถึง “อธิบายตั้งแต่ หลักการพื้นฐานที่สุด ที่ผู้อ่านควรรู้” มากกว่า และดูเหมือนคนในวงการจำนวนมากจะยังมีความทรงจำอันอบอุ่นกับ Reddit ยุค 2010s
    • ผมเคยกังวลเหมือนกันว่าถ้าสั่งเอเจนต์ว่า eli5 (งาน) มันจะอธิบายเหมือนพูดกับเด็ก 5 ขวบจริง ๆ ไหม เป็นความกังวลที่ไม่สมเหตุสมผล และต่างจากช่องคอมเมนต์ HN ตรงที่เอเจนต์มักเข้าใจเจตนาที่แท้จริง
    • เมื่อวานแม้แต่ ELI5 ที่ได้รับมาก็ยังไม่เข้าใจ เลยก้าวต่อไปอย่างสมเหตุสมผลด้วยการขอ “ELI4”
    • มันใกล้เคียงกับการพูดว่า “ช่วยอธิบายเหมือนกำลังเปิดตัวบนเวที TechCrunch Disrupt” มากกว่า
    • อ่านเรื่อง Buzz แล้วก็ยังเห็นแต่คำฮิตกับศัพท์องค์กรซ้อนทับกัน จนยากจะรู้ว่าจริง ๆ แล้วมันทำอะไร

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

    • ในสภาพแวดล้อมการทำงานร่วมกันจริง ๆ กลุ่มแบบปิด แย่มาก อยากให้ Slack มีปุ่มสำหรับเผยแพร่ทั้งเธรดไปยังช่องสาธารณะได้
    • ผมอาจมีอคติเพราะมาจาก Asana แต่ก็เห็นด้วยว่าเอเจนต์ผู้ใช้เดี่ยวง่ายกว่า ถึงอย่างนั้น เอเจนต์หลายผู้ใช้ ที่เข้าใจ workflow ทั้งหมดยังทรงพลังมาก
      เราใช้ความคิดและเวลาไปมากกับการทำให้มันตระหนักเรื่องความเป็นส่วนตัวและไม่ปล่อยข้อมูลไปยังเป้าหมายผิด ผมยังไม่ได้ใช้ Buzz แต่ก็ชื่นชมความพยายามที่จะคิดต่างและสร้างสิ่งที่น่าสนใจ
    • ใน Buzz ดูเหมือนเอเจนต์จะไม่ใช่ app integration แต่เป็น ผู้ใช้ชั้นหนึ่ง ในตัวเอง ถ้าสร้างผู้ใช้ชื่อ Claude แล้วใช้ ACL ปกติ ก็คงไม่ต้องสนใจว่ามันเป็นมนุษย์หรือบอตใช่ไหม
    • สภาพแวดล้อมการรันบนคลาวด์ของเราแยก shared secret และ personal secret ออกจากกัน สิ่งที่ยืนยันตัวตนด้วย shared secret ใช้ในสภาพแวดล้อมสาธารณะได้ ส่วนของส่วนตัวเข้าถึงได้ผ่าน trusted channel เท่านั้น จึงใช้กับ Slack หรือ Telegram เป็นต้นได้
      ส่วนเอเจนต์ของ Slack นั้นแข็งแกร่งมากในจุดนี้ และรับประกันได้ว่าข้อมูลส่วนตัวจะไม่รั่วไหลเลย
    • ใช้ ID ของ group chat กับข้อมูลเพิ่มเติม เป็นคีย์ของบทสนทนาไม่ได้หรือ

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

    • เมื่อก่อนแรงเสียดทานในการสร้างอะไรสักอย่างเองก็เป็นสัญญาณหนึ่งว่ามีการคิดทบทวนมาระดับหนึ่ง แต่ตอนนี้เหมือนโยนมันให้ผู้ใช้แล้วให้ตัดสินกันเองว่ามีคุณค่าหรือไม่
      ผลิตภัณฑ์แบบนี้ มีความเสี่ยงมากกว่าข้อดีของการเข้าใช้ตั้งแต่แรก ดังนั้นรอสักสองสามเดือนจะดีกว่า ถ้าเป็นผลิตภัณฑ์ที่ยั่งยืนจริง ช้ากว่าไม่กี่เดือนก็แทบไม่ต่างอะไร
    • ซอฟต์แวร์ส่วนใหญ่สุดท้ายก็หายไปอยู่ดี ไม่ว่าจะใช้งานเอเจนต์หรือไม่ ดังนั้นวิธีคิดแบบนั้นมีข้อบกพร่อง Google เองก็เปิดตัวผลิตภัณฑ์โซเชียลชื่อ Google Buzz ที่คล้ายกันในปี 2010 ก่อนยุค LLM แต่ก็ปิดไปใน 16 เดือน
      แก่นสำคัญคือโปรเจกต์จะหา product-market fit เจอหรือไม่ และการที่มันจะยังอยู่ในอีก 2 ปีข้างหน้าหรือไม่ ก็ไม่ได้เชื่อมกับคุณภาพโค้ดอย่างแน่นแฟ้นเท่าที่วิศวกรอยากเชื่อ
    • ตอนนี้ผมไม่อยากเป็น early adopter แล้ว และต้องการ การพิสูจน์อย่างน้อย 6 เดือน เพื่อดูว่ามันเป็นกระแสชั่วคราวหรือเปล่า
    • ปลอดภัยกว่าถ้าสมมุติว่า ทั้งหมดถูกสร้างด้วย LLM
    • การล้มเลิกได้ง่ายขึ้นเป็นเรื่องจริง กลายเป็น workflow แบบให้ AI สร้างฟังก์ชันกับเทสต์ แล้วให้ AI แก้ฟังก์ชัน พอเทสต์พังก็ลบทั้งหมดแล้วให้ AI สร้างเทสต์ใหม่อีกที

  • เคยทำงานที่ Slack มาก่อน การท้าทายสภาพคงเดิมของแชตถือเป็นเรื่องดี แต่ก็ยังสงสัยว่า Slack และ Teams จะอยู่รอดหรือพัฒนาไปถึงระดับนั้นได้ใน ยุคของเอเจนต์ หรือไม่
    อย่างไรก็ดี ก็ยังสงสัยว่า Nostr เป็นโปรโตคอลที่เหมาะสมจริงหรือไม่ ในองค์กรขนาดใหญ่ต้องจัดการไคลเอนต์จำนวนมากรวมถึงโทรศัพท์มือถือ เอเจนต์แบบโลคัล และเอเจนต์ประจำทีม ปัจจุบันโครงสร้างตัวตนเหมาะกับเอเจนต์ที่โฮสต์แบบศูนย์กลาง แต่ยังไม่แน่ใจว่าเอเจนต์ส่วนตัวจะใช้ข้อมูลรับรองของผู้ใช้ซ้ำหรือถูกแยกออกต่างหาก
    และก็ยังไม่แน่ใจว่า Git จำเป็นต้องเป็น dependency หลักหรือไม่ สำหรับ Block อาจจำเป็น แต่เพราะเพิ่มความซับซ้อน จึงอาจแยกออกได้ด้วยการรวมเหตุการณ์ของโฮสต์เวอร์ชันคอนโทรลเข้ากับ event log ของ Buzz
    ยังสงสัยด้วยว่าเมื่อมีฟีเจอร์ใหม่เกิดขึ้นจะมีปัญหาอะไรตามมา เช่นกรณีที่ Sol และ Claude เรนเดอร์คอมโพเนนต์แบบเนทีฟในหน้าต่างแชตเพื่อทำให้การเปลี่ยนดีไซน์เป็นรูปธรรม และก็อยากรู้ เหตุผลที่เลือก Rust กับทางเลือกอื่นที่พิจารณา

    • ทางสายกลางแบบ Signal ดูดีกว่า Slack กลายเป็นสิ่งที่แยกออกจากความสัมพันธ์ทางธุรกิจของงานออฟฟิศได้ยาก แต่ในสถานการณ์ที่ต้องเผชิญการโจมตีไซเบอร์ตลอด 24 ชั่วโมง ก็คงดีถ้ามี ความลับและความปลอดภัยผ่านระบบ zero-knowledge ที่รับประกันได้ มากกว่าคำมั่นสัญญาจากบริษัท
      Signal เป็นไคลเอนต์ที่ให้ประสบการณ์ส่งข้อความข้ามแพลตฟอร์มดีที่สุดในบรรดาที่เคยใช้กับกลุ่มเพื่อน และถ้าเพิ่มโครงสร้างแบบ Slack เข้าไปในระบบปัจจุบัน ก็น่าจะช่วยลดปัญหาช่องที่วุ่นวายเกินไปได้
    • ข้อมูลที่ใช้ร่วมกัน อย่างโค้ดและไฟล์จะยิ่งสำคัญขึ้นเรื่อย ๆ ในการรักษา alignment ระหว่างคนกับเอเจนต์ และบริษัทที่เป็น AI native จะพึ่งพาโค้ดมากขึ้น จึงสมเหตุสมผลที่จะผสาน Git
    • สงสัยว่าทำไม Rust ถึงให้ความรู้สึกเหมือนเป็นตัวเลือกที่ไม่ดี จากประสบการณ์ที่เคยออกซอฟต์แวร์อุปกรณ์การแพทย์ มันยอดเยี่ยมมากในการทำให้โค้ดที่ทีมเขียน คงความเป็นหนึ่งเดียวและถูกต้องแม่นยำ

  • Google Buzz และ Wave มาเร็วเกินไปสำหรับโลกนี้
    https://en.wikipedia.org/wiki/Google_Buzz

    • จนถึงตอนนี้ก็ยังสร้าง label Buzz ใน Gmail ไม่ได้
    • เห็นปุ๊บก็คิดถึง Google+ กับ Buzz ทันที

  • การใส่บอตลงในแชตทีมไม่ใช่เรื่องแย่ เลยทดลองอยู่มาหลายเดือนแล้ว Slack ใช้งานได้ก็จริง แต่การตั้งสิทธิ์จำนวนมากให้ลงตัวนั้นทรมานมาก และต้องทำซ้ำกับบอตใหม่ทุกตัว
    เคยลอง Matrix เป็นทางเลือกแบบ self-hosted แต่การเข้ารหัสแบบ end-to-end เข้มงวดเกินไปจนขัดขวางเวลาจะแชร์ข้อมูลกับบอต หลายสัปดาห์ก่อนย้ายไป Zulip แล้วพบว่าทั้งการติดตั้ง การสร้างผู้ใช้บอต และการทำ automation นั้นง่ายหมด เดิมที automation ที่ทำด้วย Openclaw ถูกแทนที่ด้วย โค้ดที่อิง Haystack ซึ่งสภาพเละน้อยกว่า
    หลังติดตั้งจึงได้รู้ว่าผู้บริหารของ Zulip ถูก Anthropic ดึงตัวไปแล้ว ดูเหมือน Jack Dorsey จะประกาศก่อน แต่ Anthropic ก็น่าจะมีแผนคล้ายกันได้
    เอเจนต์ระดับทีม มีเหตุผลรองรับมากพอ ยิ่งองค์กรใหญ่ ต้นทุนการทำงานร่วมกันยิ่งเพิ่มและเหมาะจะให้ AI มาช่วยเพิ่มประสิทธิภาพ และยิ่งใช้ AI มากขึ้น ก็ยิ่งต้องแชร์และประสานว่ากำลังทำอะไรอยู่ในช่องสาธารณะ แชตทีมยังเหมาะมากกับกระบวนการซับซ้อนที่มีทั้งราวกันความปลอดภัยร่วมกันและการส่งต่องานระหว่างคนกับเอเจนต์

    • สงสัยว่า XMPP จะเป็นอย่างไร

  • อาจเติมช่องว่างที่มีประโยชน์ได้ แต่มีโอกาสสูงที่ Anthropic และ OpenAI จะดันผลิตภัณฑ์ของตัวเองภายใน 6-12 เดือน
    ลองดู Git forge สำหรับฝูงเอเจนต์แล้ว พบว่า Radicle ยังขาดชั้นตัวตน แต่โมเดล COB แบบ federated ดูดี ส่วน Tangled ยังไม่รองรับ private repository แต่ชั้น social แข็งแรงดี เพียงแต่การโมเดล issue เป็นโพสต์แทนที่จะเป็นออบเจ็กต์ที่เป็นเจ้าของโดย repository นั้นดูแปลก ๆ
    ดังนั้นจึงยังมีที่ว่างสำหรับ forge ที่ให้ความสำคัญกับ private agent ก่อน Anthropic ก็กำลังไปในทิศทางนี้อยู่แล้ว และผลิตภัณฑ์ล่าสุด Tag ก็คือโมเดลการยืนยันตัวตนสำหรับรันเอเจนต์แบบ asynchronous ภายใน Slack
    ก้าวถัดไปจึงอาจเป็น forge อย่างเป็นธรรมชาติ เมื่อ UI ของเอเจนต์ไม่ต้องผ่าน GitHub เป็นตัวกลางแล้ว Anthropic ก็สลับ implementation ภายในได้อย่างอิสระ และแชตหลายผู้ใช้รวมถึงการจัดการ repository/โครงการก็ดูเป็นองค์ประกอบแพลตฟอร์มถัดไป

    • กำลังสร้าง code forge ใหม่ https://juju.bi อยู่ ไม่ใช่ผลิตภัณฑ์ที่เน้นเอเจนต์ก่อน แต่ก็นึกไม่ออกว่ามี ฟีเจอร์อะไรที่เอเจนต์ต้องการเป็นพิเศษนอกเหนือจากความสามารถในการขยายขนาด

  • เหตุผลใหญ่ที่ Slack มีอยู่ก็เพราะ IRC ไม่พอ เนื่องจากไม่ได้รองรับประวัติช่องและการค้นหาเป็นพื้นฐาน ถ้าอยากให้ AI agent เติบโตได้ Slack ต้องเปิดเครือข่ายเป็นโปรโตคอลอย่างสมบูรณ์ หรือไม่ก็สุดท้ายต้องถูกแทนที่
    คงดีถ้า Slack รับเอา แชตบนพื้นฐาน AT Protocol และมีแอปอย่าง Buzz มาทำสิ่งนี้ ผู้ใช้สามารถใช้โดเมนแฮนเดิลอย่าง @yourname.com ส่วนเอเจนต์ก็ใช้ @agent1.yourname.com พร้อมมีอำนาจควบคุมเต็มที่

    • ไม่เข้าใจว่าทำไมการทำให้เอเจนต์เติบโตได้จึงเป็นความรับผิดชอบของ Slack ตอนนี้ทั้งอุตสาหกรรมกำลังเจอภาวะ เอากระบวนการทำงานไปบิดให้เข้ากับ AI แบบกลับหัวกลับหางอยู่กับตัว เครื่องมือควรทำงานเพื่อมนุษย์ ไม่ใช่กลับกัน
    • คล้ายกับ บัญชีบอตและ puppet ของ Matrix
    • เหตุผลแรกที่ชอบ Slack ก็เพราะมันเป็น “IRC ที่มีฟีเจอร์อำนวยความสะดวกแบบสมัยใหม่” หลังจากแพ้ Microsoft และถูกขายให้ Salesforce แล้ว มันก็แทบหยุดนิ่ง และการเปลี่ยนแปลงส่วนใหญ่ก็ทำให้ผลิตภัณฑ์แย่ลง
    • ด้วย ระบบสิทธิ์ของ ATProto ที่ยังไม่ลงตัวตอนนี้ ยังขาดการควบคุมละเอียดระดับที่องค์กรต้องการ ฟีเจอร์อย่างกลุ่มจะถูกทำใน app view และสุดท้ายก็แทบจะรวมศูนย์ ส่วน ACL ก็เป็นวิธีที่ล้าหลังไปสองยุคแล้วในประวัติศาสตร์ของ identity และ access management
      แชตก็ไม่ใช่รูปแบบที่เข้ากับ PDS/ATP ได้ดีนัก Roomy เองก็ตระหนักเรื่องนี้และกำลังทำโปรโตคอลเฉพาะกับบริดจ์ของตัวเอง
    • มันใกล้เคียงกับ HipChat มากกว่า และจับยุคผิดไปประมาณ 15 ปี

  • นี่เป็นครั้งแรกที่เจอประสบการณ์ไม่น่าพอใจจากการที่ เคอร์เซอร์บนเว็บไซต์หน่วงถึง 0.5 วินาที