diff --git a/decentralizing-the-net-with-dotnet.md b/decentralizing-the-net-with-dotnet.md
new file mode 100644
index 0000000..a20631d
--- /dev/null
+++ b/decentralizing-the-net-with-dotnet.md
@@ -0,0 +1,25 @@
+# Decentralizing the Net with .NET
+
+## Description
+
+Building secure E2EE P2P systems has never been simpler, with .NET and SignalR – In this talk, we will walk through the process of building a P2P backplane for SignalR, and connect our application as nodes together dynamically, discussing tradeoffs and security considerations along the way.
+
+## Outline
+
+- Setting the Stage
+  - Briefly walk through the example chat application architecture and the client-server model.
+  - Review the data model and specific qualities that make it translatable to peer-to-peer implicitly.
+- Plan of Attack: SignalR Backplanes
+  - Introduce the concept of backplanes in SignalR, with the typical Redis example.
+  - Idea: Create a SignalR Backplane using a peer-to-peer gossip protocol
+  - Idea: Swap out user registry with cryptographic identities, discuss tradeoffs - how do we verify? Strategies: PKI, Web of Trust
+- Implementation: Backplane
+  - Creating the P2P HubLifetimeManager implementation
+  - Hooking it up and watching it go
+- Implementation: User Registry
+  - Cryptographic identities, how do they work?
+  - PKI/WoT hybrid implementation
+- Implementation: Securing the protocol
+  - Demonstration: Bad actors - message forgeries, message censorship, message reordering, break-ins
+  - Adding the Triple-Ratchet algorithm
+- Final notes/observations, close out
\ No newline at end of file
diff --git a/this-message-will-self-construct-in.md b/this-message-will-self-construct-in.md
new file mode 100644
index 0000000..8729ab7
--- /dev/null
+++ b/this-message-will-self-construct-in.md
@@ -0,0 +1,21 @@
+# This Message Will Self-Construct In...
+
+## Description
+
+Building an emergency plan is more than having a bug-out bag ready to go, it needs to include contingencies in the event you may not be there. Preparing for this by giving trusted individuals passwords or encryption keys may put them in danger too, so how can we solve this? Enter Timelock puzzles, and BouncyCastle.NET to make this tricky cryptographic process dead simple.
+
+## Outline
+
+- Setting the Stage
+  - Brief example demonstrating the problem: dangerous information, dangerous people who want it.
+  - Answer: What if there were a way you could make decryption only possible after a certain amount of time, giving you an opportunity to subvert the danger of knowledge?
+- Plan of Attack: Timelock Cryptography
+  - Simple demonstration of repeated squarings
+  - Explanation on how this maps into a simple symmetric (AES) cryptography setting.
+- Implementation: Basic encryption setup
+  - How to use BouncyCastle to create a key and encrypt a file.
+- Implementation: How to do the Timelock puzzle
+  - Augmenting our basic encryption setup to use timelock puzzles
+- Extra: Optional disclosure
+  - Augmenting our timelock setup to allow passing a key to a trusted individual so they can decrypt quickly amongst others who must wait.
+- Final notes/observations, close out.
\ No newline at end of file