ramforth/youtube-chat-webhook-v2
2
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

Merge branch 'main' of https://gitea.ramforth.net/ramforth/youtube-chat-webhook-v2

Browse Source
This commit is contained in:
ramforth
2025-10-30 22:14:54 +01:00
parent 7f3f65f0bf 0279a41939
commit 3845f15405
2 changed files with 64 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
DEVELOPMENT_PLAN.md
View File

@@ -60,23 +60,47 @@ Our network analysis revealed that YouTube's web client uses a `POST` request to
* **Status:** **COMPLETED.** Analysis of `pytchat` source code (`api.py`, `core/__init__.py`, `core/pytchat.py`, `config/__init__.py`, `paramgen/liveparam.py`, `paramgen/enc.py`, `util/__init__.py`, `parser/live.py`) has provided a comprehensive understanding of its internal mechanisms. The `pytchat` repository has been mirrored to `https://gitea.ramforth.net/ramforth/pytchat-fork` for easier access.
3. **Integration with `rich` Display:**
* **Action:** Adapt the existing `rich` display logic from `main.py` to consume messages received from `pytchat`.
* **Status:** **COMPLETED.** The `pytchat_listener.py` script now includes full-width alternating backgrounds, emoji coloring, and persistent unique user colors.
* **Status:** **COMPLETED.** The `pytchat_listener.py` script now includes full-width alternating backgrounds (with ongoing minor issue), emoji coloring, and persistent unique user colors.
## Phase 1.5: Display Enhancements (from To-Do-List)
* **Objective:** Implement additional display enhancements based on user feedback and the `To-Do-List.md`.
* **Actions:**
1. **Fix Multi-line Background Wrap:** Resolve the issue where alternating grey backgrounds do not fill 100% of the terminal width for multi-line messages.
2. **Add Animations (ref. Kitty terminal):** Investigate and implement subtle animations for new messages or other events.
3. **Set Terminal Title:** Dynamically set the terminal title to display relevant information (e.g., video ID, live status).
4. **Notification on New Message:** Implement a notification system for new messages, with a toggle to enable/disable it.
## Phase 2: Re-exploration of YouTube Data API v3 (Creative Use)
* **Objective:** Explore creative, highly optimized uses of the existing REST API that might offer better sustainability, even if not truly event-driven.
* **Actions:**
1. **Live Chat Replay API:** Investigate the `liveChatMessages.list` endpoint when used for *replays*. Does it have different quota characteristics or offer a more complete historical view that could be adapted for near real-time (e.g., fetching a larger batch less frequently)?
* **Findings:** `liveChatMessages.list` costs 5 quota points per request, regardless of whether it's for live or replay chat. Frequent polling (e.g., 1 request/second) will exhaust the 10,000 daily quota in about 33 minutes. The method is not designed for efficiently replaying extensive past chat history. There's no indication of different or more lenient quota characteristics for replay usage. This approach does not offer a sustainable, quota-friendly solution for continuous monitoring.
* **Status:** **COMPLETED.** Conclusion: Not a sustainable solution for continuous monitoring.
2. **Minimal `part` Parameters:** Re-confirm the absolute minimum `part` parameters required for `liveChatMessages.list` to reduce quota cost per call.
* **Findings:** The minimal `part` parameters to retrieve essential chat message information (author's name, message content, and author's unique ID for persistent colors) are `snippet,authorDetails`. This will incur a cost of 5 quota points per request.
* **Status:** **COMPLETED.**
3. **Intelligent Polling Refinement:** Explore advanced adaptive polling strategies beyond `pollingIntervalMillis`, potentially incorporating machine learning to predict chat activity and adjust polling frequency.
* **Findings:** While intelligent polling is a valuable concept for API management, it does not offer a viable path to a sustainable, quota-friendly solution for *continuous, real-time YouTube Live Chat using the official API*. Its application to `pytchat` is also not directly beneficial as `pytchat` already adapts its polling based on YouTube's internal signals.
* **Status:** **COMPLETED.** Conclusion: Not a primary solution for continuous chat fetching using the official API; not directly beneficial for `pytchat`.
## Phase 3: Community Solutions and Open-Source Projects
* **Objective:** Identify and analyze existing open-source projects that have successfully tackled sustainable YouTube Live Chat monitoring.
* **Actions:**
1. **GitHub/GitLab Search:** Search for projects related to "YouTube Live Chat bot," "YouTube Live Chat client," "YouTube Live Chat API alternative," focusing on Python and Linux compatibility.
2. **Project Analysis:** For promising projects, analyze their source code to understand their data acquisition methods, quota management, and compliance strategies.
3. **Community Forums:** Explore discussions on platforms like Reddit (r/youtube, r/livestreamfails, r/programming), Stack Overflow, and relevant developer forums for insights into unofficial methods or workarounds.
1. **GitHub/GitLab Search (Targeted `taizan-hokuto`):** Search for projects related to `pytchat` mentions by `taizan-hokuto` (original author).
* **Findings:** The original `pytchat` repository on GitHub (`https://github.com/taizan-hokuto/pytchat`) is publicly archived and no longer maintained by the author. No new active forks or related projects by the original author were immediately identified through this targeted search. However, the existence of our own fork (`https://gitea.ramforth.net/ramforth/pytchat-fork`) provides a controlled environment for potential maintenance and adaptation of the `pytchat`-based approach.
* **Status:** **COMPLETED.** Conclusion: Confirmed `pytchat`'s archived status; no direct new leads from `taizan-hokuto`. Our fork offers a path for maintenance.
2. **GitHub/GitLab Search (General):** Search for projects related to "YouTube Live Chat bot," "YouTube Live Chat client," "YouTube Live Chat API alternative," focusing on Python and Linux compatibility.
* **Findings:** Several promising projects were identified:
* **PyLivestream** (https://github.com/scivision/PyLivestream)
* **youtube-live-chat-client** (https://github.com/xenova/youtube-live-chat-client)
* **youtube-chat-downloader** (https://github.com/xenova/youtube-chat-downloader)
* **youtube-live-chat-bot** (https://github.com/xenova/youtube-live-chat-bot)
* **Status:** **COMPLETED.**
3. **Project Analysis:** For promising projects, analyze their source code to understand their data acquisition methods, quota management, and compliance strategies.
4. **Community Forums:** Explore discussions on platforms like Reddit (r/youtube, r/livestreamfails, r/programming), Stack Overflow, and relevant developer forums for insights into unofficial methods or workarounds.
## Phase 4: Re-evaluation of Third-Party Services (Event-Driven Focus)
@@ -89,4 +113,4 @@ Our network analysis revealed that YouTube's web client uses a `POST` request to
**Prioritization:** All research will prioritize **open-source and Linux-compatible solutions**. Compliance with YouTube's Terms of Service remains a critical factor.
**Next Steps:** The findings from this revised research will be compiled into a structured document to inform the design and implementation of a robust YouTube Live Chat monitoring solution.
**Next Steps:** The findings from this revised research will be compiled into a structured document to inform the design and implementation of a robust YouTube Live Chat monitoring solution.

37
PROGRESS_LOG.md
View File

@@ -37,7 +37,40 @@ This document chronicles the key steps, findings, and decisions made during the
* **Implications:** Highly fragile (subject to breaking), **critical compliance risk** (violates YouTube's Terms of Service).
* **Action:** `DEVELOPMENT_PLAN.md` was updated with these findings.
## Phase 2: Re-exploration of YouTube Data API v3 (Creative Use)
### Action 1: Live Chat Replay API
* **Investigation:** Explored `liveChatMessages.list` for replays to assess quota characteristics and suitability for near real-time.
* **Findings:** `liveChatMessages.list` costs 5 quota points per request, regardless of live or replay. Frequent polling exhausts the 10,000 daily quota quickly (approx. 33 mins at 1 req/sec). Not designed for efficient extensive chat history replay. No special quota for replay usage.
* **Conclusion:** Not a sustainable, quota-friendly solution for continuous monitoring.
### Action 2: Minimal `part` Parameters
* **Investigation:** Re-confirmed the absolute minimum `part` parameters for `liveChatMessages.list` to reduce quota cost.
* **Findings:** The minimal `part` parameters to retrieve essential chat message information (author's name, message content, and author's unique ID for persistent colors) are `snippet,authorDetails`. This will incur a cost of 5 quota points per request.
* **Conclusion:** While minimal parameters are identified, the base cost of 5 quota points per request still makes continuous polling unsustainable for the project's goal.
### Action 3: Intelligent Polling Refinement
* **Investigation:** Explored advanced adaptive polling strategies beyond `pollingIntervalMillis`, potentially incorporating machine learning to predict chat activity and adjust polling frequency.
* **Findings:** While intelligent polling is a valuable concept for API management, it does not offer a viable path to a sustainable, quota-friendly solution for *continuous, real-time YouTube Live Chat using the official API*. Its application to `pytchat` is also not directly beneficial as `pytchat` already adapts its polling based on YouTube's internal signals.
* **Conclusion:** Not a primary solution for continuous chat fetching using the official API; not directly beneficial for `pytchat`.
## Phase 3: Community Solutions and Open-Source Projects
### Action 1: GitHub/GitLab Search (Targeted `taizan-hokuto`)
* **Investigation:** Searched for projects related to `pytchat` mentions by `taizan-hokuto` (original author).
* **Findings:** The original `pytchat` repository on GitHub (`https://github.com/taizan-hokuto/pytchat`) is publicly archived and no longer maintained by the author. No new active forks or related projects by the original author were immediately identified through this targeted search. However, the existence of our own fork (`https://gitea.ramforth.net/ramforth/pytchat-fork`) provides a controlled environment for potential maintenance and adaptation of the `pytchat`-based approach.
* **Conclusion:** Confirmed `pytchat`'s archived status; no direct new leads from `taizan-hokuto`. Our fork offers a path for maintenance.
### Action 2: GitHub/GitLab Search (General)
* **Investigation:** Performed a general search for projects related to "YouTube Live Chat bot," "YouTube Live Chat client," "YouTube Live Chat API alternative," focusing on Python and Linux compatibility.
* **Findings:** Several promising projects were identified:
* **PyLivestream** (https://github.com/scivision/PyLivestream)
* **youtube-live-chat-client** (https://github.com/xenova/youtube-live-chat-client)
* **youtube-chat-downloader** (https://github.com/xenova/youtube-chat-downloader)
* **youtube-live-chat-bot** (https://github.com/xenova/youtube-live-chat-bot)
* **Conclusion:** These projects provide good starting points for further analysis of alternative solutions.
## Next Steps
* Proceed with "Integration with `rich` Display" as outlined in `DEVELOPMENT_PLAN.md`.
* Continue with other phases of the revised research plan, keeping the compliance and fragility risks of `pytchat` in mind.
* Proceed with "Project Analysis" as outlined in `DEVELOPMENT_PLAN.md`.
* Continue with other phases of the revised research plan, keeping the compliance and fragility risks of `pytchat` in mind.