diff --git a/docs/foam-core.md b/docs/foam-core.md
index 1dc10c56..1fe10ae0 100644
--- a/docs/foam-core.md
+++ b/docs/foam-core.md
@@ -44,7 +44,7 @@ Ideally, `foam-core` will be generic enough that in can be used by third parties
   - Aliasing, call the same thing by multiple names
     - Doesn't exist yet, should we support?
 - The graph should be observable (EventEmitter?) so changes can be applied
-  - EventEmitted w/ cross platform dependency
+  - EventEmitter w/ cross platform dependency
   - Wonka (staltz's callbag)
   - Can be a long term goal
     - Short term fix: Just run the build fully on every change
@@ -67,6 +67,7 @@ Here are some example use cases that the core should support. They don't need to
 - Finding all documents with instances of `[[link]]`
 - Visualisations
 - Full text search
+
   - Or, if search is too expensive/complex, when given a list of file names and line/column positions from VS Code search API, can return the document context (e.g. full paragraph, preceding/following line etc)
 
 ## Collaboration
@@ -90,12 +91,17 @@ Here are some example use cases that the core should support. They don't need to
 
 Useful for knowing what needs to be supported. See [[feature-comparison]].
 
+## Meeting notes
+
+- [[foam-core-2020-07-11]]
+
 [//begin]: # "Autogenerated link references for markdown compatibility"
 [workspace-janitor]: workspace-janitor "Workspace Janitor"
 [cli]: cli "Command Line Interface"
+[build-vs-assemble]: build-vs-assemble "Build vs Assemble"
 [wiki-links]: wiki-links "Wiki Links"
 [materialized-backlinks]: materialized-backlinks "Materialized Backlinks (stub)"
-[build-vs-assemble]: build-vs-assemble "Build vs Assemble"
-[feature-comparison]: feature-comparison "Feature comparison"
 [todo]: todo "Todo"
+[feature-comparison]: feature-comparison "Feature comparison"
+[foam-core-2020-07-11]: meeting-notes/foam-core-2020-07-11 "Foam Core 2020-07-11"
 [//end]: # "Autogenerated link references"
diff --git a/docs/meeting-notes/foam-core-2020-07-11.md b/docs/meeting-notes/foam-core-2020-07-11.md
new file mode 100644
index 00000000..a4805328
--- /dev/null
+++ b/docs/meeting-notes/foam-core-2020-07-11.md
@@ -0,0 +1,125 @@
+# Foam Core 2020-07-11
+
+Present: @jevakallio, @riccardoferretti
+
+### Tests
+
+- How do we know this approach works?
+  - Supports renaming
+  - Supports searching with (attribute-x)
+  - Find dead links
+
+### Getting started
+
+- Land work to master
+  - Create a foam-core package
+  -
+
+### Open questions
+
+- How should writing to files work
+  - What if affected notes have unsaved changes
+
+### Graph methods
+
+- get all
+- search by
+  - tag
+  - free text
+  - [[todo]]: how do vs code search editors work? are they pluggable? what do they need?
+- find dead links
+  - for linters
+- serialize/toJSON (for visualizers)
+- subscribe to changes
+
+### Node methods
+
+- rename
+- get links
+  - forward links (for link lists)
+  - backlinks (with surrounding context)
+
+### Node definition
+
+What do we need the node (and edge metadata) to contain:
+
+- `id`: tbd
+  - should be unique, needs some kind of unique gen function
+  - should be reconstructable even if links are not updated every time
+  - what happens during rename? is reparenting the graph going to be hard?
+  - do id's need to be persistent, or can we create them per in-memory session, keep them stable despite renames, and then next session generate a new id?
+  - Ideally should be a path to file, so it's easy to look up from the graph by id for renaming
+- `type`: Note | Image | etc
+- `title`: can be read from markdown title or frontmatter metadata
+- `path`: full path to file, relative to workspace (graph) root
+- `links`:
+  - `id`: File to link to
+  - `text`: The link label
+  - `type` markdown | mediawiki | image | http
+  - `section`
+  - `block` (ref)
+  - Positional data from AST?
+- `tags`
+
+### Markdown layer
+
+- `source`: raw markdown (rename?)
+- `ast`: raw markdown ast
+- `checksum`: if we do caching
+
+### Link text
+
+// some-file.md
+// # Some File
+
+Write -> Store on disk
+[[Some File]] -> [Some File](some-file.md)
+
+Editing
+[Some File](some-file.md)
+
+On disk (could be solved by migration)
+[[some-file]]
+[[Some File]]
+
+- docs/index.md -> Index
+- notes/index.md -> Index
+
+[[Index]]
+[[Index | notes/index.md]]
+
+[Index] docs/index.md
+[Index | notes/index.md]: notes/index.md
+
+[[Some File | path/to/some-file.md]]
+
+Do we apply any constraints:
+
+- `[[file-name-without-extension]]`
+- `[[file-name-with-extension.md]]`
+- `[[Title Cased File Name]]`
+
+Not supported by Markdown Notes:
+
+- `[[path/to/file-name.md]]` - Just use markdown links
+- `[[Target Note Title]]`
+
+Issues:
+
+- Name clashes in directories
+- Name clashes between extensions
+- Renaming
+  - Change filename/title needs to reflect everywhere
+- Orphaning
+
+- If we can't rely on in-memory process to rename things correctly while changes happen (e.g. file is renamed, moved, deleted, or titled) <ref id="1" />
+
+Solving this issue is necessarily heuristic. We could try to write smart solutions, plus a linter for orphans
+
+How others solve this:
+
+- Unique ids -- could support optionally as part of file name or front matter metadata. Should not be required.
+
+[//begin]: # "Autogenerated link references for markdown compatibility"
+[todo]: ../todo "Todo"
+[//end]: # "Autogenerated link references"