diff --git a/docs/twitter/1868716773937414589/thread.md b/docs/twitter/1868716773937414589/thread.md
new file mode 100644
index 00000000..4303f977
--- /dev/null
+++ b/docs/twitter/1868716773937414589/thread.md
@@ -0,0 +1,35 @@
+---
+title: "@AgileJebrim @GustavSterbrant Also I wouldn't just modify an existing compiler, "
+author: "NOTimothyLottes"
+handle: "@NOTimothyLottes"
+post_url: "https://x.com/NOTimothyLottes/status/1868716773937414589"
+post_id: "1868716773937414589"
+timestamp: "2024-12-16 17:56:12"
+post_count: 5
+reply_count: 1
+repost_count: 0
+like_count: 2
+view_count: 129
+---
+
+# @NOTimothyLottes — @AgileJebrim @GustavSterbrant Also I wouldn't just modify an existing compiler, 
+
+## Post 1 (2024-12-16 17:38:22)
+
+@GustavSterbrant So I don't know that SPIR-V vs OpTypeInt 24 question, but if someone didn't write tests for that it's likely never been setup to be pattern matched. Most of the problems I see cannot be fixed just by bypassing GLSL and doing SPIR-V directly. So not yet tempted to write a new SL
+
+## Post 2 (2024-12-16 17:46:31) — reply to Post 1
+
+@NOTimothyLottes @GustavSterbrant If you’re targeting a console with AMD hardware, why don’t you just rewrite the backend compiler? I assume you have the source for it too, so it’s more tweaking an existing compiler than anything else?
+
+## Post 3 (2024-12-16 17:55:08) — reply to Post 2
+
+@AgileJebrim @GustavSterbrant At-home stuff (aka non-employer) targets Vulkan Windows mostly (unfortunately). No interface in AMD's Windows driver to load binary shaders into Vulkan. If SteamOS ever fully took over PC gaming, then certainly I'd just go direct to the AMD kernel driver and bypass user-mode VK
+
+## Post 4 (2024-12-16 17:56:12) — reply to Post 3
+
+@AgileJebrim @GustavSterbrant Also I wouldn't just modify an existing compiler, I'd just write an assembler specific for GCN/RDNA/whateversNext family.
+
+## Post 5 (2024-12-16 17:58:00) — reply to Post 4
+
+@NOTimothyLottes @GustavSterbrant Fair enough. Current compilers are a bloated mess anyways and you’d get much faster times with your own assembler.
diff --git a/docs/twitter/1868716773937414589/thread_data.json b/docs/twitter/1868716773937414589/thread_data.json
new file mode 100644
index 00000000..a0a5e0b8
--- /dev/null
+++ b/docs/twitter/1868716773937414589/thread_data.json
@@ -0,0 +1,86 @@
+{
+  "root_post_id": "1868716773937414589",
+  "posts": [
+    {
+      "post_id": "1868712285675671711",
+      "author": "NOTimothyLottes",
+      "handle": "NOTimothyLottes",
+      "text": "@GustavSterbrant So I don't know that SPIR-V vs OpTypeInt 24 question, but if someone didn't write tests for that it's likely never been setup to be pattern matched. Most of the problems I see cannot be fixed just by bypassing GLSL and doing SPIR-V directly. So not yet tempted to write a new SL",
+      "timestamp": "2024-12-16 17:38:22",
+      "media_urls": [],
+      "reply_to_id": null,
+      "quote_of_id": null,
+      "metrics": {
+        "reply_count": 1,
+        "repost_count": 0,
+        "like_count": 0,
+        "view_count": 115
+      }
+    },
+    {
+      "post_id": "1868714338418315659",
+      "author": "Jebrim",
+      "handle": "AgileJebrim",
+      "text": "@NOTimothyLottes @GustavSterbrant If you’re targeting a console with AMD hardware, why don’t you just rewrite the backend compiler? I assume you have the source for it too, so it’s more tweaking an existing compiler than anything else?",
+      "timestamp": "2024-12-16 17:46:31",
+      "media_urls": [],
+      "reply_to_id": "1868712285675671711",
+      "quote_of_id": null,
+      "metrics": {
+        "reply_count": 1,
+        "repost_count": 0,
+        "like_count": 0,
+        "view_count": 49
+      }
+    },
+    {
+      "post_id": "1868716505325879612",
+      "author": "NOTimothyLottes",
+      "handle": "NOTimothyLottes",
+      "text": "@AgileJebrim @GustavSterbrant At-home stuff (aka non-employer) targets Vulkan Windows mostly (unfortunately). No interface in AMD's Windows driver to load binary shaders into Vulkan. If SteamOS ever fully took over PC gaming, then certainly I'd just go direct to the AMD kernel driver and bypass user-mode VK",
+      "timestamp": "2024-12-16 17:55:08",
+      "media_urls": [],
+      "reply_to_id": "1868714338418315659",
+      "quote_of_id": null,
+      "metrics": {
+        "reply_count": 2,
+        "repost_count": 0,
+        "like_count": 0,
+        "view_count": 160
+      }
+    },
+    {
+      "post_id": "1868716773937414589",
+      "author": "NOTimothyLottes",
+      "handle": "NOTimothyLottes",
+      "text": "@AgileJebrim @GustavSterbrant Also I wouldn't just modify an existing compiler, I'd just write an assembler specific for GCN/RDNA/whateversNext family.",
+      "timestamp": "2024-12-16 17:56:12",
+      "media_urls": [],
+      "reply_to_id": "1868716505325879612",
+      "quote_of_id": null,
+      "metrics": {
+        "reply_count": 1,
+        "repost_count": 0,
+        "like_count": 2,
+        "view_count": 129
+      }
+    },
+    {
+      "post_id": "1868717227866046808",
+      "author": "Jebrim",
+      "handle": "AgileJebrim",
+      "text": "@NOTimothyLottes @GustavSterbrant Fair enough. Current compilers are a bloated mess anyways and you’d get much faster times with your own assembler.",
+      "timestamp": "2024-12-16 17:58:00",
+      "media_urls": [],
+      "reply_to_id": "1868716773937414589",
+      "quote_of_id": null,
+      "metrics": {
+        "reply_count": 0,
+        "repost_count": 0,
+        "like_count": 0,
+        "view_count": 37
+      }
+    }
+  ],
+  "source_url": "https://x.com/NOTimothyLottes/status/1868716773937414589"
+}
\ No newline at end of file