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

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

เมื่อแพลตฟอร์มใหม่เกิดขึ้นและเติบโต ทางเลือกของเครือข่ายสังคมทางเลือกมักมาพร้อมกับข้อพิจารณาทางการเมือง

ไซต์ต่างๆ เช่น Getr, Parler, Gab และ Truth Social ต่างก็ให้ความสำคัญกับสิ่งที่ถูกต้องโดยการส่งเสริมตัวเองว่าเป็นทางเลือกในการพูดฟรีสำหรับ Twitter

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

พื้นหลัง: Nostr

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

Mastodon VS Nostr 

โปรโตคอล Nostr และเซิร์ฟเวอร์ส่งต่อเครื่องแรกถูกสร้างขึ้นโดยนักพัฒนา fiatjaf ในช่วงปลายปี 2020 ก่อนที่จะได้รับความสนใจอย่างกว้างขวาง Nostr เป็นโปรโตคอลเฉพาะกลุ่มที่เงียบสงบโดยมีเป้าหมายเพื่อเป็นวิธีแก้ปัญหาเล็กน้อยสำหรับ Twitter และ Mastodon

Mastodon เครือข่ายโอเพ่นซอร์สที่ก่อตั้งขึ้นในปี 2559 ช่วยให้ทุกคนตั้งค่าเซิร์ฟเวอร์ได้ การออกแบบมักถูกอธิบายว่าเป็น "ส่วนกลาง" และอาจหรือไม่อยู่ในเส้นที่เบลอของ "Web3" ขึ้นอยู่กับวิธีการกำหนด Mastodon อนุญาตให้ผู้ใช้เข้าร่วมชุมชนที่ดูแลจัดการด้วยกฎการกลั่นกรองเนื้อหาที่กำหนดเอง ในปัจจุบัน ผู้ใช้ที่ลงทะเบียนมีจำนวนถึง 200 w+ และได้กลายเป็นที่หลบภัยสำหรับพวกเสรีนิยม นักข่าว และนักวิชาการ

ในระบบ Twitter และ Mastodon ข้อมูลประจำตัว/ชื่อผู้ใช้จะถูกควบคุมโดยใครก็ตามที่ดูแลเซิร์ฟเวอร์

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

"เหตุการณ์": นี่คือประเภทวัตถุ/ข้อมูลพื้นฐานที่ใช้โดยไคลเอ็นต์และเซิร์ฟเวอร์รีเลย์ที่ไคลเอนต์เชื่อมต่อด้วยเพื่อส่งและดึงข้อความ แนวคิดทั่วไปของโปรโตคอลคือไคลเอนต์ส่งเหตุการณ์ไปยังเซิร์ฟเวอร์รีเลย์ ซึ่งจากนั้นจะจัดเก็บและจัดทำดัชนี และไคลเอนต์อื่น ๆ สามารถสื่อสารกับเซิร์ฟเวอร์รีเลย์เพื่อขอเหตุการณ์ที่ได้รับและจัดเก็บ ใน NIP 01 ดั้งเดิม มีการกำหนดเหตุการณ์ที่แตกต่างกันสามประเภท:

0 : ส่งข้อมูลเมตาเกี่ยวกับผู้ใช้ เช่น ชื่อผู้ใช้ รูปภาพ ประวัติ ฯลฯ

1: ส่ง SMS และเนื้อหาพื้นฐาน

2: แนะนำเซิร์ฟเวอร์รีเลย์สำหรับผู้ที่ติดตามผู้สร้างกิจกรรมเพื่อเชื่อมต่อ

เหตุการณ์ทั้งหมดมีโครงสร้างในลักษณะที่กำหนดไว้โดยเฉพาะ รวมคีย์สาธารณะของผู้สร้าง การประทับเวลาในการสร้าง ประเภท (หรือชนิดในข้อมูลจำเพาะ) เพย์โหลดเนื้อหา และลายเซ็นของผู้สร้างกิจกรรม หรืออาจมีแท็กที่อ้างถึงเหตุการณ์หรือผู้ใช้รายอื่น และมีค่า ID ที่เป็นแฮชของทุกอย่างยกเว้นลายเซ็นของผู้สร้าง (คล้ายกับ TXID ของธุรกรรม Bitcoin)

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

เช่นเดียวกับที่การทำธุรกรรม Bitcoin ไม่สามารถเปลี่ยนแปลงได้หลังจากได้รับการลงนามโดยไม่ได้ทำให้เป็นโมฆะ ผู้ใช้จะไม่สามารถเปลี่ยนแปลงกิจกรรม Nostr ได้หลังจากที่ได้รับการลงนามโดยผู้สร้างโดยไม่ทำให้เป็นการฉ้อโกงอย่างชัดเจน

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

เมื่อพูดถึงคำถามสุดท้าย เหตุการณ์ยังสามารถมีแท็กได้ ขณะนี้มีประเภทแท็กสำหรับเหตุการณ์ (เพื่ออ้างถึงเหตุการณ์ Nostr ที่แน่นอน), PublicKey (เพื่อแท็กหรืออ้างถึงผู้ใช้รายอื่น) และหัวเรื่อง (เพื่อเลียนแบบการทำงาน เช่น หัวเรื่องอีเมล) ทั้งหมดนี้อาจรวมถึงตัวชี้ไปยังเซิร์ฟเวอร์รีเลย์เฉพาะที่ดึงข้อมูลมา เพื่อให้ผู้ใช้สามารถโต้ตอบกับเซิร์ฟเวอร์ต่างๆ ได้ เช่น ผู้ใช้เผยแพร่เนื้อหาของตนบนเซิร์ฟเวอร์รีเลย์ เนื้อหาที่สามารถโต้ตอบและอ้างอิงโดยผู้ใช้รายอื่นบนรีเลย์อื่น เซิร์ฟเวอร์เพื่อให้ผู้ใช้สามารถรับเธรดการโต้ตอบทั้งหมดตามลำดับที่เหมาะสมโดยไม่ต้องค้นหาว่าข้อมูลที่เกี่ยวข้องอยู่ที่ไหน การดำเนินการที่ซับซ้อนจำนวนมาก

ใน NIP ดั้งเดิม มีการระบุข้อกำหนดเกี่ยวกับวิธีที่ไคลเอนต์โต้ตอบกับเซิร์ฟเวอร์รีเลย์โดยสมัครรับข้อความ/โครงสร้างข้อมูลที่มีตัวกรองสำหรับเหตุการณ์ที่ไคลเอนต์สนใจรับ ตัวกรองเหล่านี้สามารถระบุคีย์สาธารณะของผู้ใช้ เหตุการณ์ที่แน่นอน ประเภทของเหตุการณ์ หรือแม้แต่กรอบเวลาที่เจาะจงที่พวกเขาต้องการตามเกณฑ์ก่อนหน้า ผู้ใช้ยังสามารถส่งคีย์สาธารณะหรือคำนำหน้าของ ID เหตุการณ์ เช่น "1 xjisj..." และรับเหตุการณ์ใดเหตุการณ์หนึ่งหรือมากกว่าจากคีย์สาธารณะที่ขึ้นต้นด้วยสตริงสั้นๆ นั้น (สิ่งนี้มีประโยชน์สำหรับการซ่อนจากเซิร์ฟเวอร์รีเลย์สิ่งที่คุณต้องการเห็นจริงๆ)

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

เซิร์ฟเวอร์รีเลย์ยังสามารถเรียกใช้อะไรก็ได้ที่ต้องการ: ใช้งานได้ฟรี คิดค่าธรรมเนียมเล็กน้อยในการเผยแพร่หรือดาวน์โหลดข้อความ และยังมี NIP ที่ต้องใช้หลักฐานการทำงานในรูปแบบแฮชแคชเพื่อส่งข้อความ พวกเขาสามารถเป็นเซิร์ฟเวอร์ส่งต่อเดียวที่โฮสต์โพสต์และทำให้พร้อมใช้งานสำหรับผู้ใช้รายอื่นเท่านั้น หรือเซิร์ฟเวอร์ที่ทำงานตามขนาด เช่น Twitter หรือ Reddit (ไคลเอนต์สามารถแสดงและจัดระเบียบข้อมูลได้ตามต้องการ ซึ่งอนุญาตให้จำลองสื่อสังคมออนไลน์ใดๆ ก็ได้) ทั้งหมดนี้ทำงานร่วมกันได้อย่างราบรื่นโดยไม่ปิดกั้นผู้ใช้

ประเด็นสำคัญในการจัดการที่ Nostr

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

แต่สิ่งนี้ยังก่อให้เกิดปัญหาใหม่: กุญแจอาจสูญหาย กุญแจอาจถูกบุกรุก และหากเหตุการณ์ดังกล่าวเกิดขึ้น ผู้ใช้จะไม่สามารถขอความช่วยเหลือได้

สิ่งนี้ย่อมต้องมีรูปแบบสำหรับผู้ใช้ในการเปลี่ยนจากคู่คีย์หนึ่งไปยังอีกคู่หนึ่งด้วยวิธีที่ตรวจสอบได้และค้นพบได้ และเพื่อให้พวกเขาโต้ตอบกับผู้ใช้รายอื่นผ่านโปรโตคอล โปรโตคอลทั้งหมดขึ้นอยู่กับการพิสูจน์ว่าเหตุการณ์มาจากผู้ใช้เฉพาะ (รหัสประจำตัว) ดังนั้นเมื่อรหัสของใครบางคนถูกบุกรุก การรับประกันทั้งหมดจะถูกโยนทิ้งไปในอากาศ

Nostr ต้องการโครงร่างการเข้ารหัสจริงที่เชื่อมโยงการหมุนเวียนของคีย์หนึ่งไปยังอีกคีย์หนึ่ง นักพัฒนา fiatjaf ได้เสนอวิธีแก้ปัญหาเบื้องต้นที่อาจช่วยแก้ปัญหานี้ได้ แนวคิดพื้นฐานคือการใช้รายชื่อที่อยู่ยาว ๆ ที่ได้มาจาก master seed เดียว และสร้างชุดของคีย์ "ที่ปรับแต่งแล้ว" คล้ายกับวิธีที่ Taproot tree ผูกมัดกับคีย์ Bitcoin Taproot ใช้ราก Merkle ของ Taproot tree และ "เพิ่ม" ลงในรหัสสาธารณะเพื่อสร้างรหัสสาธารณะใหม่ สิ่งนี้สามารถทำซ้ำได้โดยเพิ่ม Merkle root นั้นลงในคีย์ส่วนตัวเพื่อรับคีย์ส่วนตัวที่ตรงกับคีย์สาธารณะใหม่ แนวคิดของ Fiatjaf คือการเชื่อมโยงข้อผูกมัดย้อนหลังตั้งแต่ต้นจนจบ เพื่อให้คีย์ที่ปรับแล้วแต่ละคีย์มีหลักฐานว่าคีย์ที่ปรับถัดไปถูกใช้เพื่อสร้างคีย์นั้น

ลองจินตนาการว่าเริ่มต้นด้วยคีย์ Z ซึ่งเป็นคีย์สุดท้ายในห่วงโซ่ คุณสามารถปรับแต่งบางอย่างได้ จากนั้นย้อนกลับไปสร้างคีย์ Y เวอร์ชันที่ปรับแล้วโดยใช้คีย์ที่ปรับแล้ว Z (Z' + Y = Y') จากที่นี่ คุณสามารถใช้ Y' และใช้เพื่อปรับ X (Y' + X = X') คุณต้องทำสิ่งนี้ตลอดทางกลับไปที่คีย์ A รับ A' และใช้คีย์นั้นจากที่นั่น เมื่อคีย์เสีย ผู้ใช้สามารถออกอากาศเหตุการณ์ที่มีคีย์ A ที่ยังไม่ได้ปรับแต่งและคีย์ B' ที่ปรับแต่งแล้ว ซึ่งจะมีข้อมูลทั้งหมดที่จำเป็นในการแสดงว่า B' ถูกใช้เพื่อสร้าง A' และผู้ใช้สามารถหยุดติดตาม A' ได้ทันทีและติดตาม B' แทน พวกเขาจะรู้อย่างชัดเจนว่า B' เป็นคีย์ถัดไปสำหรับผู้ใช้รายนั้น และทำตามนั้นแทน

อย่างไรก็ตาม ยังมีปัญหาบางประการเกี่ยวกับข้อเสนอนี้ ประการแรก คีย์ทั้งหมดที่จะใช้จะต้องสร้างล่วงหน้า และไม่มีทางที่จะหมุนเวียนไปยังคีย์ชุดใหม่ทั้งหมดได้ สิ่งนี้สามารถแก้ไขได้โดยการคอมมิตคีย์หลักในโครงร่างนี้ที่สามารถรับรองการหมุนนี้ หรือเพียงแค่สร้างคีย์ชุดใหญ่ตั้งแต่เริ่มต้น ทั้งสองเส้นทางเป็นไปได้ แต่ท้ายที่สุดแล้วจำเป็นต้องรักษารูทคีย์หรือคีย์เนื้อหาให้ปลอดภัย และเปิดเผยเฉพาะคีย์ลัด (Hotkey) แต่ละตัวต่อไคลเอนต์ Nostr เท่านั้น

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

สำหรับการอภิปรายเกี่ยวกับวิธีแก้ปัญหาที่เป็นไปได้ที่นี่ ให้ลองคิดอีกวิธีหนึ่ง การปรับคีย์เป็นคีย์เย็นหลักที่ต้องใช้เพื่อลงนามเหตุการณ์จากคีย์หนึ่งไปยังอีกคีย์หนึ่งในการหมุนเวียน คุณมีคีย์ A' ซึ่งได้มาจากการเพิ่ม A และ M (คีย์หลัก) เหตุการณ์การหมุนจะเป็น A, M และ B' (สร้างขึ้นโดยการเพิ่ม B และ M) และลายเซ็นของ M M สามารถเป็นคีย์เกณฑ์แบบหลายลายเซ็น - สองในสาม สามในห้า เป็นต้น สิ่งนี้อาจเพิ่มความซ้ำซ้อนเพื่อป้องกันการสูญเสียและให้กลไกที่ปลอดภัยสำหรับการหมุนเวียนคีย์ นอกจากนี้ยังเป็นการเปิดประตูสู่การใช้บริการเพื่อช่วยในการกู้คืนหรือเพื่อกระจายคีย์เหล่านี้ไปยังเพื่อนที่ไว้ใจได้ มันมีความยืดหยุ่นเช่นเดียวกับ multisig ใน Bitcoin

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

คำถามเกี่ยวกับการจัดการคีย์และความปลอดภัยเป็นปัญหาใหญ่ที่มีพื้นที่การออกแบบขนาดใหญ่มาก เต็มไปด้วยข้อแลกเปลี่ยนและปัญหาต่างๆ อย่างไรก็ตาม หาก Nostr ไม่สามารถปกป้องและรักษาความสมบูรณ์ของข้อมูลระบุตัวตนเหล่านี้สำหรับผู้ใช้ได้ โปรโตคอลที่ใช้คู่คีย์สาธารณะ/ส่วนตัวที่ใช้เป็นข้อมูลระบุตัวตนทั้งหมดจะไม่สามารถนำมาใช้ในวงกว้างได้

การขยายตัวหันหน้าไปทาง Nostr

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

โฆษณา

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

ไมโครเพย์เมนต์

Micropayments เป็นอีกหนึ่งวิธีแก้ปัญหาที่ชัดเจน โดยเฉพาะอย่างยิ่งเมื่อพิจารณาถึงความพยายามอย่างต่อเนื่องในการผสานรวม Lightning Network เข้ากับแอพ Nostr ให้แน่นแฟ้นยิ่งขึ้น รุ่นนี้มีความยืดหยุ่นอย่างมากในการชาร์จ รีเลย์สามารถเรียกเก็บเงินสำหรับการโพสต์กิจกรรมที่นั่น หรือสำหรับการดาวน์โหลดการอ่านเหตุการณ์ หรือทั้งสองอย่างรวมกัน โดยจะปรับราคาของแต่ละรายการตามปริมาณทรัพยากรที่ใช้ อย่างไรก็ตาม เป็นที่น่าสงสัยว่าโมเดลนี้สามารถปรับขนาดให้ใหญ่เท่ากับ Twitter ได้

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

ประการแรก การยอมรับ Bitcoin ยังไม่มากพอ แม้ว่าทุกคนจะยอมรับอย่างน่าอัศจรรย์ที่จะจ่ายสำหรับการโต้ตอบบริการเล็กๆ น้อยๆ บน Nostr แต่ก็คงมีคนไม่มากนักที่ถือ bitcoins เพื่อสนับสนุนสิ่งที่ยิ่งใหญ่อย่าง Twitter รีเลย์สามารถเรียกเก็บค่าธรรมเนียมการสมัครสมาชิกในสกุลเงินคำสั่ง แต่วิธีการชำระเงินเหล่านี้จะไม่สนับสนุนการจ่ายค่าธรรมเนียมเล็กน้อยสำหรับแต่ละกิจกรรมที่เผยแพร่หรือดาวน์โหลด ประการที่สอง ผู้คนมักคุ้นเคยกับบริการฟรีประเภทนี้ นี่คือสิ่งที่คาดหวัง ฉันไม่คิดว่า micropayments จะสามารถรองรับการส่งต่อข้อมูลขนาดใหญ่ได้

มีวิธีการชำระเงินแบบไมโครเพย์เมนท์"เหนียวมากขึ้น"หรือยั่งยืนกว่าโดยไม่ต้องบังคับกับผู้ใช้ทุกกลุ่มที่ใช้รีเลย์ มีการพูดคุยกันมากมายเกี่ยวกับการสร้างแอปพลิเคชันต่างๆ บน Nostr นอกเหนือจากตัวโคลนของ Twitter GitHub, Wikipedia หรือแม้แต่ Uber

สุดท้ายคือกุญแจสำคัญ: การคาดการณ์ทางเศรษฐกิจ ผู้คนคุ้นเคยกับการจ่ายค่าธรรมเนียมเมื่อมีการโฆษณางานที่ไหนสักแห่ง หรือจ่ายค่าธรรมเนียมให้กับผู้ประกอบการตลาดเมื่อสั่งซื้อบางอย่างทางออนไลน์ แต่อย่าให้บริการสิ่งที่พวกเขาคิดว่าควรฟรี - Google, Twitter นี่อาจเป็นหนทางสำหรับผู้ถ่ายทอดในการสร้างเสาหลักรายได้ที่มั่นคงจากผู้ใช้โดยไม่สร้างความขัดแย้งหรือทำลายความคาดหวังของผู้ใช้ที่มีศักยภาพโดยเฉลี่ย

สรุปแล้ว

สรุปแล้ว

โครงการโซเชียล Web3 นอกเหนือจาก Nostr และ Mastodon ที่กล่าวมาแล้ว ยังรวมถึงโครงการต่างๆ เช่น Farcaster และ Lens ซึ่งจะไม่แทนที่แพลตฟอร์มโซเชียลมีเดียที่มีอยู่อย่างรวดเร็ว ตามสถิติ Twitter มีผู้ใช้งานหลายร้อยล้านคน Facebook มีพันล้านคน แต่ Mastodon มีผู้ใช้เพียง 2.5 ล้านคน และ Nostr มีเอกลักษณ์เฉพาะตัวของผู้ใช้เพียง 22 w เท่านั้น โครงการโซเชียล Web3 จำนวนมากเผชิญกับอุปสรรคด้านการใช้งานซึ่งทำให้การยอมรับจำนวนมากช้าลง

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