การทำภาพข้อมูลผู้ใช้ Bluesky 13 ล้านคน

 (joelgustafson.com)
1 คะแนน โดย GN⁺ 2024-11-14 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ด้วยสตรีมอีเวนต์สาธารณะ ทำให้บน Bluesky สามารถสร้าง แผนที่กราฟโซเชียลทั้งระบบ ในสเกลผู้ใช้ 13 ล้านคนได้ ซึ่งเป็นสิ่งที่ทำได้ยากมากบน Twitter
  • ไปป์ไลน์การเก็บข้อมูลกรองเฉพาะการติดตามและเลิกติดตามจาก WebSocket firehose ของ bsky.network แล้วบันทึกลง SQLite โดยในเวลานั้นตาราง follows มีมากกว่า 500 ล้านแถว และมีขนาดราว 30GB
  • เพื่อจัดวางกราฟที่มี 13 ล้านโหนดและ 500 ล้านเอดจ์ จึงสร้างเอนจิน force-directed layout แบบมัลติเธรดบน Zig ชื่อ Andromeda แต่ก็พบข้อจำกัดว่ากับกราฟโซเชียลขนาดใหญ่ โครงสร้างระดับท้องถิ่นจะถูกกลบเลือน
  • ใช้การผสานระหว่าง embedding ของ GGVec กับ UMAP เพื่อให้ได้ โครงสร้างระดับกลาง มากขึ้น และแก้ปัญหาจุดของ UMAP ซ้อนกันด้วยการจำลองเพิ่มอีกไม่กี่ติ๊กใน Andromeda เพื่อเกลาคลัสเตอร์ที่หนาแน่น
  • แผนที่สุดท้ายหลังกรองข้อมูล ณ วันที่ 7 พฤศจิกายน 2024 แสดง 7.7 ล้านโหนด และสามารถสำรวจวงบอต คลัสเตอร์ตามประเทศ และกลุ่มบัญชีสื่อ/นโยบายที่มีผู้ติดตามสูงได้

เหตุผลที่แผนที่เครือข่ายทั้งหมดของ Bluesky เป็นไปได้

  • Twitter ไม่เปิดให้ใช้ข้อมูลทั้งหมด และการสแครปก็ทำได้ยากหรืออาจผิดกฎหมาย จึงสร้างแผนที่ทั้งระบบได้ยาก
  • BlueSky ให้เข้าถึงข้อมูลที่จำเป็นได้ และเติบโตอย่างมากในช่วงหลายเดือนของปี 2024
    • ปัจจัยเบื้องหลังการเติบโตมีทั้งความขัดแย้งต่อเนื่องระหว่าง Twitter กับฐานผู้ใช้ และการแบน Twitter ในบราซิลเมื่อเดือนตุลาคม 2024
  • ผลลัพธ์สามารถสำรวจแบบแผนที่อินเทอร์แอ็กทีฟได้ที่ aurora.ndimensional.xyz
    • ใช้ WebGPU จึงต้องใช้ Chrome/Chromium บนเดสก์ท็อป

วิธีเก็บกราฟการติดตาม

  • เพื่อลดขอบเขตงาน จึงใช้เฉพาะ กราฟการติดตาม แทนกิจกรรมทั้งหมด
    • การติดตามแต่ละครั้งถูกนับเป็นเอดจ์แบบไม่มีทิศทางหนึ่งเส้น
    • ถ้าติดตามกันทั้งสองฝ่าย จะเกิดสองเอดจ์ ทำให้น้ำหนักเพิ่มเป็นสองเท่าโดยพฤตินัย
  • BlueSky สร้างบน AT Protocol และออกแบบมาให้ผู้ใช้โฮสต์ PDS (personal data server) ของตัวเองได้
  • การเก็บข้อมูลจริงใช้ WebSocket firehose ของ relay bsky.network ที่ทีม BlueSky ดูแล
    • มันรวบรวมอีเวนต์จาก PDS หลัก *.bsky.social และ PDS อิสระที่ขอให้ทำ indexing
    • อีเวนต์ของเครือข่ายทั้งหมดถูกสตรีมแบบเรียลไทม์ ปัจจุบันอยู่ราว 500 อีเวนต์ต่อวินาที
    • จากนั้นกรองเฉพาะการติดตามและเลิกติดตามแล้วเก็บลงฐานข้อมูล SQLite ภายในเครื่อง
  • ช่วงแรกมีการ deploy ตัว indexer ไปที่ fly.io และใช้ litestream ทำสำเนาฐานข้อมูลแบบเรียลไทม์ไปยัง AWS S3 แต่เพราะค่าใช้จ่ายเดือนละ 40 ดอลลาร์จึงย้ายมาใช้โฮมเซิร์ฟเวอร์
    • หลังจากนั้นรันบนเดสก์ท็อป System76 ที่บ้าน โดยใช้ systemd service, logrotate, tmux monitor และ TailScale ร่วมกัน
  • ณ เวลาที่เขียน BlueSky มีผู้ใช้เกิน 13 ล้านคนแล้ว และตาราง follows มี มากกว่า 500 ล้านแถว ใช้ดิสก์ประมาณ 30GB

คอขวดในการคำนวณกราฟ 13 ล้านโหนด

  • มีหลายวิธีในการจัดวางกราฟ แต่จุดเริ่มต้นในที่นี้คือ force-directed layout ที่ทำงานคล้ายการจำลองฟิสิกส์
    • ทุกโหนดมีแรงผลักซึ่งกันและกัน
    • เอดจ์สร้างแรงดึงระหว่างต้นทางกับปลายทาง
    • ในแต่ละ simulation tick จะคำนวณแรงลัพธ์ของแต่ละโหนด แล้วสเกลด้วยพารามิเตอร์อุณหภูมิก่อนขยับตำแหน่ง
  • คอขวดไม่ได้อยู่ที่ขนาดกราฟเพียงอย่างเดียว แต่อยู่ที่ความซับซ้อนเชิงคำนวณของ n-body problem
    • อัลกอริทึมแบบตรงไปตรงมาต้องใช้ O(n^2) + O(e) ต่อหนึ่งติ๊ก
    • ในสเกลหลายล้านโหนด แม้ใช้ GPU ก็ยังไม่สมจริง
  • ถ้าใช้การเพิ่มประสิทธิภาพแบบ Barnes-Hut เหมือนเอนจิน force-directed ทั่วไป จะลดเหลือ O(n log(n)) + O(e)
    • แต่ต้องแลกกับการประมาณผลของโหนดที่อยู่ไกล
    • การสร้างและ query quadtree มีลักษณะเป็นลำดับชั้น จึงคำนวณแรงของโหนดบน GPU ได้ไม่ง่าย
  • เพื่อทำงานขนาน จึงแบ่ง quadtree ออกเป็น 4 หรือ 16 ส่วน สร้างใหม่พร้อมกันตอนเริ่มแต่ละติ๊ก แล้วแบ่งช่วงของโหนดให้แต่ละเธรดคำนวณแรง
    • แรงลัพธ์ของแต่ละโหนดคือผลรวมของแรงจากแต่ละ quadtree และแรงจากเอดจ์ขาเข้าและขาออก
    • วิธีนี้ใช้ CPU ที่มีอยู่ได้แทบเต็มโดยมี overhead น้อยมาก

Andromeda และข้อจำกัดของแนวทาง force-directed

  • มีการสร้างเอนจินจัดวางกราฟแบบ force-directed มัลติเธรดบน Zig ชื่อ Andromeda และทำ GUI ด้วย GTK4 และ OpenGL
  • Andromeda ได้อิทธิพลอย่างมากจาก Gephi และบทความ ForceAtlas2
    • ในการทำภาพกราฟขนาดใหญ่ ความโต้ตอบได้ มีความสำคัญ เพราะต้องดูการเปลี่ยนแปลงของกราฟและปรับพารามิเตอร์การจำลองแบบไดนามิก
    • ถ้าเป็นเครื่องมือที่ทึบและต้องวนรันนาน จะได้ผลลัพธ์ที่ดีได้ยาก
  • ใน Andromeda ยังมีวิดเจ็ต UI ที่ชื่อ “natural slider”
    • มันช่วยลดปัญหาที่ไม่รู้ล่วงหน้าว่าช่วงค่าที่เหมาะสมควรเป็นเท่าไร เมื่อต้องเจอกับกราฟใหม่ เอนจินเวอร์ชันใหม่ หรือพารามิเตอร์ใหม่
    • ตัวมันจะปรับช่วงค่าแบบไดนามิกตามกำลังของ e
    • เพราะมองว่ากำลังของ 2 เล็กเกินไป ส่วนกำลังของ 10 ใหญ่เกินไป
  • เมื่อนำเลย์เอาต์ ForceAtlas2 ไปใช้กับสแนปช็อต Bluesky ที่มีผู้ใช้ 5 ล้านคนในเดือนกันยายน 2024 จะเห็นมวลและความหนาแน่นของคลัสเตอร์ใหญ่ ๆ แต่โดยรวมยัง จับตัวเป็นก้อน มาก
    • โหนดส่วนใหญ่กระจายอยู่รอบซูเปอร์คลัสเตอร์ในบริเวณกว้างที่แยกความต่างได้ยาก
    • มีเพียงชุมชนขนาดเล็กราวหลายสิบแห่งเท่านั้นที่แยกออกชัด โดยส่วนใหญ่เป็นชุมชนตามประเทศ
  • ตอนเผยแพร่เวอร์ชัน 2 ล้านบัญชีในเดือนกุมภาพันธ์ 2024 แม้มุมมองระดับโลกจะน่าสนใจ แต่มุมมองระดับท้องถิ่นกลับน่าผิดหวัง
    • ผู้ใช้บางคนหาบัญชีของตัวเองเจอ แต่กลับจำบัญชีรอบข้างไม่ได้
    • การจัดวางบนระนาบ 2 มิติอย่างเดียวจับโครงสร้างการเชื่อมต่อของเครือข่ายทั้งหมดได้ไม่ครบถ้วน

UMAP, สี และแผนที่สุดท้าย

  • การจัดวางกราฟสามารถมองเป็นการ ลดมิติข้อมูล ได้เช่นกัน โดยเป็นปัญหาการฉาย adjacency matrix ขนาด 13 ล้าน × 13 ล้าน ลงบนระนาบ 2 มิติ
  • t-SNE และ UMAP เป็นเทคนิคลดมิติแบบไม่เชิงเส้นที่เหมาะกับการแสดงผล 2 มิติ
    • แต่การป้อนเมทริกซ์ของ BlueSky เข้า UMAP โดยตรงมีขนาดใหญ่เกินไปสำหรับโฮมเซิร์ฟเวอร์
    • จึงสร้าง embedding ต่อผู้ใช้ราว 32 มิติก่อน แล้วค่อยส่งผลลัพธ์เข้า UMAP
  • เลือกใช้เครื่องมือทำ node embedding แบบโอเพนซอร์ส nodevectors และพบว่าอัลกอริทึม GGVec ที่ยังไม่เผยแพร่ดูจะมีประสิทธิภาพแบบขนานดีที่สุดสำหรับกราฟขนาดใหญ่
    • embedding ของสแนปช็อต 5 ล้านโหนดในเดือนกันยายน 2024 สร้างเสร็จใน 5 นาที
    • ภาพ UMAP แรกได้มาในอีก 10 นาทีถัดมา
    • มันแสดง โครงสร้างระดับกลาง ได้มากกว่าผลลัพธ์แบบจับตัวเป็นก้อนของ Andromeda
  • UMAP มีปัญหาที่ทำให้บางคลัสเตอร์หนาแน่นเกินไปจนจุดซ้อนกัน
    • สำหรับเป้าหมายการลดมิติแบบบริสุทธิ์ ที่ต้องการให้จุดที่เหมือนกันในมิติต้นทางอยู่ตำแหน่งเดียวกันในมิติปลายทาง นี่ถือเป็นพฤติกรรมตามธรรมชาติ
    • แต่ไม่เหมาะกับแผนที่ที่ต้องแสดงรูปโปรไฟล์ของแต่ละบัญชีเมื่อซูมเข้าใกล้
  • ภายใน UMAP เอง ในขั้นตอนสุดท้ายก็ใช้ force-directed layout กับกราฟ weighted k-nearest neighbors
    • UMAP ใช้การสุ่มตัวอย่างเพราะข้อจำกัดด้านการคำนวณ จึงไม่ใช่ว่าทุกโหนดจะผลักกันทั้งหมด แม้แบบประมาณค่าเหมือน Barnes-Hut ก็ไม่ใช่
    • จึงมองว่าพารามิเตอร์ min_dist ควบคุมการแยกระหว่างจุดได้ไม่สม่ำเสมอในกราฟขนาดใหญ่
  • ปัญหาการซ้อนกันถูกบรรเทาด้วยการนำผลลัพธ์จาก UMAP เข้า Andromeda แล้วปรับสมการแรงผลักก่อนรันต่ออีกไม่กี่ติ๊ก
    • ทำให้แม้ในคลัสเตอร์หนาแน่น โหนดก็ไม่ทับกันเป็นชั้น ๆ แต่กระจายเติมพื้นที่มากขึ้น
    • ในเวอร์ชันถัดไปมีแผนจะเข้าถึงค่าน้ำหนักดิบของกราฟที่ UMAP สร้าง แล้วผสาน quadtree แบบขนานของ Andromeda เข้ากับสมการแรงจากบทความ UMAP โดยตรง
  • สีไม่ได้กำหนดจากการใช้ HDBScan กับผลลัพธ์ UMAP แต่ใช้ k-means clustering ใน embedding space แทน
    • กำหนด hue ให้แต่ละคลัสเตอร์
    • แต่ละจุดจะ interpolate hue จากศูนย์กลางคลัสเตอร์ที่ใกล้ที่สุด 3 แห่ง
    • วิธีนี้เผยโครงสร้างระดับท้องถิ่นได้ดีกว่าสีแบบ PCA และเมื่อซูมใกล้จะให้พื้นผิวคล้ายกระจกสีเป็นจุด ๆ
  • hue เป็น float เดี่ยวระหว่าง 0 ถึง 1 และถูกแมปเป็น RGB ด้วย color space แบบ hsluv
    • ทุกโหนดคงค่าความอิ่มสีเท่าเดิม
    • ความสว่างถูกสเกลด้วย log10 ของจำนวนผู้ติดตาม ทำให้บัญชีใหญ่ดูสว่างเหมือนดาว ส่วนบัญชีที่มีผู้ติดตามน้อยจะดูจางกว่า
    • แนวทางที่ทำให้บัญชีใหญ่ถูกเรนเดอร์ให้มีขนาดใหญ่จริง ๆ ถูกตัดออก เพราะจะซับซ้อนเกินไปสำหรับกราฟขนาดใหญ่
  • ณ วันที่ 7 พฤศจิกายน 2024 แผนที่เครือข่ายทั้งหมดถูกกรองออกจากบัญชีที่ติดตามมากกว่า 50,000 บัญชี และบัญชีที่ติดตามน้อยกว่า 5 บัญชีพร้อมมีผู้ติดตามน้อยกว่า 5 คน เหลือ 7.7 ล้านโหนด
    • แถบกลุ่มบัญชีสื่อ นโยบาย และคอมเมนเทเตอร์ที่มีผู้ติดตามสูง แยกออกจากกลุ่มพื้นหลังที่มีความเกี่ยวข้องต่ำกว่าอย่างชัดเจน
    • คลัสเตอร์ของไอซ์แลนด์ก็สังเกตได้ทั้งในมุมไกล มุมใกล้ และระดับรูปโปรไฟล์
    • วงบอตก็เห็นได้ชัดเจนเช่นกัน
  • ฟีเจอร์ถัดไปที่อยากเพิ่มคือแถบด้านข้างที่สามารถพับไทม์ไลน์โพสต์ของบัญชีที่กำลังเห็นอยู่บนหน้าจอได้
    • เป้าหมายคือพัฒนาให้เป็นเครื่องมือสำรวจโซเชียลและมีมรูปแบบใหม่

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

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

 
GN⁺ 2024-11-14
ความคิดเห็นจาก Hacker News

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

    • บัญชีของแฮนเดิลนั้นมีคนที่ติดตามอยู่น้อยมาก และดูใกล้เคียงกับ การกระจายคอนเทนต์แบบออกอากาศ มากกว่าการเข้าไปร่วมบทสนทนา น่าจะลองทำตรงกันข้ามดู
    • ตอนนี้ใน BSKY มีปัญหา คนยิ่งรวยยิ่งรวย คนยิ่งจนยิ่งจน มากเพราะ Starter Packs ถ้าได้เข้าไปอยู่ใน Starter Pack ที่คนมีอิทธิพลเป็นคนทำ ผู้ติดตามก็จะเพิ่มแบบฟรี ๆ ไม่รู้จบ แต่ถ้าต้องสร้างตัวตนเองตั้งแต่แรกแทบจะไม่ถูกค้นพบเลย
    • สงสัยว่าได้ลอง Mastodon ด้วยหรือยัง หลายคนมีประสบการณ์ที่ดีกว่าที่นั่น

  • Bluesky และ atproto ดูเหมือนจะถูกออกแบบมาโดยคำนึงถึงการ เปิดให้ดัดแปลงได้
    ชุมชนเพิ่งสร้างไดเรกทอรีสำหรับค้นหา Bluesky “Starter Packs” ขึ้นมา Starter Packs เป็นฟีเจอร์ที่เปิดให้ผู้ใช้เผยแพร่ชุดรายชื่อคนและฟีดที่น่าติดตาม เพื่อช่วยให้ผู้ใช้ใหม่จัดประสบการณ์เริ่มต้นของตัวเองได้เร็วขึ้น
    https://blueskydirectory.com/starter-packs/all
    วันนี้ Dan Abramov ก็พูดถึงเรื่องนี้ในทางบวก โดยบอกว่า “มันเจ๋งที่ของแบบนี้เกิดขึ้นได้ภายใน ecosystem แบบนี้ ปล่อยให้ ecosystem ได้ลงมือปรุงกันเถอะ” [1]
    และยังพูดได้คมกว่านั้นอีกว่า “พอเห็นโปรเจกต์สารพัดแบบผุดขึ้นมาใน ecosystem ของ atproto ก็ยิ่งรู้สึกชัดว่า บริษัทโซเชียลทั้งหลายกดทับพื้นที่ส่วนรวมของเว็บสาธารณะไว้มากแค่ไหนด้วยการปิด API ทิ้ง ภูมิทัศน์ของเครื่องมือทั้งผืนถูกยอมแพ้และถูกทิ้งไป” [2]
    [1] https://bsky.app/profile/danabra.mov/post/3lar3sdna222d
    [2] https://bsky.app/profile/danabra.mov/post/3lar3xpuu4c2d

    • กำลังลังเลอยู่ว่าจะย้ายไปดีไหม แต่คอมเมนต์นี้ฟังดูโน้มน้าวใจที่สุด
      ผมมองว่าหนึ่งในความผิดพลาดร้ายแรงที่สุดที่บริษัทเทคทำไว้คือการ ขังทุกอย่างไว้ สิ่งที่ทำให้คอมพิวเตอร์และสมาร์ตโฟนยอดเยี่ยมคือความสามารถในการดัดแปลง และการสร้างสภาพแวดล้อมกับ ecosystem การล็อกทุกอย่างไว้มีแต่จะทำให้ช้าลง ถ้าไม่มีแอป เราจะต้องรอนานแค่ไหนกว่าสมาร์ตโฟนจะมีไฟฉายหรือ stopwatch ฟีเจอร์เหล่านี้เคยเป็นแอปก่อนจะถูกฝังมาในระบบปฏิบัติการ
    • รู้สึกว่าเดิมที Twitter เองก็มีลักษณะแบบนี้อยู่พอสมควรไม่ใช่หรือ จากที่จำได้ ฟีเจอร์ยอดนิยมในทุกวันนี้อย่าง รีทวีต เอง ตอนแรกก็เป็นธรรมเนียมเฉพาะหน้าที่ผู้ใช้ช่วยกันสร้างขึ้นมา
    • ใช่แล้ว ตั้งใจให้ ดัดแปลงได้ ตั้งแต่แรก เราเชื่อว่าโซเชียลมีเดียจะดีขึ้นเมื่อผู้คนมีอิสระที่จะสร้าง เปลี่ยน ฟอร์ก และรีมิกซ์สิ่งต่าง ๆ บนมัน ecosystem ของ Bluesky และ atproto สามารถพัฒนาได้เร็วเท่ากับที่ผู้ใช้และนักพัฒนาต้องการ
    • Starter Packs ยอดเยี่ยมมาก ลองดูบัญชีที่มีปฏิสัมพันธ์มากที่สุดตอนนี้ก็น่าสนใจ: https://www.graphtracks.com
    • ในอีกมุมหนึ่ง มันอาจนำไปสู่ปัญหา บอต ที่หนักกว่า Twitter ถึง 10 เท่าก็ได้

  • ดูเหมือนว่า Bluesky จะระเบิดความนิยมอย่างมากในบางวงการเมื่อสัปดาห์ที่แล้ว ตั้งแต่วันเสาร์มาผู้ติดตามเพิ่มขึ้น 5~6 เท่า
    ตลอดปีที่ผ่านมาผมใช้งานอยู่พอสมควร เพราะบทสนทนาเรื่องพลังงานซึ่งเป็นสายงานที่ผมทำอยู่บน Twitter พังจนแทบไม่มีประโยชน์แล้ว มันก้าวร้าวในหลายความหมายและมีสแปมมากแบบเหลือเชื่อ ในทางกลับกัน Bluesky สบายกว่าแต่การตอบสนองก็ไม่มากนัก แต่ตอนนี้บรรยากาศเริ่มคึกคักขึ้นแล้ว หวังว่าคลื่นคนที่ไหลเข้ามานี้จะเป็นของจริง และมันก็ทำให้ผมใช้งานอย่างกระตือรือร้นมากขึ้นมาก

    • ฝั่ง X ของผมไม่ได้พังหนักขนาดนั้น ผมใช้ X ภาษาญี่ปุ่นเยอะ ซึ่งอาจเป็น ecosystem คนละแบบก็ได้ แต่ถึงอย่างนั้นตลอดปีที่ผ่านมาก็ใช้ Bluesky มาด้วย และมันเป็นเครือข่ายที่สนุกแต่ค่อนข้างเงียบอยู่พักหนึ่ง บางครั้งไม่มีโพสต์ใหม่เลยเป็นชั่วโมง
      ในช่วง 3 สัปดาห์ล่าสุด Bluesky คึกคักขึ้นมาก และตอนนี้ก็เริ่มให้ความรู้สึกเหมือน X ตรงที่ตามฟีดไม่ทันแล้ว ผมเชื่อว่าชุมชนที่ใหญ่ขึ้นจะสร้างมุมมองที่หลากหลายกว่า เลยตื่นเต้นมาก ผมยังรันทั้ง Bluesky labeler และตัวเก็บข้อมูล Firehose เองด้วย และได้เห็นปริมาณการประมวลผลอีเวนต์เพิ่มขึ้นราวสองเท่าในช่วง 3~4 เดือนที่ผ่านมา
    • อีกไม่นานพวกสแปมเมอร์กับโทรลก็จะมาเหมือนกัน ที่ไหนดัง ก็ไม่เคยถูกปล่อยว่างไว้นาน
    • สำหรับผม ทุกอย่างกำลังเข้าที่เข้าทาง
      Threads เป็นลูกผสมครึ่ง Twitter ครึ่ง Instagram ที่เด่นด้านคอนเทนต์สายครีเอทีฟ ท่องเที่ยว และโซเชียล ส่วน Bluesky ใกล้เคียงกับ Twitter ยุคแรกที่เด่นด้านข่าว การเมือง และวิทยาศาสตร์ ทุกวันนี้ผมไม่ค่อยแน่ใจแล้วว่าจะทำทุกอย่างไว้ในแอปเดียวได้จริงหรือเปล่า แบบนั้น X ก็คงจะเหลือบทบาทเป็น 4chan แบบใหม่
    • ประสบการณ์ของผมก็เป็นแบบนั้นทุกด้าน มีคนไหลเข้ามาแบบฉับพลัน มีคนที่น่าสนใจและมีความหมายให้น่าติดตามเพิ่มขึ้นมาก และประสบการณ์โดยรวมก็เปลี่ยนไปเป็นอะไรที่ชวนมีส่วนร่วมมากขึ้นอย่างรวดเร็ว
    • ผมยังหา บัญชีสายใช้งานจริง บน Bluesky ไม่เจอ บน Twitter ผมตามเรื่องเกม สตูดิโอเกมและผู้จัดจำหน่าย เว็บข่าว วงดนตรี และข่าวจากอย่าง NASA แต่บน Bluesky ยังไม่มีอะไรแบบนั้น และผมก็ไม่ค่อยสนใจคนธรรมดาที่ไม่รู้จัก ซึ่งบน Twitter ก็เหมือนกัน
      เลยแวะเข้าไปดูเป็นครั้งคราว แต่แทบจะเรียกได้ว่า 0/50

  • นี่เป็นเพียงส่วนหนึ่งของกระแสผู้ใช้ที่ย้ายไป Bluesky เมื่อสัปดาห์ที่แล้ว จนถึงตอนนี้ชอบมากทีเดียว และก็แปลกใจนิดหน่อยเพราะก่อนหน้านี้เคยผิดหวังกับ Mastodon ตอนนี้ใช้เวลาอยู่บน Bluesky มากกว่า Twitter ไปแล้ว
    ถ้าจะอธิบายให้คนที่ไม่รู้จัก Bluesky ฟัง มันแทบจะเป็นร่างโคลนของ Twitter ราวปี 2015 และ UI ก็แทบเหมือนกันเลย เพียงแต่ยังไม่มีการทำเงิน โฆษณา หรือ growth hacking ดังนั้นฟีเจอร์หลัก ๆ จึงมีไว้เพื่อผู้ใช้ ตัวอย่างที่ชอบคือแอปมือถือธรรมดาที่สร้างบน Expo/React Native ซึ่งเปิดลิงก์ใน Safari ได้แทนที่จะใช้ in-app browser ที่ไร้ประโยชน์

    • เนื่องจาก Bluesky ได้รับเงินลงทุนจาก VC ก็คงเป็นแค่เรื่องของเวลาก่อนที่จะเริ่มทำเงิน ใส่โฆษณา และทำ growth hacking คงต้องรีบสนุกกับมันก่อนถึงตอนนั้น
    • ลองใช้แล้ว เทคโนโลยีก็ดูเจ๋งดี แต่อยากให้มีเนื้อหาที่หลากหลายกว่านี้ ตอนนี้ Twitter เต็มไปด้วยการหลอกลวงคริปโตและเรื่องเพ้อเจ้อการเมืองขวาจัดของอเมริกาไปหมดแล้ว ก็เลยอยากได้อะไรที่น่าสนใจกว่าเรื่องเพ้อเจ้อการเมืองซ้ายจัดของอเมริกานิดหน่อย
      โลกนี้กว้างกว่าอเมริกาหรือดราม่าบนอินเทอร์เน็ตฝั่งตะวันตกมาก ในฐานะคนยุโรป เวลาอ่านโซเชียลมีเดียกระแสหลักรวมถึง BlueSky แล้วแทบปวดตาไปหมด ไม่ได้สนใจการเมือง อัตลักษณ์ทางเพศ หรือ keyboard activism เลย จะมีอย่างอื่นขึ้นมาบนเมนูบ้างไม่ได้หรือ อะไรก็ได้จริง ๆ ถ้าจะเปิดรับสิ่งใหม่ ๆ ที่ไม่ใช่การเมืองอเมริกาหรือชีวิตส่วนตัวว่าใครชอบเพศไหน ถึงขั้นเริ่มคิดว่าต้องไปเรียนภาษารัสเซียหรือจีนหรือเปล่า ใครจะสนกันล่ะ
      Nostr สนุกดีในเชิงเทคนิค แต่ก็น่าเสียดายที่ท้ายที่สุดก็ไม่พ้น ช่วงคริปโตโบร
    • ถ้าเป็น “ร่างโคลนของ Twitter ราวปี 2015 และไม่มีการทำเงิน โฆษณา หรือ growth hacking จึงทำให้ฟีเจอร์มีไว้เพื่อผู้ใช้” ก็เท่ากับว่าเหมือน Mastodon ทุกอย่าง
    • สงสัยว่าเทียบกับ Threads แล้วเป็นอย่างไร

  • เจ๋งมาก BlueSky API ออกแบบมาดี เพื่อนร่วมงานคนหนึ่งทำภาพแบบนี้จาก Firehose: https://bigmood.blue/
    ที่มา: https://bsky.app/profile/even.westvang.com/post/3laob7tefxk2...

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

  • สิ่งที่ดีที่สุดของ Bluesky คือสามารถใช้ โดเมนเป็นชื่อผู้ใช้ ได้ ฉันใช้ @bradgessler.com อยู่ที่นั่น และถ้าใครอยาก “ยืนยัน” ตัวฉัน ก็จะได้เห็นเว็บไซต์ของฉันซึ่งมีความหมายมากกว่าเครื่องหมายถูกสีน้ำเงินมาก
    ต่อให้ถูกบล็อก ถูกแบน หรือถูกไล่ออกจากแพลตฟอร์ม ผู้คนก็ยังเห็นโดเมนของฉันและเข้าไปที่นั่นเพื่อดูว่าเกิดอะไรขึ้น ในแง่หนึ่งมันเป็นโครงสร้างที่ทำให้การเซ็นเซอร์มองเห็นได้ น่าจะดีต่อบริษัทด้วย การเรียกบริษัทด้วย @example.com แล้วได้รับคำตอบกลับมานั้นคลุมเครือน้อยกว่ามาก ผมยังทำ starter pack รวมบริการ SaaS บน Rails ที่ใช้วิธีนี้ไว้แล้ว: https://go.bsky.app/JQyXa2u
    ชอบมากกับสิ่งที่ BlueSky กำลังทำอยู่ และหวังว่ามันจะไม่เสื่อมคุณภาพลงไปในอนาคต ถึงจะเป็นแบบนั้น ตอนนี้ก็ดูเหมือนเป็น จังหวะโกลดิล็อกส์ ที่บรรยากาศกำลังดี ใช้เวลา 5 นาทีในการสร้างบัญชีแล้วเชื่อมกับโดเมนของตัวเอง แนะนำมาก

    • การยืนยันตัวตนของ Mastodon ก็เปิดให้ทุกคนเช่นกัน และอิงกับ มาตรฐานเว็บแบบเปิด
      https://joinmastodon.org/verification
    • แม้แต่แฮนเดิลเริ่มต้นที่ได้ตอนสมัครอย่างที่อยู่ .bsky.social ก็จะรีไดเร็กต์ไปยังโปรไฟล์บน bsky.app โดยปริยาย คนที่ไม่รู้จัก Bluesky เลยก็แค่เปิด URL นั้น แล้วถึงจะมี @ นำหน้าอยู่ก็ยังเห็นว่าเป็นโปรไฟล์โซเชียลได้ทันที

  • มีประโยคว่า “ถ้าเอาเมทริกซ์ของ BlueSky ไปใส่ใน UMAP จะเกิดอะไรขึ้น? อย่างน้อยก็ทำตรง ๆ ไม่ได้ แม้ UMAP จะรับ sparse matrix ได้ในทางเทคนิค แต่สเกลนี้ใหญ่เกินไปสำหรับ home server ของผม แทนที่จะทำแบบนั้น ก็ใช้เทคนิคอื่นดึง embedding ของผู้ใช้ทุกคนออกมาเป็นมิติขนาดกลางอย่าง 32 มิติก่อน แล้วค่อยใส่เข้า UMAP ง่ายนิดเดียว!” เลยสงสัยว่าเขาสร้าง embedding นั้นขึ้นมาอย่างไรกันแน่

  • พอเห็นประโยคที่ว่า “การสร้างและการคิวรี quadtree นั้นมีลักษณะเป็นลำดับชั้นโดยเนื้อแท้” ก็รู้สึกดีที่อย่างน้อยไม่ได้มีแค่ฉันคนเดียวที่สับสนกับคำว่า hierarchy
    เป็นงานที่น่าสนใจในหลายระดับ ไม่ได้ตั้งใจเล่นคำนะ มีทั้งเรื่องความพร้อมใช้ของข้อมูล Bluesky การประมวลผล ไปจนถึงอัลกอริทึมการทำภาพให้ดู แต่ก็ยังไม่ค่อยชัดว่าจะจัดงานภาพแบบนี้ไว้ตรงไหนในสเปกตรัมของ data science กราฟเชิงตัวเลขแบบดั้งเดิมได้พัฒนาหลักไวยากรณ์ที่ซับซ้อนพอสมควรมาเรื่อย ๆ ตามกาลเวลา ทำให้อนุมานและตีความได้ค่อนข้างแม่นยำ จึงถูกใช้เพื่อสื่อสารข้อมูลจริงในงานอย่างบทความวิชาการหรือแวดวงการเงิน และผู้คนยังถึงขั้น reverse engineer กราฟเพื่อกู้ข้อมูลกลับมาได้ด้วย
    แต่สำหรับเครือข่ายและกราฟ นอกจากภาพรวมเรื่อง topology การเชื่อมต่อ และการจับกลุ่มแล้ว ก็ค่อนข้างยากที่จะชี้ชัดว่ามีข้อมูลอะไรถูกสื่อออกมาบ้าง ไม่แน่ใจว่ายังไม่มีใครคิดค้นหลักไวยากรณ์ที่มีประโยชน์สำหรับ กราฟขนาดใหญ่ แบบนี้ หรือว่ามันเป็นธรรมชาติของสิ่งนี้ตั้งแต่แรก

  • อยากเห็นข้อมูลนี้มากขึ้นในมุมมองของ การประมวลผลภาษาธรรมชาติ ถ้าดูได้แบบ Google Trends ว่าหัวข้อสนทนาไหนโผล่มาเป็นระยะ ๆ หรืออะไรพุ่งขึ้นในช่วงเวลาใดก็น่าจะดี
    จะสรุปได้ไหมว่านักเศรษฐศาสตร์กำลังคุยเรื่องอะไรกันอยู่? จะหาคนที่ไม่ได้อยู่ในเครือข่ายเดียวกันแต่กำลังพูดถึงเรื่องเดียวกันได้ไหม น่าสนใจมาก