diff --git a/README.md b/README.md
index 8171af1..8fc54ca 100644
--- a/README.md
+++ b/README.md
@@ -22,3 +22,4 @@ Meeting Notes
 -------------
 
 - [2022-09-05](./meetings/2022-09-05.md)
+- [2022-10-01](./meetings/2022-10-01.md) (OpenJS Foundation Collaborator Summit: Dublin)
diff --git a/meetings/2022-10-01.md b/meetings/2022-10-01.md
new file mode 100644
index 0000000..c82bbc4
--- /dev/null
+++ b/meetings/2022-10-01.md
@@ -0,0 +1,69 @@
+# Node.js Single-Executable OpenJS Mini-summit 2022-10-01
+
+## Present
+
+* Michael Dawson @mhdawson
+* Darshan Sen @RaisinTen
+* Juan Cruz Viotti @jviotti
+* Claudio Wunder @ovflowd
+* Ruy Adorno @ruyadorno
+* Orta Therox @orta
+* Tierney Cyren @bnb
+* Tobias Nießen @tniessen 
+* Tony Gorez @tony-go
+* Anton Whalley @No9
+* Waleed Ashraf @WaleedAshraf
+
+## Notes
+
+- There is general agreement that we want to try as hard as possible to make
+  SEAs truly "single executable" without additional resources
+- There is agreement that we don't want Node.js to support a single specific
+  blessed VFS. Instead, Node.js should aim to provide the necessary hooks for
+  supporting arbitrary VFS implementations
+- Teaching Node.js how to transparently work with a VFS on `fs`, `require`,
+  `import` and `child_process` is non-trivial. We agreed that we do not want
+  implementations to continue monkey-patching these modules and that
+  monkey-patching will not work with ESM at all
+- Exposing hooking capabilities is a complex problem. While we agree that a VFS
+  is essential for supporting dynamic requires, read operations, etc we believe
+  that there is a significant number of Node.js CLIs that might not need this
+- Therefore, we can explore delivering an MVP without a VFS while we continue
+  thinking about how we'll do VFS properly
+- This MVP would assume that apps are bundled into a single JavaScript file
+  before injection
+- Node.js core would take a small patch to detect a single file embedded as a
+  section and jump to it if found
+- In the interest of making Node.js binaries smaller without operating custom
+  Node.js builds, we will move the ICU data into a new section, so it can be
+  replaced by the ICU "small" data (or removed?) if needed post-compilation
+  rather than at build-time
+- We expect that distributing Node.js injected binaries to user computers will
+  come with challenges we want to solve in advance. For example, Windows PE
+  binaries including plain JavaScript tend to be flagged by AntiViruses as
+  trojans. We will start maintaining a list of these challenges and then try to
+  figure out how to incrementally solve them.
+
+## Action Items
+
+- Send patch to https://github.com/nodejs/node to detect and jump to a section
+  containing a single JavaScript file if found
+  (https://github.com/nodejs/single-executable/issues/47)
+- Collect a list of potential problems we would face when distributing Node.js
+  injected binaries to user computers across operating systems
+  (https://github.com/nodejs/single-executable/issues/46)
+- Split Node.js ICU data into its own section (so we can fiddle with it with
+  Postject) (https://github.com/nodejs/single-executable/issues/48)
+- @No9 to connect us with IBM AIX folks to understand the need for SEAs on AIX
+  (and potential XCOFF help?)
+- Start working on a proper "SEA" CLI MVP that can bundle and inject simple
+  Node.js applications (https://github.com/nodejs/single-executable/issues/49)
+
+## Other Ideas
+
+- We could explore splitting different Node.js modules (like `fs`) into
+  separate sections to strip them out for applications that do not need them
+- We could explore a different mechanism for loading native add-ons in order to
+  embed them into the executable itself. For example, marking the corresponding
+  sections as readable + executable and doing a long jump to the instructions
+  corresponding to the add-ons instead of using `dlopen`, etc