เป็นเจ้าของข้อมูลของตัวเอง ตอนที่ 1: การผสานรวมโซลูชันปฏิทินแบบโฮสต์เอง

 (emilygorcenski.com)
2 คะแนน โดย GN⁺ 2025-04-11 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อการเดินทางเพื่อธุรกิจ/ท่องเที่ยวบ่อยครั้งซ้อนทับกับการจัดการความสัมพันธ์ข้ามหลายเขตเวลา จึงเกิดความจำเป็นต้องมี ระบบปฏิทินของตัวเอง เพื่อลดการพึ่งพา Big Tech และควบคุมข้อมูลตารางเวลาโดยตรง
  • โครงสร้างใหม่มี Baïkal CalDAV server เป็นแกนกลาง รวบรวมข้อมูลจาก Airtrail, อีเมล IMAP และ ICS ของโรงเรียนภาษาเข้า CalDAV แล้วเผยแพร่ออกมาอีกครั้งเป็นไฟล์ .ics สำหรับแชร์
  • วิธีเดิมที่เขียนตารางเวลาใน YAML แล้วแปลงเป็น ICS ผ่าน CI/CD นั้นเพียงพอสำหรับโปรโตไทป์ แต่เมื่อเกิดข้อผิดพลาดจากการทำมือและภาระดูแลเพิ่มขึ้น จึงต้องแทนที่ วิธีไฟล์สแตติก
  • สคริปต์ Python รวบรวมและจัดหมวดหมู่อีเวนต์ทุก 15 นาที สร้าง ICS แยกสำหรับครอบครัวและงาน และทำเครื่องหมายบางอีเวนต์ในปฏิทินงานเป็น PRIVATE
  • Google Calendar และ Google Script ใช้เฉพาะสำหรับซิงก์ปฏิทินงานเท่านั้น หลังเชื่อมต่อ Airtrail API แล้ว เมื่อกรอกเที่ยวบินหนึ่งครั้ง ระบบจะสะท้อนในปฏิทินส่วนตัวภายใน 15 นาที และในปฏิทินงานภายใน 1 ชั่วโมง

เหตุผลที่การจัดการปฏิทินซับซ้อนขึ้น

  • เนื่องจากเดินทางบ่อย ครอบครัว เพื่อน และเพื่อนร่วมงานจึงรู้ได้ยากว่าอยู่เขตเวลาไหนในขณะนั้นหรือกำลังขึ้นเครื่องบินอยู่หรือไม่ และการนัดหมายข้ามหลายเขตเวลายังต้อง คำนวณเวลา อยู่เรื่อยๆ
  • ต้องกรอกเที่ยวบิน รถไฟ ช่วงเวลาบล็อกก่อนขึ้นเครื่อง และเวลาเดินทางไปสนามบินซ้ำในหลายที่ ทำให้ภาระจัดการตารางเวลาเพิ่มขึ้น
  • ความไม่สะดวกของระบบนิเวศปฏิทินเดิมมีอยู่ทั่วทั้งมาตรฐาน แอปฟรอนต์เอนด์ และประสบการณ์ผู้ใช้
    • แม้ผู้ให้บริการอีเมลจะสร้างรายการปฏิทินสำหรับเที่ยวบินให้ ก็อาจตกหล่นเที่ยวบินต่อเครื่องหรือระบุเขตเวลาผิด
    • organizer ของรายการที่สร้างขึ้นไม่ใช่ผู้ใช้เอง จึงอาจแชร์หรือแก้ไขได้ยาก
  • เงื่อนไขที่ต้องการไม่ได้มีแค่การเก็บตารางเวลา แต่รวมถึงการแชร์และการควบคุมด้วย
    • อีเวนต์ต้องแสดงเป็น blocker ในปฏิทินงาน
    • คู่สมรสต้องสมัครรับปฏิทินได้
    • ต้องกรอกอีเวนต์ไม่เกินหนึ่งครั้ง
    • ต้องแก้ไขได้จากหลายอุปกรณ์
    • ต้องควบคุมข้อมูลได้เองโดยตรง
    • ใช้วิธีแชร์ปฏิทินงานกับคู่สมรสไม่ได้
  • ข้อกำหนดเพิ่มเติมรวมถึงการนำเข้าไฟล์แนบ .ics จากอีเมล, การนำเข้า HTTP ICS ของปฏิทินโรงเรียนภาษา, การเชื่อมต่อกับตัวติดตามเที่ยวบินแบบโฮสต์เอง Airtrail, การแยกสี, แฟล็กส่วนตัวสำหรับปฏิทินงาน, การรีเฟรชบ่อยครั้ง และการใช้ฟรอนต์เอนด์ใดก็ได้

จุดที่วิธี YAML/ICS ชนขีดจำกัด

  • วิธีแชร์เดิมมักต้องมีแพลตฟอร์มร่วมกันหรือสภาพแวดล้อมบัญชีเดียวกันจึงจะให้ฟังก์ชันได้ครบ
    • ระบบนิเวศ Gmail หรือ Outlook.com
    • การแชร์บัญชีในสภาพแวดล้อมเดียวกัน เช่น Exchange
  • วิธีเลี่ยงทั่วไปมีอยู่สองแบบ
    • เผยแพร่ข้อมูล iCal ผ่าน HTTP เป็น ปฏิทินแบบอ่านอย่างเดียว
    • ส่งไฟล์ iCal .ics ทางอีเมล
  • เวอร์ชันแรกใช้วิธีอัปโหลดไฟล์ .ics ไปยัง URL บนเว็บไซต์ที่เปิดสาธารณะแต่เดายาก และสร้างหลาย URL ตามวัตถุประสงค์
  • ข้อมูลอีเวนต์เขียนด้วย YAML แล้ว serialize กลับเป็นไฟล์ ICS ด้วยสคริปต์เล็กๆ ในไปป์ไลน์ CI/CD
  • สำหรับโปรโตไทป์นั้นเพียงพอ แต่เมื่อขนาดใหญ่ขึ้น การเขียน YAML ด้วยมือทำให้ผิดพลาดบ่อย และงานที่เดิมควรใช้ความพยายามต่ำกลับกลายเป็นภาระ

โครงสร้างที่เปลี่ยนมาใช้ CalDAV และ Baïkal

  • โครงสร้างใหม่ย้ายออกจากไฟล์สแตติกไปเป็นระบบที่โฮสต์บนพื้นฐาน CalDAV
  • CalDAV เป็นส่วนขยายของสเปก WebDAV distributed authoring ที่ให้ความสามารถที่แอปพลิเคชันปฏิทินต้องใช้
  • เมื่อมี CalDAV server ก็สามารถดูและจัดการอีเวนต์จากอุปกรณ์หลายเครื่อง เช่น โน้ตบุ๊กและโทรศัพท์ ผ่านแอปฟรอนต์เอนด์ที่เลือกได้
  • เนื่องจากมี CalDAV server ไม่มากที่สมัครรับได้ง่ายโดยไม่ต้องยืนยันตัวตน จึงต้องมีสคริปต์ที่คอย poll เซิร์ฟเวอร์เป็นระยะ ดึงอีเวนต์ออกมา แล้วเผยแพร่เป็นไฟล์ iCal บนเว็บไซต์
  • โฟลว์ทั้งหมดเป็นดังนี้
    • poll อีเวนต์จากแหล่งข้อมูล
    • เผยแพร่อีเวนต์เข้า CalDAV ด้วยโปรแกรม
    • ดึงอีเวนต์ทั้งหมดจาก CalDAV แล้วเขียนเป็นไฟล์ .ics
    • ให้บริการไฟล์ .ics ผ่าน HTTP

การติดตั้ง Baïkal และการเชื่อมต่อไคลเอนต์

  • เครื่องมือที่เลือกคือ Baïkal ซึ่งเป็น CalDAV/CardDAV server แบบโฮสต์เองน้ำหนักเบาสำหรับจัดการปฏิทินและรายชื่อผู้ติดต่อ
  • รันอิมเมจ ckulka/baikal:0.9.5 ด้วย Docker Compose กำหนดพอร์ตและ local volume แล้วเริ่มด้วย docker compose up -d
  • Baïkal ใช้ MySQL ได้ แต่ทำงานกับ SQLite ได้เช่นกัน และ SQLite จัดการได้ง่ายกว่า
  • สำหรับการเปิดให้เข้าจากเว็บ ใช้ nginx reverse proxy
    • เชื่อมต่อไปยังพอร์ต Baïkal ในเครื่องด้วย proxy_pass
    • ทำ 301 redirect จาก /.well-known/caldav ไปยัง dav.php
    • redirect นี้จำเป็นเมื่อต้องเพิ่มลงในแอป Calendar ของ iPhone หรือ Mac
  • ตั้งค่า TLS ด้วย Let’s Encrypt และ certbot โดย certbot จะอัปเดตไฟล์ตั้งค่า nginx ให้อัตโนมัติ
  • เข้าโดเมนจากเบราว์เซอร์ สร้างบัญชีผู้ดูแลระบบ จากนั้นสร้างผู้ใช้และปฏิทิน
  • เชื่อมต่อกับแอป Calendar พื้นฐานของ macOS และ iOS โดยในการตั้งค่า macOS/iOS ใช้ manual settings ไม่ใช่ automatic หรือ advanced

การจัดหมวดหมู่อีเวนต์และขอบเขตการเผยแพร่ปฏิทินงาน

  • สเปก iCalendar มีคุณสมบัติ CATEGORIES แบบเลือกได้ของคอมโพเนนต์ EVENT แต่เครื่องมือที่ใช้ เช่น macOS Calendar, iOS Calendar และ Google Calendar ไม่ได้ implement ฟิลด์นี้
  • การจัดหมวดหมู่ด้วยข้อความอิสระรักษาความสม่ำเสมอได้ยาก จึงโมเดลประเภทอีเวนต์ด้วย Python enum
    • ตัวอย่าง: TerminType, CultureType, SocialType, AwayType, TransportType
    • มีค่าต่างๆ เช่น MEETUP, CONFERENCE, CLASS, APPOINTMENT, MEETING, EXAM
  • เหตุผลที่แบ่ง enum เป็นหลายกลุ่มก็เพื่อจัดระเบียบประเภทอีเวนต์ในเชิงแนวคิด
  • ระบบจัดหมวดหมู่นี้ยังมีลอจิกสำหรับกำหนดขอบเขตการเผยแพร่ในปฏิทินงานด้วย
    • ค่า enum แบบสองตัวอักษรจะถูกจัดการเป็น private โดยค่าเริ่มต้นในปฏิทินงาน
    • อีเวนต์อย่างการพบแพทย์จะถูก serialize เป็นแบบส่วนตัวในไฟล์ปฏิทินงานแยกต่างหาก
  • การจัดหมวดหมู่นี้ใช้เพื่อเพิ่มความสามารถในการค้นหาและการระบุด้วยสายตาของอีเวนต์ และช่วยให้ดูได้ง่ายในพริบตาบนฟรอนต์เอนด์ที่รองรับการแยกสี

สคริปต์ซิงก์ Python และการเผยแพร่ ICS

  • เพื่อทำ automation จึงผูกสคริปต์ Python เข้ากับ cron job
  • สคริปต์รวบรวมอินพุตหลายแหล่งเข้า Baïkal แล้วส่งออกกลับเป็น ICS ที่แชร์ได้
    • นำเข้าอีเวนต์จากอีเมลผ่าน IMAP
    • ดึงอีเวนต์เที่ยวบินจาก Airtrail API
    • นำเข้าไฟล์ ICS ที่โรงเรียนภาษาโฮสต์ไว้
    • push อีเวนต์ที่รวบรวมได้เข้า Baïkal
    • ดึงอีเวนต์ทั้งหมดจาก Baïkal แล้ว serialize กลับเป็นไฟล์ ICS ที่แชร์ได้หนึ่งไฟล์ขึ้นไป
  • การเชื่อมต่อ IMAP นำคำเชิญปฏิทินที่ได้รับทางอีเมลเข้ามาโดยอัตโนมัติและเพิ่มลงในปฏิทิน จึงให้ความสามารถคล้าย Google Calendar
  • สคริปต์ entry point ของ cron สร้าง Calendar สำหรับครอบครัวและงานแยกกัน แล้วดึงอีเวนต์จาก Baïkal มาประมวลผลแยกทาง
    • เพิ่มอีเวนต์ลงใน ICS สำหรับครอบครัว
    • เพิ่มลงใน ICS สำหรับงานเฉพาะเมื่อไม่มีที่อยู่อีเมลงานอยู่ในผลลัพธ์การ serialize ของอีเวนต์
    • ตั้ง classification เป็น PUBLIC หรือ PRIVATE ตามผลลัพธ์ของ is_work_public
  • สคริปต์เชื่อมต่อ Baïkal ใช้คำขอ PROPFIND และ HTTP Digest authentication เพื่อดึงอีเวนต์จากระยะไกล
  • หากมีแพตเทิร์น CATEGORIES: ในคำอธิบายอีเวนต์ จะดึงหมวดหมู่ออกจากฟิลด์คำอธิบาย ใส่ไว้ใน event.categories และลบสตริงนั้นออกจากคำอธิบาย
  • ไฟล์ ICS สำหรับแชร์ให้บริการผ่าน nginx ด้วย URL ที่เดายาก โดย URL สร้างจากสตริงแฮชแบบสุ่มที่ใส่ salt
  • cron job นี้รัน ทุก 15 นาที

การซิงก์ Google Calendar สำหรับงาน

  • ไม่ใช่แค่การดูอีเวนต์ในปฏิทินส่วนตัวเท่านั้น แต่ตารางการเดินทาง/เที่ยวบินต้องแสดงเป็นเวลาที่ถูกบล็อกในปฏิทินงาน และเพื่อนร่วมงานต้องรู้สถานะได้ด้วย
  • การคัดลอกไปยังปฏิทินงานใช้ Google Script Engine
  • สคริปต์พื้นฐานเป็นเวอร์ชันดัดแปลงของ GAS-ICS-Sync
  • เวอร์ชันดัดแปลงอ่านคุณสมบัติ CATEGORIES ของปฏิทินและใช้ color coding ในปฏิทินงาน
  • Google Script รันด้วย ช่วงเวลา 30 นาที
  • การใช้ Google Calendar ขัดกับเป้าหมายการลดการพึ่งพา Big Tech แต่แยกความแตกต่างว่าเป็นทางเลือกของสภาพแวดล้อมงาน ไม่ใช่การพึ่งพาสำหรับการใช้งานส่วนตัว

ผลการใช้งานและค่าใช้จ่าย

  • ระบบนี้ถูกใช้งานมาประมาณ 6 เดือน พร้อมการแก้ไขและเพิ่มเติมเล็กๆ น้อยๆ
  • การเปลี่ยนแปลงล่าสุดคือการผสานรวม Airtrail API
    • เมื่อจองเที่ยวบิน จะกรอกข้อมูลลงในตัวติดตามเที่ยวบิน
    • ระบบจะเพิ่มลงในปฏิทินส่วนตัวภายใน 15 นาที
    • ระบบจะคัดลอกไปยังปฏิทินงานโดยอัตโนมัติภายใน 1 ชั่วโมง
  • สำหรับความต้องการเดินทางที่ซับซ้อน ระบบช่วยลดเวลาจัดการตารางเวลาได้มากและนำไปสู่ คุณภาพชีวิตที่ดีขึ้น
  • ค่าใช้จ่ายรวมสามารถทำให้ต่ำที่สุดได้ และรันบน NAS ในบ้านได้ง่าย
  • ปัจจุบันสมัครใช้เวลาเซิร์ฟเวอร์ประมาณ 100 ดอลลาร์ ต่อเดือน โดยเก็บข้อมูลไว้ในสวิตเซอร์แลนด์เพื่อรันเว็บไซต์และการผสานรวม
  • ค่าใช้จ่ายนี้เป็นการตั้งค่าที่ค่อนข้างเกินความจำเป็น และมีแผนจะปรับให้เหมาะสมเมื่อเวลาผ่านไป
  • การตั้งค่าได้อย่างรวดเร็วบน Docker host ของ VM instance เป็นสิ่งที่คุ้มกับค่าใช้จ่ายเพิ่มเติม และการจัดการตารางเวลาที่ง่ายขึ้นก็ช่วยประหยัดเวลาได้เทียบเท่า 100 ดอลลาร์ต่อเดือน

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

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

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

  • อาจมีคนไม่เห็นด้วย แต่ผมมองว่า CalDAV ไม่ค่อยดีเท่าไร
    ถ้ามันง่ายและยอดเยี่ยมจริง ก็น่าจะมีโซลูชัน CalDAV แบบเซลฟ์โฮสต์มากกว่านี้มาก และใช้งานได้ดีกว่านี้ แต่ Radicale ก็ไม่ได้ทำให้ประทับใจ
    จริง ๆ แล้วสำหรับผมมันก็แค่ไฟล์ปฏิทินไฟล์เดียวที่จะให้บริการ เลยเคยลองทำ CalDAV server เอง แต่แม้แต่การเปิดให้เข้าถึงไฟล์เดียวก็ยังไม่เป็นธรรมชาติและซับซ้อนเกินไป จนยอมแพ้
    ถ้าต้องแชร์ปฏิทินกับคนอื่นผ่านแอปที่รองรับ CalDAV ก็เข้าใจความจำเป็นอยู่ แต่ถ้าใช้โฮสต์ปฏิทินสำหรับใช้คนเดียว รู้สึกว่าเกือบจะเป็นการเสียเวลา
    แทนที่จะทำแบบนั้น ตอนแรกผมอัปโหลด ไฟล์ iCal ที่อัปเดตแบบไดนามิกไปยัง S3 bucket แล้วซิงก์ด้วย ICSx5 บน Android แค่ HTTPS ก็พอแล้ว ไม่ต้องมี CalDAV
    อย่างไรก็ดี แอปปฏิทินโอเพนซอร์สเสรีสำหรับ Android ยังมีไม่พอ และ ICSx5 ทำงานบน GrapheneOS ได้ไม่ค่อยดี ตอนนี้เลยใช้ Proton Calendar ที่รองรับลิงก์ไฟล์ iCal โดยตรง ในแนวทางแทบจะเหมือนกัน
    แนวทางที่ใช้รูปแบบ iCalendar นั้นดี แต่ซอฟต์แวร์ปฏิทินแต่ละตัวรองรับฟีเจอร์ของ iCalendar แตกต่างกันมาก สุดท้ายจึงต้องยัดเมทาดาทาส่วนใหญ่ลงในช่องคำอธิบาย แทนที่จะใช้พร็อพเพอร์ตีเฉพาะ
    การใช้งานของผมคือซอฟต์แวร์ที่ดึงข้อมูลจากหลายไซต์ เช่น Eventbrite, Meetup, ผู้จัด pub quiz, ปฏิทินอีเวนต์สาธารณะ แล้วกรองเฉพาะอีเวนต์สังคมที่สนใจ จากนั้นรวมเป็นปฏิทินเดียวที่ดูได้ในแอปปฏิทินที่ใช้ประจำ

    • ผมเคยทำงานกับ CalDAV client ที่อยู่ในผลิตภัณฑ์ Apple ทุกตัว และเห็นด้วยว่าโปรโตคอลนี้ไม่ค่อยดี
      แถมยังลำบากมากกับการต้องรับมือ CalDAV server ของ Exchange และ Google ที่ไม่ทำตามสเปก แล้วผู้ใช้ก็โยนความผิดทั้งหมดมาให้เรา
      ตอนนี้พอมาทำงานที่ Google ก็พบว่าแอป gCal ใช้โปรโตคอลคนละตัวกันโดยสิ้นเชิง
    • ปัญหาหลักของ CalDAV และ WebDAV ที่เป็นพื้นฐานของมัน คล้ายกับโรคเรื้อรังที่เห็นในมาตรฐานส่วนใหญ่ที่ W3 อนุมัติ
      มันไม่ใช่รูปแบบที่เบา แต่พยายามทำหลายอย่างเกินไปในคราวเดียวจนออกแบบเกินจำเป็น และผลลัพธ์คือโปรโตคอลที่เหมือนก้อนขนที่ไอเดียต่าง ๆ พันกันยุ่ง
      จึงเกิดสถานการณ์ที่บริการจำนวนมากไม่อยากปฏิบัติตามสเปกทั้งหมดอย่างสมบูรณ์ เพราะมันเกินขอบเขตที่พวกเขาต้องการจริง ๆ
      สเปกรูปแบบข้อมูลของ W3 ดูเหมือนจะจบแบบนี้เสมอ ส่วนสเปกโปรโตคอลระดับต่ำดูจะเป็นแบบนี้น้อยกว่า
    • หนังสือชื่อ Dreaming in Code เล่าละเอียดว่า CalDAV และ WebDAV เกิดขึ้นมาได้อย่างไร ผ่านทีมที่สร้างโปรแกรมปฏิทิน Chandler
      ผมอ่านมา 15 ปีแล้ว แต่จำได้ว่ามันพูดถึงบางส่วนด้วยว่าโปรโตคอลแบบนี้หลงทางไปในคณะกรรมการระหว่างกระบวนการออกแบบอย่างไร
      แค่ข้อเท็จจริงที่ว่าโปรเจกต์นี้เริ่มราวปี 2001 ก็พอจะบอกได้ว่าปัญหาเรื่องปฏิทินเป็นเรื่องปวดหัวที่ยาวนานแค่ไหนแล้ว
      ถ้าอยากรู้ว่าทำไมมันถึงไม่ดี ก็แนะนำเล่มนี้ และยังเป็นเรื่องที่ดีเกี่ยวกับการปะทะกันของสตาร์ทอัพกับโอเพนซอร์ส การสร้างผลิตภัณฑ์ และการพัฒนาซอฟต์แวร์โดยรวมด้วย
      http://www.dreamingincode.com/ ; https://en.m.wikipedia.org/wiki/Dreaming_in_Code
    • ใช้ CalDAV และ CardDAV ของ Nextcloud ร่วมกับ DAVx5 อยู่ และทำงานได้เกือบสมบูรณ์แบบ
    • ผู้ให้บริการ CalDAV ของผมคือ ZOHO
      สำหรับการซิงก์บน Android ผมใช้ DAVX5 ซึ่งเป็นแอปโอเพนซอร์สแบบไม่ต้อง root ที่รันบริการซิงก์เบื้องหลัง แต่การตั้งค่ามีปัญหาเยอะ และอาจเป็นเพราะความแตกต่างในการ implement CalDAV การซิงก์จาก DAVX5 ไปยัง ZOHO Calendar ก็ใช้เวลานานด้วย
      Evolution บน Ubuntu รองรับ CalDAV ได้ค่อนข้างดี แต่ทุกครั้งที่สลับระหว่างมุมมองเมลกับมุมมองปฏิทิน มันจะรีเฟรชทั้งปฏิทิน การรีเฟรช ZOHO Calendar ใช้เวลานาน และ rate limit ของ ZOHO ก็เข้มมาก จนแทบจะโดนบล็อกแบบ soft block
      Thunderbird รุ่นล่าสุดมีความไม่เข้ากันกับ CalDAV เพราะคาดหวังรหัส HTTP สำเร็จคนละตัว ZOHO ส่ง 200 แต่ Thunderbird คาดหวังโค้ดอื่น อนึ่ง โค้ด CalDAV ของ Thunderbird เขียนด้วย JS
      ปัญหานี้เกิดเฉพาะกับปฏิทินที่สอง และทันทีที่เพิ่มอันที่สองเข้าไป มันก็เริ่มล้มเหลว อย่างน้อยบน ZOHO ก็เจ็บปวดพอสมควร

  • CalDAV server อีกตัวที่น่าแนะนำคือ Radicale
    เขียนด้วย Python และออกแบบค่อนข้างเป็นโมดูล จึงต่อปลั๊กอินสำหรับการยืนยันตัวตน การอนุญาตสิทธิ์ และอื่น ๆ ได้
    ข้อมูลถูกเก็บเป็นไฟล์ข้อความธรรมดา และผมติดตามกับสำรองด้วย git
    เมื่อเวลาผ่านไป ผมสะสมการปรับแก้ที่น่าสนใจไว้หลายอย่าง การยืนยันตัวตนทำผ่าน pam ของระบบโฮสต์ และมีสคริปต์ตามรอบเวลาที่ทำ symbolic link ปฏิทินไปให้ผู้ใช้ทุกคนที่ได้รับอนุญาต เพื่อแชร์ปฏิทิน แต่มีปัญหาการระเบิดเชิงจัดหมู่
    ผมเพิ่ม access control list ด้วยปลั๊กอินสิทธิ์ที่ใช้พร็อพเพอร์ตี CalDAV แบบกำหนดเอง และเว็บปลั๊กอินที่ปรับแก้แล้ว
    ปฏิทินสาธารณะให้สิทธิ์อ่านแก่ผู้ใช้ public ผ่าน ACL และใช้การแฮ็ก nginx เพื่ออนุญาตการเข้าถึงแบบครอบคลุมสำหรับงานอ่าน
    ปฏิทินสาธารณะนี้ดูได้ในเว็บปฏิทิน: https://gitlab.nomagic.uk/popi/js_calendar_from_ics
    ผมน่าจะต้องเขียนบล็อกเกี่ยวกับการตั้งค่านี้

    • ใช้ Radicale มาหลายปีแล้ว นอกจากปัญหาที่เกิดขึ้นเป็นครั้งคราวใน BusyCal ก็ทำงานได้ ราบรื่นมาก

  • เป็นบทความที่ผมต้องการพอดี
    บนเซิร์ฟเวอร์ส่วนตัวผมใช้ปฏิทิน SoGO ของ Mailcow ส่วนปฏิทินงานใช้ Fastmail แต่ทั้งสองอย่างเข้ากันได้ไม่ดี
    ผมหาวิธีเชื่อมปฏิทิน Mailcow กับเครื่องมืออื่นให้ถูกต้องไม่ได้ เลยเสียเวลากับการซิงก์แบบกึ่งแมนนวลอยู่
    อยากแยกปฏิทินมาสักพักแล้ว แต่ทางเลือกที่รู้จักมีแค่ Nextcloud และผมมองว่ามันค่อนข้างหนัก
    Baïkal ดูน่าสนใจ และอยากลองใช้เร็ว ๆ นี้ วิธีนี้อาจทำให้ผมสำรวจการเปลี่ยน Mailcow ไปเป็นบริการเมลแบบเซลฟ์โฮสต์ตัวอื่นได้ด้วย

  • ช่วงนี้กำลังพยายามออกจากคลาวด์อย่างจริงจังมาก มีข้อมูลอยู่หลายร้อย GB แต่ถึงจะย้ายแบบทำ ๆ หยุด ๆ ก็ใช้เวลา ไม่ถึง 2 สัปดาห์ และทำงานได้ดีกว่าที่คาดไว้มาก
    บริการเดียวที่ยังฝากไว้ข้างนอกคืออีเมล เพราะไม่อยากจัดการ MX record กับ IMAP/SMTP
    ส่วนอื่น ๆ Asus PN40 ที่ใช้ CPU Celeron แบบ dual-core ช่วยได้มาก ข้อดีคือเข้าถึงง่าย และมีสล็อต M.2 NVME กับไดรฟ์ SATA ทำให้ตั้งค่าการสำรองข้อมูลที่ปลอดภัยไว้ในที่เดียวได้
    เห็นด้วยว่า CalDAV ดูน่ากังขาอยู่บ้าง แต่ Nextcloud ก็เติมเต็มความต้องการส่วนใหญ่ได้ แม้ต่อ Redis แล้วงานบางอย่างอาจยังช้า แต่ก็จัดการได้ดีตั้งแต่ปฏิทิน, ตัวแทน Dropbox/Google Drive, เอกสาร, รูปภาพ, การสำรองข้อมูล ไปจนถึงการซิงก์อัตโนมัติ
    ถ้าเสริมโซลูชันโอเพนซอร์สหลายตัวเข้าไป ก็แก้ได้ครบทั้งสตรีมเพลงและวิดีโอ, monitoring, การแจ้งเตือน, VPN, reader, เครื่องมือจัดการ และยูทิลิตีต่าง ๆ
    มินิพีซีเครื่องนี้แม้สเปกค่อนข้างต่ำ แต่เพราะ ISP ดีมาก จึงรับทั้งหมดได้โดยยังเหลือเผื่อเยอะ และน่าจะรองรับคนแบบผมเพิ่มอีก 5–6 คนได้สบาย

    • ถ้าอยากเพิ่มความทนทานของข้อมูล แนะนำให้ลองค้นหา กลยุทธ์สำรองข้อมูล 3-2-1 ดู RAID ก็น่าดูควบคู่กันไป

  • ให้ความรู้สึกเหมือนของเก่ากลับมาใหม่
    ช่วงต้นทศวรรษ 2000 เคยโฮสต์ปฏิทินด้วย Mozilla Sunbird ผ่านโมดูล IIS WebDAV บนเซิร์ฟเวอร์ Win2k ส่วนตัว
    ตอนนั้น CardDAV น่าจะยังไม่มี แต่อาจจำผิดก็ได้
    สุดท้ายก็ย้ายข้อมูลทั้งหมดนั้นเข้า Google Calendar และถ้าย้อนไปไกล ๆ ก็ยังมีอย่างงานส่งอาจารย์สมัยมหาวิทยาลัยหลงเหลืออยู่ด้วย ซึ่งค่อนข้างสนุกดี

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

  • Baikal ดูน่าสนใจ
    เมื่อก่อนเคยใช้ DAViCal เพื่อแชร์ปฏิทินระหว่างอุปกรณ์ Apple iOS หลายเครื่อง ตอนมันทำงานก็ทำงานได้ดี แต่พอเวอร์ชัน iOS เปลี่ยนไปก็เหมือนเริ่มไม่เสถียร สุดท้ายเลยเลิกใช้
    ถ้าวันหนึ่งได้กลับไปดูอีกครั้ง คงจะดู DAViCal กับ Radicale และตอนนี้ก็รวม Baikal ด้วย
    https://www.davical.org/
    https://radicale.org/v3.html

    • ใช้ Radicale มานานและทำงานได้ดี
      ช่วงหลังย้ายไป Nextcloud เพราะ shared hosting ช่วยดูแลการ deploy ให้ และมีเว็บ UI แบบรวมศูนย์ ทำให้ภาระการตั้งค่าน้อยลงมาก

  • ใช้ Baikal มาหลายปีแล้ว ค่อนข้างแข็งแรงดี แต่ใช้คนเดียว และไม่ได้มีข้อกำหนดทั้งหมดเหมือนในโพสต์ต้นฉบับ
    บนเดสก์ท็อปเชื่อมผ่านปฏิทินในตัวของ Thunderbird ส่วนบนมือถือใช้ DAVx5 จาก F-Droid กับ Fossify Calendar
    Fossify Calendar แยกออกมาจากแอป Calendar ของ Simple Mobile Tools แต่แม้ชื่อจะฟังดูเรียบง่าย กลับเป็นแอปปฏิทินที่ฟีเจอร์ครบที่สุดเท่าที่เคยเห็นมา
    ชอบตรงความเรียบง่ายแบบ แสดงตัวเลือกทั้งหมดให้เห็นทันที ไม่ต้องให้ขุดเข้าเมนูและกล่องโต้ตอบหลายชั้น

  • ที่ทำงานใช้ Outlook ที่บ้านใช้ Google Calendar แต่พอซิงก์ผ่าน HTTP แล้วไม่เสถียรโดยสิ้นเชิง
    เหมือนมันทำ timezone พังตลอด บางครั้ง publish เป็น UTC บางครั้งก็ไม่ใช่ ทำให้เวลา meeting ผิดอยู่เสมอ
    ไม่เข้าใจว่าผู้ให้บริการรายใหญ่สองเจ้านี้แก้ฟีเจอร์พื้นฐานขนาดนี้ไม่ได้อย่างไร
    ถ้าใช้ระบบของตัวเองแล้วแก้ได้ก็จะทำทันที แต่กังวลว่าจะเจอเรื่องเดิมคือ meeting ที่สร้างใน Outlook ถูก import มาเหลื่อมไป 2 ชั่วโมง

    • การจัดการ timezone ของผลิตภัณฑ์ Google โดยรวมพังอย่างสิ้นหวังข้ามแอปมาหลายสิบปีแล้ว แต่เดี๋ยวนักพัฒนา AI ก็คงจัดการให้ได้ในไม่ช้า
    • แทบไม่มีแรงจูงใจทางการเงินให้แก้ปัญหานี้ ตรงกันข้าม มันยังช่วยสร้าง lock-in effect ด้วย
      อีกอย่าง หลายบริษัทห้ามซิงก์ปฏิทินส่วนตัวกับปฏิทินงานจริง ๆ เพราะปัญหาข้อมูลรั่วไหล

  • อยากทำแบบนี้กับ รูปภาพ ด้วย อยากออกจาก Dropbox กับ Google มาสักพักแล้ว และมีเรื่องสำคัญสองอย่าง
    อย่างแรก อยากสร้างฟีเจอร์แนว memories จากรูปของตัวเองแล้วส่งไปยังมือถือ เช่น จัดกลุ่มตามวันครบรอบ, กิจกรรมที่คล้ายกัน, ฉันกับ X(X คือคู่สมรส ครอบครัว เพื่อน ฯลฯ), การเปลี่ยนแปลงตามเวลา
    อย่างที่สอง ต้องสามารถเก็บรูปที่ถ่ายจากอุปกรณ์ไว้บนเซิร์ฟเวอร์ของตัวเองได้
    เตรียมเครื่อง TrueNAS 3 เครื่องที่มีพื้นที่ 2TB อยู่ต่างสถานที่กันไว้แล้ว และอยากค่อย ๆ สร้างฟีเจอร์นี้ขึ้นมา

    • เพิ่งตั้งค่าแบบนี้ด้วย Immich รูป 2TB ถูกใส่เข้าไปแล้ว และมือถือสำรองข้อมูลอัตโนมัติ การเข้าถึงจากระยะไกลใช้ Cloudflare Tunnels
    • ถ้าใช้ Synology NAS ระบบปฏิบัติการ DiskStation Manager รองรับฟีเจอร์นี้ผ่านแอป Photos และ Moments
      https://www.synology.com/en-global/dsm/feature/photos
      https://www.synology.com/en-global/dsm/feature/moments
    • เมื่อไม่กี่เดือนก่อนตั้งค่านี้ด้วย PhotoPrism: https://github.com/photoprism/photoprism
    • ถ้าใช้ Nextcloud อยู่แล้วก็มี Nextcloud Memories และถ้าไม่ใช่ อย่างที่คนอื่นพูดกัน Immich ก็ค่อนข้างดี
    • เคยทิ้งคอมเมนต์รวมโปรเจกต์ในสายนี้ไว้ก่อนหน้านี้: https://news.ycombinator.com/item?id=39155977

  • อีกวิธีคือใช้ DecSync โดยไม่ต้องมีเซิร์ฟเวอร์
    Thunderbird หรือ Evolution ซิงก์กับแอป Android และปฏิทิน รายชื่อ งาน รวมถึง RSS จะถูก replicate ไปยัง peer อื่น ๆ ได้ มีให้โหลดบน F-Droid ด้วย
    https://github.com/39aldo39/DecSync

    • น่าสนใจ แต่ไม่เห็นว่ารองรับ iOS และน่าเสียดายที่ดูเหมือนไม่มีการบำรุงรักษาแล้ว