diff --git a/meetings/2020-04-10.mdx b/meetings/2020-04-10.mdx
new file mode 100644
index 000000000..4d9fb5713
--- /dev/null
+++ b/meetings/2020-04-10.mdx
@@ -0,0 +1,25 @@
+---
+title: "2020-04-10"
+description: Tyler van der Hoeven explains how Stellar path payments route value through the decentralized exchange, demonstrating strict-send and strict-receive flows for wallets and cross-asset payments.
+authors: john
+tags: [tutorial]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+
+
+Tyler van der Hoeven kicked off the Engineering Talks series with a practical, developer-focused walkthrough of path payments and why they are one of Stellar’s most powerful primitives. He framed the core idea simply: traditional (“vanilla”) payments move assets, while path payments move value. By routing payments through the decentralized exchange and multiple order books in a single atomic operation, Stellar enables complex conversions without users or applications manually touching markets.
+
+Through live demos, Tyler showed how path payments can be used as market orders inside a wallet, as well as how they scale into more complex, enterprise-style flows. These examples illustrated how trustlines, order books, strict send/receive constraints, and atomic execution combine to make cross-asset payments reliable, composable, and developer-friendly, even when liquidity is fragmented.
+
+### Key Topics
+
+- How path payments differ from standard payments by converting assets across the DEX to deliver value, not just tokens.
+- Using path payments as market orders inside wallets, including self-payments to acquire new assets without visiting an exchange.
+- Sending one asset (e.g., USD) while the recipient receives another (e.g., BTC), with all conversions handled automatically.
+- Enterprise-style flows where market makers seed orderbooks (e.g., USD/EUR) and wallets route payments without holding intermediate assets.
+- The importance of atomic execution for price certainty and user protection within a single ledger close.
+- Liquidity considerations, failed paths, and how strict send/receive settings safeguard users.
+- Why market makers and better tooling are critical to scaling path payments and the Stellar DEX.
+- The broader implication of transacting in value rather than assets, enabling global payments across currencies as long as markets exist.
diff --git a/meetings/2020-04-16.mdx b/meetings/2020-04-16.mdx
new file mode 100644
index 000000000..157c00172
--- /dev/null
+++ b/meetings/2020-04-16.mdx
@@ -0,0 +1,30 @@
+---
+title: "2020-04-16"
+description: This roundtable develops a send/receive SEP for anchor-to-anchor transfers, covering interoperability with SEP-6, SEP-10, and SEP-24, KYC responsibilities, transaction lifecycles, and regulatory constraints.
+authors: john
+tags:
+ - community
+ - SEP-6
+ - SEP-10
+ - SEP-12
+ - SEP-16
+ - SEP-24
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+
+
+Lisa Nestor moderated the first virtual roundtable focused on defining a new “send/receive” SEP that standardizes how anchors transfer funds to each other on behalf of end users. She opened by explaining how Stellar Ecosystem Proposals evolve from community discussion into GitHub drafts, and why this effort builds on existing standards like SEP-6, SEP-10, and SEP-24 rather than reinventing anchor interoperability from scratch.
+
+The discussion quickly moved from theory into real-world remittance workflows. Participants from Tempo, SatoshiPay, Cowrie, and SDF examined how KYC data should flow, which responsibilities belong inside or outside the SEP, and how edge cases like failed bank deposits or cash pickup name mismatches should be handled. The group emphasized keeping the protocol narrow and composable, while leaving space for bilateral agreements, compliance-as-a-service providers, and future extensions.
+
+### Key Topics
+
+- Scope of a send/receive SEP: why anchor-to-anchor payments need a dedicated endpoint, and which responsibilities (onboarding, business agreements) intentionally live outside the protocol.
+- Relationship to existing SEPs: reusing SEP-6/24 request shapes, SEP-10 for anchor authentication, and debating whether SEP-12 adds value for this flow.
+- KYC handling: when sending anchors can reuse stored customer data, when receiving anchors dictate requirements, and how third-party compliance providers might integrate.
+- Transaction lifecycle gaps: need for clearer intermediate statuses (pending, info-needed), update flows for fixable errors, and better handling of cash rename scenarios.
+- Refunds and failures: why full refunds are costly, and how update-in-place mechanisms could improve user experience for downstream bank rejections.
+- Jurisdictional complexity: differing regulatory requirements across regions, and why high-touch compliance cases cannot always be fully codified.
+- Ecosystem trust model: anchors are independent, regulated businesses, with reputation and bilateral trust—not SDF—governing who participates.
diff --git a/meetings/2020-04-24.mdx b/meetings/2020-04-24.mdx
new file mode 100644
index 000000000..a709028e9
--- /dev/null
+++ b/meetings/2020-04-24.mdx
@@ -0,0 +1,31 @@
+---
+title: "2020-04-24"
+description: This engineering talk examines usability barriers in Stellar applications—including key management, trustlines, anchors, federation, recovery, and the DEX—and how developers can abstract them for users.
+authors: john
+tags:
+ - tutorial
+ - SEP-5
+ - SEP-6
+ - SEP-26
+ - SEP-30
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+
+
+Kolten led this Engineering Talks session with a focus on usability rather than protocol mechanics, framing the discussion around how developers can make Stellar applications approachable for people who are new to blockchain. He described the main obstacles users face—key management, on/off ramps, trustlines, anchors, and the DEX—and argued that most of this “hard stuff” should be abstracted away so users can focus on clear, understandable actions.
+
+The talk emphasized that Stellar Ecosystem Proposals (SEPs) are the primary tool for achieving this abstraction. By treating SEPs as an application-layer standard rather than core protocol changes, teams can build interoperable products that evolve over time while delivering simpler user experiences. Kolten illustrated how narrowing scope, simplifying interfaces, and educating users up front can dramatically improve adoption without sacrificing the power of the network.
+
+### Key Topics
+
+- Why usability is a major barrier to adoption, especially for developers and users who are new to blockchain.
+- Treating SEPs as the glue between apps and the network, enabling interoperability without exposing protocol complexity.
+- Federation (SEP-5) and mnemonic phrases as ways to reduce user anxiety around public and private keys.
+- Account recovery via SEP-30 as a critical usability improvement for lost keys without handing control to third parties.
+- Anchor standards (SEP-6, SEP-24, SEP-26) that let users move between the real world and Stellar without leaving their wallet.
+- The progression from raw tools (Stellar Laboratory) to wallets, and finally to single-purpose apps with focused use cases.
+- Examples of simplifying experiences through vertical apps like SatoshiPay, DStoq, and Vega.
+- The importance of onboarding and education: showing value before sign-up, clear messaging, and localized translations.
+- Encouraging developers to both follow existing standards and participate in creating new ones as the ecosystem evolves.
diff --git a/meetings/2020-04-30.mdx b/meetings/2020-04-30.mdx
new file mode 100644
index 000000000..e37209599
--- /dev/null
+++ b/meetings/2020-04-30.mdx
@@ -0,0 +1,36 @@
+---
+title: "2020-04-30"
+description: This roundtable advances a direct-send SEP for anchor-to-anchor fiat transfers, focusing on multilateral KYC, regulatory data sharing, and noncustodial wallet initiation through SEP-10.
+authors: john
+tags:
+ - community
+ - SEP-3
+ - SEP-6
+ - SEP-9
+ - SEP-10
+ - SEP-24
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+
+
+Lisa Nestor reconvened the Stellar ecosystem for a continued public roundtable on creating a “direct send” (or send/receive) SEP, building on discussions from two weeks earlier. She framed the session around a key gap in today’s standards: while SEP-6 and SEP-24 handle deposit and withdrawal flows well, many real-world remittance and B2B payments never touch a wallet at all. In these cases, users simply want funds to move from one bank account or cash point to another, and Stellar lacked a clear, standardized way to support that fiat-to-fiat flow between anchors.
+
+The conversation focused on two major extensions needed to make this model viable at scale. First was multilateral KYC, where anchors could securely share compliance results instead of duplicating checks in every jurisdiction. Second was enabling noncustodial wallets to initiate direct send transactions without becoming anchors themselves. Representatives from Tempo, Cowrie, SatoshiPay, Inclusive, and SDF explored how these pieces could fit together while preserving regulatory responsibility, user consent, and anchor control.
+
+### Key Topics
+
+- Purpose of the direct send SEP as a complement to SEP-6 and SEP-24, targeting anchor-to-anchor fiat payments where recipients never interact with digital assets.
+- How SEPs evolve as open, community-driven standards to formalize new Stellar use cases as they emerge.
+- Inclusive’s multilateral KYC (“EDD Connect”) concept for sharing KYC and KYB results across anchors to reduce cost, friction, and regional specialization.
+- Regulatory considerations across strict jurisdictions such as the EU, Japan, and Switzerland, and the need for authorized compliance providers.
+- Handling edge cases where receiving anchors require additional data beyond what originating anchors collected.
+- Consent, privacy, and trust models for sharing KYC data, including which parties can access data and under what conditions.
+- Enabling noncustodial wallets to initiate direct sends through SEP-10 authentication, key whitelisting, and anchor-controlled endpoints.
+- Separation of concerns between KYC processes and payment execution to allow pre-registration and smoother user experiences.
+- Use of memos and references so wallet-initiated payments can carry user-specified identifiers through bank transfers.
+
+### Resources
+
+- [GitHub discussion thread (pre-read)](https://github.com/stellar/stellar-protocol/pull/592)
diff --git a/meetings/2020-05-08.mdx b/meetings/2020-05-08.mdx
new file mode 100644
index 000000000..aedbb6879
--- /dev/null
+++ b/meetings/2020-05-08.mdx
@@ -0,0 +1,28 @@
+---
+title: "2020-05-08"
+description: This overview highlights how SCP works end-to-end—quorum sets, blocking sets, federated voting, and how nomination + ballot narrow the network to one ledger value.
+authors: john
+tags: [tutorial]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+
+
+Marta Lokhava walks through the Stellar Consensus Protocol (SCP) in plain language, aiming to give newcomers a mental model before they dive into formal specs. She starts by defining quorum sets (who you trust), thresholds (how many of them must agree), quorum slices (subsets that meet the threshold), and blocking sets (the smallest sets that can prevent you from moving forward).
+
+With those primitives, she introduces **statements** as SCP’s basic unit of agreement (e.g., “I propose transaction set X for ledger N” or “I’m ready to apply transaction set X”). She then explains **federated voting**—how nodes progress from _vote_ → _accept_ → _confirm_ on a statement—and uses a step-by-step demo to show how blocking sets can force nodes that initially voted differently to converge on the same outcome.
+
+Finally, she frames SCP as a **funnel**: the **nomination protocol** gathers and confirms a candidate set of values (transaction sets), while the **ballot protocol** _prepares_ and then _commits_ a single value. Nomination continues in the background while ballot runs, letting the system start optimistically but still converge safely if the network needs to adjust.
+
+### Key Topics
+
+- Clear definitions of quorum sets, thresholds, quorum slices, and blocking sets—and how each node’s configuration shapes safety and liveness.
+- Federated voting mechanics (vote/accept/confirm) and why “accepting what your blocking set accepted” prevents deadlock.
+- SCP’s two-phase structure: nomination to build a candidate set, then ballot to prepare/commit one value.
+- Why ballot can start as soon as a node confirms its first nomination, even while nomination continues (optimistic progress with safe fallback).
+- Practical guidance on thresholds: aiming for ~67% across organizations, while internal org nodes may use lower thresholds; recommendation to use Stellar Core’s automatic quorum generation.
+
+### Resources
+
+- Blog Post: [Intuitive Stellar Consensus Protocol](https://stellar.org/blog/developers/intuitive-stellar-consensus-protocol)
diff --git a/meetings/2020-05-22.mdx b/meetings/2020-05-22.mdx
new file mode 100644
index 000000000..60219d92f
--- /dev/null
+++ b/meetings/2020-05-22.mdx
@@ -0,0 +1,29 @@
+---
+title: "2020-05-22"
+description: This overview highlights Kelp GUI v1—how it simplifies launching and managing market-making bots on the SDEX, from bot creation and price feeds to advanced safeguards and clean shutdown.
+authors: john
+tags: [tutorial]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+
+
+Nikhil Saraf introduces **Kelp GUI v1**, the desktop interface for Kelp—an open-source trading bot originally built for the Stellar decentralized exchange (and later extended to many centralized exchanges via the CLI). The focus of the talk is how the GUI lowers the barrier for non-technical liquidity providers by turning configuration-heavy market-making into a guided workflow: generate a starter bot, or create a custom one by selecting assets, setting spreads and levels, and wiring up price feeds.
+
+He explains how pricing in the **buy/sell strategy** works by composing a numerator and denominator feed (for example, valuing XLM via an exchange feed while treating a “coupon” asset as a fixed $1). The GUI displays the derived mid price and lets users define multiple “levels” around that mid, which translate into ladders of bids and asks. A live demo shows creating two bots on testnet, connecting a fiat price feed (Currencylayer), and using “advanced” price adjustments (offsets) to intentionally misprice one bot so it trades through the other—illustrating how bots place, cross, and refresh offers over time.
+
+Nikhil also emphasizes **operational hygiene**: if you quit without stopping a bot, its offers can remain on the orderbook, potentially filling unexpectedly. Stopping a bot should both halt the process and cancel outstanding offers so the market doesn’t retain stray bids/asks after you’re done.
+
+### Key Topics
+
+- What Kelp is (CLI + strategies in Go) and why the GUI matters for first-time market makers on the SDEX.
+- Bot setup workflow: secret key handling, asset/issuer selection, and the “starter bot” vs custom configuration paths.
+- Price feeds and derived pricing: composing numerator/denominator sources, sanity-checking quotes, and understanding how the bot refreshes prices on an interval.
+- Market-making controls: spreads, multi-level ladders, order sizing, and how thin/no markets affect displayed spread.
+- Advanced safeguards and tuning: correction knobs (offset % / offset), multipliers, and preventing bad quoting when price data drifts.
+- Safe shutdown: stopping bots to cancel offers so you don’t leave live orders behind.
+
+### Resources
+
+- [GitHub PR / Discussion referenced](https://github.com/stellar/stellar-protocol/pull/592)
diff --git a/meetings/2020-06-04.mdx b/meetings/2020-06-04.mdx
new file mode 100644
index 000000000..cf7b84ce4
--- /dev/null
+++ b/meetings/2020-06-04.mdx
@@ -0,0 +1,52 @@
+---
+title: "2020-06-04"
+description: The first livestreamed Open Protocol Discussion reviews proposed Core Advancement Proposals for Protocol 14, focusing on claimable balances, sponsored reserves, and process improvements for evaluating and rolling out protocol changes.
+authors: john
+tags:
+ - legacy
+ - CAP-18
+ - CAP-23
+ - CAP-31
+ - CAP-33
+ - SEP-8
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+
+
+Justin Rice opened the first livestreamed Open Protocol Discussion with an update on Protocol 13, explaining why the validator vote was delayed by two weeks to give exchanges additional time to complete testing. That operational context set the tone for the rest of the call, which focused on how protocol changes are evaluated, coordinated, and safely rolled out across a diverse ecosystem.
+
+The discussion then turned to proposals targeting Protocol 14, especially claimable balances and sponsored reserves. Participants dug into how these changes affect payment flows, reserve economics, and wallet and service design. As the conversation evolved, it widened into a candid examination of process gaps—how working groups should be structured, how downstream impacts on Horizon and SDKs can be surfaced earlier, and how upgrade communications can better reach exchanges and operators who do not closely follow core developer channels.
+
+### Key Topics
+
+- **Protocol 13 readiness and coordination**
+ - Validator vote delayed to late June to avoid breaking exchanges.
+ - Need for clearer runbooks, readiness checks, and direct outreach to large operators.
+- **CAP-23: Claimable Balances (Two-part Payments)**
+ - Separating sending from receiving so payments can be delivered to unprepared accounts.
+ - Decision that unclaimable funds route to the fee pool rather than back to the sender.
+ - General agreement that the proposal is ready for Final Comment Period.
+- **CAP-33: Sponsored Reserves**
+ - Allowing one party (issuers, wallets, services) to cover reserves for user accounts.
+ - Handshake workflows between sponsor and sponsored account, especially during `create_account`.
+ - Sequence-number lockups as a scaling concern and recognition that this exposes a broader, long-standing protocol limitation.
+- **Delegated authorization and future primitives**
+ - Discussion of longer-term ideas (operation-level authorization, pre-signed operations) to reduce reliance on sequence numbers.
+ - Consensus that CAP-33 should proceed while the broader problem is addressed separately.
+- **Issue 622: Close time application**
+ - Tradeoffs in how transaction time bounds are evaluated during consensus.
+ - Concerns about delayed ledgers, expired transactions, and brittle smart contract assumptions.
+ - Agreement to clarify requirements before committing to a concrete solution.
+- **Issue 624: Improving the CAP process**
+ - Formalizing working groups and clarifying ownership and responsibilities.
+ - Capturing downstream impacts on Horizon, SDKs, exchanges, and hardware wallets earlier.
+ - Improving upgrade communication so ecosystem participants know when and how to prepare.
+
+### Resources
+
+- [CAP-23: Two-part Payments (Claimable Balances)](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0023.md)
+- [CAP-33: New Sponsored Reserves](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0033.md)
+- [Issue 622: Request to change close time application](https://github.com/stellar/stellar-protocol/issues/622)
+- [Issue 624: Update CAP process](https://github.com/stellar/stellar-protocol/issues/624)
diff --git a/meetings/2020-06-05.mdx b/meetings/2020-06-05.mdx
new file mode 100644
index 000000000..63d85b426
--- /dev/null
+++ b/meetings/2020-06-05.mdx
@@ -0,0 +1,30 @@
+---
+title: "2020-06-05"
+description: An overview of Project Slingshot and zkVM, covering confidential transactions, programmable predicates, and a modular zero-knowledge architecture designed to support scalable, multi-asset smart contracts.
+authors: john
+tags: [spotlight]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+
+
+This talk introduces Project Slingshot, an experimental zero-knowledge blockchain architecture centered around zkVM—a programmable transaction format designed to combine confidentiality, composability, and scalability. Rather than starting from protocol mechanics, the session frames the core problem: how to build a public, auditable ledger that still supports private balances, private transfers, and customizable financial logic without constantly upgrading the network.
+
+At the heart of the design is zkVM’s execution model. Transactions are treated as small, self-contained programs that run inside an ephemeral virtual machine. As the VM executes, it builds a constraint system and verifies it using zero-knowledge proofs (Bulletproofs), ensuring assets are conserved and rules are followed without revealing sensitive data. All state changes are expressed as inputs and outputs, allowing transactions to be validated independently and in parallel, while higher-level features like accounts, order books, and payment channels live outside consensus-critical code.
+
+### Key Topics
+
+- Motivation for Slingshot and zkVM: encrypted assets by default, public verifiability, and extensibility without frequent network-wide upgrades.
+- Modular architecture: cryptographic libraries, VM, networking stack, and blockchain state machine designed to be deployed as a sidechain, private ledger, or embedded node.
+- zkVM execution model: transactions as “PDF-like” programs, stack-based execution, constraint-system generation, and zero-knowledge verification.
+- Contracts and predicates: locking assets behind public keys or programmable conditions, including taproot-style branching.
+- Confidential value flow: linear asset types, mixing (cloak), and protection against duplication or unintended asset creation.
+- Example applications: confidential payments, programmable order books, collateralized loans, and two-party payment channels.
+- Design comparisons: contrasts with Stellar’s built-in operations, Ethereum’s global state machine, and Zcash’s fixed circuits.
+- Roadmap and integration questions: running zkVM alongside Stellar as a sidechain, bridging Stellar assets, and packaging networking and tooling for broader experimentation.
+
+### Resources
+
+- [Demo site](https://idioms-demo.stellar.org)
+- [Project Slingshot GitHub repo](https://github.com/stellar/slingshot)
diff --git a/meetings/2020-06-26.mdx b/meetings/2020-06-26.mdx
new file mode 100644
index 000000000..caaca8952
--- /dev/null
+++ b/meetings/2020-06-26.mdx
@@ -0,0 +1,29 @@
+---
+title: "2020-06-26"
+description: An Engineering Talk on SEP-30, explaining how recovery signers enable noncustodial wallets to offer consumer-grade onboarding and account recovery without seed phrases or centralized key custody.
+authors: john
+tags: [tutorial, SEP-10, SEP-30]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+
+
+Leigh McCulloch presents SEP-30 (Recovery Signer) as a response to one of the biggest barriers to mainstream blockchain adoption: key management. He begins by grounding the audience in Stellar’s account model—master keys, additional signers, thresholds, and weights—and explains why most wallets still rely on fragile patterns like written recovery phrases or encrypted server backups that either overload users or require excessive trust in infrastructure.
+
+SEP-30 reframes the problem by shifting focus from backing up a single master key to preserving control of the account itself. Instead of asking users to safeguard secret material forever, wallets manage rotating device keys while registering recovery identities (such as phone numbers or email addresses) with independent recovery services. These services can co-sign transactions during recovery but never gain unilateral control of funds, preserving self-custody while enabling familiar, consumer-style recovery flows.
+
+The talk walks through a concrete example using a fictional user, Alice. Her wallet generates a master key, derives a device key, removes the master key entirely, and registers two independent recovery signers with limited weights. If Alice loses her phone, she can authenticate to both recovery services, add a new device key, revoke the lost one, and regain full control—without creating a new Stellar account or exposing a seed phrase. All of this can happen behind the scenes, delivering an experience comparable to modern consumer apps.
+
+### Key Topics
+
+- Stellar’s key model: master keys, additional signers, thresholds, and why most wallets still rely on a single key.
+- Common wallet approaches today: paper recovery phrases, encrypted server backups, and their usability and security tradeoffs.
+- SEP-30 registration flow: wallet authentication via SEP-10, identity registration, and adding recovery signers with limited weights.
+- Recovery flow: authenticating via phone or email, co-signing transactions, revoking lost device keys, and preserving the same account address.
+- Benefits of the model: no single recovery service with full control, optional recovery phrases, multi-device support, and rapid revocation of lost devices.
+- Why UX matters: aligning noncustodial wallets with user expectations from mainstream consumer applications to drive adoption.
+
+### Resources
+
+- [SEP-30: Account Recovery Signer](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0030.md) ([Stellar-dev mailing list discussion](https://groups.google.com/g/stellar-dev/c/SFr2dHBZlsY))
diff --git a/meetings/2020-07-09.mdx b/meetings/2020-07-09.mdx
new file mode 100644
index 000000000..3f2d92ff2
--- /dev/null
+++ b/meetings/2020-07-09.mdx
@@ -0,0 +1,45 @@
+---
+title: "2020-07-09"
+description: The second Open Protocol Discussion broadcast reviews readiness for Protocol 14, focusing on claimable balances, sponsored reserves, and downstream impacts across Horizon and SDKs.
+authors: john
+tags:
+ - legacy
+ - CAP-15
+ - CAP-19
+ - CAP-23
+ - CAP-33
+ - CAP-34
+ - SEP-30
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+
+
+Justin Rice opened the second livestreamed Open Protocol Discussion with a status check on preparations for Protocol 14. The session followed up on earlier meetings and focused on closing out open questions around the two largest proposed changes: claimable balances (CAP-23) and sponsored reserves (CAP-33). Participants emphasized that both proposals were in final comment period and close to acceptance, with remaining concerns centered on edge cases, implementation clarity, and ecosystem readiness.
+
+Much of the discussion explored how these protocol changes interact with real-world usage. For CAP-23, the group debated the structure and limits of claim predicate trees, balancing expressiveness against safety, XDR recursion limits, and ease of implementation in SDKs. For CAP-33, attention shifted to downstream effects—particularly compatibility with SEP-30 recovery signers, naming clarity for sponsorship operations, and whether certain invalid sponsorship “sandwiches” should fail earlier during validation rather than at apply time. The call closed with a broader conversation on close-time semantics (later CAP-34) and how subtle timing and sequence-number behaviors can affect smart-contract-style workflows.
+
+### Key Topics
+
+- CAP-23 claimable balances
+ - Predicate tree depth limits, recursion safety, and XDR implementation concerns.
+ - Tradeoffs between disjunctive-normal-form predicates and bounded tree structures.
+ - Agreement to continue design discussion on the mailing list before finalizing.
+- CAP-33 sponsored reserves
+ - Compatibility issues with SEP-30 recovery signers and short-term mitigations at the SEP level.
+ - Renaming operations to clarify the sponsorship “sandwich” flow (`begin`, `end`, `revoke`).
+ - Consideration of whether invalid sponsorship patterns should be rejected during validation.
+- Protocol 14 readiness
+ - Coordination with Horizon and SDK teams, including open GitHub issues for required changes.
+ - Working-group outcomes and the need for clearer ecosystem-facing documentation and FAQs.
+- Close-time semantics (Issue 622 / CAP-34 draft)
+ - Edge cases where transactions can consume sequence numbers despite time-bound invalidity.
+ - Risks for advanced workflows such as payment channels and cross-chain swaps.
+ - Agreement to continue investigation on the dev mailing list before committing to changes.
+
+### Resources
+
+- [CAP-23: Two-part Payments (Claimable Balances)](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0023.md)
+- [CAP-33: New Sponsored Reserves](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0033.md)
+- [Issue 622: Request to change close time application](https://github.com/stellar/stellar-protocol/issues/622)
diff --git a/meetings/2020-07-10.mdx b/meetings/2020-07-10.mdx
new file mode 100644
index 000000000..4e2761d00
--- /dev/null
+++ b/meetings/2020-07-10.mdx
@@ -0,0 +1,51 @@
+---
+title: "2020-07-10"
+description: A community proposal exploring decentralized, Turing-complete transaction creation on Stellar through programmable signing servers, enabling trust-minimized smart contract workflows without altering core consensus.
+authors: john
+tags: [tutorial]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+
+
+This community session introduces a draft Stellar Ecosystem Proposal (SEP) aimed at bringing Turing-complete smart contract capabilities to Stellar without embedding a virtual machine into the protocol itself. Rather than executing arbitrary code on-chain, the proposal focuses on decentralized transaction creation using external but standardized services called Turing Signing Servers. These servers generate partially signed transactions according to programmable contract logic, leaving final execution to Stellar’s existing consensus layer.
+
+The core motivation is functional feature parity with Ethereum in the financial domain, while preserving Stellar’s strengths: predictable execution, asset-first design, and strong safety guarantees. By separating transaction creation from execution, the model allows complex business logic, trust minimization, and programmability without exposing accounts to arbitrary execution risk. Contracts define what may happen, while users retain final control over whether transactions are submitted.
+
+### Key Topics
+
+- Motivation and framing:
+ - Distinction between functional feature parity and protocol-level feature parity with Ethereum.
+ - Emphasis on finance-native use cases where Stellar already excels.
+- Transaction creation vs execution:
+ - Stellar already provides decentralized execution but relies on off-chain transaction creation.
+ - The proposal decentralizes creation using programmable, deterministic contract logic.
+- Turing Signing Servers:
+ - External services that host contracts and generate partially signed transactions.
+ - Incentivized via fees, disinterested in outcomes, and designed to be run by many independent operators.
+- Contract architecture:
+ - Three roles: users, contract creators, and Turing Signing Servers.
+ - Contracts are uploaded once and replicated across multiple servers for redundancy and trust minimization.
+- Multi-signature and thresholds:
+ - Contracts rely on Stellar’s native multisig and thresholds to prevent unilateral control.
+ - No single server can act alone; collusion is mitigated by requiring matching signatures.
+- Safety model:
+ - Transactions generated by contracts are never executed automatically.
+ - Turing Signing Servers only create and partially sign transactions according to predefined logic.
+ - Users retain final authority to inspect, sign, or reject any transaction before submission.
+- Demonstrated examples:
+ - Vending machine swaps (asset-for-asset exchanges).
+ - Oracle-style contracts using external APIs (e.g., weather-based payouts).
+ - Account-level filters limiting payment size.
+ - Wager pools and donation pools with automated payout logic.
+ - Recurring revenue and subscription-style payments without pre-signed transactions.
+- Ecosystem implications:
+ - Reduced trust in centralized service operators.
+ - Potential applications in DeFi, anchors, liquidity provision, and subscriptions.
+ - Compatibility with existing Stellar tooling and protocol guarantees.
+
+### Resources
+
+- [Stellar Ecosystem Proposals](https://github.com/stellar/stellar-protocol)
+- [SEP-30: Account Recovery](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0030.md)
diff --git a/meetings/2020-07-15.mdx b/meetings/2020-07-15.mdx
new file mode 100644
index 000000000..27bbda33f
--- /dev/null
+++ b/meetings/2020-07-15.mdx
@@ -0,0 +1,54 @@
+---
+title: "2020-07-15"
+description: A quarterly review covering ecosystem growth, anchor expansion, protocol upgrades, and developer-focused improvements across the Stellar network.
+authors: john
+tags:
+ - community
+ - CAP-15
+ - CAP-18
+ - CAP-23
+ - CAP-27
+ - CAP-28
+ - CAP-30
+ - CAP-33
+ - SEP-30
+ - SEP-31
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+
+
+This quarterly review walks through progress across ecosystem growth, product development, and network operations, alongside updates on public engagement and regulatory participation. Leaders outline how recent protocol upgrades and ecosystem proposals are shaping a more usable, scalable, and compliant network for real-world financial use cases.
+
+The session also highlights how anchors, wallets, and application-layer tooling fit together: improving user experience, reducing operational friction for businesses, and preparing the network for higher-volume, regulated activity without compromising decentralization.
+
+### Key Topics
+
+- Samsung Blockchain Keystore integration enabling secure private key storage on supported Galaxy devices and opening a new distribution channel for Stellar-based applications.
+- Anchor ecosystem growth focused on opening real payment corridors, with new and expanding anchors across the U.S., Africa, and Latin America.
+- Vibrant wallet beta and SEP-30 account recovery as a path toward mainstream-friendly key management without third-party custody.
+- Enterprise Fund investments supporting ecosystem companies, including cross-border payments and next-generation financial platforms.
+- Network growth metrics showing steady account counts, rising payments, increased DEX volume, and stable validator participation.
+- Protocol 13 upgrades:
+ - Fee-bump transactions allowing applications to cover user fees and validators to respond to changing network conditions.
+ - Fine-grained asset authorization enabling compliant issuance without disrupting markets.
+ - Multiplexed accounts simplifying exchange and custodial account management.
+- Upcoming Protocol 14 features:
+ - Claimable balances for payments to unprepared recipients.
+ - Sponsored reserves allowing applications to cover account minimums for users.
+- SEP-31 anchor interoperability to support end-to-end fiat transfers and travel-rule–compliant information exchange.
+- Expanded policy and public engagement through global forums, virtual events, and ongoing regulator education.
+- Meridian conference announced as a virtual, free event focused on global connections and real-world use cases.
+
+### Resources
+
+- [CAP-15: Fee-bump transactions](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0015.md)
+- [CAP-18: Fine-Grained Control of Authorization](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0018.md)
+- [CAP-23: Two-Part Payments with `ClaimableBalanceEntry`](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0023.md)
+- [CAP-27: First-class multiplexed accounts](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0027.md)
+- [CAP-28: Clear pre-auth transaction signer on failed transactions](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0028.md)
+- [CAP-30: Remove `NO_ISSUER` Operation Results](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0030.md)
+- [CAP-33: Sponsored reserves](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0033.md)
+- [SEP-30: Account recovery](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0030.md)
+- [SEP-31: Anchor send/receive interoperability](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0031.md)
diff --git a/meetings/2020-07-24.mdx b/meetings/2020-07-24.mdx
new file mode 100644
index 000000000..9666013b9
--- /dev/null
+++ b/meetings/2020-07-24.mdx
@@ -0,0 +1,33 @@
+---
+title: "2020-07-24"
+description: A hands-on engineering talk showing how Polaris (a reusable Django app) accelerates building a SEP-24 anchor by providing standard endpoints, UI flows, and integration hooks for KYC and banking rails.
+authors: john
+tags: [tutorial, SEP-1, SEP-24, SEP-31]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+
+
+Interested in becoming a Stellar anchor but aren't sure where to start? This talk provides a step-by-step walkthrough of setting up Polaris, configuring a Django project, and implementing the integration points that let you connect your own KYC requirements and off-chain banking rails. The demo focuses on getting a working SEP-24 deposit/withdraw flow quickly, then explains where anchors typically customize behavior for production deployments.
+
+### Key Topics
+
+- Polaris as a plug-and-play Django app that implements the “standard” parts of SEP-24 while exposing integration hooks for anchor-specific behavior.
+- SEP-24 flow from a user’s perspective (interactive deposit/withdraw pages) and how wallets launch the anchor UI.
+- Integration points Polaris cannot automate: banking/payment rails, KYC/user data collection, UI customization, and transaction state handling.
+- Setup walkthrough: creating a Django project, installing `django-polaris`, enabling required apps/middleware, and configuring static assets for the built-in UI.
+- Implementing SEP-1 via a TOML file and how anchors populate organization + asset metadata for clients.
+- Core Polaris background jobs (e.g., polling pending deposits, watching transactions) and why anchors must run more than just the web server in production.
+- Deposit/withdraw lifecycle: how pending deposits are detected off-chain, then settled on-chain; how withdrawals reverse the flow by paying users off-chain after on-chain receipt.
+- Development workflow tips: local-mode considerations, using Docker/Docker Compose to run the web server plus worker processes together.
+- SEP-31 support direction: how Polaris can help receiving anchors interoperate for anchor-to-anchor transfers (remittance-style flows), reducing wallet/user complexity.
+- Tradeoffs and ecosystem demand: why Polaris is Django-based today, and what would need to change to justify a Node.js equivalent.
+
+### Resources
+
+- Documentation: [django-polaris.readthedocs.io/en/stable/](https://django-polaris.readthedocs.io/en/stable)
+- Code: [github.com/stellar/django-polaris](https://github.com/stellar/django-polaris)
+- SEP-1: [Stellar TOML](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0001.md)
+- SEP-24: [Interactive Deposit & Withdrawal](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0024.md)
+- SEP-31: [Cross-border payments / anchor interoperability](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0031.md)
diff --git a/meetings/2020-08-14.mdx b/meetings/2020-08-14.mdx
new file mode 100644
index 000000000..ad5c12809
--- /dev/null
+++ b/meetings/2020-08-14.mdx
@@ -0,0 +1,34 @@
+---
+title: "2020-08-14"
+description: An overview of how the Vibrant wallet uses SEP-24, anchor services, and JavaScript SDKs to connect real-world bank accounts to the Stellar network.
+authors: john
+tags: [community, SEP-24]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+
+
+This session explains how Vibrant, a Stellar-based savings wallet, enables users to deposit and withdraw real-world currencies through anchors using SEP-24. The talk focuses on user experience first, showing how non-technical users can move funds between bank accounts and the Stellar network without needing to understand blockchain mechanics.
+
+From a technical perspective, the presentation walks through Vibrant’s React Native architecture and its use of Stellar’s JavaScript Wallet SDK. Morley Zhi details how the app coordinates authentication, deposit initiation, transaction tracking, and notifications while relying on anchors to handle KYC, banking rails, and compliance-specific workflows.
+
+### Key Topics
+
+- Vibrant’s mission to protect users from currency instability by providing simple access to tokenized fiat on Stellar.
+- The role of anchors in bridging cash, bank accounts, and credit cards into on-chain assets.
+- SEP-24 deposit flow from the user’s perspective, including interactive anchor-hosted webviews.
+- Use of the JavaScript Wallet SDK’s deposit and withdrawal providers to simplify SEP-24 integration.
+- SEP-10 authentication handling via the SDK’s key manager and challenge–response flow.
+- Tracking transaction state changes using deposit IDs and long-lived “watch transactions” calls.
+- Handling interrupted sessions, cancellations, and stale deposits to keep the UX clean.
+- Push notification architecture driven by backend monitoring of on-chain payments.
+- Withdrawal flow differences, where users initiate transfers by sending Stellar payments to anchors.
+- Practical limitations and future plans around supported currencies, countries, and SDK language support.
+
+### Resources
+
+- [Vibrant website](https://vibrant.cash)
+- [SEP-24: Interactive Deposit & Withdrawal](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0024.md)
+- [SEP-10: Web Authentication](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0010.md)
+- [Stellar JavaScript Wallet SDK](https://github.com/stellar/js-stellar-wallets)
diff --git a/meetings/2020-08-28.mdx b/meetings/2020-08-28.mdx
new file mode 100644
index 000000000..fe3d2e26d
--- /dev/null
+++ b/meetings/2020-08-28.mdx
@@ -0,0 +1,27 @@
+---
+title: "2020-08-28"
+description: An overview of SCF 2.0, including Lab and Seed funds, quadratic voting, a panel-of-judges finalist process, and updated submission workflows.
+authors: john
+tags: [community]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+
+
+This session introduces the redesigned Stellar Community Fund and explains why the program evolved after multiple rounds of community feedback. The update separates funding into two tracks so that smaller experimental efforts and larger, long-lived projects can each receive support that better matches their scope and needs.
+
+The discussion also covers changes to how projects are selected and funded. A panel of experienced community members reviews submissions and advances finalists, after which the wider community allocates funding using quadratic voting. This structure is intended to better reflect voter sentiment, reduce fatigue, and improve fairness as participation scales.
+
+### Key Topics
+
+- The mandate behind the Stellar Community Fund and its evolution from earlier grant programs.
+- Differences between the Lab Fund and Seed Fund, including cadence and funding size.
+- Why a panel-of-judges stage helps improve finalist quality and scale community voting.
+- How quadratic voting captures intensity of preference rather than simple up-or-down votes.
+- The use of flagging to help surface potential anomalies for reviewer attention.
+- An overview of the new submission and voting experience.
+
+### Resources
+
+- [Learn more about the SCF](https://communityfund.stellar.org) and how you can submit your project built on Stellar.
diff --git a/meetings/2020-09-11.mdx b/meetings/2020-09-11.mdx
new file mode 100644
index 000000000..37cbcb4a1
--- /dev/null
+++ b/meetings/2020-09-11.mdx
@@ -0,0 +1,31 @@
+---
+title: "2020-09-11"
+description: Debnil Sur walks through an SDF analytics stack for exploring the network at scale, covering Horizon/Core data limitations, a BigQuery-based pipeline, and practical SQL patterns for market and account analysis.
+authors: john
+tags: [tutorial]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+
+
+Do you want to analyze historical trends on the network in seconds? In this talk, software engineer Debnil Sur explains how SDF designed a large-scale analytics pipeline using off-the-shelf tools, and shares examples of the kinds of questions you can answer with basic SQL.
+
+The session starts by outlining why Horizon and Core databases (optimized for transactional workloads and API access) are a poor fit for heavy historical analytics at scale, then walks through the design goals for a warehouse-backed approach: organization-wide access, daily refreshes, easy integration with existing infrastructure, and approachable metrics/visualization for non-technical stakeholders.
+
+Debnil then covers an initial implementation that exports data from Postgres, stages files in cloud storage, and loads tables into a warehouse to enable much faster queries. The talk also surveys visualization options and why Metabase was selected for an early, internal drag-and-drop + SQL experience. It closes with v1 limitations and a roadmap toward higher update frequency, better observability, and more public-facing analytics.
+
+### Key Topics
+
+- Why Horizon/Core schemas are great for transactions but slow for large historical analytics.
+- Design goals for an internal + community-friendly analytics system.
+- A first-pass warehouse pipeline: exports, staging, loading, and fast SQL queries.
+- Metrics workflows and why spreadsheets and Python fit the reporting layer well.
+- Visualization tradeoffs and why Metabase works for an initial deployment.
+- Roadmap topics: real-time-ish updates, task orchestration, observability, and public dashboards.
+
+### Resources
+
+- [Voyager](https://stellar.expert/explorer)
+- [Horizon API](/docs/data/apis/horizon/)
+- [Stellar Core](https://github.com/stellar/stellar-core)
diff --git a/meetings/2020-10-09.mdx b/meetings/2020-10-09.mdx
new file mode 100644
index 000000000..ff78229a9
--- /dev/null
+++ b/meetings/2020-10-09.mdx
@@ -0,0 +1,32 @@
+---
+title: "2020-10-09"
+description: Tyler van der Hoeven introduces Stellar Quest, a gamified set of testnet code challenges that awards XLM and collectible badges, and walks through the app’s architecture, anti-sybil login, and prize-claim flow using Albedo and fee-bump transactions.
+authors: john
+tags: [tutorial]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+
+
+Join this Engineering Talk to learn about Stellar Quest, a new way to onboard developers through a structured series of practical challenges. SDF’s Ecosystem Evangelist, Tyler van der Hoeven, explains the goal—bridging “normie devs” into the network with a low-friction learning path—and demos how the experience works end-to-end.
+
+Stellar Quest is organized into timed challenge drops (released on a schedule), completed on testnet so participants don’t need to buy XLM. Each challenge unlocks a collectible badge, and early finishers can win XLM prizes while supplies last. Tyler also explains how the team balances “enough hints to keep people moving” without giving away the full solution.
+
+On the engineering side, the backend is built with Cloudflare Workers and KV storage, while the frontend uses StencilJS hosted on Vercel. For authentication and anti-sybil protection, Stellar Quest uses SMS-based login (with support paths for regions where verification is tricky). Prize claiming is handled through Albedo: users sign transactions in a non-custodial flow, while the app uses fee-bump transactions so users don’t need to pay fees when claiming prizes.
+
+### Key Topics
+
+- How Stellar Quest onboards developers with gamified, modular challenges on testnet.
+- Challenge cadence: scheduled releases, badges for completion, and limited XLM prize pools.
+- Architecture overview: Cloudflare Workers + KV, StencilJS frontend, Vercel hosting.
+- SMS login as an anti-sybil mechanism (and how exceptions/support are handled).
+- Prize claiming UX: Albedo signing, non-custodial design, and fee-bump transactions to sponsor fees.
+- Why prizes may be queued (KV latency), and how more real-time primitives could improve it.
+
+### Resources
+
+- [Stellar Quest](https://quest.stellar.org)
+- [Stellar Community Fund](https://communityfund.stellar.org)
+- [Albedo](https://albedo.link)
+- [StellarExpert](https://stellar.expert)
diff --git a/meetings/2020-10-29.mdx b/meetings/2020-10-29.mdx
new file mode 100644
index 000000000..72962ea65
--- /dev/null
+++ b/meetings/2020-10-29.mdx
@@ -0,0 +1,39 @@
+---
+title: "2020-10-29"
+description: A roundtable discussion examining how Stellar applications manage users’ secret keys, comparing custodial and non-custodial approaches and exploring new protocol developments that could shape the future of key management.
+authors: john
+tags:
+ - community
+ - CAP-27
+ - CAP-35
+ - SEP-6
+ - SEP-24
+ - SEP-30
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+
+
+If you’re building a product on Stellar — or on any blockchain — one of the first and most consequential decisions you’ll face is how to manage users’ secret keys. Custodial solutions keep keys on behalf of users, while non-custodial solutions place keys directly in users’ hands. These two approaches are often presented as opposites, carrying different technical, regulatory, and philosophical implications.
+
+In this ecosystem roundtable, builders and Stellar ecosystem leaders debate which approach matters most right now. Drawing on real-world product experience, the panel discusses how custodial and non-custodial designs affect usability, compliance, recovery, and adoption, especially as Stellar applications reach beyond crypto-native users toward mainstream audiences.
+
+Panelists shared real-world experiences building wallets, anchors, and financial products for non-crypto users, highlighting how usability, recovery, compliance, and customer trust often matter more than ideological purity. The discussion also explored how newer protocol features and ecosystem standards could shift the balance by making both custodial and self-custodial designs easier to implement safely.
+
+### Key Topics
+
+- How custodial and non-custodial key management differ in practice and in philosophy
+- Tradeoffs between user sovereignty, recovery, and regulatory responsibility
+- Why enterprises increasingly adopt custodial designs as applications scale
+- How CAP-27 (multiplexed accounts) could simplify custodial architectures
+- How SEP-30 (recovery signer) could improve non-custodial key recovery
+- Which key management approach the Stellar ecosystem should prioritize next
+
+### Resources
+
+- [CAP-27: First-class multiplexed accounts](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0027.md)
+- [CAP-35: Asset clawback](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0035.md)
+- [SEP-30: Recovery Signer](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0030.md)
+- [SEP-6: Deposit and withdrawal API](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0006.md)
+- [SEP-24: Interactive deposit and withdrawal](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0024.md)
diff --git a/meetings/authors.yml b/meetings/authors.yml
index 9d92d724b..8f808c704 100644
--- a/meetings/authors.yml
+++ b/meetings/authors.yml
@@ -56,3 +56,11 @@ kaankacar:
image_url: https://github.com/kaankacar.png
socials:
github: kaankacar
+john:
+ name: John Wooten
+ url: https://wooten.link
+ image_url: https://github.com/JFWooten4.png
+ socials:
+ github: jfwooten4
+ x: jfwooten4
+ linkedin: jfwooten4
diff --git a/routes.txt b/routes.txt
index 9f0304cc0..8cf43c83e 100644
--- a/routes.txt
+++ b/routes.txt
@@ -837,6 +837,24 @@
/docs/validators/admin-guide/soroban-settings
/docs/validators/tier-1-orgs
/meetings
+/meetings/2020/04/10
+/meetings/2020/04/16
+/meetings/2020/04/24
+/meetings/2020/04/30
+/meetings/2020/05/08
+/meetings/2020/05/22
+/meetings/2020/06/04
+/meetings/2020/06/05
+/meetings/2020/06/26
+/meetings/2020/07/09
+/meetings/2020/07/10
+/meetings/2020/07/15
+/meetings/2020/07/24
+/meetings/2020/08/14
+/meetings/2020/08/28
+/meetings/2020/09/11
+/meetings/2020/10/09
+/meetings/2020/10/29
/meetings/2024/01/18
/meetings/2024/01/26
/meetings/2024/02/01
@@ -925,12 +943,42 @@
/meetings/page/5
/meetings/page/6
/meetings/page/7
+/meetings/page/8
+/meetings/page/9
/meetings/tags
+/meetings/tags/cap-15
+/meetings/tags/cap-18
+/meetings/tags/cap-19
+/meetings/tags/cap-23
+/meetings/tags/cap-27
+/meetings/tags/cap-28
+/meetings/tags/cap-30
+/meetings/tags/cap-31
+/meetings/tags/cap-33
+/meetings/tags/cap-34
+/meetings/tags/cap-35
+/meetings/tags/community
/meetings/tags/developer
/meetings/tags/developer/page/2
/meetings/tags/developer/page/3
/meetings/tags/developer/page/4
/meetings/tags/developer/page/5
/meetings/tags/developer/page/6
+/meetings/tags/legacy
/meetings/tags/protocol
+/meetings/tags/sep-1
+/meetings/tags/sep-10
+/meetings/tags/sep-12
+/meetings/tags/sep-16
+/meetings/tags/sep-24
+/meetings/tags/sep-26
+/meetings/tags/sep-3
+/meetings/tags/sep-30
+/meetings/tags/sep-31
+/meetings/tags/sep-5
+/meetings/tags/sep-6
+/meetings/tags/sep-8
+/meetings/tags/sep-9
+/meetings/tags/spotlight
+/meetings/tags/tutorial
/search