Podcasts about crdt

Ben Holmes, product engineer at Warp, joins PodRocket to talk about local-first web apps and what it takes to run a database directly in the browser. He breaks down how moving data closer to the user can reduce latency, improve performance, and simplify frontend development. Learn about SQLite in the browser, syncing challenges, handling conflicts, and tools like WebAssembly, IndexedDB, and CRDTs. Plus, Ben shares insights from building his own SimpleSyncEngine and where local-first development is headed! Links https://bholmes.dev https://www.linkedin.com/in/bholmesdev https://www.youtube.com/@bholmesdev https://x.com/bholmesdev https://bsky.app/profile/bholmes.dev https://github.com/bholmesdev We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: Ben Holmes.

В этом выпуске: что нас ждет в OrcaSlicer v2.3.0, какие проблемы решает Spice.ai, совместное редактирование текстов с Eg-walker, а также темы наших слушателей и GameZen. [00:03:43] Чему мы научились за неделю [00:26:24] OrcaSlicer v2.3.0-beta Release OrcaSlicer v2.3.0-beta Release · SoftFever/OrcaSlicer · GitHub OrcaSlicer — Powerful 3D Printing Slicer [00:42:23] CMU Spice.ai https://www.youtube.com/watch?v=tyM-ec1lKfU [Building Blocks] Accelerating… Читать далее →

Today in the Creator's Lab, Tony Dang joins Elixir Wizards Sundi Myint and Owen Bickford to break down his journey of creating a local-first, offline-ready to-do app using Phoenix LiveView, Svelte, and CRDTs (Conflict-free Replicated Data Types). Tony explains why offline functionality matters and how this feature can transform various apps. He shares insights on different libraries, algorithms, and techniques for building local-first experiences and highlights the advantages of Elixir and Phoenix LiveView. Tony also shares his go-to tools, like Inertia.js for connecting Phoenix backends with JavaScript frontends, and favorite Elixir packages like Oban, Joken, and Hammer, offering a toolkit for anyone building powerful, adaptable applications. Topics discussed in this episode: Tony Dang's background from mechanical engineer to web developer Building an offline-enabled to-do app with Phoenix LiveView and Svelte CRDTs: Conflict-free Replicated Data Types for merging changes offline How to make a LiveView app work offline Sending full state updates vs. incremental updates for performance optimization Inspiring others through open-source projects and community contributions Learning vanilla Phoenix and Channels to understand LiveView better Handling stale CSRF tokens when reconnecting to a LiveView app offline Exploring service workers and browser APIs for managing offline connectivity Balancing the use of JavaScript and Elixir in web development Fostering a supportive and inspiring Elixir community Links mentioned: Working in Elevators: How to build an offline-enabled, real-time todo app (https://www.youtube.com/watch?v=PX9-lq0LL9Q) w/ LiveView, Svelte, & Yjs Tony's Twitter: https://x.com/tonydangblog https://liveview-svelte-pwa.fly.dev/ https://github.com/tonydangblog/liveview-svelte-pwa CRDT: https://en.wikipedia.org/wiki/Conflict-freereplicateddatatype PWA: https://en.wikipedia.org/wiki/Progressivewebapp https://github.com/josevalim/sync https://github.com/sveltejs/svelte https://github.com/woutdp/livesvelte https://github.com/yjs/yjs https://github.com/satoren/yex https://github.com/y-crdt/y-crdt https://linear.app/ https://github.com/automerge/automerge https://hexdocs.pm/phoenix/1.4.0-rc.1/presence.html Vaxine, the Rich CRDT Database for ElixirPhoenix Apps (https://www.youtube.com/watch?v=n2c5eWIfziY) | James Arthur | Code BEAM America 2022 https://github.com/electric-sql/vaxine Hybrid Logical Clocks https://muratbuffalo.blogspot.com/2014/07/hybrid-logical-clocks.html https://en.wikipedia.org/wiki/256(number) CSRF Tokens in LiveView https://hexdocs.pm/phoenixliveview/Phoenix.LiveView.html#getconnectparams/1 https://hexdocs.pm/phoenix/channels.html Authentication with Passkeys (https://www.youtube.com/playlist?list=PL8lFmBcH3vX-JNIgxW3THUy7REthSRFEI) Talk by Tony https://www.meetup.com/dc-elixir/ https://github.com/rails/rails https://github.com/facebook/react-native https://github.com/vuejs https://github.com/laravel/laravel https://hexdocs.pm/phoenixliveview/js-interop.html https://github.com/inertiajs https://github.com/inertiajs/inertia-phoenix https://savvycal.com/ https://github.com/wojtekmach/req https://github.com/oban-bg/oban https://github.com/joken-elixir/joken https://github.com/ExHammer/hammer Special Guest: Tony Dang.

News includes Chris McCord's speedrun video on adding a self-hosted llama2-7b to an existing application, Tyler Young's release of parameterized_test v0.2.0, major updates in Oban Pro's new launch week, potential for CRDTs being added to Mnesia DB, Zach Daniel's blog post on Igniter for code generation, and a preview of ElixirConf 2024 with exciting speakers and topics, and more! Show Notes online - http://podcast.thinkingelixir.com/213 (http://podcast.thinkingelixir.com/213) Elixir Community News - https://x.com/chris_mccord/status/1815409966611648705 (https://x.com/chris_mccord/status/1815409966611648705?utm_source=thinkingelixir&utm_medium=shownotes) – Chris McCord does a YouTube video speedrun of adding a self-hosted llama2-7b to an existing application. He's running it against Ollama and making REST API calls to it, showing how to run the Ollama server on a private Fly.io IPv6 network using auto-stop and auto-start features. - https://x.com/TylerAYoung/status/1815391743484870980 (https://x.com/TylerAYoung/status/1815391743484870980?utm_source=thinkingelixir&utm_medium=shownotes) – Tyler Young shared a new release of his library parameterizedtest, version v0.2.0, which includes support for longer test names, comments in tables, and Obsidian markdown table format. - https://github.com/s3cur3/parameterized_test (https://github.com/s3cur3/parameterized_test?utm_source=thinkingelixir&utm_medium=shownotes) – GitHub repository for Tyler Young's parameterizedtest library that makes it easier to create tests using multiple combinations in markdown tables. - https://x.com/Exadra37/status/1815694986345611683 (https://x.com/Exadra37/status/1815694986345611683?utm_source=thinkingelixir&utm_medium=shownotes) – The Mnesia database may receive native support for automated conflict resolution via CRDTs, sponsored by ErlangSolutions and developed by Vincent Lau. - https://www.youtube.com/watch?v=tHdPRyMjmW8 (https://www.youtube.com/watch?v=tHdPRyMjmW8?utm_source=thinkingelixir&utm_medium=shownotes) – Vincent Lau spoke at Code BEAM Europe 2023 about his work on adding CRDTs to Mnesia for automated conflict resolution. - https://www.erlang.org/doc/apps/mnesia/mnesia.html (https://www.erlang.org/doc/apps/mnesia/mnesia.html?utm_source=thinkingelixir&utm_medium=shownotes) – Documentation on Mnesia, a distributed key-value DBMS built into Erlang. - https://x.com/sorentwo/status/1791166342034255938 (https://x.com/sorentwo/status/1791166342034255938?utm_source=thinkingelixir&utm_medium=shownotes) – Oban Pro's launch week introduces unified migrations, worker aliases, better support for distributed databases, faster unique job checks, and the @job decorator for small jobs. - https://x.com/sorentwo/status/1807155900609904973 (https://x.com/sorentwo/status/1807155900609904973?utm_source=thinkingelixir&utm_medium=shownotes) – Improvements in Oban Pro include better batch workflows with mermaid visualizations. - https://getoban.pro/articles/pro-1-5-launch-week-day-1 (https://getoban.pro/articles/pro-1-5-launch-week-day-1?utm_source=thinkingelixir&utm_medium=shownotes) – Article on Oban Pro's launch week, detailing new features and improvements. - https://getoban.pro/articles/pro-1-5-launch-week-day-2 (https://getoban.pro/articles/pro-1-5-launch-week-day-2?utm_source=thinkingelixir&utm_medium=shownotes) – Second day of Oban Pro's launch week article series. - https://getoban.pro/articles/pro-1-5-launch-week-day-3 (https://getoban.pro/articles/pro-1-5-launch-week-day-3?utm_source=thinkingelixir&utm_medium=shownotes) – Third day of Oban Pro's launch week article series. - https://alembic.com.au/blog/igniter-rethinking-code-generation-with-project-patching (https://alembic.com.au/blog/igniter-rethinking-code-generation-with-project-patching?utm_source=thinkingelixir&utm_medium=shownotes) – Blog post by Zach Daniel about Igniter, a tool for rethinking code generation with project patching, useful for installing libraries into existing Phoenix applications. - https://2024.elixirconf.com/ (https://2024.elixirconf.com/?utm_source=thinkingelixir&utm_medium=shownotes) – ElixirConf 2024 Preview with details on scheduled speakers and topics. Do you have some Elixir news to share? Tell us at @ThinkingElixir (https://twitter.com/ThinkingElixir) or email at show@thinkingelixir.com (mailto:show@thinkingelixir.com) Find us online - Message the show - @ThinkingElixir (https://twitter.com/ThinkingElixir) - Message the show on Fediverse - @ThinkingElixir@genserver.social (https://genserver.social/ThinkingElixir) - Email the show - show@thinkingelixir.com (mailto:show@thinkingelixir.com) - Mark Ericksen - @brainlid (https://twitter.com/brainlid) - Mark Ericksen on Fediverse - @brainlid@genserver.social (https://genserver.social/brainlid) - David Bernheisel - @bernheisel (https://twitter.com/bernheisel) - David Bernheisel on Fediverse - @dbern@genserver.social (https://genserver.social/dbern)

Join Wes and Scott as they explore LoFi (local first) web development, delving into CRDT, Websockets, IndexedDB, SQLite, and more. Discover when Local-First shines and when it's better to steer clear in this episode packed with practical insights. Show Notes 00:00 Welcome to Syntax! 03:18 Brought to you by Sentry.io. 04:08 What is LoFi? localfirst.dev 05:02 The Seven Ideals for Local-first. 05:29 1: No Spinners. 06:48 2: Your work is not trapped on one device. 07:56 3: The network is optional. 08:50 4: Seamless collaboration with your colleagues. 09:35 Oops, we for got to read 5: The Long Now. 09:37 6: Security and privacy by default. 09:45 7: You retain ultimate ownership and control. Actual Budget Finance App Ink & Switch 13:01 Sounds great, let's go! Not so fast, this stuff is hard. 14:07 The technology involved. 14:30 CRDT (Conflict-free Replicated Data Types). Wikipedia Definition James Long dotJS 2019 dotconfrences 17:48 How does it prioritize conflict resolutions? 19:36 Websockets. 20:17 IndexedDB + SQLite. 21:23 Service Workers. 22:16 The software involved. 22:24 Replicache. 24:48 YJS. 25:06 Electric SQL. 25:51 The most basic LoFi application. 31:26 Some bigger concepts. 32:34 Answering some common questions. 35:19 Some real-world examples of LoFi. Habit Path by Scott Tolinski 37:18 What about Apple PWA nonsense? 38:20 This seems similar to real-time software and multiplayer. 38:47 Sounds like too much work. Triplit Fullstack Database Electric SQL Evolu 40:46 Some useful links. Local-First Web Development Local-First Lo.fi YouTube Local-First Ink & Switch Local-First Reddit Syntax GitHub Local-First 43:30 Sick Picks + Shameless Plugs. Sick Picks Wes: Dresscode.dev Scott: Monarch Money Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott:X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

On 16th May, 2023, we had an introductory presentation session with IIT – Delhi, Centre for Rural Development and Technology (CRDT) as well as Unnat Bharat Abhiyan (UBA). The session was chaired by Prof. (Dr.) VK Vijay, National Coordinator – UBA, IREDA Chair Professor and Coordinator of Biogas Development & Training Centre of MNRE, Government of India. Various members (students, professors and research scholars) of CRDT cell & UBA cell also attended and appreciated the session too. Our team included Mr. Madhukar Swayambhu, Mr. Chandra Shekhar, Mr. Pankaj Kumar, Mr. Atul Mohan, Mr. Neeraj Kumar and Shri Ramesh Pandya ji (who joined a little later). We would like to express our gratitude towards Dr. Pankaj & Mr. Mohan for visualizing, organizing and making it happen. And would look forward to more such sessions in future. #Cownomics #VaidicSrijan #CRDT #UBA #IITDelhi #RuralDevelopment --- Send in a voice message: https://podcasters.spotify.com/pod/show/vaidicsrijan/message

thx

n/a

James Arthur shares his project Vaxine.io, an Elixir layer built on top of a CRDT based distributed Erlang database called Antidote DB. We cover what CRDTs are and introduce how they work. We learn more about Antidote DB, the CURE protocol and especially the Vaxine.io project that adds Ecto types and makes it more approachable to Elixir applications. As applications become more global, the need for strongly consistent distributed writes becomes much more important. Show Notes online - http://podcast.thinkingelixir.com/103 (http://podcast.thinkingelixir.com/103) Elixir Community News - https://www.elixirconf.eu/talks/typecheck-effortless-runtime-type-checking/ (https://www.elixirconf.eu/talks/typecheck-effortless-runtime-type-checking/) – Marten shared an update on the TypeCheck project from ElixirConf.EU (June 9-10) - https://podcast.thinkingelixir.com/72 (https://podcast.thinkingelixir.com/72) – Episode with Martin about TypeCheck - https://twitter.com/elixirphoenix/status/1532707770415325185 (https://twitter.com/elixirphoenix/status/1532707770415325185) - https://twitter.com/wojtekmach/status/1532662628077785088 (https://twitter.com/wojtekmach/status/1532662628077785088) – Screenshot showing the single-file LiveView page - https://github.com/wojtekmach/mixinstallexamples/blob/main/phoenixliveview.exs (https://github.com/wojtekmach/mix_install_examples/blob/main/phoenix_live_view.exs) - Mix Install Examples - Phoenix LiveView app in ~70 LOC (Mix Install Examples - Phoenix LiveView app in ~70 LOC) - https://twitter.com/polvalente/status/1532439823964946432 (https://twitter.com/polvalente/status/1532439823964946432) – New Nx library called nx-signal was shared by the author, Paulo Valente - https://github.com/polvalente/nx-signal (https://github.com/polvalente/nx-signal) - https://twitter.com/josevalim/status/1533136904736198656 (https://twitter.com/josevalim/status/1533136904736198656) – José's cryptic tweet about Torchvision, ONNX, and a LiveView app - https://pytorch.org/vision/stable/index.html (https://pytorch.org/vision/stable/index.html) – Torchvision docs - https://onnx.ai/ (https://onnx.ai/) – ONNX a format for transporting trained machine learning models - https://github.com/thehaigo/live_onnx (https://github.com/thehaigo/live_onnx) – LiveOnnx project that combines the previous things with Axon and LiveView - https://github.com/oestrich/aino (https://github.com/oestrich/aino) – Aino released 0.5 - https://twitter.com/ericoestrich/status/1533995968793919488 (https://twitter.com/ericoestrich/status/1533995968793919488) – Eric explained v0.5 Aino changes - https://twitter.com/josevalim/status/1533907809942880261 (https://twitter.com/josevalim/status/1533907809942880261) – José Valim tweeted a new graphic, teasing something new in Nx land. - https://twitter.com/josevalim/status/1534120503182602240 (https://twitter.com/josevalim/status/1534120503182602240) – José mentioned that there are 3 major announcements this month starting at ElixirConfEU. Stay tuned! Do you have some Elixir news to share? Tell us at @ThinkingElixir (https://twitter.com/ThinkingElixir) or email at show@thinkingelixir.com (mailto:show@thinkingelixir.com) Discussion Resources - https://vaxine.io (https://vaxine.io) – Vaxine.io website - https://antidotedb.eu (https://antidotedb.eu) – Antidote DB website - https://crdt.tech (https://crdt.tech) – CRDT information website - https://vaxine.io/tech/how-it-works (https://vaxine.io/tech/how-it-works) - https://github.com/vaxine-io (https://github.com/vaxine-io) - https://github.com/AntidoteDB/antidote (https://github.com/AntidoteDB/antidote) – Erlang project by a different group "A planet scale, highly available, transactional database built on CRDT technology" - https://www.antidotedb.eu/ (https://www.antidotedb.eu/) - https://github.com/vaxine-io/vaxine (https://github.com/vaxine-io/vaxine) - https://github.com/vaxine-io/vax (https://github.com/vaxine-io/vax) – Data access library and Ecto integration - https://github.com/vaxine-io/examples (https://github.com/vaxine-io/examples) – Example and demo apps - https://www.foundationdb.org/ (https://www.foundationdb.org/) - https://riak.com/index.html (https://riak.com/index.html) - https://www.cockroachlabs.com/ (https://www.cockroachlabs.com/) - https://en.wikipedia.org/wiki/CockroachDB (https://en.wikipedia.org/wiki/CockroachDB) - https://supabase.com/ (https://supabase.com/) - https://lunar.vc/ (https://lunar.vc/) Guest Information - https://twitter.com/VaxineIO (https://twitter.com/VaxineIO) – Vaxine.io on Twitter - https://github.com/vaxine-io/ (https://github.com/vaxine-io/) – Vaxine Github Organization - https://vaxine.io (https://vaxine.io) – Vaxine.io website - https://vaxine.io/blog (https://vaxine.io/blog) – Blog Find us online - Message the show - @ThinkingElixir (https://twitter.com/ThinkingElixir) - Email the show - show@thinkingelixir.com (mailto:show@thinkingelixir.com) - Mark Ericksen - @brainlid (https://twitter.com/brainlid) - David Bernheisel - @bernheisel (https://twitter.com/bernheisel) - Cade Ward - @cadebward (https://twitter.com/cadebward)

Holmes Wilson explains to Doc Searls and Katherine Druckman how central servers limit personal freedom, and how you can improve the quality of private P2P team chat and collaboration like Slack and Discord with Quiet, his open source team's work in progress. Hosts: Doc Searls and Katherine Druckman Guest: Holmes Wilson Download or subscribe to this show at https://twit.tv/shows/floss-weekly Think your open source project should be on FLOSS Weekly? Email floss@twit.tv. Thanks to Lullabot's Jeff Robbins, web designer and musician, for our theme music. Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit Sponsors: kolide.com/floss NewRelic.com/FLOSS

Holmes Wilson explains to Doc Searls and Katherine Druckman how central servers limit personal freedom, and how you can improve the quality of private P2P team chat and collaboration like Slack and Discord with Quiet, his open source team's work in progress. Hosts: Doc Searls and Katherine Druckman Guest: Holmes Wilson Download or subscribe to this show at https://twit.tv/shows/floss-weekly Think your open source project should be on FLOSS Weekly? Email floss@twit.tv. Thanks to Lullabot's Jeff Robbins, web designer and musician, for our theme music. Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit Sponsors: kolide.com/floss NewRelic.com/FLOSS

Holmes Wilson explains to Doc Searls and Katherine Druckman how central servers limit personal freedom, and how you can improve the quality of private P2P team chat and collaboration like Slack and Discord with Quiet, his open source team's work in progress. Hosts: Doc Searls and Katherine Druckman Guest: Holmes Wilson Download or subscribe to this show at https://twit.tv/shows/floss-weekly Think your open source project should be on FLOSS Weekly? Email floss@twit.tv. Thanks to Lullabot's Jeff Robbins, web designer and musician, for our theme music. Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit Sponsors: kolide.com/floss NewRelic.com/FLOSS

Holmes Wilson explains to Doc Searls and Katherine Druckman how central servers limit personal freedom, and how you can improve the quality of private P2P team chat and collaboration like Slack and Discord with Quiet, his open source team's work in progress. Hosts: Doc Searls and Katherine Druckman Guest: Holmes Wilson Download or subscribe to this show at https://twit.tv/shows/floss-weekly Think your open source project should be on FLOSS Weekly? Email floss@twit.tv. Thanks to Lullabot's Jeff Robbins, web designer and musician, for our theme music. Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit Sponsors: kolide.com/floss NewRelic.com/FLOSS

Twitch channel with the full show: https://www.twitch.tv/terminusdbAlso check out Matthijs' coding sessions on twitch - they are a delight, you won't regret.Shared in the chat (funny): https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascriptVaxine, the CRDT data platform: https://github.com/vaxine-ioBob Muglia's talk at the Knowledge Graph Conference: https://zenodo.org/record/6515008RelationalAI raise a lot of money (i think I said 26m in the episode, but it is much, much more): https://relational.ai/blog/relationalai-raises-usd122m-to-redefine-how-intelligent-data-apps-are-built  

Hello everyone! My name is Martin Kleppmann. I'm a researcher at the University of Cambridge. And I would like to tell you briefly about the technology called CRDTs. So, CRDT stands for Conflict-free Replicated Data Type. It's a type of data structure that you can use to build collaboration software. So think software like Google Docs for example. Or Figma. Or Trello. Or a TODO list that syncs between your computer and your phone. You can build this type of software using CRDTs. Read more: https://nurkiewicz.com/70 Get the new episode straight to your mailbox: https://nurkiewicz.com/newsletter

Another episode Beyond Chat. Again? Yes! A lot of cool things are going on! And today my guest is going to tell you how they're building awesome collaborative apps with Matrix. Le menu du jour is in la description ⏬ 00:00 Bonjour 00:29 CRDTs are easier to understand if you have seen them in practice. Let's start with a demo! 08:37 So, what are CRDTs? 10:05 What is Yjs and what is a provider for it? 12:20 Why do you see Matrix as a good fit for document/data storage and syncing? 16:32 Are we Maximised Widgets yet? 17:57 What would make widgets better? 18:47 How is matrix-CRDT funded (featuring the noisy microphone Jitsi notification) 20:27 Is matrix-CRDT used in a commercial project? If yes, what can you share about it? 27:02 What is SyncedStore? How different is it from Yjs? 29:07 Can you expand on local-first applications? 33:25 Final Thoughts? The paper on local-first applications: https://www.inkandswitch.com/local-first/ A talk Yousef recommends to go further on CRDTs: https://www.youtube.com/watch?v=yCcWpzY8dIA Matrix-CRDT

About YiftachYiftach is an experienced technologist, having held leadership engineering and product roles in diverse fields from application acceleration, cloud computing and software-as-a-service (SaaS), to broadband networks and metro networks. He was the founder, president and CTO of Crescendo Networks (acquired by F5, NASDAQ:FFIV), the vice president of software development at Native Networks (acquired by Alcatel, NASDAQ: ALU) and part of the founding team at ECI Telecom broadband division, where he served as vice president of software engineering.Yiftach holds a Bachelor of Science in Mathematics and Computer Science and has completed studies for Master of Science in Computer Science at Tel-Aviv University.Links: Redis, Inc.: https://redis.com/ Redis open source project: https://redis.io LinkedIn: https://www.linkedin.com/in/yiftachshoolman/ Twitter: https://twitter.com/yiftachsh TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by our friends at Rising Cloud, which I hadn't heard of before, but they're doing something vaguely interesting here. They are using AI, which is usually where my eyes glaze over and I lose attention, but they're using it to help developers be more efficient by reducing repetitive tasks. So, the idea being that you can run stateless things without having to worry about scaling, placement, et cetera, and the rest. They claim significant cost savings, and they're able to wind up taking what you're running as it is, in AWS, with no changes, and run it inside of their data centers that span multiple regions. I'm somewhat skeptical, but their customers seem to really like them, so that's one of those areas where I really have a hard time being too snarky about it because when you solve a customer's problem, and they get out there in public and say, “We're solving a problem,” it's very hard to snark about that. Multus Medical, Construx.ai, and Stax have seen significant results by using them, and it's worth exploring. So, if you're looking for a smarter, faster, cheaper alternative to EC2, Lambda, or batch, consider checking them out. Visit risingcloud.com/benefits. That's risingcloud.com/benefits, and be sure to tell them that I said you because watching people wince when you mention my name is one of the guilty pleasures of listening to this podcast.Corey: This episode is sponsored in part by our friends at Sysdig. Sysdig is the solution for securing DevOps. They have a blog post that went up recently about how an insecure AWS Lambda function could be used as a pivot point to get access into your environment. They've also gone deep in-depth with a bunch of other approaches to how DevOps and security are inextricably linked. To learn more, visit sysdig.com and tell them I sent you. That's S-Y-S-D-I-G dot com. My thanks to them for their continued support of this ridiculous nonsense.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. This promoted episode is brought to us by a company that I would have had to introduce differently until toward the end of last year. Today, they're Redis, but for a while they've been Redis Labs, here to talk with me about that and oh, so much more is their co-founder and CT, Yiftach Shoolman. Yiftach, thank you for joining me.Yiftach: Hi, Corey. Nice to be a guest of you. This is a very interesting podcast, and I often happen to hear it.Corey: I'm always surprised when people tell me that they listen to this because unlike a newsletter or being obnoxious on Twitter, I don't wind up getting a whole lot of feedback from people via email or whatnot. My operating theory has been that it's like a—when I send an email out, people will get that, “Oh, an email. I know how to send one of those.” And they'll fire something back. But podcasts are almost like a radio show, and who calls into radio shows? Well, lunatics, generally, and if I give feedback, I'll feel like a lunatic.So, I get very little email response on stuff like this. But when I talk to people, they mention the show. It's, “Oh, right. Good. I did remember to turn the microphone on. People are out there listening.” Thank you.So you, back in August of 2021, the company that formerly known as Redis Labs, became known as Redis. What caused the name change? And sure, is a small change as opposed to, you know, completely rebranding a company like Square to Block, but what was it that really drove that, I guess, rebrand?Yiftach: Yeah, a great question. And by way, if you look at our history, we started the company under the name of Garantia Data, which is a terrible name. [laugh]. And initially, what we wanted to do is to accelerate databases with both technologies like memcached, and Redis. Eventually, we built a solution for both, and we found out that Redis is much more used by people. That was back in 2011.So, in 2021, we finally decided to say let's unify the brand because, you know, as a contributors to Redis from day one, and creator of Redis is also part of the company, Salvatore Sanfilippo. We believed that we should not confuse the market with multiple messages about Redis. Redis is not just the cache and we don't want people to definitely interpret this. Redis is more than a cache, it's actually, if you look at our customer, like, 66% of them are using it as a real-time database. And we wanted to unify everyone around this naming to avoid different interpretation. So, that was the motivation, maybe.Corey: It's interesting you talk about, I guess, the evolution of the use cases for Redis. Back in 2011, I was using Redis in an AWS environment, and, “Ah, disk persistence, we're going to turn that on.” And it didn't go so well back in those days because I found that the entire web app that we were using would periodically just slam to a halt for about three seconds whenever Redis wound up doing its disk persistent stuff, diving in far deeper than I really had any right to be doing, I figured out this was a regression in the Xen hypervisor and Xen kernel that AWS was using back then around the fork call. Not Redis's fault, to be very clear. But I looked at this and figured, “Ah. I know how to fix this.”And that's right. We badgered AWS into migrating to Nitro years later and not using Xen anymore, and that solve that particular problem. But this was early on in my technical career. It sort of led to the impression of, “Oh, Redis. That's a cache, I should never try and use it as anything approaching a database.” Today, that guidance no longer holds, you are positioning yourself as a data platform. What did that dawning awareness look like? How did you get to where you are from where Redis was once envisioned in the industry: Primarily as a cache?Yiftach: Yeah, very good question. So, I think we should look at this problem from the application perspective, or from the user perspective. Sounds like a marketing term, but we all know we are in the age of real-time. Like, you expect everything to be instantly. You don't want to wait, no one wants to wait, especially after Covid and everything's that brought to the you know, online services.And the expectation today from a real-time application is to be able to reply less than 100 milliseconds in order to feel the real-time. When I say 100 milliseconds, from the time you click the button until you get the first byte of the response. Now, if you do the math, you can see that, like, 50% of this goes to the network and 50% of this goes to the data center. And inside the data center, in order to complete the transaction in less than 50 milliseconds, you need a database that replies in no time, like, less than a millisecond. And today, I must say, only Redis can guarantee that.If you use Redis as a cache, every transaction—or there is a potential at least—that not all the information will be in Redis when the transaction is happening and you need to bring it probably from the main database, and you need to processing it, and you need to update Redis about it. And this takes a while. And eventually, it will help the end-user experience. And just to mention, if you look at our support tickets, like, I would say the majority of them is, why Redis replies—why Redis latency grew from 0.25 millisecond to 0.5 millisecond because there is a multiplier effect for the end-user. So, I hoping I managed to answer what are the new challenges that we see today in the market.Corey: Tell me a little bit more about the need for latency around things like that. Because as we look at modern web apps across the board, people are often accessing them through mobile devices, which, you know, we look at this spinning circle of regret as it winds up loading a site or whatnot, it takes a few seconds. So, the idea of oh, that the database call has to complete in millisecond or less time seems a little odd viewed purely from a perspective of, “Really? Because I spent a lot of time waiting for the webpage to load.” What drives that latency requirement?Yiftach: First of all, I agree with you. A lot of time, you know, application were not built for it then. This is why I think we still have an opportunity to improve existing application. But for those applications that weren't built for real-time, for instance, in the gaming space, it is clear that if you delay your reaction for your avatar, in more than two frame, like, I mean, 60 millisecond, the experience is very bad, and customers are not happy with this. Or, in transaction scoring example, when you swipe the card, you want the card issuer to approve or not approve it immediately. You don't want to wait. [unintelligible 00:07:19] is another example.But in addition to that there are systems like mobility as a service, like the Ubers of the world, or the Airbnb of the world. Or any e-commerce site. In order to be able to reply in second, they need to process behind the scene, thousand, and sometime millions of operations per second in order to get to the right decision. Yeah? You need to match between riders and drivers. Yeah, and you need to match between guests and free room in the hotel. And you need to see that the inventory is up-to-date with the shoppers.And all these takes a lot of transactions and a lot of processing behind the scene in order just to reply in second in a consistent manner. And this is why that this is useful in all these application. And by the way, just a note, you know, we recently look at how many operations per second actually happening in our cloud environment, and I must tell you that I was surprised to see that we have over one thousand clusters or databases with the speed of between 1 million to 10 million operation per second. And over 150 databases with over 10 million operations per second, which is huge. And if you ask yourself how come, this is exactly the reason. This is exactly the reason. For every user interaction, usually you need to do a lot of interaction with your data.Corey: That kind of transaction volume, it would never occur to me to try and get that on a single database. It would, “All right, let's talk about sharding for days and trying to break things out.” But it's odd because a lot of the constraints that I was used to in my formative years, back when I was building software—badly—are very much no longer the case. The orders of magnitude are different. And things that used to require incredibly expensive, dedicated hardware now just require, “Oh yeah, you can click the button and get one of those things in the cloud, and it's dirt cheap.”And it's been a very strange journey. Speaking of clicking buttons, and getting things available in the cloud, Redis has been a thing, and its rise has almost perfectly tracked the rise of the cloud itself. There's of course the Redis open-source project, which has been around for ages and is what you're based on top of. And then obviously AWS wind up launching—“Ah, we're going to wind up ‘collaborating'”—and the quotes should be visible from orbit on that—“With Redis by launching ElasticCache for Redis.” And they say, “Oh, no, no, it's not competition. It's validating your market.”And then last year, they looked at you folks again, like, “Ah, we're launching a second service: MemoryDB in this case.” It's like Redis, except bad. And I look at this, and I figure what is their story this time? It's like, “Oh, we're going to validate the shit out of your market now.” It's, on some level, you should be flattered having multiple services launched trying to compete slash offer the same types of things.Yet Redis is not losing money year-over-year. By all accounts, you folks are absolutely killing it in the market. What is it like to work both in cloud environments and with the cloud vendors themselves?Yiftach: This is a very good question. And we use the term frenemy, like, they're our friend, but sometimes they are our enemy. We try to collaborate and compete them fairly. And, you know, AWS is just one example. I think that the other cloud took a different approach.Like with GCP, we are fully integrated in the console, what is called, “Third-party first-class service.” You click the button through the GCP console and then you're redirected to our cloud, Redis Enterprise cloud. With Azure even, we took a one step further and we provide a fully integrated solution, which is managed by Azure, Azure Cache for Redis, and we are the enterprise tier. But we are also cooperating with AWS. We cooperating on the marketplace, and we cooperate in other activities, including the open-source itself.Now, to tell you that we do not have, you know, a competition in the market, the competition is good. And I think MemoryDB is a validation of your first question, like, how can you use Redis [more than occasion 00:11:33], and I encourage users to test the differences between these services and to decide what fits to their use case. I promise you my perspective, at least, that we provide a better solution. We believe that any real-time use case should eventually be served by Redis, and you don't need to create another database for that, and you don't need to create another caching layer; you have everything in a single data platform, including all the popular models, data models, not only key-value, but also JSON, and search, and graph, and time-series… and probably AI, and vector embedding, and other stuff. And this is our approach.Corey: Now, I know it's unpopular in AWS circles to point this out, but I have it on good authority that they are not the only large-scale cloud provider on the planet. And in fact, if I go to the Google Cloud Console, they will sell me Redis as well, but it's through a partner affinity as a first-party offering in the console called Redis Enterprise. And it just seems like a very different interaction model, as in, their approach is they're going to build their own databases that solve for a wide variety of problems, some of them common and some of them ridiculous, but if you want actual Redis or something that looks like Redis, their solution is, “Oh, well, why don't we just give you Redis directly, instead of making a crappy store-brand equivalent of Redis?” It just seems like a very different go to market approach. Have you seen significant uptake of Redis as a product, through partnering with Google Cloud in that way?Yiftach: I would do answer this politely and say that I can no more say that the big cloud momentum is only on AWS. [laugh]. We see a lot of momentum in other clouds in terms of growth. And I would challenge the AWS guys to think differently about partnership with ISV. I'm not saying that they're not partnering with us, but I think the partnerships that we have with other clouds are more… closer. Yeah. It's like there is less friction. And it's up to them, you know? It's up to any cloud vendor to decide the approach they wants to take in this market. And it's good.Corey: It's a common refrain that I hear is that AWS is where we see the eight-hundred-pound gorilla in the space, it's very hard to deny that. But it also has been very tricky to wind up working with them in a partnership sense. Partnering is not really a language that Amazon speaks super well, kind of like, you know, toddlers and sharing. Because today, they aren't competing directly with you, but what about tomorrow? And it's such a large distributed company that in many cases, your account manager or your partner manager there doesn't realize that they're launching a competitor until 12 hours before it launches. And that's—yeah, feels great. It just feels very odd.That said, you are a partner with AWS and you are seeing significant adoption via the AWS Marketplace, and the reason I know that is because I see it in my own customer accounts on the consulting side, I'm starting to see more and more spend via the marketplace, partially due to offset spend commitments that they've made contractually with AWS, but also, privately I tend to believe a lot of that is also an end-run around their own internal procurement department, who, “Oh, you want some Redis. Great. Give me nine months, and then find three other vendors to give me competitive bids on it.” And yeah, that's not how the world works anymore. Have you found that the marketplace is a discovery mechanism for customers to come to Redis, or are they mostly going into the marketplace saying, “I need Redis. I want it to be Redis Enterprise, from Redis, but this is the way I'm going to procure it.”Yiftach: My [unintelligible 00:15:17], you know, there are people that are seeing differently, that marketplace is how to be discovered through the marketplace. I still see it, I still see it as a billing mechanism for us, right? I mean, AWS helping us in sell. I mean, their sell are also sell partner and we have quite a few deals with them. And this mechanism works very nicely, I must say.And I know that all the marketplaces are trying to change it, for years. That customer whenever they look at something, they will go through the marketplace and find it there, but it's hard for us to see the momentum there. First of all, we don't have the metrics on the marketplace; we cannot say it works, it doesn't works. What we do see that works is that when we own the customer and when the customer is ascertaining how to pay, through the credit card or through the wire, they usually prefer to pay through the commit from the cloud, whether it is AWS, GCP, or Azure. And for that, we help them to do the transaction seamlessly.So, for me, the marketplace, the number one reason for that is to use your existing commit with the cloud provider and to pay for ourselves. That said, I must say that [with disregard 00:16:33] [laugh] AWS should improve something because not the entire deal is committed. It's like 50% or 60%, don't remember the exact number. But in other clouds when ISVs are interacting with them, the entire deal is credited for the commit, which is a big difference.Corey: I do point out, this is an increasing trend that I'm seeing across the board. For those who are unaware, when you have a large-scale commitment to spend a certain dollar amount per year on AWS Marketplace spend counts at a 50% rate. So, 50 cents of every dollar you spend to the marketplace counts toward your commit. And once upon a time, this was something that was advertised by AWS enterprise sales teams, as, “Ah. This is a benefit.”And they're talking about moving things over that at the time are great, you can move that $10,000 a year thing there. And it's, “You have a $50 million annual commit. You're getting awfully excited about knocking $5,000 off of it.” Now, as we see that pattern starting to gain momentum, we're talking millions a year toward a commit, and that is the game changer that they were talking about. It just looks ridiculous at the smaller-scale.Yiftach: Yeah. I agree. I agree. But anyway, I think this initiative—and I'm sure that AWS will change it one day because the other cloud, they decided not to play this game. They decided to give the entire—you know, whatever you pay for ISVs, it will be credited with your commit.Corey: We're all biased by our own experiences, so I have a certain point of view based upon what I see in my customer profile, but my customers don't necessarily look like the bulk of your customers. Your website talks a lot about Redis being available in all cloud providers, in on-prem environments, the hybrid and multi-cloud stories. Do you see significant uptake of workloads that span multiple clouds, or are they individual workloads that are on multiple providers? Like for example Workload A lives on Azure, Workload B lives on GCP? Or is it just Workload A is splattered across all four cloud providers?Yiftach: Did the majority of the workloads is splitted between application and each of them use different cloud. But we started to see more and more use cases in which you want to use the same data sets across cloud, and between hybrid and cloud, and we provide this solution as well. I don't want to promote myself so much because you worried me at the beginning, but we create these products that is called Active-Active Redis that is based on CRDT, Conflict-free Replicated Data Type. But in a nutshell, it allows you to run across multiple clouds, or multiple region in the same cloud, or hybrid environment with the speed the of Redis while guaranteeing that eventually all your rights will be converged to the same value, and while maintaining the speed of Redis. So, I would say quite a few customers have found it very attractive for them, and very easy to migrate between clouds or between hybrid to the cloud because in this approach of Active-Active, you don't need the single cut-off.A single cut-off is very complex process when you want to move a workload from one cloud to another. Think about it, it is not only data; you want to make sure that the whole entire application works. It never works in one shot and you need to return back, and if you don't have the data with you, you're stuck. So, that mechanism really helps. But the bigger picture, like you mentioned, we see a lot of [unintelligible 00:20:12] distribution need, like, to maintain the five nines availability and to be closer to the user to guarantee the real-time. Send dataset deployment across multiple clouds, and I agree, we see a growth there, but it is still not the mainstream, I would say.Corey: I think that my position on multi-cloud has been misconstrued in a variety of corners, which is doubtless my fault for failing to explain it properly. My belief has been when you're building something on day-one, greenfield pickup provider—I don't care which one—go all in. But I also am not a big fan of potentially closing off strategic or theoretical changes down the road. And if you're picking, let's say, DynamoDB, or Cloud Spanner, or Cosmos DB, and that is the core of your application, moving a workload from Cloud A to Cloud B is already very hard. If you have to redo the entire interface model for how it talks to his data store and the expectations built into that over a number of years, it becomes basically impossible.So, I'm a believer in going all-in but only to a certain point, in some cases, and for some workloads. I mean, I done a lot of work with DynamoDB, myself for my newsletter production pipeline, just because if I can't use AWS anymore, I don't really need to write Last Week in AWS. I have a hard time envisioning a scenario in which I need to go cross-cloud but still talk about the existing thing. But my use case is not other folks' use case. So, I'm a big believer in the theoretical exodus, just because not doing that in many corporate environments becomes a lot less defensible. And Redis seems like a way to go in that direction.Yiftach: Yeah. Totally with you. I think that this is a very important—and by the way, it is not… to say that multi-cloud is wrong, but it allows you to migrate workload from one cloud to another, once you decide to do it. And it's put you in a position as a consumer—no one wants—why no one likes [unintelligible 00:22:14]. You know, because of the pricing model [laugh], okay, right?You don't want to repeat this story, again with AWS, and with any of them. So, you want to provide enough choices, and in order to do that, you need to build your application on infrastructures that can be migrated from one cloud to another and will not be, you know, reliant on single cloud database that no one else has, I think it's clear.Corey: This episode is sponsored in part by our friends at Vultr. Spelled V-U-L-T-R because they're all about helping save money, including on things like, you know, vowels. So, what they do is they are a cloud provider that provides surprisingly high performance cloud compute at a price that—while sure they claim its better than AWS pricing—and when they say that they mean it is less money. Sure, I don't dispute that but what I find interesting is that it's predictable. They tell you in advance on a monthly basis what it's going to going to cost. They have a bunch of advanced networking features. They have nineteen global locations and scale things elastically. Not to be confused with openly, because apparently elastic and open can mean the same thing sometimes. They have had over a million users. Deployments take less that sixty seconds across twelve pre-selected operating systems. Or, if you're one of those nutters like me, you can bring your own ISO and install basically any operating system you want. Starting with pricing as low as $2.50 a month for Vultr cloud compute they have plans for developers and businesses of all sizes, except maybe Amazon, who stubbornly insists on having something to scale all on their own. Try Vultr today for free by visiting: vultr.com/screaming, and you'll receive a $100 in credit. Thats v-u-l-t-r.com slash screaming.Corey: Well, going greenfield story of building something out today, “I'm going to go back to my desk after this and go ahead and start building out a new application.” And great, I want to use Redis because this has been a great conversation, and it's been super compelling. I am probably not going to go to redis.com and sign up for an enterprise Redis agreement to start building out.It's much likelier that I would start down the open-source path because it turns out that I believe ‘docker pull redis' is pretty close to—or ‘docker run redis latest' or whatever it is, or however it is you want to get Redis—I have no judgment here—is going to get you the open-source tool super well. What is the nature of your relationship between the open-source Redis and the enterprise Redis that runs on money?Yiftach: So, first of all, we are, like, the number one contributor to the Redis open-source. So, I would say 98% of the code of Redis contributed by our team. Including the creator of Redis, Salvatore Sanfilippo, was part of our team. Salvatore has stepped back in, like—when was it? Like, one-and-a-half, almost two years ago because the project became, like, a monster, and he said, “Listen, this is too much. I worked, like, 10 years or 11 years. I want to rest a bit.”And the way we built the core team around Redis, we said we will allocate three people from the company according to their contribution. So, the leaders—the number two after Salvatore in terms of contribution, I mean, significant contribution, not typo and stuff [laugh] like this. And we also decided to make it, like, a community-driven project, and we invited people from other places, including AWS, Madelyn, and Zhao Zhao from Alibaba.And this is based on the past contribution to Redis, not because they are from famous cloud providers. And I think it works very well. We have a committee which is driven by consensus, and this is how we agree what we put in the open-source and what we do not. But in addition to the pure open-source, we also invested a lot in what we call Source Available. Source Available is a new approach that, I think, we were the first who started it, back in 2018, when we wanted to have a mechanism to be able to monetize the company.And what we did by then, we added all the modules which are extensions to the latest open-source that allow you to do the model, like JSON and search and graph and time series and AI and many others with Redis under the Source Available license. That mean you can use it like BSD; you can change everything, without copyleft, you don't need to contribute back. But there is one restriction. You cannot create a service or a product that compete directly with us. And so far, it works very well, and you can launch Docker containers with search, and with JSON—or with all the modules combined; we also having this—and get the experience from day zero.We also made sure that all your clients are now working very well with these modules, and we even created the object mapping client for each of the major language. So, we can easily integrate it with Spring, in Django, and Node.js platform, et cetera. This is called when OM .NET, OM Java, OM Node.js, OM Python, et cetera, very nicely. You don't need to know all the commands associated. We just speak [unintelligible 00:26:22] level with Redis and get all the functionality.Corey: It's a hard problem to solve for, and whenever we start talking about license changes for things like this, it becomes a passionate conversation. People with all sorts of different perspectives and assumptions baked in—and a remembrance of yesteryear—all have different thoughts on coulda, woulda, shoulda, et cetera, et cetera. But let's be very clear, running a business is hard. And building a business on top of an open-source model is way harder. Now, if we were launching an open-source company today in 2022, there are different things we would do; we would look at it very differently. But over a decade ago, it didn't work that way. If you were to be looking at how open-source companies can continue to thrive in a time of cloud, what guidance do you have for him?Yiftach: This is a great question, and I must say that the every month or every few weeks, I have a discussion with a new team of founders that want to create an open-source, and they asked me what is my opinion here. And I would say, today, that we and other ISV, we built a system for you to decide what you want to freely open-source, and take into account that if this goes very well, the cloud provider will pick it up and will make a service out of it. Because this is the way they work. And the way for you to protect yourself is to have different types of licenses, like we did. Like you can decide about Source Available and restrict it to the minimum.By the way, I think that Source Available is much better than AGPL with the copyleft and everything that it's provide. So, AGPL is a pure open-source, but it has so many other implications that people just don't want to touch it. So, it's available, you can do whatever you want, you just cannot create a competing product. And of course, if there are some code that you want to close, use closed-source. So, I would say think very seriously about your licensing model. This is my advice. It's not to say that open-source is not great. I truly believe that it helps you to get the adoption; there are a lot of other benefits that open-source creates.Corey: Historically, it feels that open-source was one of those things that people wanted the upside of the community, and the adoption, and getting people to work. Especially on a shoestring budget, and people can go in and fix these things. Like, that's the naive approach of, “Oh, it just because we get a whole bunch of free, unpaid labor.” Okay, fine, whatever. It also engenders trust and lets people iterate rapidly and build things to suit their use cases, and you learn so much more about the use cases as you continue to grow.But on the other side of it, there's always the Docker problem where they gave away the thing that added stupendous value. If they hadn't gone open-source with Docker, it never would have gotten the adoption that it did, but by going open-source, they wound up, effectively, being forced more or less than to say, “Okay, we're going to give away this awesome thing and then sell services around it.” And that's not really a venture-scaled business, in most cases. It's a hard market.Yiftach: And the [gate 00:29:26] should never be the cloud. Because people, like you mentioned, people doesn't start with the cloud. They start to develop with on the laptop or somewhere with Docker or whatever. And this is where Source Available can shine because it allows you to do the same thing like open-source—and be very clear, please do not confuse your user. Tells them that this is Source Available; they should know in advance, so they will be not surprise later on when they move to the production stage.Then if they have some question, legal questions, for Redis, we're able to answer, yeah. And if they don't, they need to deal with the implication of this. And so far, we found it suitable to most of the users. Of course, there will be always open-source gurus.Corey: If there's one thing people have on the internet, it's opinions.Yiftach: Yeah. I challenge the open-source gurus to change their mindset because the world has changed. You know, we cannot treat the open-source like we used to treat it there in 2008 or early-90s. It is a different world. And you want companies like Redis, you want people to invest in open-source. And we need to somehow survive, right? We need to create a business. So, I challenge these [OSI 00:30:38] committees to think differently. I hope they will, one day.Corey: One last topic that I want to cover is the explosion of AI—artificial intelligence—or machine-learning, or bias-laundering, depending upon who you ask. It feels in many ways like a marketing slogan, and I viewed it as more or less selling pickaxes into a digital gold rush on the part of the cloud providers, until somewhat recently, when I started encountering a bunch of customers who are in fact using it for very interesting and very appropriate use cases. Now, I'm seeing a bunch of databases that are touting their machine-learning capabilities on top of the existing database offerings. What's Redis's story around that?Yiftach: Great question. Great question. So, I think today, I have two story, which are related to the real-time AI, yeah, we are in the real-time world. One of them is what we call the online feature store. Just to explain the audience what is a feature store, usually, when you do inferencing, you need to enhance the transaction with some data, in order to get the right quality.Where do you store this data? So, for online transaction, usually you want to store it in Redis because you don't want to delay your application whenever you do inferencing. So, the way it works, you get a transaction, you bring the features, you combine them together, sends them to inferencing, and then whatever you want to do with the results. One of the things that we did with Redis, we combine AI inferencing inside with this, and we allow you to do that in one API call, which makes the real-time much, much faster. You can decide to use Redis just as a [unintelligible 00:32:16] feature store; this is also great.The other aspect of AI is vector embedding. Just to make sure that we are all aligned with vector embedding term, so vector embedding allows you to provide a context for your text, for your video, for your image in just 128-byte, or floating point. It really depends on the quality of vector. And think about is that tomorrow, every profile in your database will have a vector that explain the context of the product, the context of the user, everything, like, in one single object in your profile.So, Redis has it. So, what can you do once you have it? For instance, you can search where are the similar vector—this is called vector similarity search—for recommendation engines, and for many, many, many others implications. And you would like to combine it with metadata, like, not only bring me all the similar context, but also, you know, some information about the visitor, like the age, like the height, like where does the person live? So, it's not only vector similarity search, it's search with vector similarity search.Now, the question could be asked, do we want to create a totally different database just for this vector similarity search, and then I will make it fast as Redis because you need everything to run in real-time? And this is why I encourage people to look at what they have in Redis. And again, I don't want to be marketeer here, but they don't think that the single-feature deployment require a new database. And we added this capability because we do see the need to support it in real-time. I hope my answer was not too long.Corey: No, no, it's the right answer because the story that you're telling about this is not about how smart you are; it's not about hype-driven stuff. You're talking about using this to meet actual customer needs. And if you tell me that, “Oh, we built this thing because we're smart,” yeah, I can needle you to death on that and make fun of you until I'm blue in the face. But when you say, “I'm going to go ahead and do this because our customers have this pain,” well, that's a lot harder for me to criticize because, yeah, you have to meet your customers where they are; that's the right thing to do. So, this is the kind of story that is slowly but surely changing my view on the idea of machine-learning across the board.Yiftach: I'm happy that you like it. We like it as well. And we see a lot of traction today. Vector similarity search is becoming, like, a real thing. And also features store.Corey: I want to thank you so much for taking the time to speak with me today. If people want to learn more, where can they find you?Yiftach: Ah, I think first of all, you can go to redis.io or redis.com and look for our solution. And I'm available on LinkedIn and Twitter, and you can find me.Corey: And we will of course put links to all of that in the [show notes 00:35:10]. Thank you so much for your time today. I appreciate it.Yiftach: Thank you, Corey. It was very nice conversation. I really enjoy it. Thank you very much.Corey: Thank you. You as well. Yiftach Shoolman, CTO and co-founder at Redis. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with a long rambling angry comment about open-source licensing that no one is going to be bothered to read.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

Ihr kennt es bestimmt: die gemeinsam verwaltete digitale Einkaufsliste. Oder: Tools wie Etherpad und Google Docs, die uns das gleichzeitige Bearbeiten des selben Texts ermöglichen. Doch was steckt technisch dahinter? Wir erklären, was theoretisch dahintersteckt. Und wie Ihr es praktisch nutzen könnt!

The entire CRDT team gets together for a lighter episode with mixed 'What If' questions - this is a relaxed episode with the team as they have fun with more than just dog training questions..

Host Nono Martínez Alonso and Nate Peters on the machine learning-based audio-editing solution this podcast is being produced with, web components, React and UI libraries, the effects of COVID-19 in our work lives, NFTs and cryptocurrencies, and the new informal catch-up conversation podcast format we're testing out. Nono hosts the Getting Simple podcast, sketches things that call his attention, writes stories about enjoying a slower life, and records live streams and tutorials on creative coding and machine intelligence. Nate works as a software engineer for Autodesk. Before joining Autodesk, he earned his Master of Design Studies in Technology at the Harvard Graduate School of Design and a Bachelor of Architecture at Iowa State University. Links Audio Hijack and Loopback by Rogue Amoeba OBS Descript Lyrebird Deepfakes GPT-3 Adobe Audition p5.js perfect-freehand by Steve Ruiz TypeScript Yjs, y-websocket & y-webrtc CRDT WebSocket WebRTC DigitalOcean Figma SVG Next.js Leva Perlin noise G-Code Pen plotter React React Hooks React Router React Three Fiber Three.js dat.gui How Figma's multiplayer technology works Material UI Grommet SCSS Lex Fridman podcast Travis Oliphant on Lex Fridman NumPy & SciPy zk-SNARKs Zero Knowledge Proof Foundation.app People mentioned Aziz Barbar Lex Fridman Nate Peters Travis Oliphant Steve Ruiz Outline Intro. [00:00] Announcements. [00:33] Start. [01:22] Descript: Machine-learning-based audio editing. [03:53] Studio Sound. [09:40] What's that little UI library? [11:37] CRDT, Yjs, WebSocket, and WebRTC. [13:41] React hooks. [19:40] UI libraries. [21:39] Technical conversations. [23:48] COVID-19. [25:44] Podcast format. [28:11] NFTs and cryptocurrencies. [28:41] Outro. [29:53] Submit a question about this or previous episodes. I'd love to hear from you. Join the Discord community. Meet other curious minds. If you enjoy the show, would you please consider leaving a short review on Apple Podcasts/iTunes? It takes less than 60 seconds and really helps. Show notes, transcripts, and past episodes at gettingsimple.com/podcast. Follow Nono Twitter.com/nonoesp Instagram.com/nonoesp Facebook.com/nonomartinezalonso YouTube.com/nonomartinezalonso

Rafael is joined by Mark Henderson and Haadcode to talk about OrbitDB, a distributed database / data mesh for use in peer to peer applications. They talk about what it is like developing in the peer to peer field, talk about developing an oplog CRDT, complain a little bit about safari and browser storage limitations, and discuss how one of the core innovations in developing for p2p applications is finding the capacity to "think in a distributed way". - https://orbitdb.org/ - Equilibrium: https://equilibrium.io/en/ - Jon Sarkin's Art: jonsarkin.com - Distributed (c): https://distributedc.org/ - A Post about Watchit: https://dev.to/geolffreym/watchit-2b88 - Watchit App: https://watchitapp.site/ - Mark on Twitter: https://twitter.com/aphelionz - OrbitDB on github: https://github.com/orbitdb/orbitdb.org - OrbitDB on Matrix: https://riot.im/app/#/room/#orbit-db:matrix.org

Rafael is joined by Mark Henderson and Haadcode to talk about OrbitDB, a distributed database / data mesh for use in peer to peer applications. They talk about what it is like developing in the peer to peer field, talk about developing an oplog CRDT, complain a little bit about safari and browser storage limitations, and discuss how one of the core innovations in developing for p2p applications is finding the capacity to "think in a distributed way". - https://orbitdb.org/ - Equilibrium: https://equilibrium.io/en/ - Jon Sarkin's Art: jonsarkin.com - Distributed (c): https://distributedc.org/ - A Post about Watchit: https://dev.to/geolffreym/watchit-2b88 - Watchit App: https://watchitapp.site/ - Mark on Twitter: https://twitter.com/aphelionz - OrbitDB on github: https://github.com/orbitdb/orbitdb.org - OrbitDB on Matrix: https://riot.im/app/#/room/#orbit-db:matrix.org

Wszystkie dobre podcasty o kryptowalutach https://darmowekrypto.org.pl/podcasty-----------------------------------------Krypto Newsy Lite #166 | 17.02.2021 | Bitcoin nie zatrzymuje się - $52k! Instytucje i banki chcą Bitcoina! Coinbase warty $77B robi IPOBitcoin nie zatrzymuje się! Mamy już $52k! Czy widać gdzieś granicę? A może jakaś większa korekta na horyzoncie? Niektórzy czekają na korektę od poziomów $20k. Doczekają się? Być może i nie! Instytucje i banki chcą Bitcoina! Tesla i BNY Mellon przetarły szlaki. Banki chcą oferować usługi kryptowalutowe, a instytucje chcą kupować BTC! Czy cena poleci wyżej? Podobno nawet inwestorzy w złoto chcą przechodzić do Bitcoina.A Coinbase jest wart $77B i zrobi własne IPO. Akcje już są w sprzedaży. Będzie to największe IPO firmy ze świata kryptowalut.Zapraszam na wiadomości ze świata kryptowalut i technologii blockchain, czyli Krypto-Newsy Lite. Prowadzi Mike Satoshi.Spis treści:[]Wstęp[]Amerykańska firma kupuje 10000 Antminer S19 - https://bitcoinpl.org/amerykanski-firma-wydobywajaca-bitcoiny-blockcap-kupuje-kolejne-10000-asic/[]Coinbase warty $77B robi IPO - https://comparic.pl/gielda-coinbase-wyceniana-na-77-mld-dol-szykuje-sie-do-ipo/​[]Bitocin przebija $50k i robi 200$ w 3 miesiące - https://news.bitcoin.com/bitcoin-hits-50k-crypto-asset-jumps-200-in-3-months-usd-shorts-touch-a-decade-high/[]Bitcoin nie zatrzymuje się - $52k - https://www.newsbtc.com/news/bitcoin/...​[]Krypto influencerzy - https://beincrypto.com/crypto-influen...​[]Dlaczego alty spadają jak Bitcoin rośnie? - https://cointelegraph.com/news/here-s...​[]Trzech hakerów na celowniku USA - https://cointelegraph.com/news/us-cha...​[]Microstrategy chce zebrać $900M i kupić BTC - https://cointelegraph.com/news/micros...​[]Blockchain.com zbiera $120M od inwestorów - https://cointelegraph.com/news/blockc...​[]Czy są privacy coins? - https://cointelegraph.com/news/what-a...​[]Chiński biometryczny portfel sprzętowy dla CBDC - https://cointelegraph.com/news/chines...​[]https://cointelegraph.com/news/the-ba...​[]CRDT na Coinbase Wallet - https://twitter.com/CRDTpay/status/13...​[]Coinbase zatrudnia Melissę Strait - https://coinfomania.com/coinbase-appo...​[]Banki chcą oferować usługi kryptowalutowe - https://coinfomania.com/elliptic-foun...​[]Strateg JP Morgan przewiduje rajd na Bitcoinie - https://coinfomania.com/jpmorgan-stra...​[]YouTuber w depresji, kupił Hondę za BTC - https://coinfomania.com/depressed-you...​[]Elon Musk mówi o centralizacji Dogecoina - https://dailyhodl.com/2021/02/17/elon...​[]Grayscale kupuje Ethereum - https://dailyhodl.com/2021/02/17/cryp...​[]Bitcoin może dobić do $70k - https://en.cryptonomist.ch/2021/02/17...​[]Dave Portnoy nigdy nie kupi BTC - https://decrypt.co/57998/barstool-spo...​[]Inwestorzy porzucają złoto dla Bitcoina - https://thedailychain.com/investors-could-dump-gold-positions-to-seek-returns-in-bitcoin/[]Większość DOGE jest w 100 portfelach - https://beincrypto.pl/wiekszosc-doge-jest-na-100-portfelach/[]Walczymy o Mikołaja! - https://www.siepomaga.pl/krypto​[]Podsumowanie-------------------------Listy Twitter:Krypto-Naród: https://twitter.com/i/lists/1310182514137407502Krypto/blockchain Polska: https://twitter.com/i/lists/1320830727488000006KRYPTO-NARÓD POLSKA SPOŁECZNOŚĆ KRYPTOWALUT: https://krypto-narod.pl/Na tej stronie znajdziecie linki do wszystkich najlepszych, polskich twórców w tematyce kryptowalut i technologii blockchain.OFICJALNY SKLEP Z GADŻETAMI KANAŁU MIKE SATOSHI http://kryptonarod.store/ZOSTAŃ PATRONEM KANAŁU MIKE SATOSHI https://patronite.pl/mike-satoshi-----------------------------------------Jeżeli chciałbyś wesprzeć rozwój i działania kanału, możesz przekazać dotację: https://tipanddonation.com/mikesatoshi lub PayPal: paypal.me/mikesatoshi Portfele do dotacji krypto są tutaj: https://cryptokoks.wixsite.com/mikesatoshi/dotacje ----------------------------------------- Mój kanał na YouTube: https://www.youtube.com/channel/UCEX4iDKLfxtIJY6IVgMSqCQE-mail do kontaktu: cryptokoks@gmail.com Oficjalny Twitter: https://twitter.com/Mikey_Satoshi Kanał na DTube: https://d.tube/#!/c/mikesatoshi Grupa KryptoNaród na FB: https://www.facebook.com/groups/230649241027530/ Grupa KryptoNaród na Discord: https://discord.gg/CPTSa43 Airdropy i inne sposoby na darmowe kryptowaluty: https://darmowekrypto.org.pl -----------------------------------------

John Papa @John_PapaWard Bell @WardBellDan Wahlin @DanWahlinCraig Shoemaker @craigshoemakerSam Artioli @SamArtioliBrought to you byag-GridIdeaBladeResources:Start BootstrapNgrxRedux principles2011 Stackoverflow question on how much data is too muchBrowser storage limitsMax size of a redux storeLarge sets of data in react and reduxCan we store lots of data in redux?CRDTsCRDTs: The Hard Parts by Martin KleppmannOperational Transformation (OT)Debouncing explainedTimejumps02:09 Guest introduction03:24 What problem were you trying to solve?07:02 Do you download the entire project each time?14:48 What is CRDT?17:57 Sponsor: Ag Grid19:03 Breaking your browser22:34 Is it collaborative?25:59 The clone wars36:15 Sponsor: IdeaBlade37:20 Why put everything in a store?Podcast editing on this episode done by Chris Enns of Lemon Productions.

ТОП доклады по порядку: The race to Mach 2.0 at scale | Nickolas Means | #LeadDevAustin ( https://youtu.be/2sIzfGzf_50 ) Jamstack conf ( https://www.youtube.com/c/JAMstackConf/videos ) Try! Swift NYC 2019 - Building the Server-side Swift ecosystem ( https://youtu.be/CzTikweGO3E ) Spring: your next Java micro-framework - Alexey Nesterov ( https://youtu.be/Rvk_laat_-I ) Павел Черторогов — Революция в микрофронтендах, module federation, Webpack 5 ( https://youtu.be/pcY8-pDGLkI ) Keynote Interview with David Heinemeier Hansson ( https://youtu.be/OltCr8AWpWw ) Eliminating hero culture in software engineering teams - Brianna McCollough ( https://youtu.be/aLEqgnQM0Xc ) TSConf 2020: TalkScript with the TypeScript Team ( https://youtu.be/vBJF0cJ_3G0 ) Ashley Williams — Why the #wasmsummit Website isn't written in Wasm ( https://youtu.be/J5Rs9oG3FdI ) The ActivityPub ecosystem ( https://conf.tube/videos/watch/playlist/75b2fa34-a88a-4c89-969e-b63751c1d7d3?playlistPosition=8 ) CRDT #Backend, Антон Чапоргин, Редактор текста на CRDT в продакшене ( https://youtu.be/JLS8wusKC5s ) "Как подсидеть тимлида" / Егор Толстой (JetBrains) ( https://youtu.be/xL9zM09NDTk ) Картинки как коробки. Что же там внутри? - Полина Гуртовая ( https://youtu.be/CMlXUS6e46w ) Apollo GraphQL Federation ( https://youtu.be/lRI0HfXBAm8 ) A Look Into the Future by Roman Elizarov ( https://youtu.be/0FF19HJDqMo ) Нас можно найти: 1. Telegram: https://t.me/proConf 2. Youtube: https://www.youtube.com/c/proconf 3. SoundCloud: https://soundcloud.com/proconf 4. Itunes: https://podcasts.apple.com/by/podcast/podcast-proconf/id1455023466 5. Spotify: https://open.spotify.com/show/77BSWwGavfnMKGIg5TDnLz

В этом выпуске выпуске: Event Sourcing со всех сторон, проходим аудит разными способами, современный CRDT, Rust как единственный современный язык для embedded и, конечно, темы слушателей Шоу нотес: [00:05:18] «Change Data Capture» vs «Event Sourcing» [01:06:54] Коллаборативное редактирование на основе CRDT глазами соавтора Wave I was wrong. CRDTs are the future CRDTs: The Hard Parts —… Читать далее →

並列編集しても衝突しないデータ構造 CRDT に森田が入門します。

Today we talk about YJS. Yjs is a conflict-free replicated data type (CRDT) implementation that exposes its internal data structure as shared types. I know you are wondering what I'm talking about. Fabian Franz from Tag1 joins us to talk about the possibility of bringing Google Docs like collaborative edits to Drupal. www.talkingdrupal.com/264 Topics Stephen - no Post John - new light Nic - Less noise Fabian - Caching Lab was accepted for Drupal EU What isa YJS How is YJS being used today A Drupal implementation Secutiry risks Next step to Drupal Resources How does ranked-choice voring work? Alternate Voting Explained John's Light Stephen's No Post YJS on Github Hosts Stephen Cross - www.stephencross.com @stephencross John Picozzi - www.oomphinc.com @johnpicozzi Nic Laflin - www.nLighteneddevelopment.com @nicxvan Guest Fabian Franz  @fabianfranz   www.tag1.com  

Fredrik snackar Elixir med Lars Wikman. Elixir kombinerar ett kulturellt arv från Ruby och Rails med en solid teknisk grund från Erlang. Vad är det som lockar med Elixir, och behöver man kunna Erlang? Hur funkar det med felhantering, trådar, och processer? Vilken är den största vardagsnyttan med Elixir? Hur går Lars projekt att skriva webbgränssnitt som inte behöver Javascript? Och varför bygger Whatsapp en typad version av Erlang? Ett stort tack till Cloudnet som sponsrar vår VPS! Har du kommentarer, frågor eller tips? Vi är @kodsnack, @tobiashieta, @antikristoffer, och @bjoreman på Twitter, har en sida på Facebook och epostas på info@kodsnack.se om du vill skriva längre. Vi läser allt som skickas. Gillar du Kodsnack får du hemskt gärna recensera oss i iTunes! Du kan också stödja podden genom att ge oss en kaffe (eller två!) på Ko-fi. Länkar Lars Wikman Elixir Algonet Ruby Ruby on rails Erlang BEAM - Erlangs virtuella maskin Active record OTP - Open telecom platform Phoenix - webbramverk för Elixir Nerves - embeddedplattform för Elixir Lars blogginlägg om att det är trevligt med en runtime som kan göra mer än en sak i taget Funktionell programmering - den läskigaste grejen när man närmar sig Elixir Monader Erlang ecosystem foundation Mix - byggverktyg för Elixir Hex.pm - “NPM för Elixir och Erlang” Soft real time Metaprogrammering Makron i Elixir DSL - domänspecifikt språk Ecto Phoenix presence Eventual consistency CRDT - conflict-free replicated data type Phoenix liveview Websockets Membrane - mediaströmningsramverk för Elixir MJPEG Leka med statusen :checked I know what you :visited Let it crash Cowboy - webbservern under Phoenix The soul of Erlang and Elixir - Saša Jurić Actor-modellen Rekursion NIF - native implemented functions, lösning för att anropa C-kod Rustler - skriv NIFfar i Rust istället för C Django gen_server Arv Elixir mix Elixir outlaws Elixir wizards Thinking Elixir Elixirtalk Lumen-projektet - kompilerar Erlang och Elixir till Webassembly Webassembly Dockyard Rabbitmq Whatsapp bygger typad Erlang Visual studio code Elixir LS Dialyzer - statiskt analysverktyg för Erlang Lars är @lawik på Twitter underjord.io - Lars webbplats Titlar Lättpocket i HTML från Algonet Socialt och kulturellt arv från Ruby och Ruby on rails Tekniskt arv från Erlang Distribuerade slagtåliga system Bränt barn söker sig till nytt språk Pragmatisk funktionell programmering Som att skriva ful-SQL Allt det där huvudvärksarbetet Ett verktyg för att slippa skriva Javascript Inte perfekt för latency Felhantera i varenda löv i hela trädet Larma den som har driftansvar idag En pool billiga BEAM-processer En oändlig loop kan vara helt rätt Det potenitella taket för hur bra man kan bygga system är väldigt högt Väldigt pragmatisk funktionell programmering Om du vill göra fel får du jobba lite för det

I saw Martin Kleppmann's talk a few weeks ago about CRDTs, and I felt a deep sense of despair. Maybe all the work I've been doing for the past decade ... https://josephg.com/blog/crdts-are-the-future/ Martin Kleppmann’s talkJupiter paperShareJSglorified for() loopsome helper functionsoptimized CFirepadShareDBa schemeI gave a talkBenchmarks - look for B4handles this fineMartin’s talk54 minutes into his talkimplementation of automerge in only about 100 lines of codesimple proof of concept CRDT implementation in Rust6 million edits per seconditerationY.jsin the Y.js benchmarksfinanced by advertisers bidding for my eyeballslocal first softwareoperationaltransformcodeAnd that matters.

Wszystkie dobre podcasty o kryptowalutach https://darmowekrypto.org.pl/podcasty-----------------------------------------Krypto Newsy #233 | 05.08.2020 | Testnet Ethereum 2.0 ruszył, Bitcoin po $400k w 2021? Nowa wersja Lighting Network, Ripple XRPRuszył ostateczny testnet Ethereum 2.0. Jeżeli wszystko pójdzie dobrze, to faza 0 Ethereum 2.0 powinna pojawić się już niedługo. Czyżby powoli zbliżał się ten wielki dzień? Cena Ethereum rośnie.Bitcoin osiągnie ponad $400k pod koniec 2021 roku. Taką prognozę wygłosił Pompliano z Morgan Creek Digital. Wierzycie mu? Trzymacie kciuki? A przy okazji wyszła nowa wersja Lighting Network. Firma Ripple chce mocno promować XRP i uczynić ekosystem XRP królem finansów. Xpring zapewnił finansowanie XRPL Labs na kolejne dwa lata. Czyżby cena XRP miała zaraz polecić to the moon.Zapraszam na środowe Krypto-Newsy, czyli wiadomości ze świata kryptowalut, a także wydarzenia, analizę rynku i przegląd Twitter. Trzymamy też kciuki za zdrowie Kamila z kanału @Encyklopedia Kryptowalut, który idzie na operację i będzie miał przerwę od nagrywania. Oby szybko wrócił do zdrowia! W dzisiejszym odcinku:[]Wstęp[]ETH futures z ATH - https://news.bitcoin.com/crypto-derivatives-set-new-records-eth-futures-set-all-time-highs-cme-open-interest-spikes/[]VeChain i makarony - https://www.newsbtc.com/2020/08/05/pasta-producer-de-cecco-adopts-vechain-my-care-framework/[]Amerykański Kongres, IRS i PoS - https://beincrypto.com/congress-asks-the-irs-to-create-policy-protecting-proof-of-stake/[]Coinbase wprowadza Unstoppable Domains - https://cointelegraph.com/news/coinbase-follows-huobi-in-supporting-crypto-domains-based-payments[]17-latek twierdzi, że jest niewinny - https://cointelegraph.com/news/17-yea...[]Czy zbliża się kolejny krypto-ban w Indiach? - https://cointelegraph.com/news/indian...[]Aktualizacja Lighting Network - https://www.coindesk.com/rat-poison-s...[]CRDT i karta płatnicza - https://cryptodaily.co.uk/2020/08/crd...[]Ripple ujawnia nową inwestycję XRP - https://dailyhodl.com/2020/08/05/ripp...[]Bitcoin będzie po $400k – Morgan Creek Digital - https://dailyhodl.com/2020/08/05/here...[]Nowy scam - https://en.cryptonomist.ch/2020/08/05...[]Uruchomione testnet Ethereum 2.0 - https://bitcoinpl.org/uruchomiono-testnet-ethereum-2-0-medalla/[]Bitcoin i darknet: dealerzy narkotyków staną przed sądem w Niemczech - https://comparic.pl/bitcoin-i-darknet-dealerzy-narkotykow-stana-dzis-przed-sadem-w-niemczech/[]Co tam w Crypto.com? - https://blog.crypto.com/twitter-200k-giveaway/[]Nadchodzące wydarzenia[]Co tam w krypto ćwierka?[]Analiza bieżącej sytuacji na rynku[]Kilka słów na koniec -----------------------------------------OFICJALNY SKLEP Z GADŻETAMI KANAŁU MIKE SATOSHI http://kryptonarod.store/ZOSTAŃ PATRONEM KANAŁU MIKE SATOSHI https://patronite.pl/mike-satoshi-----------------------------------------Jeżeli chciałbyś wesprzeć rozwój i działania kanału, możesz przekazać dotację: https://tipanddonation.com/mikesatoshi lub PayPal: paypal.me/mikesatoshi Portfele do dotacji krypto są tutaj: https://cryptokoks.wixsite.com/mikesatoshi/dotacje ----------------------------------------- Mój kanał na YouTube: https://www.youtube.com/channel/UCEX4iDKLfxtIJY6IVgMSqCQE-mail do kontaktu: cryptokoks@gmail.com Oficjalny Twitter: https://twitter.com/Mikey_Satoshi Kanał na DTube: https://d.tube/#!/c/mikesatoshi Grupa KryptoNaród na FB: https://www.facebook.com/groups/230649241027530/ Grupa KryptoNaród na Discord: https://discord.gg/CPTSa43 Airdropy i inne sposoby na darmowe kryptowaluty: https://darmowekrypto.org.pl -----------------------------------------

In this episode of React Round Up, Carson Farmer joins us to talk about the decentralized web. We discuss what the decentralized web actually is, and some interesting new way the web could work. Panel Paige Niedringhaus TJ VanToll Guest Carson Farmer Sponsors G2i | Enjoy the luxuries of freelancing React Native Remote Conf 2020 Links IPFS Textile CRDT ThreadDB Carson’s “Bring Your Own Data” talk Filecoin Picks Carson Farmer: Follow Carson on Twitter > @carsonfarmer Let my People go surfing IPFS: interplanetary file system on Reddit   TJ VanToll: Recoil David McCabe’s talk about Recoil at React Europe Paige Niedringhaus: Killing Eve Follow React Round Up on Twitter > @reactroundup

In this episode of React Round Up, Carson Farmer joins us to talk about the decentralized web. We discuss what the decentralized web actually is, and some interesting new way the web could work. Panel Paige Niedringhaus TJ VanToll Guest Carson Farmer Sponsors G2i | Enjoy the luxuries of freelancing React Native Remote Conf 2020 Links IPFS Textile CRDT ThreadDB Carson’s “Bring Your Own Data” talk Filecoin Picks Carson Farmer: Follow Carson on Twitter > @carsonfarmer Let my People go surfing IPFS: interplanetary file system on Reddit   TJ VanToll: Recoil David McCabe’s talk about Recoil at React Europe Paige Niedringhaus: Killing Eve Follow React Round Up on Twitter > @reactroundup

Добрый день уважаемые слушатели. В гостях RWpod Cafe сегодня Andrey Sitnik: Logux Firebase Y.js Automerge Сторибук Амплифера со страницами UIbook Local-first software Визуализация редактирования текста в CRDT Как мы сделали сайт Логакса без Реакта Страницы Сайт Github Facebook Twitter

Today on The InfoQ Podcast, Wes Reisz talks with Peter Bourgon. Peter is a distributed system engineer working on Fastly. His area of interest is around coordination free replicated systems. The two engineers talk about the space of Conflict-Free Replicated Data Types (CRDTs) specifically in the context of edge compute. Topics covered on the podcast include Edge compute, CRDTs, CAP Theorem, and challenges around building distributed systems. Why listen to this podcast: - CRDTs (conflict-free replicated data types) are a class of coordination free replication systems (or systems that don’t require strategies such as leader election). - An easy way to think of a CRDT is as an associative, commutative, and idempotent data structure plus the operations needed to use it. The edge is an overloaded term that people tend to define based on where they sit on a spectrum between the customer and the data center. Fastly’s edge is away from the data center and but not to the telephone pole or handset. - RAFT and Gossip are two alternative approaches to using a coordination free replication system like CRDTs. To get the properties of a CRDT and have useful data types, you have to pay a cost in size and often bytes on the wire. These are challenges that continue to need solutions. - Modern Distributed systems and data structures like CRDTs require you to start thinking about state in the system itself. It’s not unusual for a system today to give you multiple results back that the system will have to handle or merge. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/3dTZOO4 You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/3dTZOO4

203 Яндекс.Коннект и группа сервисов — The Art Of Programming [ Service ] Поглощение сервисов Служба мониторинга Миграция в монорепозиторий Инженерные практики Яндекс.Коннект Code Review at Cisco Systems Некоторые выступления: Редактор текста на CRDT в продакшене Изменение схемы таблиц без долгих блокировок в PostgreSQL UWSGI в помощь метрикам Свежие вакансии: Бекенд-разработчик коллаборативных сервисов Разработчик в Коннект Участники @golodnyj Антон Чапоргин Благодарности патронам: Aleksandr Kiriushin, Alex Malikov, Fedor Rusak, Grigori Pivovar, Lagunovsky Ivan, Leo Kapanen, Mikhail Gaidamaka, Neikist, nikaburu, Pavel Drabushevich, Pavel Sitnikov, Sergey Kiselev, Sergey Vinyarsky, Sergii Zhuk, Vasiliy Galkin Telegram канал Поддержи подкаст Подпишись в iTunes Подпишись без iTunes Скачай подкаст Старые выпуски

В этом выпуске: разбираемся зачем нужны soft skills; что делать если хочется просто фигачить и как выжить в беспощадном мире корпоративной политики; учимся давать фидбек и познаём тонкости саморазвития; готовим CRDT правильно и материализуем вьюхи с ksqlDB; радуемся выходу новой игры во вселенной Half Life и грустим по судьбе домена .org Шоу нотес: [00:05:18] Интервью… Читать далее →

What is real-time collaborative editing, and what are some of the most compelling technologies available in the space? In the inaugural TAG Team Talk, hosted by Preston So (Contributing Editor, Tag1 Consulting), we conduct a wide-ranging discussion about both the business prerogatives and technical ins-and-outs of real-time collaborative editing and its landscape today, with our guests Kevin Jahns (creator of Yjs and collaborative editing expert at Tag1 Consulting), Fabian Franz (Senior Technical Architect and Performance Lead, Tag1 Consulting), and Michael Meyers (Managing Director, Tag1 Consulting). In this talk, we explore collaborative editing, diving into how it works and some of the challenges borne by shared editing. Through the lens of Yjs, a real-time collaboration framework that supports not just text but also collaborating on drawings and 3-D models, we take a look at Operational Transformation (OT) and how implementing Conflict-free Replicated Data Types (CRDT) drives decentralized server approaches in collaborative editing and supports more robust distributed applications with true real-time support. Yjs:  https://github.com/yjs/yjs (https://github.com/yjs/yjs) ProseMirror:  https://prosemirror.net (https://prosemirror.net/) Great Overview of CRDT https://conclave-team.github.io/conclave-site/#conflict-free-replicated-data-type-crdt (https://conclave-team.github.io/conclave-site/#conflict-free-replicated-data-type-crdt) Deep dive int CRDT by the author of Automerge:  https://www.youtube.com/watch?v=yCcWpzY8dIA (https://www.youtube.com/watch?v=yCcWpzY8dIA) Yjs was inspired by: Sharedb  https://github.com/share/sharedb (https://github.com/share/sharedb) DerbyJS  https://derbyjs.com/ (https://derby.js/)

Episode Summary   In this week’s episode of Elixir Mix the panel follows up with Wiebe-Marten ("Marten") Wijnja about his talk at Elixir Conf EU, where he spoke about the distributed system his team was working on.    They start by discussing the eight fallacies of distributed computing that Marten talked about in talk. He lays out a couple of the fallacies and invites listeners to watch his talk for all eight. Marten explains that these fallacies most commonly happen to developers who are used to working with a single system. The panel discusses how to be mindful of these mistakes and how developers take for granted of how easy one system is to use.    Marten gives some tool recommendations to help with these fallacies. TLA+ is a small programming language that lets the developer describe their system and it will point out when something is wrong but it works purely on concepts. Erlang quick check implementation is also a tool that will help combat these problems. The last suggestion which was given by the panel is a library called comcast on github that will simulate poor network connections so the developer can see how the system runs on a poor connection.    Marten describes the byzantine problem. Two nodes or generals are trying to agree on something but communication keeps failing. The various outcomes are considered and Mark Ericksen gives an additional example of he and Josh Adams trying to connect to record a podcast, and how the miscommunication could change the outcome. This is a big problem that complicates using a distributed system.    The panel discussed CRDT’s and how they are a better way for nodes to sync up. Marten gives a very simple example of a CRDT as a counter. The panel discusses when to use CRDT’s and when not too. Marten explains what questions to ask before using CRDT’s.    Another way of solving the byzantine problem is by connecting the nodes. The panel discusses the tools they use to connect their nodes. Partisan is one tool, instead of connecting all nodes, each node connects to a specific number of nodes. That way if one node goes down the whole system doesn’t stop, while at the same time not, overwhelming the nodes. Libcluster, another tool, uses Kubernetes and has multiple strategies for connecting nodes so developers can choose the right one for their system.     The panel asks Marten about multicall and abcast. Marten explains that these tools help one node talk to all the other nodes in a cluster, and multicall will gather the results. Multicall also tells the developer which nodes failed to respond to the request. Mark shares an example of using these tools to effectively communicate between gen servers.    In Marten’s talk, he described four distributed databases. The panel asks Marten to talk about each one of them. The first one is mnesia. Marten talks about his first experience with Mnesia and how he thought it was amazing. He soon realized while it is still a great tool it also has its quirks.    He explains that each of these databases has its own quirks. Mnesia doesn't do conflict resolution, that along with a few other things the developer will need to build themselves. This can be a good and bad thing because developers can customize the database to their needs but it’s not ready out of the box. Mark explains the use cases mnesia is good for and even references the mnesia documentation.     Cassandra is the next database Marten describes. Cassandra is the database discord uses. Cassandra does not let developers control their own conflict resolution. It always uses the latest time-stamp and with nodes that can be confusing.    Couchdb is another database they discuss. Again, couchdb is also not made to deal with conflicts. It will either solve them randomly or the developer can opt into resolving it themselves. The panel discusses times when this is useful, such as when connectivity is intermittent.    Riak is the final database and the one Marten’s team chose for their distributed system project. Riak was written in Erlang and is a key-value store and uses CRDT’s. It uses a CRDT conflict resolution. Marten shares his experience using Riak. The panel considers Riak’s history and need for some love.     Marten gives an update on planga, the chat application they were building the distributed system for. Marten explains that during the talk they were in the middle of development. He shares the story of why they wanted a distributed system for this chat application. The client they were doing it for wanted to do video streaming but pulled out in the end. When the client no longer needed the video streaming solution they stopped building the distributed system. Marten is still hopeful they will go back and finish it.    To end the episode Marten shares his programming journey. He started programming at age nine. At age 12 he started doing professional web development. After a few years of that, he started doing some frontend work in JavaScript. Once that got old, bitcoin was getting big so he and some friends got into that. Finally, he got a job doing backend work with Ruby while at university. When he heard about Elixir he was so excited he learned the basics in one weekend and has loved it ever since.  Panelists Mark Ericksen Josh Adams Guest Wiebe-Marten ("Marten") Wijnja Sponsors   Sentry– use the code “devchat” for two months free on Sentry’s small plan Adventures in DevOps My Ruby Story CacheFly Links Wiebe Marten Wijnja - An adventure in distributed programming - ElixirConf EU 2019 https://elixirforum.com/  https://lamport.azurewebsites.net/tla/tla.html  http://www.quviq.com/products/erlang-quickcheck/  https://github.com/tylertreat/Comcast  https://en.wikipedia.org/wiki/Byzantine_fault#Byzantine_Generals'_Problem  https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type  https://github.com/bitwalker/libcluster  http://partisan.cloud/  http://erlang.org/doc/man/mnesia.html  https://learnyousomeerlang.com/mnesia  How Discord Stores Billions of Messages  https://pouchdb.com/  https://planga.io/  https://riak.com/  https://github.com/basho/riak_core  https://riak.com/where-to-start-with-riak-core/  Using Erlang, Riak and the ORSWOT CRDT at bet365 (...) - Michael Owen - Erlang User Conference 2015  https://hex.pm/packages/effects  https://github.com/graninas/automatic-whitebox-testing-showcase  https://github.com/Qqwy/elixir-riak_ecto3 https://hex.pm/packages/sea  https://twitter.com/WiebeMarten  https://github.com/qqwy/  https://wmcode.nl  https://www.facebook.com/Elixir-Mix  https://twitter.com/elixir_mix Picks Mark Ericksen: ElixirConf YouTube Channel  Josh Adams: Automatic White-Box Testing with Free Monads  Wiebe-Marten ("Marten") Wijnja: https://propertesting.com/  https://globalgamejam.org/ https://polyphasic.net/

Episode Summary   In this week’s episode of Elixir Mix the panel follows up with Wiebe-Marten ("Marten") Wijnja about his talk at Elixir Conf EU, where he spoke about the distributed system his team was working on.    They start by discussing the eight fallacies of distributed computing that Marten talked about in talk. He lays out a couple of the fallacies and invites listeners to watch his talk for all eight. Marten explains that these fallacies most commonly happen to developers who are used to working with a single system. The panel discusses how to be mindful of these mistakes and how developers take for granted of how easy one system is to use.    Marten gives some tool recommendations to help with these fallacies. TLA+ is a small programming language that lets the developer describe their system and it will point out when something is wrong but it works purely on concepts. Erlang quick check implementation is also a tool that will help combat these problems. The last suggestion which was given by the panel is a library called comcast on github that will simulate poor network connections so the developer can see how the system runs on a poor connection.    Marten describes the byzantine problem. Two nodes or generals are trying to agree on something but communication keeps failing. The various outcomes are considered and Mark Ericksen gives an additional example of he and Josh Adams trying to connect to record a podcast, and how the miscommunication could change the outcome. This is a big problem that complicates using a distributed system.    The panel discussed CRDT’s and how they are a better way for nodes to sync up. Marten gives a very simple example of a CRDT as a counter. The panel discusses when to use CRDT’s and when not too. Marten explains what questions to ask before using CRDT’s.    Another way of solving the byzantine problem is by connecting the nodes. The panel discusses the tools they use to connect their nodes. Partisan is one tool, instead of connecting all nodes, each node connects to a specific number of nodes. That way if one node goes down the whole system doesn’t stop, while at the same time not, overwhelming the nodes. Libcluster, another tool, uses Kubernetes and has multiple strategies for connecting nodes so developers can choose the right one for their system.     The panel asks Marten about multicall and abcast. Marten explains that these tools help one node talk to all the other nodes in a cluster, and multicall will gather the results. Multicall also tells the developer which nodes failed to respond to the request. Mark shares an example of using these tools to effectively communicate between gen servers.    In Marten’s talk, he described four distributed databases. The panel asks Marten to talk about each one of them. The first one is mnesia. Marten talks about his first experience with Mnesia and how he thought it was amazing. He soon realized while it is still a great tool it also has its quirks.    He explains that each of these databases has its own quirks. Mnesia doesn't do conflict resolution, that along with a few other things the developer will need to build themselves. This can be a good and bad thing because developers can customize the database to their needs but it’s not ready out of the box. Mark explains the use cases mnesia is good for and even references the mnesia documentation.     Cassandra is the next database Marten describes. Cassandra is the database discord uses. Cassandra does not let developers control their own conflict resolution. It always uses the latest time-stamp and with nodes that can be confusing.    Couchdb is another database they discuss. Again, couchdb is also not made to deal with conflicts. It will either solve them randomly or the developer can opt into resolving it themselves. The panel discusses times when this is useful, such as when connectivity is intermittent.    Riak is the final database and the one Marten’s team chose for their distributed system project. Riak was written in Erlang and is a key-value store and uses CRDT’s. It uses a CRDT conflict resolution. Marten shares his experience using Riak. The panel considers Riak’s history and need for some love.     Marten gives an update on planga, the chat application they were building the distributed system for. Marten explains that during the talk they were in the middle of development. He shares the story of why they wanted a distributed system for this chat application. The client they were doing it for wanted to do video streaming but pulled out in the end. When the client no longer needed the video streaming solution they stopped building the distributed system. Marten is still hopeful they will go back and finish it.    To end the episode Marten shares his programming journey. He started programming at age nine. At age 12 he started doing professional web development. After a few years of that, he started doing some frontend work in JavaScript. Once that got old, bitcoin was getting big so he and some friends got into that. Finally, he got a job doing backend work with Ruby while at university. When he heard about Elixir he was so excited he learned the basics in one weekend and has loved it ever since.  Panelists Mark Ericksen Josh Adams Guest Wiebe-Marten ("Marten") Wijnja Sponsors   Sentry– use the code “devchat” for two months free on Sentry’s small plan Adventures in DevOps My Ruby Story CacheFly Links Wiebe Marten Wijnja - An adventure in distributed programming - ElixirConf EU 2019 https://elixirforum.com/  https://lamport.azurewebsites.net/tla/tla.html  http://www.quviq.com/products/erlang-quickcheck/  https://github.com/tylertreat/Comcast  https://en.wikipedia.org/wiki/Byzantine_fault#Byzantine_Generals'_Problem  https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type  https://github.com/bitwalker/libcluster  http://partisan.cloud/  http://erlang.org/doc/man/mnesia.html  https://learnyousomeerlang.com/mnesia  How Discord Stores Billions of Messages  https://pouchdb.com/  https://planga.io/  https://riak.com/  https://github.com/basho/riak_core  https://riak.com/where-to-start-with-riak-core/  Using Erlang, Riak and the ORSWOT CRDT at bet365 (...) - Michael Owen - Erlang User Conference 2015  https://hex.pm/packages/effects  https://github.com/graninas/automatic-whitebox-testing-showcase  https://github.com/Qqwy/elixir-riak_ecto3 https://hex.pm/packages/sea  https://twitter.com/WiebeMarten  https://github.com/qqwy/  https://wmcode.nl  https://www.facebook.com/Elixir-Mix  https://twitter.com/elixir_mix Picks Mark Ericksen: ElixirConf YouTube Channel  Josh Adams: Automatic White-Box Testing with Free Monads  Wiebe-Marten ("Marten") Wijnja: https://propertesting.com/  https://globalgamejam.org/ https://polyphasic.net/

Phil’s guest on this episode of the IT Career Energizer podcast is Aslak Hellesoy. Aslak is the creator of Cucumber and co-founder of Cucumber Limited.  He is a co-author of The Cucumber Book and was an early adopter of XP and BDD.   He has worked as a programmer, software architect, business owner and trainer in a variety of industries including finance, telecom and retail.   In this episode Phil and Aslak discuss his involvement in the test-driven way of working and how Cucumber came about. He explains how his Open Source projects played a role in the company’s formation and how his career has benefited from this way of getting things done.   Aslak demonstrates why learning functional programming languages is now a good idea. They also discuss the merits of CRDT and functional programming languages.   KEY TAKEAWAYS: (8.50) TOP CAREER TIP Get involved in Open Source. Doing that has played a big role in Aslak’s career success. It is an effective way to learn new tech, have fun, expand your network and make a difference.   Aslak also recommends taking on speaking engagements. In the podcast, he explains how he got started and how you can do the same.   (12.05) WORST CAREER MOMENT Many years ago, Aslak found himself working on a big finance project. From the start, the team knew the deadline was impossible to meet. But, the project manager ignored this fact and did not make the customer aware of this issue. Despite everyone working long hours, the deadline was missed. It was a very de-motivating and stressful experience.   Bert saw firsthand the damage a lack of transparency and trust could do. That incident sparked his interest in behaviour-driven development (BDD). He could see that working collaboratively was a far better approach.   (14.27) CAREER HIGHLIGHT Selling the company he had built up with his team over the course of 5 years is Aslak’s career highlight. Aslak is looking forward to having more time to dedicate to Open Source work while still being involved in evolving Cucumber. It has also enabled him to get back to being able to code all day.   (16.05) THE FUTURE OF CAREERS IN I.T Aslak is a little concerned about where the latest tech is going to take us as a society. A lot of good things are going to come out of AI. But, AI and other new techs are still very much open to abuse by governments and organizations.   More optimistically, Aslak points out that a career in tech still offers excellent job security, particularly for software developers. A situation that is not likely to change anytime soon.   (17.50) THE REVEAL What first attracted you to a career in I.T.? – Aslak ended up pursuing an IT career by accident. Only when he understood the power of the World Wide Web did his desire to work in tech really take hold. What’s the best career advice you received? – Get a mentor, someone who is prepared to spend time with you. What would you do if you started your career now? – Aslak would learn functional programming rather than procedural programming. What are your current career objectives? – Aslak is looking forward to having a full-time team working on Cucumber. There are a lot of exciting features he wants to see added. What’s your number one non-technical skill? – Listening to other people. How do you keep your own career energized? – Learning new techniques, languages, frameworks, databases and platforms. What do you do away from technology? – Aslak has two young daughters and enjoys cooking and playing five-a-side football.   (23.15) FINAL CAREER TIP Have lunch with a colleague you do not know well, preferably, someone who is doing something different from you. This will help you to understand the business you are working in far more. That will make you a far better developer.   BEST MOMENTS (9.22) – Aslak - “Working on Open Source projects is a great way to learn new technologies.”  (16.51) – Aslak - “Being a software developer is going to be a pretty safe job choice.” (19.16) – Aslak - “Get yourself a mentor. No matter where you are in your career a mentor will help.” (20.08) – Aslak - “Learn functional programming languages, you can get more done with them.” (21.32) – Aslak - “Listen to others and ask the right questions.” (23.15) – Aslak - “Get to know people from all areas of the business it will make you a better programmer.”     ABOUT THE HOST – PHIL BURGESS Phil Burgess is an independent IT consultant who has spent the last 20 years helping organisations to design, develop and implement software solutions.  Phil has always had an interest in helping others to develop and advance their careers.  And in 2017 Phil started the I.T. Career Energizer podcast to try to help as many people as possible to learn from the career advice and experiences of those that have been, and still are, on that same career journey.   CONTACT THE HOST – PHIL BURGESS Phil can be contacted through the following Social Media platforms:   Twitter: https://twitter.com/philtechcareer LinkedIn: https://uk.linkedin.com/in/philburgess Facebook: https://facebook.com/philtechcareer Instagram: https://instagram.com/philtechcareer Website: https://itcareerenergizer.com/contact   Phil is also reachable by email at phil@itcareerenergizer.com and via the podcast’s website, https://itcareerenergizer.com Join the I.T. Career Energizer Community on Facebook - https://www.facebook.com/groups/ITCareerEnergizer   ABOUT THE GUEST – Aslak Hellesoy Aslak Hellesoy is the creator of Cucumber and co-founder of Cucumber Limited.  He is a co-author of The Cucumber Book and was an early adopter of XP and BDD.   He has worked as a programmer, software architect, business owner and trainer in a variety of industries including finance, telecom and retail.     CONTACT THE GUEST – Aslak Hellesoy Aslak Hellesoy can be contacted through the following Social Media platforms:   Twitter: https://twitter.com/aslak_hellesoy LinkedIn: https://www.linkedin.com/in/aslak/ Website: https://aslakhellesoy.com/  

Наконец технический выпуск, да еще и заманили сразу двух гостей: Александра Сычева и Евгения Камышанова! Говорим о кэшировании данных, а также как жить в условиях распределенных систем. Сложное простыми словами, да еще и в уши, все как вы любите! Словарные слова выпуска: CQRS, CRDT. Содержание: 00:00:50 - Знакомство с гостями 00:02:18 - Проблематика 00:06:55 - Про актеров 00:09:30 - CAP-теорема 00:19:00 - CQR-принцип 00:26:07 - CQRS 00:40:20 - Решения из коробки 00:46:30 - Что почитать? 00:47:54 - Проблематика случая с множеством узлов 00:58:02 - CRDT 01:02:32 - Примеры из реального мира 01:04:30 - Типы CRDT 01:08:38 - Конфликты все равно останутся >.< 01:12:56 - Реальные примеры, ч.2 01:15:50 - Подводим черту Полезные ссылки: CQRS: https://habr.com/post/272987/ https://stanfy.com/blog/do-not-let-your-user-see-spinners/ https://mwhittaker.github.io/blog/an_illustrated_proof_of_the_cap_theorem/ и http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.67.6951&rep=rep1&type=pdf https://skillsmatter.com/skillscasts/1980-cqrs-not-just-for-server-systems https://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf https://jaysoo.ca/2015/02/06/what-the-flux/ https://github.com/reduxjs/redux/issues/351 CRDT: https://dl.acm.org/citation.cfm?doid=67544.66963 http://hal.upmc.fr/inria-00555588/document https://github.com/archagon/crdt-playground https://github.com/gritzko/swarm

We venture out into Python country only to discover a healthy, diverse and growing community. This episode is brought to you by OfferZen, a South African recruitment startup for developers. OfferZen inverts the normal recruitment process. Instead of applying for jobs, 350 tech companies in Cape Town, Johannesburg and Pretoria, send developers interview requests with upfront salary info. For developers it’s completely free to signup and use. In fact, you get R5000 if you take a job through them. Visit offerzen.com to sign up. Chantal, Kenneth & Kevin are joined by Simon Cross, Neil Muller and David Sharpe to talk about the popular PyCon ZA conference and the local Python community in general. Together this experienced, yet humble trio organize PyCon and are involved in various other local Python communities. Simon has a decade of Python under his belt, worked on the Square Kilometer Array and is currently based at Praekelt. Neil is the organizer of the Cape Town Python User Group (CTPUG) and works on medical image processing systems. David started off as an electrical engineer and embedded C programmer and has since "crossed over to the dark side" (his words) as he started using Python more and more. Despite the technical difficulties of recording this show, it is packed with amazing content and well worth your time. Follow Simon online: * https://twitter.com/hodgestar * http://hodgestar.za.net * https://github.com/hodgestar Follow Neil online: * https://github.com/drnlm Follow PyCon ZA online: * https://za.pycon.org/ * https://twitter.com/pyconza Here are some of the other great community projects listed in the show: * Cape Town Python User Group - https://ctpug.org.za/ * Gauteng Python User Group - https://www.meetup.com/Gauteng-Python-Users-Group/ * Software Carpentry - https://software-carpentry.org/ * Django Girls - https://djangogirls.org/ And finally our picks Kevin: * 144Hz monitors for gaming * Ubuntu Desktop Linux - http://www.ubuntu.com Chantal: * TYCHO - http://tychomusic.com/ Kenneth: * The Hundred-Foot Journey - http://www.imdb.com/title/tt2980648/ * FOKOFPOLISIEKAR - http://www.fokofpolisiekar.co.za/ * Rokoff CD+DVD * MK Hoordosis Simon: * Conflict-free Replicated Data Type, or CRDT - https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type Simon & Neil: * Sphinx documentation - http://www.sphinx-doc.org/ * Read the Docs - https://readthedocs.org/ David: * Radiooooo - http://radiooooo.com/ Thanks for listening! Stay in touch: * Website & newsletter - https://zadevchat.io * Socialize - https://twitter.com/zadevchat & http://facebook.com/ZADevChat/ * Suggestions and feedback - https://github.com/zadevchat/ping * Subscribe and rate in iTunes - http://bit.ly/zadevchat-itunes

Новости Scala Fiddle Scala 2.12 RC SIP-NN Inline/meta Блоги Li Haoyi: Easy Parsing with Parser Combinators Темы Scala для бизнеса. В чем профит? Как продемонстрировать профит основателям Удаленная работа. За и против Полезняшки: The Type Astronaut's Guide to Shapeless Scala Starter Kit Scala Exercises is an Open Source project for learning different technologies based in the Scala Longevity - A Persistence Framework for Scala and NoSQL A conflict-free replicated JSON datatype (CRDT) in Scala Прочее scastie.org Zalando Tech Radar https://habrahabr.ru/post/127727/ http://codeforces.com/ Ведущие: Алексей Фомкин, Вадим Челышов Евгений Токарев

Новости Статья о GIL и продолжение Документация в Dictionary Библиотека для C Cello Еще один парсер командной строки Пэт про Hash.fetch и счастье Предпросмотр мейлов как Rails Engine Статья про Gem Protector Обсуждение DevConf — в поиске затерянных презентаций Jepsen — проверка разных СХД на разрыв сети CRDT — Commutative Replicated Data Type

Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: And I feel like this idea of really changes the abstractions that operating systems should provide because maybe OSs should not just be providing this model of files as a sequence of bytes, but this higher level CRDT like model and how does that impact the entire way how software is developed. 00:00:23 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad. This podcast isn’t about Muse the product, it’s about Muse the company and the small team behind it. I’m Adam Wiggins here with my colleague Mark McGranaghan. Hey, Adam, and joined today by Martin Klutman from the University of Cambridge. Hello. And we talked before about Mark’s dabbling in playing the piano. I understand this is a hobby you’re starting to look into as well, Martin. 00:00:49 - Speaker 1: Oh yes, I’ve been playing the piano, like trying to do it a bit more consistently for the last year and a half or so. My lockdown projects. 00:00:57 - Speaker 2: And do you have a technique for not annoying your neighbors, or is this an electronic piano, or how do you do that? 00:01:03 - Speaker 1: It’s an electric piano, although I don’t think it’s too bad for the neighbors. Lately I’ve been trying to learn a WBC 400 piece that I can play together with my wife, so she’ll play two hands and I’ll play the other two. 00:01:15 - Speaker 2: Nice. I suspect a lot of our listeners know you already, Martin. I think you’re within your small, narrow niche, you’re a pretty high profile guy, but for those that don’t, it’d be great to hear a little bit about your background. What brought you on the journey to the topic we’re gonna talk about today? 00:01:31 - Speaker 1: Yeah, well, I’m a computer scientist, I guess. I started out as an entrepreneur and started two startups some years ago. I ended up at LinkedIn through the acquisition of the 2nd startup. And they worked on large scale stream processing with Apache Kafka and was part of that sort of stream processing world for a while. And then I wanted to share what I had learned about building large scale distributed data systems. And so I then took some time out to write a book which is called Designing Data Intensive Applications, which has turned out to be surprisingly popular. 00:02:10 - Speaker 2: Yeah, you wrote a nice kind of tell-all, you showed the numbers on it, which it’s been financially successful for you, but also one of the more popular O’Reilly books just by kind of copy sold in recent times. I like that post, like the candor there, but yeah, it makes you a pretty successful author, right? 00:02:28 - Speaker 1: Yeah, it’s sold over 100,000 copies, which is, wow, way more than what I was expecting for something that it’s a pretty technical, pretty niche book, really. But the goal of the book really is to help people figure out what sort of storage technologies and data processing technologies are appropriate for their particular use case. So it’s a lot about the trade-offs and the pros and cons of different types of systems. And there’s not a whole lot on that sort of thing out there, you know, there’s a lot of sort of vendor talk hyping the capabilities of their particular database or whatever it might be, but not so much on this comparison between different approaches. So that’s what my book tries to provide. Yeah, and then after writing that book, I sort of slipped into academia, sort of half by accident, half by design. So I then found a job at the University of Cambridge where I could do research full time. And since then I’ve been working on what we have come to call the first software, which we’re going to talk about today. The nice thing there is that now then academia compared to the startup world, I have the freedom to work on really long term ideas, big ideas which might take 5 or 10 years until they turn into like viable technologies that might be used in everyday software development. But if they do work, they’ll be really impactful and really important and so I’m enjoying that freedom to work on really long term things now as an academic. 00:03:53 - Speaker 2: And certainly it struck me when we got the chance to work together through these Ink & Switch projects that because you have both the commercial world, including startup founder, but obviously you’re very immersed in the academic kind of machinery now and again just that long-term mindset and thinking about creating public goods and all that sort of thing. And I found that I actually really like now working with people that have both of those. Another great example there would be another former podcast guest Jeffrey Litt. He was also in the startup world, now he’s doing academic work at MIT. 00:04:26 - Speaker 1: Yes, and I’m actually doing a project with him right now, right, I forgot about that. 00:04:29 - Speaker 2: There’s a current Ink & Switch project there. So I find that maybe if you live your whole life in one of those two kind of commercial slash industry or academia, you get like a fish doesn’t know what water is kind of thing, but if you have experienced both models, then it’s easier to know the pros and cons and understand the shape of the venue you’re doing your work in in the end. The point is to have some meaningful impact on humanity through your work, whatever small piece of the world you hope you’re making better. In our case, it’s computer things, but that the venue you’re in is not the point, that’s just a vehicle for getting to where you want to go, and each of these styles of venue have different trade-offs, and being aware of those maybe makes it easier to have your work have an impact. 00:05:19 - Speaker 1: Yes, I think it is really helpful to have seen both sides and I find it allows me to be a little bit more detached from the common mindset that you get like in every domain you get, you know, there are certain things that everyone believes, but you know, they’re kind of unspoken, maybe not really written down either. And so like in academia, that’s like the publishing culture and the competitiveness of publication venues and that sort of stuff, which seems ridiculous to outsiders. But if you’re in it, you kind of get accustomed to it. And likewise in startups, it’s like the hype to be constantly selling and marketing and promoting what you’re doing to the max crushing it, always crushing it, exactly, and to an outsider that seems really. it’s kind of a ridiculous show that people put on frankly. But to an insider, you know, you just get used to it and that’s just your everyday life. I find that having seen both makes me a bit more detached from both of them and I don’t know, maybe I see a little bit more through the bullshit. 00:06:21 - Speaker 2: So as you hinted, our topic today is local first software. So this is an essay that I’ll link to in the show notes. It’s about 2 years old, and notably there’s 4 authors on this paper, 3 of them are here, kind of almost a little reunion, and actually the 4th author, Peter van Hardenberg, we hope to have on as a future guest. But I thought it would be really fun to not only kind of summarize what that philosophy is, particularly because we’re actively pursuing that for the Muse sinking persistence model, but also to look at sort of what we’ve learned since we published that essay and revisiting a little bit. What do we wish we’d put in, how’s the movement, if that’s the right word for it, how’s that evolved, what have we learned in that time? But I guess before getting into all that, maybe Martin, you can give us the elevator pitch, if I’m to reference the startup terminology, the brief summary of what is local first software. 00:07:18 - Speaker 1: Yeah, local first software is a reaction to cloud software and so with cloud software, I mean things like Google Docs, where you have a browser window and you type into it and you can share it really easily. You can have several people contributing to a document really easily, you can send it for comments. Very easily and so on. So, it has made collaboration a ton easier, but it’s come at a great cost to our control and our ownership of the data, because whenever you’re using some cloud software, the data is stored on the cloud provider servers, like Google servers, for example. And you know, as users, we are given access to that data temporarily. Until that day where Google suddenly decides to lock your account and you are locked out of all of the documents that you ever created with Google Docs, or until the startup software as a service product you’re using, suddenly goes bust and decides to shut down their product with 2 weeks' notice and maybe allows you to download a zip file full of JSON files as your data export. And I find that tragic because as creative people, we put a ton of effort, time and our souls and really our personalities into the things that we create. And so much now the things that we create are computer-based things, you know, whether you’re writing the script for a play or whether you’re negotiating a contract or whether you’re doing any sort of endeavor, it’s probably a file on a computer somewhere. And if that file is in some cloud software, then there’s always this risk that it might disappear and that you might lose access to it. And so what we try to do with local first software is to articulate a vision for the future where that does not happen, where We have the same convenience that we have with cloud software that is we have the same ability to do real-time collaboration. It’s not back to the old world of sending files back and forth by email. We still want the same real-time collaboration that we get with Google Docs, but at the same time we also want the files stored. On our own computers. Because if there are files on our own computers, then nobody can take them away. They are there, we can back them up ourselves. We can optionally back them up to a cloud service if we want to. There’s nothing wrong with using a cloud service as long as the software still continues working without the cloud service. Moreover, we want the software to continue working offline so that if you’re working on a plane or working on a train that’s going through a tunnel or whatever, the software should just continue to work. And we want better security and privacy because we don’t want cloud services scanning through the content of all of our files. I think for creativity, it’s important to have that sense of privacy and ownership over your workspace. And so those are some of the ideas that we try to encapsulate in this idea of local first software. So how can we try to have the best of both worlds of the convenience of cloud software. But the data ownership of having the files locally on your own device. 00:10:15 - Speaker 2: Yeah, for me, the core of it is really agency and much of the value of cloud, and I think there’s a version of this also for mobile apps, let’s say and app stores and that sort of thing, which is not what we’re addressing in the paper, but maybe there’s a theme in computing that we’ve made computers vastly more accessible by In many cases, taking agency from people, and that’s actually a good thing in many cases, right? You don’t need to defrag your hard drive anymore. You lose your device, your email, and your photos and all those things are still in this cloud that’s managed by experiencedmins and product managers and so forth at companies like Google and So forth, and they can often do a better job of it in a lot of cases than an individual can. I mean, I think of managing my own email servers, SMTP servers, years back and needing to deal with data backup and spam filtering and all that kind of thing, and Gmail came along and I was just super happy to outsource the problem to them. Absolutely. They did a better job managing it. So I think that’s basically in many ways a good trend or as a net good in the world, and I don’t think we feel like we necessarily want to go back to everyone needs to do more of those data management tasks, but I think for the area of creative tools or more, I guess you call them power users, but it’s like you said, if you’re writing a play, that’s just a very different kind of interaction with a computer than the average person doing some calendar and email and messaging. Yeah, maybe they want different trade-offs. It’s worth doing a little bit more management and taking a little more ownership to get that greater agency over something like, yeah, my work product, the script of my play or my master thesis or whatever it is that I’m working on is something that really belongs to me and I want to put a little extra effort to have that ownership. 00:12:08 - Speaker 1: Right, exactly. And I feel like it’s not reasonable to expect everyone to be a sys admin and to set up their own services, you know, you get this self-hosted cloud software, but most of it is far too technical for the vast majority of users, and that’s not where we want to go with this. I think you still want exactly the same kind of convenience of clouds software that, you know, it just works out of the box and you don’t have to worry about the technicalities of how it’s set up. But one part of local first software is that because all of the interesting app specific work happens client side on your own device, it now means that the cloud services that you do use for syncing your data, for backing up your data, and so the cloud services become generic. And so you could imagine Dropbox or Google Drive or AWS or some other big cloud provider just giving you a syncing service for local first apps. And the way we’re thinking about this, you could have one generic service that could be used as the syncing infrastructure for many different pieces of software. So regardless of whether the software is a text editor or a spreadsheet or a CAD application for designing industrial products or music software or whatever it might be, all of those different apps. Could potentially use the same backup and syncing infrastructure in the cloud, and you can have multiple cloud providers that are compatible with each other and you could just switch from one to the other. So at that point, then it just becomes like, OK, who do you pay 6 cents a month to in order for them to store your data, it becomes just a very generic and fungible service. And so that’s what I see makes actually the cloud almost more powerful. Because it removes the lock-in that you have from, you have to use a single, the, the cloud service provided by the software offer. Instead, you could switch from one cloud provider to another very easily and you still retain the property that you’re using all of the cloud providers' expertise in providing a highly available service and you don’t have to do any admin yourself. It’s not like running your own SMTP server. So I feel like this is a really promising direction that local first software enables. 00:14:24 - Speaker 3: Yeah, for sure, indeed, and you could even describe local first software, I think, as sort of generalizing and distributing the capabilities of the different nodes. So in the classic cloud model, you have these thin clients, they can dial into the server and render whatever the server tells them. And then you have the servers and they can store data and process it and return to clients and when you have both of those at the same time, you know, it works great, but then if you’re a client like you said, who’s in a tunnel, well too bad you can’t do anything, and the local first model is more that any node in that system can do anything, it can. Process the data, I can validate it, it can store it, it can communicate it, it can sync it, and then you can choose what kind of typologies you want. So it might be that you just want to work alone in your tunnel, or it might be that you want to subscribe to a cloud backup service that does the synchronization storage part for you while you still maintain the ability to process and render data locally. This actually gets to how I first got into what we’re now calling local first software. I was in a coffee shop with Peter Ben Hartenberg, who’s one of the other authors that Adam mentioned. And we’re talking about working together at the lab when he was a principal there, he’s now the director, and he showed me the pixel pusher prototype. So Pixel Pusher was this Pixel art app where you color individual pictures to make a kind of retrographic thing, and it was real time collaborative, but the huge thing was that there was no server, so that you had this one code base and this one app, and you got real time collaboration. Across devices, and that was the moment that I realized, you know, I was a fish in the cloud infrastructure water and I didn’t realize it. Just assumed, oh, you need servers and AWS need a whole ops team, you’re gonna be running that for the rest of your life, it’s the whole thing. Well, actually, no, you could just write the app and point at the other laptop and there you go. And we eventually kind of realized all these other benefits that we would eventually articulate as the desiderao property to the local for software article, but that was the thing that really actually kicked it off for me. 00:16:19 - Speaker 1: Yeah, and that’s aspect that the apps become really self-contained and that you just don’t have a server anymore, or if you have a server, it’s like a really simple and generic thing. You don’t write a specific server just for your app anymore. That’s something that I’m not sure we really explored very well in the local first asset as it was published, but I’ve been continuing to think about that since, you know, this has really profound implications for the economics of software development. Because right now, as you said, like if you’re a startup and you want to provide some SAS product, you need your own ops team that is available 24/7 with one pager duty so that when the database starts running slow or a node falls over and you need to reboot something or whatever, you know, there’s just all this crap that you have to deal with, which makes it really. to provide cloud software because you need all of these people on call and you need all of these people to write these scalable cloud services and it’s really complicated, as evidenced by my book, a lot of which is basically like, oh crap, how do I build a scalable cloud service. And with local first software, potentially that problem simply goes away because you’ve just got each local client which just rights to storage on its own local hard disk. You know, there are no distributed systems problems to deal with, no network time outs and so on. You just write some data locally and then you have this syncing code which you just use an open source library like automerge, which will do the data syncing between your device and maybe a cloud service and maybe the other services. And the server side is just non-existent. And you’ve just like removed the entire backend team from the cost of developing a product and you don’t have the ops team problem anymore because you’re using some generic service provided by some other cloud provider. And you know, that has the potential to make the development of collaborative software so much cheaper. Which then in turn will mean that we get more software developed by smaller teams, faster, it’ll improve the competitiveness of software development in general, like it seems to have so many positive effects once you start thinking it through. 00:18:22 - Speaker 2: Yeah, absolutely. For me, yeah, maybe similar to both of you, my motivations were, well, both as a user and as a, let’s say a software creator or provider on the user side, we have these 7 different points we articulate and I think you can, in fact, we even set it. Up this way is you can give yourself a little scorecard and see which of the boxes you tick. It’ll be fun to do that for the muse syncing service when that’s up and running, but the offline capability is a huge one to me, and it’s not just the convenience. I mean, yeah, it’s. Every time I’m working on the train and my train goes through a tunnel, and suddenly I can’t type into my documents anymore, for example, or I don’t know, I like to go more remote places to work and have solitude, but then I can’t load up Figma or whatever else, and Yeah, that for me as a user is just this feeling of it comes back to the loss of agency, but also just practically it’s just annoying and you know we assume always on internet connections, but I wonder how much that is because the software engineers are people sitting in office. Or maybe now at home in San Francisco on fast internet connections with always connected devices versus kind of the more realities of life walking around in this well connected but not perfectly so world we all live in. That’s on the user side. 00:19:42 - Speaker 1: Yeah, I feel like there’s a huge bias there towards like, oh, it’s fine, we can assume everyone always has an internet connection because yes, we happen to be that small segment of the population that does have a reliable internet connection most of the time. There’s so many situations in which you simply can’t assume that and that might be anything from a farmer working on their fields using an app to manage what they’re doing to their crops and something like that and you know, they won’t necessarily have reliable cellular data coverage even in industrialized countries, let alone in other parts of the world where you just can’t assume that sort of level of network infrastructure at all. 00:20:17 - Speaker 3: Yeah. Yeah, it’s funny you mention this because we often run into this on the summits that we have for Muse. So we were recently in rural France and we had pretty slow internet, especially on upload. I think it was a satellite connection, and we always had this experience where there are 4 of us sitting around a table and you’re looking at each other, but you can’t, you know, send files around cause it needs to go to, you know, whatever, Virginia and come all the way back. 00:20:43 - Speaker 1: It’s crazy if you think about it, it’s ridiculous. 00:20:46 - Speaker 2: Yeah, and I don’t think you even need to reach as far as a farmer or a team summit at a remote location. I had a kitchen table in the house I lived in right before this one that was like a perfect place to sit and work with my laptop, but the location of the refrigerator, which it really couldn’t be any other place, just exactly blocked path to my router, and the router couldn’t really be any other place. I guess I could run a wire or something, but I really wanted to sit right there and work. But again, it’s this ridiculous thing where you can’t even put a character into a document and I could pick up the laptop and walk a meter to the left, and now suddenly I can type again and you can be that to something like. G, which does have more of a local is probably one of the closest thing the true local first software where you can work and yes, you need an internet connection to share that work with others, but you’re not stopped from that moment to moment typing things into your computer. 00:21:38 - Speaker 3: Yeah, and furthermore, from the implementation perspective, even when you have a very fast internet connection, you’re still dealing with this problem. So if I’m using an app and I type in a letter on my keyboard, between the time when I do that and when the round trip happens with the AWS server, which might be 50 or 100 milliseconds, the app needs to do something useful. I can’t wait for that full round trip. It needs to immediately show. Me what’s happening. So you inevitably have this little distributed system where you have your local process and app trying to display something immediately, and you have the remote server. And the great elegance, I think, of the local first approach is that that’s just like another instance of the general problem of synchronizing across nodes, whereas often in other apps, that’s sort of like an ad hoc kind of second special case thing, like, oh, It’s only going to be like this for 100 milliseconds. So just kind of do a hacky solution and make it so that most of the time the right letter shows up. And that’s why you have this behavior where apps will have like an offline mode, but it like never works, because I think we mentioned this on the podcast before, there’s systems that you use all the time and systems that don’t work. This is a maximum we can link to. But again, with local first, you’re kind of exercising that core synchronization approach all the time, including when it’s just you and another server on a good connection. 00:22:50 - Speaker 1: Yeah, and from a sort of fundamentals of distributed systems point of view, I find that very satisfying because I just see this as different amounts of network latency. Like if you’re online you have network latency of 50 or 100 milliseconds. If you’re offline, you have network latency of 3 hours or however long it’s going to be until you next come back online again. To me those are exactly the same, you know, I don’t care if it’s a few orders of magnitude apart. Both the network latency both need to be dealt with and if we can use the same techniques for dealing with both standard online latency and being offline, that just simplifies the software dramatically. 00:23:25 - Speaker 2: Going back to sort of the infrastructure, fewer moving parts thing and speaking to our personal motivations, for me, the experience of running Hiroku was a big part of my motivation or fed into my interest in this because Hiokku was an infrastructure business. I didn’t quite grasp what that meant when we went into it. I just wanted a better way to deploy apps, and in the end, I enjoy writing software, I enjoy creating products that solve problems for people, but infrastructure is a whole other game. And you know, it became the point where once you’re, I don’t know if mission critical is the right word, but just something people really care about working well and you’re in the critical path. So for example, our routing infrastructure, if it was down for 3 seconds, people would complain. So the slightest hiccup, and as they should, that was part of the service that that company is providing, and so that’s fair enough. But then when I go, OK, well, I’m building software, when I think of, for example, Muse, where I’m providing this productivity tool to help people think and that sort of thing. I don’t want to be paged because someone went to move a card 5 centimeters to the right and our server was down or overloaded or something, so then they can’t move the card and so then they’re writing into support angrily. I’m pretty comfortable with there’s some kind of cloud syncing problem and OK, I can’t easily like push my changes to someone else, and that is still a problem, but it feels like it’s on this slightly different timeline. You’re not just blocking the very most basic fundamental operation of the software. And so the idea that exactly as you said, it changes the economics, for me personally, I want to spend more of my time writing software and building products and less of my time setting up, maintaining and running infrastructure. So I guess looking back on the two years that have elapsed, I would say that this is probably, it’s hard to know for sure, but the Inkot switch essays, there’s a number of them that I think had a really good impact, but I think this one probably just my anecdotal feeling of seeing people cite it by. it in Twitter comments and things like that. It feels like one of the bigger impact pieces that we published, and I do really see quite a lot of people referencing that term, you know, we’ve sort of injected that term into discussion again, at least among a certain very niche narrow world of things. So, yeah, I’d be curious to hear from both of you, first, whether there’s things that looking back you wish we’d put in or you would add now, and then how that interacts with what you make of local first movement or other work that people are doing on that now. 00:25:59 - Speaker 1: I’m very happy that we gave the thing a name. There’s something we didn’t have initially when we started writing this and we’re just writing this like manifesto for software that works better basically. And then at some point we thought like it would be really good to have some way of referring to it and you know, people talk about offline first or mobile first, and these were all kind of established things and terms that people would throw around. And we also wanted some term X where we could say like I’m building an X type app. And so I’m very glad that we came up with this term they first because I’ve also seen people even outside of our direct community starting to use it. And just, you know, put it in an article casually without even necessarily explaining what it means and just assuming that people know what it is. And I think that’s a great form of impact if we can give people a term to articulate what it is they’re thinking about. 00:26:50 - Speaker 2: Yeah, language, a shared vocabulary to describe something as a very powerful way to, one, just sort of advance our ability to communicate clearly with each other, but also, yeah, there’s so many ideas. I mean, it’s a 20 something page paper and there’s so many ideas, but you wrap this up in this one term and for someone who has downloaded some or most of these ideas, that one term can carry all the weight and then you can build on that. You can take all that as a given and then build forward from there. 00:27:19 - Speaker 1: Yeah. One thing I wish we had done more on is I think trying to get a bit more into the economic implications of it. I guess that would have made the essay another 5 pages longer and so at some point we just have to stop. But I feel like it’s quite an important aspect like what we talked about earlier of not having to worry about back ends or even just like not having to worry generally about the distributed systems problem of like you make a request to a server, the request times out. You have no idea whether the server got the request or not. Like, do you retry it? If so, how do you make the retry? Is that potent so that it’s safe to retry and so on. Like all of those problems just go away if you’re using a general purpose syncing infrastructure that somebody else has written for you. And there are other implications as well that are less clear of what about the business model of software as a service. Because there a lot of companies' business model right now is basically pay us, otherwise you’re going to get locked out of your data. So it’s using this idea of holding data hostage almost as the reason why you should pay for a product. And you know, it’s like that with Slack. Like you put all of your messages in Slack those messages were written by you and your colleagues. There’s nothing really Slack did to own those, they just facilitated the exchange of those messages between you and your colleagues. But then once you go over the, whatever it is, 10,000 messages limit, then suddenly you have to pay slack to see the messages that you wrote yourself. And generally that’s the business model with a lot of software as a service. And with local first, it’s not clear that that business model will still work so clearly. But of course, software developers still have to be paid for their time somehow. So how do we find a way of building sustainable software businesses for collaboration software but without holding data hostage? I think that’s a really deep and interesting question. 00:29:07 - Speaker 3: Yeah, I think as an aside that uh you might call it the political economy of software is understudied and underconsidered, and I would put in here like the economics of software business, but also the interaction with things like regulation and governments and the huge amount of path dependence that’s involved. I think that’s just a huge deal. I think we’re starting to realize it, but yeah, there’s a ton of stuff we could do and think about just for local first. Like just one kind of branch that I hope we get to explore is we mentioned how local first enables you to do totally different topologies. So with cloud software almost by definition, you have this hub and spoke model where everything goes through. The central server and the central corporation. Well with local first, you can very easily, for example, have a federated system where you dial into one of many synchronization nodes and you could even have more like a mesh system where you request and incentivize packets to be forwarded through a mesh to their destination, sort of like TCPIP networking, but for like the application layer, and it may be, you know, it’s still kind of TBD but it may be that a mesh or a distributed approach has totally different political implications from a centralized node and that might become important, so. I just think there’s a lot to think about and do here. 00:30:15 - Speaker 1: Yeah, I think so too. And like, I would take email as an analogy maybe, which is a federated system just like what you described, like you send your email to your local SMTP server and it forwards it to the recipient’s SMTP server and the system works really well. Certainly as criticisms like spam filtering is difficult in a really decentralized way. Maybe spam is not a problem that local first software will have as much because it’s intended more like for collaboration between people who know each other rather than as a way of contacting people you don’t know yet. But certainly like I think taking some inspiration from that federation and seeing how that can be applied to other domains, I think would be very interesting. 00:30:55 - Speaker 3: Yeah, and this brings us to the topic of like industrialization and commercialization, and I feel like there’s more promise than ever around local First and more people are excited about it, but I still feel like we’re just in the beginning phases of getting the ball rolling on industrial and commercial applications. And if I’m being really honest, I feel like it might have been slower than I had initially hoped over the past few years, so I’m just curious if Adam and Martin, you would reflect on that. 00:31:21 - Speaker 2: It’s always hard to say, right? The thing with any technology, but certainly my career in computing, this has always proven to be the case, is that something seems right around the corner and it stays so for 20 years. I don’t know, maybe VRs in that category, but then there’ll be a moment, suddenly it’ll just be everywhere, broadband internet or something like that. So as a people who are both trying to advance the state of the art but also making Business decisions, you know, should I start a company? Should I invest in a company? Should I keep working on the company I’m working on based on what technologies exist or where you see things going? Yeah, you’re always trying to make accurate predictions. So yeah, I agree on one hand it felt very close to me on the basis of the prototypes we’d built, the automerged library, the reference, Martin I’ll link that in the notes here, but basically that’s a JavaScript implementation of something called CRDTs which Just I guess as a sidebar, it could be easy to think that CRDTs and local first software are kind of one and the same because they are often mentioned together and in fact our paper talks about them together, but CRDTs are a technology we find incredibly promising for helping to deliver local first software, but local first is a set of principles. It doesn’t require any particular technological solution. Yeah, based on the strength of those prototypes, many of which worked really well, there’s the networking side of it and whether you can have that be fully kind of decentralized versus needing more of a central coordination server. But once you get past that hump, it does work really, really well. But I think that comes back to the point you both made there about the economic model side of things, which is we have a whole software industry that’s built around people will pay for software when there’s a service connected to it. Right, so Sass, in particular B2BASS is just a fantastic business to be in, and as a result, we’ve seen a huge explosion of software around that, but connected to that is, for example, the Fremium model, exactly like what you mentioned with Slack, the docs is one of those. Notion is one of those. They do this kind of free for individuals, but then you pay when you’re a business and then you need to come up with the feature stuff, the kinds of features that seem to be selecting for you being a business with more serious needs and something like retaining your message history is there. I wrote a whole other shorter essay about paying for software. I’ll link that in the notes, but I think we got into a weird corner. The industry got itself into a weird painted itself into a corner because Things like Google giving you so much incredibly high quality software, Gmail, Google Docs, Google Maps, etc. for quote unquote free, but then how you’re really paying for it is your attention and your data, right? And that being kind of montizable through being able to essentially serve you ads. And I think that’s fine and I’m very glad for Google’s existence and they found that model, but it almost feels like then it taught people that good software should be free and that you shouldn’t pay for, maybe that’s a little bit connected to the concept that software R&D basically costs nothing to make additional copies of it. So therefore, if you make this big upfront investment and then the software exists and you can duplicate it endlessly, but I think there’s a lot of things flawed about all of that. But the end place that gets you to is, OK, if someone has my data and I’m paying them to maintain it and run the servers that it’s on, I can stomach that. OK, now I’ll pay $5 a month, $10 a month for my Dropbox account or something like that. But other than that, we’ve become accustomed to, oh, if it’s an app on the App Store, the App Store is a good example of these kind of consumer economics, we just expect it to be vastly lower cost or free and good software costs money to make, and as we kind of talked about earlier, I would rather be building the software, not maintaining the infrastructure, but when you set it up so that The only way you can make money is to build software that has infrastructure, you’re actually incentivized, build that back end as soon as you can and get the user’s data in there and not necessarily hold it hostage, but just take ownership of it, because that’s what people will pay for. They won’t pay for software where they own the data themselves. 00:35:34 - Speaker 1: Yes, one thing that a friend has suggested is that when talking about the business model of local first software, we should just call it SA, like label it as SAS, market it in exactly the same way as SAS. Don’t even tell people that it’s local first software and just use the fact that it’s a lot cheaper and easier to implement local first software and use that for your own benefit in order to build the software more cheaply. But don’t actually market the local first aspect. And I thought that’s quite an interesting idea because, you know, it is an idea that people are accustomed to and to be honest, I think the amount of piracy that you would get from people like ripping out the sinking infrastructure and putting it for something else and then continuing to use the app without paying for it, it’s probably pretty limited. So you probably only need to put in a very modest hurdle there of say, OK, like this is the point at which you pay. Regardless of whether that point for payment is, you know, necessarily enforced in the infrastructure, it might just be an if statement in your client side up and maybe that’s fine. 00:36:38 - Speaker 2: Muse is basically an example of that. We have this membership model that is, you know, subscription is your only option and there are a lot of folks that complain about that or take issue with it, and I think there are many valid complaints you can make, but I think in many cases it is just a matter of what. Folks are accustomed to and we want to be building and delivering great software that improves and changes over time and maps to the changing world around it, and that’s something where as long as you’re getting value, you pay for it and you’re not getting value anymore, you don’t have to pay anymore. And then a model like that basically works best for everyone, we think, again, not everyone agrees. But then again, you do get this pushback of we are running a small service, but it’s not super critical to the application, but maybe that would be a good moment to speak briefly about the explorations we’re doing on the local first sync side, Mark. 00:37:32 - Speaker 3: Yeah, so right now Muse is basically a local only app, like it’s a traditional desktop app where files are just saved to the local device and that’s about it, and you can manually move bundles across devices, but otherwise it just runs locally and the idea is to extend be used with first syncing across your devices and then eventually collaboration across users using a local first approach. Now we don’t plan to do, at least initially the kind of fully distributed mesh networking peer to peer thing. It will be a sync service provided by Muse and kind of baked in to the app, but it will have all those nice local first properties of it works offline, it’s very fast, all the different nodes are first class and so forth while eventually supporting syncing and and collaboration. So, yeah, we’re going through this journey of, we had a lot of experience with um basic prototypes in a lab, but there’s a big jump to have a commercialized and industrialized product, not just in terms of charging for the business model and stuff, but in terms of the performance and it’s like all the weird things that you deal with in the real world, like versioning and schemas and the idiosyncrasies of networking and All the things that go around the core functionality, like one thing we’re thinking a lot about is visibility into the sync status and how it’s different in a local first world. Yeah, so I’m excited that we are now investing a lot in bringing local first into the real world with MS. 00:38:57 - Speaker 1: Yeah, and I feel like more generally, if we want the local first ideas to be adopted, we need to make it easy in a way that people can just take an open source library off the shelf, not have to think too much about it, plug it into their app, have a server that’s ready to go, that’s either it’s already hosted for them or they can spin up their own server and make that path. Super easy and straightforward and that’s kind of where my research is focusing of trying to get the technologies to that point. So right now, we have some basic implementations of this stuff. So automerge is a library that does this kind of data synchronization. It includes a JSON like data model that you can use to store the state of your application. It has a sort of basic network protocol that can be used to sync up two nodes. But there’s so much more work to be done on making the performance really good, like at the moment it’s definitely not very good. We’re making progress with that, but it’s still a long way to go. Making the data sync protocol efficient over all sorts of different types of network link in different scenarios, making it work well if you have large numbers of files, for example, not just single file and so on. And so there’s a ton of work still to be done there on the technical side. I think before this is really in a state where people can just pick up the open source library and run with it. Part of it is also like just uh getting the APIs right, making sure it has support across all the platforms, just having a JavaScript implementation is fine for initial prototypes, but Obviously, iOS apps are written in SWIFT and Android apps will be written in coin or whatever people use and so you need to have support across all of the commonly used platforms and we’re gradually getting there, but it’s a ton of work. 00:40:43 - Speaker 2: And conceptually seeing how autoerge is evolving. And how people are trying to use it sometimes very successfully, sometimes less so, but I see this as a case of technology transfer, which is an area I’m incredibly interested in because I think it’s kind of a big unsolved problem in HCI research, computer science, honestly, maybe all research, but I’ll stick to my lane in terms of what I know, which is there is often this very excellent cutting edge research that does sit in the labs. So to speak, and never graduates or it’s very hard or there isn’t a good path often for it to jump over that hump into what’s needed in the production world and of course in the research world you’re trying to do something new and different and push the boundaries of what was possible before and in the production commercial side you want to choose boring technologies and do things that are really reliable and known and stable, and those two, there’s often a bridge that’s hard to divide there. Sitting in your seat as again someone who’s enmeshed in the academic world right now and you’re creating this library, you know, started as a called a proof of concept for lack of a better term, and then you have customers if that’s the right way to put it, but as an academic you would Shouldn’t have customers, but you sort of do because people want to use this library and in fact are for their startups and things like that. How do you see that transition happening or is there a good role model you’ve seen elsewhere or just kind of figure it out as you go? 00:42:16 - Speaker 1: Well, I think where we’re trying to go with this is it’s great for automerge to have users. I don’t think of them as customers. I don’t care about getting any money from them. But I do care about getting bug reports from them and experienced reports of how they’re getting on with the APIs and reports of performance problems and so on. And those things are all tremendously valuable because they actually feed back into the research process and so I’m essentially using the open source users and the contributors as a source of research problems. So with my research hat on, this is great because I have essentially here right in front of me a goldmine of interesting research problems to work on. I just take like the top issue that people are complaining about on GitHub, have a think about how we might solve that. And often there’s enough of a nugget of research problem in there that when we solve the problem, we can write a paper about it. It can be an academic contribution as well as moving the open source ecosystem gradually towards a point where we’ve ironed out all of those major technical problems and hopefully made something that is more usable in production. So, I actually feel those worlds are pretty compatible at the moment. There are some things which are a bit harder to make compatible like sort of the basic work of porting stuff to new languages on new platforms, that’s necessary for real life software engineering, but there’s no interesting research to be done there, to be honest. But so far I’ve found that quite a lot of the problems that we have run into actually do have interesting research that needs to be done in order to solve them. And as, as such, I think they’re quite well compatible at the moment. 00:43:56 - Speaker 2: And like imagining or the mental picture of someone submits a bug report and one year later you come back and say, here’s the fix and also the paper we published about it. 00:44:08 - Speaker 1: I’ve literally had cases where somebody turns up on Slack and says, I found this problem here. What about it? And I said, oh yeah, I wrote a paper about it. And the paper has a potential algorithm for fixing it, but I haven’t implemented it yet, sorry. And they go like, WTF what you put all of this thought into it. You’ve written the paper. And you haven’t implemented. And I go, well, actually sorry for me, that’s easier because if I want to implement it, I have to put in all of the thoughts and convince myself that it’s correct. And then I also have to implement it and then I also have to write all the tests for it and then I have to make sure that it doesn’t break other features and it doesn’t break the APIs and need to come up with good APIs for it and so on. So for me actually like implementing it is a lot more work than just doing the research in a sense, but actually, Doing the research and implementing it can be a really useful part of making sure that we’ve understood it properly from a research point of view. So that at the end what we write in the paper is ends up being correct. In this particular case, actually, it turned out that the algorithm I had written down in the paper was wrong because I just haven’t thought about it deeply enough and a student in India emailed me to say, hey, there’s a bug in your algorithm, and I said, yeah, you’re right, there’s a bug in our algorithm. We better fix it. And so probably through implementing that maybe I would have found the bug, maybe not, but I think this just shows that it is hard getting this stuff right, but the engagement with the open source community, I found a very valuable way of Both working towards a good product but also doing interesting research. 00:45:39 - Speaker 3: I think it’s also useful to think of this in terms of the research and development frame. So research is coming up with the core insights, the basic ideas, those universal truths to unlock new potential in the world, and it’s my opinion that with local first, there’s a huge amount of development that is needed, and that’s a lot of what we’re doing with Muse. So analogy I might use is Like a car and an internal combustion engine. If you came up with the idea of an internal combustion engine, that’s amazing. It’s pretty obvious that that should be world changing. You can spin this shaft at 5000 RPM with 300 horsepower, you know, it’s amazing, but you’re really not there yet. Like you need to invent suspension and transmission and cooling and It’s kind of not obvious how much work that’s gonna be until you go to actually build the car and run at 100 miles an hour. So I think there’s a lot of work that is still yet to be done on that front. And eventually, that kind of does boil down or emit research ideas and bug reports and things like that, but there’s also kind of its own whole thing, and there’s a lot to do there. There’s also a continuous analogy. I think once the research and the initial most obvious development examples get far enough along, you should have some. Unanticipated applications of the original technology. So this should be someone saying like, what if we made an airplane with an internal combustion engine, right? I don’t think we’ve quite seen that with local first, but I think we will once it’s more accessible, cause right now to use local first, you gotta be basically a world expert on local first stuff to even have a shot. But once it’s packaged enough and people see enough examples in real life, they should be able to more easily come up with their own new wild stuff. 00:47:11 - Speaker 1: Yeah, we have seen some interesting examples of people using our software in unexpected ways. One that I quite like is the Washington Post, as in the newspaper, everyone knows. They have an internal system for allowing several editors to update the layout of the home page. So the placement of which article goes where, with which headline, with which image, in which font size, in which column. All of that is set manually, of course, by editors. And they adopted automerge as a way of building the collaboration tool that helps them manage this homepage. Now, this is not really a case that needs local first, particularly because it’s not like one editor is going to spend a huge amount of time editing offline and then sharing their edits to the homepage. But what I did want is a process whereby multiple editors can each be responsible for a section of the homepage and they can propose changes to their section. And then hand those changes over to somebody else who’s going to review them and maybe approve them or maybe decline them. And so what they need essentially is this process of version control, Git style version control almost, but for the structure of representing the homepage. And they want the ability for several people to update that independently. And that’s not because people are working offline, but because people are using essentially branches using the Git metaphor. So different editors will be working on their own local branch until they’ve got it right and then they’ll hit a button where they say, OK, send this to another editor for approval. And that I found really interesting. It’s sort of using the same basic technologies that we’ve developed with CRTTs, tracking the changes to these data structures, being able to automatically merge changes made by different users, but applying it in sort of this interesting unexpected context. And I hope like as these tools mature, we will expand the set of applications for which they can be sensibly used and In that expansion, we will then also see more interesting unexpected applications where people start doing things that we haven’t anticipated. 00:49:19 - Speaker 2: Maybe this reflects my commercial world bias or maybe I’m just a simple man, but I like to see something working more than I like to read a proof that it works. And both are extremely important, right? So the engineering approach to seeing if something works is you write a script, you know, fuzz testing, right, you try a million different permutations and if it all seemed to work, kind of the Monte Carlo simulation test of something, and it seems to work in all the cases you can find, so it seems like it’s working. And then there’s, I think, the more proof style in the sense of mathematical proof of here is an airtight logical deductive reasoning case or mathematical case that shows that it works in all scenarios that it’s not a Monte Carlo calculation of the area under the curve, it’s calculus to determine precisely to infinite resolution area to the curve. And I think they both have their place kind of to Mark’s point, you need to both kind of conceptually come up with the combustion engine and then build one, and then all the things that are gonna go with that. And I think we all have our contributions to make. I think I probably, much as I like the research world at some point when there’s an idea that truly excites me enough, and local first broadly and CRDT. in this category, and I wanna see it, I want to try it, I want to see how it feels. In fact, that was our first project together. Martin was, we did this sort of trello clone essentially that was local first software and could basically merge together of two people worked offline, and they had a little bit of a version history. I did a little demo video, I’ll link that in the show notes. But for me it was really exciting to see that working, and I think maybe your reaction was a bit of a like, well, of course, you know, we have 5 years of research. Look at all these papers that prove that it would work, but I want to see it working and moreover feel what it will be like because I had this hunch that it would feel really great for the end user to have that agency. But seeing it slash experiencing it, for me that drives it home and creates internal motivation far more than the thought experiment is the right word, the conceptual realm work, even though I know that there’s no way we could have built that prototype without all that deep thinking and hard work that went into the science that led up to it. 00:51:42 - Speaker 1: Yeah, and it’s totally amazing to see something like working for the first time and it’s very hard to anticipate how something is going to feel, as you said, like you can sort of rationalize about its pros and cons and things like that, but that’s still not quite the same thing as the actual firsthand experience of really using the software. 00:52:01 - Speaker 2: All right, so local first, the paper and the concept, I think we are pretty happy with the impact that it made, how it’s changed a lot of industry discussion, and furthermore, that while the technology maybe is not as far along as we’d like, it has come a long way, and we’re starting to see it make its way into more real world applications, including news in the very near future. But I guess looking forward to the future for either that kind of general movement or the technology. What do you both hope to see in the coming, say, next 2 years, or even further out? 00:52:38 - Speaker 3: Well, the basic thing that I’d like to see is this development of the core idea and see it successfully applied in commercial and industrial settings. Like I said, I think there’s a lot of work to do there and some people have started, but I’d like to see that really land. And then assuming we’re able to get the basic development landed, a particular direction I’m really excited about is non-centralized topologies. I just think that’s going to become very important and it’s a unique potential of local first software. So things like federated syncing services, mesh topologies, end to end encryption, generalized sync services like we talked about, really excited to see those get developed and explored. 00:53:18 - Speaker 1: Yeah, those are all exciting topics. For me, one thing that I don’t really have a good answer to but which seems very interesting is what does the relationship between apps and the operating system look like in the future? Because like right now, we’re still essentially using the same 1970 Unix abstraction of we have a hierarchical file system. A file is a sequence of bytes. That’s it. A file has a name and the content has no further structure other than being a sequence of bytes. But if you want to allow several users to edit a file at the same time and then merge those things together again, you need more knowledge about the structure of what’s inside the file. You can’t just do that with an opaque sequence of bytes. And ICRDTs is essentially providing a sort of general purpose higher level file format that apps can use to express and represent the data that they want to have just like Jason and XML are general purpose data representations and CRDTs further refined this by not just capturing the current state, but also capturing all the changes that were made to the state and thereby they much better encapsulate the what was the intent of the user when they made a certain change and then capturing those intents of the user through the operations they perform that then allows different users changes to be merged in a sensible way. And I feel like this idea of really changes the abstractions that operating systems should provide because maybe OSs should not just be providing this model of files as a sequence of bytes, but this higher level CRDT like model and how does that impact the entire way how software is developed. I think there’s a potential for just rethinking a lot of the stack that has built up a huge amount of craft over the past decades. And potential to like really simplify and make things more powerful at the same time. 00:55:17 - Speaker 2: Yeah, local first file system to me is kind of the end state, and maybe that’s not quite a file system in the sense of how we think about it today, but a persistence layer that has certainly these concepts baked into it, but I think also just reflects the changing user expectations. People want Google Docs and notion and Figma. And they expect that their email and calendar will seamlessly sync across all their devices and then you have other collaborators in the mix, so your files go from being these pretty static things on the disk, you know, you press command S or ControlS and every once in a while it does a binary dump of your work that you can load later and instead it becomes a continuous stream of changes coming from a lot of different sources. They come from, I’ve got my phone and my computer and Mark’s got his tablet and his phone, and Martin, you’ve got your computer and we’re all contributing to a document and those changes are all streaming together and need to be coalesced and made sense of. And I think that’s the place where, for example, Dropbox, much as I love it, or iCloud, which I think in a lot of ways is a really good direction, but both of those are essentially dead ends, because they just take the classic static binary file and put it on the network, which is good, but it only takes you so far, cause again, people want Google Docs, that’s just the end of it. And that puts every single company that’s going to build an application of this sort. They have to build the kind of infrastructure necessary to do that. And we’ve seen where I think FIMA is the most dramatic example, they just took sketch and ported it to a kind of a real-time collaborative web first environment, and the word just there is carrying a lot of weight. Because in fact, it’s this huge engineering project and they need to raise a bunch of venture capital, but then once you had it, it was so incredibly valuable to have that collaboration, and then, of course, they built far beyond the initial, let’s just do sketch on the web. But any company that wants to do something like that, and increasingly that’s not table stakes from user expectation standpoint, they want to be able to do that, but you have to do that same thing. You’ve gotta drop, you know, tens of millions of dollars on big teams to do that. It seems strange when I think many and most at least productivity applications want something similar to that. So, if that were built into the operating system the same way that a file system is, or, you know, we proposed this idea of like a firebase style thing for local first and CRDTs which could be maybe more developer infrastructure, maybe that’s also what you guys were speaking about. Earlier with kind of like AWBS could run a generic sync service. I don’t know exactly what the interface looks like, it’s more of a developer thing or an end user thing, but basically every single application needs this, and the fact that it is a huge endeavor that costs so much money and requires really top talent to do at all, let alone continue running over time and scale up, just seems like a mismatch with what the world needs and wants right now. 00:58:25 - Speaker 3: Yeah, and now I want to riff on this, Adam, because the strongest version of that vision is

Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: And I don’t hold this against Apple or anybody else. There are billions of people on Earth who need great computers, and most of them are not scientists or authors or policymakers, but we believe that this has left a gap where there just simply isn’t a major computing group that’s actually focused on how to use computers in this intelligence amplifying way. 00:00:25 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad and Mac. This podcast isn’t about Muse the product, it’s about Muse the company and the small team behind it. I’m Adam Wiggins here today with my colleague Mark McCrannigan. Hey, Adam, and my frequent collaborator, Peter Van Hardenberg from I and Switch. Hi, it’s good to be here. And Peter, one of the things that I find fascinating to talk to you about is your varied hobbies outside of the world of computing. What’s your latest interest? 00:00:56 - Speaker 1: Oh yeah, I mean, when I’m not, you know, brewing beer or getting into some strange creative hobby of one form or another, well, I guess I’m always picking up another one. So lately I’ve been doing a lot of hydroponic gardening, and I’m not growing anything of legal dubiousness, but with the pandemic, first I was focused on trying to basically have some green space in my home, because I was living in San Francisco and we didn’t have a yard. And then more recently, I have moved back to my ancestral homeland of Canada, and it gets real dark and cold here in the winter, and I wanted to make sure I could secure a steady supply of Mexican ingredients, particularly herbs and chili peppers and things that you just can’t find. Sort of north of the wall in the offseason. So that’s been a lot of fun. I’ve been learning a ton about electrical conductivity and how to take pH measurements and having a lot of fun with automating all the components of this system over time. So these are going to be the most expensive cherry tomatoes in the world by the time I’m done, but it’s just a blast learning about all this stuff and, you know, what kind of absorption wavelengths are better for different kinds of plants and so on and so forth. 00:02:09 - Speaker 2: And correct me if I’m wrong, but I think the term hydroponics typically refers to growing plants without soil or with minimal soil. That’s right, I assume here you also have the artificial light element as well with the northernly climate. 00:02:22 - Speaker 1: Yeah, and basically what I have is sort of, if you imagine like a 2 m by 2 m bed or maybe a 1.5 garden bed, that’s sort of cut into 3 pieces and then stacked into a bookshelf. And then nutrient and oxygen-rich water circulates sort of around these U-shaped trays and then cascades back down to a reservoir in the bottom, where it gets pumped back up to the top in a loop. And so I routinely come in and I have to top up the water, there’s a lot of water loss due to transpiration, which is where basically the water goes out to the leaves and then evaporates, and then you have to sort of monitor how much water there is, but also regularly top up the nutrients to make sure that all of the vital macro and micro nutrients that the plants need to live are present in the solution. It’s a fun little chemistry project. 00:03:10 - Speaker 2: And I would be disappointed if there wasn’t, I don’t know, a raspberry pie or something connected in this mix somewhere. 00:03:17 - Speaker 1: Oh yeah, there are 2 computers now involved. There’s one that doses out the nutrients using peristaltic pumps. And there’s a separate one that came with the unit, which handles notifying me when the water levels are too low, there’s a little ultrasonic sensor that can tell when the reservoir tank gets low on water, and also handles scheduling the lights off and on during the day. I’m still hopeful about automating the nutrient sensors, but it turns out that monitoring pH over time is actually a surprisingly difficult problem, and that a good hardware solution actually involves a fair amount of like upkeep and maintenance and expense just in sensor probes alone. So so far I haven’t quite taken the plunge there, but I think it’s just a matter of time. We’ll get there, don’t worry. The end state, of course, is to build a robot arm that will like use computer vision to spot when a cherry tomato is ripe, and then pluck it for me and place it on a conveyor belt. But uh, you know, I think we’re still a few years out from that, both in terms of like technological feasibility, but also just in terms of like, I got a lot of other projects on the go these days. 00:04:23 - Speaker 2: And surely plucking the ripe literal fruits of your labor is the funnest part of the whole thing, so save that for last to automate. 00:04:33 - Speaker 1: Yeah, my kids really enjoy going into the garden. They get the little step ladders out and climb up and peer into the different tiers and pluck leaves to sample. Honestly, this thing is the only way I’ve ever convinced them to eat green leaves, because they’ve learned now that there’s lots of interesting green leaves they’re allowed to eat in the garden. But if you put a salad on their plate, they won’t eat it, but they’ll go and like forage some mint leaves or basil or things like that. They’re into that. 00:04:57 - Speaker 2: And I mentioned we’re frequent collaborators, so the three of us worked together all the way back in the Hiroki days. Nowadays you are leading, administrating, directing the I and Switch Research Lab, which was a position I had previously held before entering the new spin out, which we can talk about the relationship there, but I’m sure the audience would love to hear about your background. How did you end up connected to this unusual band of misfits and unusual space in computing? 00:05:26 - Speaker 1: I always tell people that I like to move like a knight across the chessboard of the industry. I don’t like to go in a straight line and I don’t like to follow an obvious path, so I move a little bit to one side and a little bit across. So before Ink and Switch, I had been working at Hiroku with the two of you. But my background is super varied. I have been an Arctic oceanographer and spent time collecting data at sea. I’ve had waves roll over the side of a flat bottomed research vessel and swamp my boots while I was working on the aft deck. I’ve worked in game development and written physics engines for the Game Boy DS. You know, it’s really hard to ride a physics engine using only integer math. You really sort of take the ability to like divide numbers for granted in day to day computing, and so that was a really cool challenge. Yeah, I’ve done computational Shakespeare, which was cool. There’s the Internet Shakespeare editions are like a scholarly Shakespeare, so if you want to be able to ask questions about, like, can we tell who typeset this page of an original edition by analyzing their use of combined letter ligatures. You know, because they think they can tell different typesetters had different habits for where they would draw type out of the frames. But all those kinds of questions about provenance and genuineness of Shakespeare, we were building technology to enable that kind of computationally. So, yeah, I’ve done a lot of weird and wonderful things before I wound up at I and Switch, and if I’m lucky, I hope to do many more in my career, so, so far so good. 00:06:57 - Speaker 2: And then another important piece here is, what actually is Ik and Switch? What does it do? 00:07:01 - Speaker 1: Right, yeah, I and Switch is an independent industrial research group. We’ll break that down a little bit more, but basically, the way I describe what we do to people who are sort of outside the field is that we think that computers have much more potential to Make us smarter and more capable than we’re really seeing happen with the kind of technology platforms we have today, and we know that that’s true, but we don’t really know how best to pursue it, and we sort of feel like a lot of the fundamental requirements to be able to do that work aren’t in place yet. And so, I can switch research. It is about trying to light the way to make possible these kinds of breakthroughs in the way people build software and the kinds of software people can build by unblocking and discovering paths forward for people. 00:07:57 - Speaker 2: And if one were to flip through the publications on the I can switch website, I’ll link in the show notes, you’d quickly get a feel for, I think a lot of research areas that are things that Mark and I mention and with our guests here all the time on this podcast. So end user programming, for example. Yeah, what a coincidence, increasing the accessibility of programming, obviously kind of tablet touch interfaces or next generation interfaces generally. Local first software is a huge one. We had Mark Klepman on just. Recently to talk about that, and there’s many kind of sub branches of that sort of you think of it as like oh what comes after the cloud or how do we give data agency back to creative people. So those topics, many, many of the things that we talk about here really do come from or have their roots in the research there, and the research is ongoing, so those ideas are continuing to be developed and pushed forward by you and your team. 00:08:48 - Speaker 1: Yeah, there’s an endless amount of work to do, and I think the hard part is really just sort of continuing to find the efficient frontier, right, which is where are the most important unanswered questions, who are the people that can do that work, and how can we convince them to come and spend a bit of time with our ragtag band of adventurers? 00:09:09 - Speaker 2: Could you give us an example of something you’ve published recently on, just to give a taste for the kind of research work that’s undergoing there? 00:09:18 - Speaker 1: I’ll give a little preview of two unreleased papers that are coming up. Maybe that’ll be even more exciting for folk if anyone out there follows us. We have two pieces that are currently in editing and sort of preparation for publication. One of them is called Inkbase and the other one is Paratext. Now, Ibase was led by James Lindenbaum with Shimon Kliski, and it was an exploration of how you could program ink. Now, One way of looking at this is to say, well, what should the programming language for Ik be? But in fact, we sort of deliberately cut that out of scope. What we wanted to know was what would an ink programming environment feel like? What would it be capable of? You know, how could you use it if you had it, even though we didn’t have it, right? As a research project, what we wanted to know was kind of like, well, what would happen if you did? This was also in partnership with Josh Horowitz, who came to us from Dynamic land on his way to grad school. 00:10:22 - Speaker 2: So we built an environment that allowed you to program ink drawings to make them interactive, and ink here you mean the digital ink, the same exact kind that is in use, except there you scribble on your board or whatever, and that ink can be moved, it can be deleted, it can respond to To your interactions and create interactions of its own. 00:10:31 - Speaker 1: And so we saw really cool ideas explored there like Shimon built a music sequencer that produced MIDI out of the system and let him drive sound synthesis engines using drawn lines. James demonstrated how to build like a fitness tracker, you know, sort of like the Seinfeld streak that people often use. What if you could make that a programmable thing or like a to do list? You know, like a Zettel casting or a personal GTD kind of system, but one that you could mold and actually make smarter over time by adding interactions as you develop them the same way that sort of like an Excel spreadsheet grows out of a simple table of numbers into some fully featured and powerful computational environment. We want to know what happens if a drawing evolves over time to become a computational environment that responds to your needs. And your discovered requirements. So that’s the ink-based paper. It was presented at live very briefly this year, but in classic Ink & Switch style, we have a massive paper going into all kinds of detail and with links to some code coming soon. And that kind of represents one angle of our work. Another piece that we’ve been working on, we’ve talked about local first, you mentioned earlier, we’ve been exploring something called CRDTs, that’s a conflict-free replicated data types. A really gratuitously confusing name for what is basically maybe more usefully to think about like Git for data structures, mergeable data maybe mergeable data, yeah, if you have like a JSON file in Git and then you check in changes and then somebody else checks in changes and then you go to merge and you just have like some kind of nightmare of text editing and comma placement and figuring out what really happened. The idea behind automerge is like, well, what if the data structures were smart enough to synchronize themselves and what kind of new capabilities would you get that? And that’s really been sort of foundational research that’s enabled a lot of local first work over the last few years and we’re by no means the only game in town, but one of the problems we keep running into with that is we write a lot of these big essays and we want to have local first tools for it. But today the kind of state of the art is like, OK, well, you can do plain text editing. Or you’ve got nothing, and our essays are these like complex multimedia documents with videos and asides, and we won’t be able to make suggestions and comments all throughout them as we edit. And so, what we needed was a rich text CRDT and that is to say a CRDT that was aware of formatting and spans. And we talked a lot in the Paraex paper, which is coming out soon, I hope, is in concert with Jeffrey Litt, who led that project with Slim. 00:13:12 - Speaker 2: Notion, former guest of the podcast, in fact. Yeah. 00:13:15 - Speaker 1: So we’re looking forward to publishing that because it turns out to be a surprisingly subtle problem. If you’ve ever dealt with non-hierarchical data, like extent data overlapping extents, it just leads to a lot of like really interesting and subtle, quite literal edge cases. So, we’re eager to present that to everybody as soon as we stop finding bugs in the implementation. I think we’re close, we’re close. 00:13:43 - Speaker 2: I think we said before we talked with Lis Lee in a previous podcast about whether software is ever done and certainly research is never done. You have to just kind of draw a line in the sand somewhere and say we’ve advanced the state of the art enough that we think others can build on this. Let’s publish. 00:13:59 - Speaker 1: Oh, I have a great Dune quote for this, it’s right in the zeitgeist now. I’ve been using this line for years, but the way I think about this is in the words of Frank Herbert, Araki teaches the way of the knife, it is finished because we stopped here. Yeah. So by that, I mean, you know, you kind of go into a space and you work for a while, and you can spend your whole career bashing away at one problem, but one of the things I think we do really well and actually that we’ve inherited from your time as lab director is like this ruthless discipline about sort of pencils down on a given date and moving on. If you don’t do that, it’s really easy to get caught up in what you’re doing and to continue to pull that thread, you could be at it for the rest of your career. And maybe that’s good, but by stepping back and sort of re-evaluating, it forces you to kind of Both take the time to publish, but also to sort of take the time to think about what’s next and what’s really important now. 00:14:49 - Speaker 2: I think that maybe this is different for other researchers or labs, but Frankenswitch, I think we want to take kind of a breath first search of the adjacent possible for how we can improve creative computing rather than sort of the depth first, follow one fork in the trail and go as deep as we can. 00:15:07 - Speaker 1: Yeah, the way I talk about this is I often describe us as a lighthouse, you know, we can’t necessarily walk the path for everybody, but we can light the way and hopefully show people how to get to where they need to be and show them opportunities that may not have existed before. And related to that, one of our core values is to produce actual demonstrations of our ideas, right? Real tangible objects, computational objects that a human can use. You know, one is this just kind of comes from our background as like hackers and entrepreneurs, you know, you have to go and build it, but it also kind of comes from a DARPA sort of motto. DARPA, of course, is the American Department of Defense Research Group. And they talk about how you really have to show somebody a robot climbing a wall before they’ll believe you. It’s one thing to say, oh yes, robots can climb walls now, and to write papers showing sort of thrust vectors and forces and friction and so on. But if you walk into a room and a robot climbs a wall, then you believe. So we like to show people the robot climbing the wall, that’s what we do. That’s a long way from having robots in every home, but, you know, once you’ve seen it happen once, then you believe. 00:16:18 - Speaker 2: Well, I think we sort of naturally slid into the topic here, which is independent research and actually you previously described I can switch as being an independent industrial research lab, so it seems like it’d be worth breaking those down a little bit. I guess I’d like to start actually really fundamentally what is research and how does it differ from other kinds of work you could do in the computing field, and then what do those modifiers mean for you? 00:16:43 - Speaker 1: Yeah, so, OK, what is research? In the words of Richard Hamming, who I think is quite an influential figure in this space, his art of doing science and engineering, essay, lectures and book. There’s a really great book from Richard Hamming, published by Stripe Press. If you haven’t got a copy of that, you should definitely pick it up if this stuff interests you. But he said, if you know what you’re doing, and it’s science, you should not be doing it. And if it’s engineering and you don’t know what you’re doing, you should not be doing it. So science is oriented fundamentally towards the unknown. That’s what research is. If you know how to do it, you shouldn’t be doing it. You should be oriented towards the unknown. So, as a research group, we are oriented towards how to solve questions, how to answer questions that nobody knows the answer to, or at least that we don’t know the answer to and can’t find, you know. There’s an old joke that 2 years in the lab could save you 2 hours in the library. So we do try and find prior art and do some survey of the space before we do research, but, you know, sometimes you miss things and then you find out when you go to publish that somebody else had already written about that. But that’s OK. We’re learning as much for ourselves as for anything else. So that’s research, but of course, research comes in a lot of flavors, right? There’s sort of pure research, you know, if you think about the National Science Foundation will fund you. To do things potentially if you have the right connections and proposals that may not bear fruit or may not have any direct industrial application ever, or certainly not for hundreds of years. And a great example of this would be prime number theory. Prime number theory is at the very heart, the very heart of cryptography. Now it is extremely important mathematical research. But most of the core of that research happened like 100 years before anybody found any use for it. So it’s undeniably good for society that this research was done. I mean, depends how you feel about cryptography, but let’s say that it’s good for society that this research was done, but the people who actually did the research, they were dead for centuries or decades at least before any real fruit of this sort of transformational work was known. And that’s not to say that there isn’t value in it, it’s just industrial research. What we’re trying to do is be much closer to what’s happening in the world today, and to sort of connect problems that we see in the real world of humans and software authors and businesses back through this sort of lens of what we care about to doing research. So we want to identify problems or we don’t see solutions. And then we want to develop candidate solutions that could be applied in at least the span of our lives or hopefully over the next few years. 00:19:27 - Speaker 3: Yeah, and I think importantly, it’s a two-way relationship with the industrial ecosystem. You’re solving problems that have some potential industrial application, but you’re also drawing from the experience of industry, you’re talking to the customers, you’re understanding the current technology and what’s possible, you’re aware of the trends and things that are happening and it’s that sort of alchemy of not only solutions to problems, but potential that you’re identifying from the industry. 00:19:51 - Speaker 1: That’s right. And so I think you often find industrial research groups inside big companies like Microsoft Research or Xerox PARC, or Bell Labs. So there have been a number of these very impactful industrial research groups in recent decades, but of course, all of those examples I just listed. are anything but independent. And this brings us to sort of what is perhaps most strange and most unique about ink and Switch, which is that we are not part of an academic body and we are not part of another corporation. We are autocephalus, we are our own head, there’s nothing above us, much like the strange Greek monasteries of the Orthodox church that date back their independence thousands of years. Well, OK, we don’t have thousands of years, but, you know, the independence is a blessing, right? We’re not sort of tied to the Quarterly returns cycle of some business, but it also creates all of these kinds of pressure and constraints. We don’t have this like cozy relationship with the money fountain that will keep trickling us budget year to year. We have to kind of find ways to carve out our existence as we go. 00:21:03 - Speaker 2: And if you’re interested in kind of all the ways that research and labs work in the world, I point the audience to Ben Reinhardt’s work. He’s got a pretty Extensive set of writings on this. He writes quite a bit about DARPA, which you previously mentioned there, Peter, just because they’re one of the more interesting long running government sort of research funding institutions. And he speaks about ink and which specifically as sort of inverting this normal relationship between an innovation organization and it’s money machine, right, which is that the corporate research labs, yeah, Bell Labs certainly is has been a creator of so many incredible things from lasers to GPS. To the transistor, for example, and Xerox PARC, of course, for its short run was legendary. There’s many others like that, say the skunkworks, but typically you have a corporate parent whose job is they’re an industrial company, their job is to commercialize to sell things to make money, and then the money they make from that, they want to put into this research arm. But it does mean that always that that organization, of course, is subservient to that. So with it could switch the idea here a little bit is to kind of switch that around a bit, or at a minimum, make it kind of standalone. 00:22:15 - Speaker 1: Right, and so for us, you know, there’s sort of two puzzles, one which is, you know, how to get our work out there, how to have an impact, because You know, as an industrial research group doing work but not actually impacting the industry, you know, what was the point, you know, you could have just stayed home and watched Netflix all day, would have had the same end result. So it’s important to us to actually sort of change how things happen, but we also need to find ways to do that sustainably over time. So we have a number of hypotheses, you know, as with all kinds of like, long term projects, you tend to have long cycles before you see results. But we believe that there’ll be a combination of strategies that ultimately make this thing self-sustaining, and one of those is to commercialize our technology through producing spin-out companies and then maintaining sort of a share in those companies. And of course, the flagship example of this is Muse itself, right? 00:23:13 - Speaker 2: I mean, that’s kind of the videos. 00:23:14 - Speaker 1: Yeah, spoiler alert. Here’s the big reveal, you know, Muse came out of work we were doing at I can Switch. And the original version of Muse was a prototype built at the lab, and of course, the 3 founding partners, 3 of the 4 founding partners, were there 4 of you in the beginning? 00:23:32 - Speaker 2: We were 3 actually, so they were all 3 lab participants. 00:23:35 - Speaker 1: Yeah, so, all 3 of the founding partners of Muse were ink and Switch staff, and of course, that was the 2 of you, and then Julia as well. So the lab helped develop the concepts that led to Muse. It brought the team together and it built the initial prototypes, and then as a spin out from the lab, the lab retains some stake in the company. So we’re not only delighted to see our ideas put into practice, we’re incredibly excited to see the work that you’re doing and the testing of our values in the world, but we’re also sort of directly incentivized to see you succeed. And so I really love this kind of like Symbiotic relationship where we have both proof in the market of our ideas being feasible, but we also have this incentive to follow closely and make sure that, you know, we’re doing research that can help and that we’re communicating with you and vice versa. So I think it’s a really great relationship and I’m looking forward to many more of those as the years go on. 00:24:36 - Speaker 2: Yeah, I hope at least the flywheel that we’re trying to go for here, but as you said, it’s a very long cycle to prove that out is do research that is driven by real world problems. And of course, basic science and just the pursuit of truth for its own sake is absolutely incredibly valuable, the prime number theory you mentioned or maybe Gregor Mendel sitting there breeding his pea plants just to learn about how the world works or to learn about mathematics or computing’s most basic principles is worthwhile, but in it which really goes after things that are related to real world problems, all the ones that are maybe too far out, for example. Startup or a commercial entity to tackle. 00:25:16 - Speaker 1: What a great segue. Let’s talk about why Ink and Switch exists a little more. What we’ve talked about is the notion of like independent industrial research in the abstract. You could do this kind of independent industrial research in any field, material science, you could build spaceships if you had enough capital, which apparently some people do, you know, you could study journalism, as long as you have this sort of like connective loop. But in the words of Thoreau, it’s not enough to be busy, so are the ants. The question is, what are we busy about? And what we’re busy about is sort of this despair that computers have increasingly become mechanisms entirely for consumption, and that so many of the groups and bodies that were building the bicycles for the mine that were pursuing this sort of vision of computers as these intelligence amplifying devices have kind of retreated from that vision towards a more Natural consumer demand. And I don’t hold this against Apple or anybody else, you know, there are billions of people on Earth who need great computers, and most of them are not scientists or authors or policymakers, and so it’s natural that they would sort of follow the pull of their users and go to where the market is. But we believe that this has left a gap where there just simply isn’t a major computing group that’s actually focused on solving problems. Around how to use computers in this sort of intelligence amplifying way. And specifically, the reason why a research group exists to solve this problem is that people are, oh, well, startups are these great innovators. That’s only true in a very narrow way. All three of us on this call here have plenty of background in startups, both working in them, and founding them, advising them, etc. And startups can take certain kinds of risks, but they can’t take every kind of risk, and it’s sort of like the old advice about only break one law at a time, you know, it’s the same thing with startups, which is you should only take one risk at a time, and generally for the startup, there’s like a core hypothesis to the startup that they are trying to test. It’s Some new kind of product or in some new kind of market. And so the advice people give startups is, well, you should be conservative in all your other choices because you’re already taking a massive risk on this one axis. And so the way we see that play out is lots of people are building startups that would be much more effective from, we think a software and user perspective as local first software, but they build them as cloud sass because that’s what the market expects and that’s what’s easy, that’s what’s known how to do. It’s also what venture capitalists expect. Right, venture capitalism is, let’s be honest, mostly about pattern matching and comparing with other past successes and trying to into it based on this sort of both guiding and being guided by the structure of what the market is doing right now. And that’s fine too. It’s just, this doesn’t leave much space for the kinds of major transformative direction. That a research group can pursue. We can think a decade out. A startup can only think 2 or 3 years out at most. And so that means that we have the opportunity to do work that simply isn’t possible in the context of a startup. And in so doing, we can bring those time horizons in closer and bring things into sort of striking range for a startup, and then those startups can go and pursue these ideas. And in fact, we’re seeing that all the time these days, not just with Muse, but You know, we’re seeing lots of startups these days who reach out and contact us and say, hey, thanks so much for your essays, they were really inspiring, they’ve been really influential on how we’re thinking about this, and we’re hearing from venture capitalists when there are local first startups in some new domain, we’re seeing tangible results of this work on the industry today. 00:29:10 - Speaker 2: Your point about markets and the fact that sort of even startups or commercial ventures, I think just generally speaking, need to follow market trends. It would be dumb not to. In fact, that’s almost the definition of a good opportunity is capitalizing on an immediate trend and In fact, what we see that for example, ARPA slash DARPA, what they do is try to change the whole industry. So one famous example of theirs is they decided in the early 2000s, we think self-driving cars should be a thing, and they put their money to work with prizes and other kinds of funding grants to Get a bunch of both researchers but also companies and investors interested in that, and they basically kicked off that whole revolution that has yet to perhaps fully yield fruit, but at least you see they got a bunch of people caring about it, they got a bunch of money into it, they got a bunch of smart people who want to make that future come true. 00:30:05 - Speaker 1: Yeah, and DARPA refers to this as the challenge-based model. So they use this trick everywhere. DARPA doesn’t actually do any research in-house. They are fundamentally a funding agency. And so, with self-driving cars, they said, hey, we’re gonna give you this challenge, which is you have to drive this car across the desert. And the first year, I think none of the contestants made it to the finish line at all, but each year it got closer and closer until they were eventually, there were entrants that were able to traverse this whole landscape and they won some prize money, but they talk about at DARPA how The way they evaluate projects is that they want things that are really ambitious in their outcome, but they also want things that are tangible in their direction. And so they need to be both very hard, they call it DARPA hard as sort of like a discriminator of ambition. They don’t want something that’s just difficult, they want something that’s really difficult, but they also want something that can be articulated in like a real world results that can be measured or evaluated. 00:31:06 - Speaker 2: Yeah, so obviously I can switch doesn’t have that same structure. We do the research in-house. We don’t have government money to spend, etc. but I think just broadly this idea of moving the market rather than going with the trends that exist, we’re saying we actually don’t like some of the trends where the massive consumerization of computers, which has many nice benefits like most people use the computers in their pockets as Messaging devices, right, and stay in touch with friends and family. Great, that’s good, but then who is working on the creative tools? Creative tools are just not sexy, not interesting, not where it’s seen to be the place that smart people or smart investors put their effort. 00:31:45 - Speaker 1: Well, the smart investors is, I think the secret here. This is the core, right, which is that if you’re an investor, you need a Big market and it turns out that a bunch of novelists and like researchers, there aren’t a billion novelists and researchers to buy your product and if there were, they probably don’t have the budget themselves to go after it. So I think it’s perceived as a relatively small market, though we think there’s a lot of opportunity there if you build tools focused for them. 00:32:10 - Speaker 2: I don’t know, Microsoft Office did OK back in the day. Adobe seems to be doing all right. 00:32:14 - Speaker 3: That’s true. Yeah, so here’s my variant on this. I think there are actually 3 big markets that are already very well funded and being effectively pursued. One is what I would call consumer software, this is ad funded, engagement based software, Facebook, and so forth. There’s enterprise software, which is perhaps actually the most profitable domain right now. This is now Microsoft. AWS stripe, things like that. A third one actually that we often don’t mention is like surveillance and weapons related stuff, like kind of government stuff. That’s all very well funded. So this is an area with individuals that’s perceived to be less economically lucrative. So the entirely predictable and predicted outcome is that there’s just much less investment and therefore, much less progress in it. And we’re trying to jumpstart that flywheel a little bit and get some more progress in this area. 00:33:00 - Speaker 2: But I do think it’s not just on the investor side, we talked to Jason Yuan about this, which is, for example, doing design work for designers, do they want to go to work on the next Excel or do they want to go to work on the next, I don’t know, Snapchat and. At least in the recent past, I feel like these consumer facing companies because they are so big because they have such big outsized brands, but you’ve heard of them, but also they have so much money to put into it, they can do a lot to build those brands and be perceived as a place that the best talent comes to. So I might think of one of the goals of use and I can switch and all the other folks who are in our sphere of creative tools and tools for thought and so forth is just making that a cool area that people are drawn to work in. 00:33:47 - Speaker 1: Obviously you got to pay your rent and Nothing says cool like 6000 word essays on esoteric technical subjects, and then we all got our own definition of cool. 00:33:55 - Speaker 1: Oh yeah. 00:33:56 - Speaker 3: I think that’s true. I think that gets to this idea of institutional alchemy, which is it’s not a matter of just going to a space and working on it or even of just providing funding for it. You gotta bring together all these different factors. There’s funding, there’s vision, there’s people. There’s memes, you know, there’s lines of research, you need it all to be there. Communities, yeah, exactly. And one of the things I’m really proud of with ink and Switches I think we’ve managed to do that somewhat for this space. There’s this nexus, this scene that is formed around the work. 00:34:29 - Speaker 1: Yeah, I think that’s true. It’s very exciting to see a growing space, and of course, we’re talking about Ink & Switch and so I’m sort of focused on that, but I want to note that like we’re by no means operating in a vacuum, and there are plenty of other people like Gordon Brander out there who are writing about this, and there’s lots of startups like Rome Research, who are out there building products in addition to Muse, and I like to think that we are. Certainly a significant player in that ecosystem, but I don’t mean to sort of imply ownership over it or take credit for what is by every indication. A rapidly growing and very dynamic space. I think that’s true. One thing I would like to talk about is why this is important, and why we’re doing this. Now, I think all of us, sort of longtime members of the lab. Believe that the world is kind of in a rough spot right now, like in a big picture sense, right, we have major climate change problems ahead of us, we’ve got this sort of breakdown of the old social order, which is largely driven by new dynamics and communication tools through social media, without getting too much into that, there’s these attentional economy problems, right? You know, you go to unlock your phone and there’s 75 push notifications waiting for you from a mixture of actually useful things and marketers that have somehow managed to slide into your mentions. So you’ve got like all of these kinds of, like, real major issues, and here we are monkeying around with CRDTs and programmable ink. You know, I’ve had friends who are like, if you think these problems that are facing the world are so important, why are you playing with computers? Why aren’t you out there working on the front lines of climate change? I think it’s a good critique and it’s a fair question, but I think, specifically our work. And our motivation behind our work is that we want to empower the people who have those first order skills to be able to attack these problems. We want to support physicists, we want to support journalists, we wanna support writers and authors, and there’s this whole pipeline of knowledge. Pipeline is Gordon Brander, if you’re listening. There’s a systems theory explanation here. It’s not a pipeline, there’s lots of feedback loops at every step along the way, but there’s this system of cultural change that occurs where real knowledge about the universe produces change in the way that we live. And at one end of the pipeline are scientists and social theorists and other people, activists, and then, you know, it goes through a long process that involves a lot of different parties and systems like journalists and writers who bring these ideas to the public and talk about them and communicate them and eventually winding up with policymakers and entrepreneurs and government officials who either change public policies, introduce new laws, or start new businesses and pursue opportunities revealed by this. And so all of that kind of structure. You know, we believe that there’s a lot of unnecessary friction and loss of productivity caused by these bad tools. Every time someone who could be working on climate change loses their data because whatever, the computer reboots to run an update or, you know, they have some great idea and they go to take a note, but they get distracted before they take that note, because their phone is telling them to play whatever Flappy Bird or something. Like anytime those kinds of things happen. That is slowing down and taxing our ability to respond to all of these problems. And so we as a group, the people in the lab, don’t have physics degrees. We’re not social theorists, but we hope that by working with journalists and talking to them, and working with scientists and talking to them, and working with writers and talking to them, that we can learn what the challenges these people have are. And develop a set of values and theories and practices that we can then build infrastructure around that will enable these people to be more effective. But why that, right? The answer is just, this is what we’re good at, this is what we know how to do, right? We’re taking our skills, our unique advantage, and we’re trying to apply them indirectly, perhaps, but sincerely and over a prolonged time scale and intentionally towards enabling those kinds of changes. 00:38:58 - Speaker 2: 80,000 hours has a kind of whole set of essays and theory about how to apply your career in the most effective way as possible to do good in the world, and they reference exactly that point you just mentioned, which is you have to find the overlap between a meaningful problem in the world. What you specifically are great at, drawn to or passionate about, or you have skills or knowledge or experience that very few others have. And the third one actually is an area that not a lot of people are working on. And so I think that’s part of what drew us to this space for for and switch. 00:39:31 - Speaker 1: Not a lot of people were working on this when we started here. Certainly there have been times when people have kind of looked at me and been like, why aren’t you doing AI or ML or blockchain or cloud software or like any of the things that anybody ever raises any money to work on. It’s like, well, doing what everybody else does takes you where everybody else is going. If you want to solve interesting problems, you’ve got to work on things that other people aren’t already doing. That’s part of it. 00:39:57 - Speaker 3: Yeah. Another angle on the why that I would give in addition to this like kind of productivity and effectiveness motivation is one of just aesthetics and beauty and sentiment. I talk about how we are using these tools 468 hours a day, and it’s incredible. demoralizing if they’re not beautiful, if they don’t feel good. And I think that is the state of a lot of our tools. And you would feel terrible and in fact, refuse to go to work on a really creative project, 8 hours every day in like some terrible concrete block building, right? It would be demoralizing. That’s a situation that I feel like we are in with a lot of our tools. And just making people feel better about what they’re working with well I think also enable more good work. 00:40:37 - Speaker 1: Yes, we’re asking all of the artists and scientists of the world to do their best work inside a Walmart full of billboards, while the internet is screaming at them. Yeah. It’s not ideal. 00:40:49 - Speaker 2: Yeah. Yeah, to sort of summarize what both of you said or perhaps my take on it would be that computers and software and the internet have become a really fundamental infrastructure in the world. They’re like roads and bridges, they’re like our agricultural systems and our economy, and those things need to work well and for us to do anything else, solve any other worthwhile problems or do. Things like make great art, create beauty in the world, and computers have gone from being something that is maybe more of a toy or a novelty to being something that is fundamental and everywhere. And so them supporting the humanity’s best aims and noblest pursuits versus being swept up in that Walmart of billboards demanding your attention is something we think will produce returns for all of society. 00:41:41 - Speaker 1: Talking about all of society, I think one of the really valid criticisms of both our work and a lot of the other work in this space is that it is rooted in this kind of technocratic elitist view that there are experts and brilliant people out there in the world, and what we really need to do is enable them to do better work. You know, I have young kids and I was at sort of some 3 year old’s birthday party in a playground. And I got to talking to a golf course equipment manager who lives here in this town, super nice guy, sort of opened with, oh, I don’t know too much about those computer things. But he’s interested in what we did, so I was trying to sort of translate my work for him because, you know, it’s nice to hear about what other people do and share what you do. 00:42:23 - Speaker 2: Just as a note, the cocktail party conversation, which is exactly what I described this, trying to bridge, you know, describe your nichey work to someone that’s completely outside the field, was one of the biggest challenges for me working on Incode switches very hard to summarize that. It’s gotten a little easier since I’ve been onus cause I can just say, yeah, we’re making an iPad app. 00:42:43 - Speaker 1: Well, so, funny enough, this gentleman who claimed not to know much about computers was actually more plugged into the problems of our industry than anybody I know in Silicon Valley that you just pick off the street. He starts telling me about how he doesn’t trust the tractor companies. Because they’re taking all their data and putting it in cloud services and it’s not necessarily to the benefit of him or the equipment managers at the golf course, and how he’s been building all his own software and FileMaker Pro to do all of this stuff in-house, because he doesn’t like that all this data is going to these. Enterprises who are deciding what they pay and how much maintenance is going to cost and all these things, and he’s trying to maintain his independence and he doesn’t trust them not to change the data. I’m like, oh man, you get this work better than almost anybody I talked to. You understand the problems cause you’re out there on the edge. You’re the guy who is suffering because of all these venture capital backed startups and this big push to cloud sass, like, yeah, there’s a lot of benefit, but there’s a lot of cost. And this guy sees it in a way that most Silicon Valley software people don’t, because he’s feeling the pain. And so one of the things that I think we need all to do as a group is do a better job of like. Realizing that climate change is not something for scientists to solve, it’s too late for that, right? We need resilience at every level of our communities. Everybody is going to be finding new ways to live and working on new solutions to these problems, right? Social media driven sort of like cultural collapse. It is not something that only media theorists are going to solve. It’s all of us on our phones, on our computers, in our lives are going to find new ways to communicate. We’re going to need new tools to find that quiet space for ourselves, whether you’re, you know, designing knitting patterns or whether you’re Organizing neighborhood barbecues and potlucks, right? Like this is not solely a problem that affects sort of elite thinkers in society, and we should be building tools for everybody and thinking really about deep resilience through all of society. And so I think that’s something that I’ve been challenged on lately and I’ve been thinking a lot about and so I want to encourage everybody listening to remember that like this is an all of society problem and so we should be building all of society responses. 00:44:57 - Speaker 2: Well, after that grand and sweeping discussion of the big picture stuff, I’d actually be curious to just get a little nuts and bolts. What does an Ink & Switch project look like? Mark and I have talked before here about the Hollywood model a little bit, and you talked in the very beginning about the pens down, the strict pens down at the end of the project, but for example, two of these two projects you mentioned earlier, what does it actually look like start to finish? 00:45:22 - Speaker 1: So, we have a number of sort of active areas of research, and there are other areas we need to expand into and haven’t, but that’s a separate problem. So, to do a project, the first step is to find a problem, and so we have a process of sort of developing project briefs we call pre-infusion. And so, you know, around the lab and in our community of past and future collaborators are a lot of people who are sort of tracking these kinds of interesting problems, but a good Ink & Switch problem is one that we think is really important. That we don’t know how to solve and that we don’t think somebody else will solve for us if we just wait a little 00:46:03 - Speaker 1: bit. 00:46:04 - Speaker 2: So maybe an example here might be the rich text CRDT you mentioned earlier. We’ve done lots of projects with CRDTs because that’s a great technology for collaboration and local first, but then anytime we go to add text, you go, can we make this rich text? Nope, because there’s no such thing as a rich text CRDT. OK, well, put that in the future research bin somewhere. 00:46:26 - Speaker 1: Right, and I do want to point out that Kevin Jan’s uh YJS project has a rich tech CRDT, but it had some properties that we felt didn’t make it suitable for the particular task we had at hand, and also, while he’s done a ton of great work there, There’s no sort of documentation about how to do this that other people could pick up and draw from because it’s, you know, an implementation he wrote to solve his problems. So we wanted to write something about this, both so that we could implement it as well, but also so that other people could learn from this and build on this work in a more sort of open way. So that’s a great example of a problem. So basically do some research upfront. We usually have one person doing this sort of pre-infusion thing, they’ll look at the state of the art, they’ll try and scope a problem, they’ll define what we need to do, and they’ll kind of write up like a 1, maybe 2. Page description of what’s the problem we’re trying to solve and how are we going to solve it and who do we need on the team to be able to solve that. And that’s important because as you’ve talked about the Hollywood model before, but for folks who haven’t heard that episode, we sort of treat each research project kind of like a film production. We put together a team of experts or domain knowledge or generalists with the right kind of philosophy, depending on the project. To execute on some vision, and then when it’s over, we ship the paper and most people move on and go on to whatever they’re doing next, just like you would if you were building a film, rather than these sort of like permanent staff researchers. So we do have a couple of folks like that around as well. And so that’s kind of the pre-infusion. 00:47:57 - Speaker 2: One thing I’ll just note briefly on the staff side is that being able to hire people kind of as short term for these projects, which are usually a couple of months, means that you can get the exact combination of skills that you need. When we’ve done more kind of innovation oriented R&D within an existing company that has a standing staff, you know, when it comes time to say, well, we need to implement this back end system, what are we going to use? Well, we use Erlang because we have an Erlang programmer on the team rather than coming at it from what is actually the best technology or the specific skills that we need and go. Find those people. I think one of the more dramatic examples to that for me, Peter, was when you came into the lab and started advocating for CRDTs as a solution to the kind of sinking problems we’ve been thinking about a little bit, and then we decided to do a project around that, you know, this was 2016 or something, because this was such an early time for that. There was probably only 10 or 12 people in the world who you could consider experts or even reasonably knowledgeable about CRDTs. We literally made a list, you made a spreadsheet and contacted every one of them and saw who might like to work with us or who did we vibe with, and that’s how we met Martin Kleppman. 00:49:08 - Speaker 1: Yeah, and we’ve been working with him ever since. 00:49:11 - Speaker 2: Yeah, it turned out to be a great collaboration, but it’s a good example of where You don’t start from, you know, you say, well, we’ve got some post graphs experts on the team, let’s do post graphs. No, you start from what is actually needed if you look at the whole world of skills and technology and design needs and what have you, and then go find the specific person or people who have that exact skill. 00:49:33 - Speaker 1: Yeah, and one of the other sort of killer advantages of the lab is that there’s Code for America, and Code for America is this great organization that basically gets engineers to spend some time doing basically civic service, building software for some kind of governmental body or agency and. You know, we could debate sort of what percentage of that work ends up being sort of abandonwa or how effective that is, but I think the model is great, which is it sort of recognizes that in your career, you may have these gaps between things, you’re finished one thing, you’re not quite ready to start something new. And so Code for America, it’s sort of like an escape hatch that people use when they’re tired of their job or just need a break or want to do something different. Similarly, because we run these sort of short term projects, We’ve had this amazing ability to bring in incredibly talented people who will be in eventually are snapped up by the top companies in our industry. Moments later, but we get to work with them for a few months on some really interesting project and not only do they influence our thinking, but we influence their thinking, and so we’ve really been able to scale our influence on the world. And to bring in a ton more insight and knowledge and sort of inspiration by working short term with people than we would have by working long term. And so I think that’s one of our like secret weapons for sure at the lab. So, once we scope a project and kind of say, OK, well, we want to do this thing, we’re going to need these kinds of people, we go into recruiting mode, as we said, and we bring in a team. And then at that moment, our goal is like on kickoff day for a project, not always, but this is sort of the archetype. We want to have like a really clear sense of, you know, what’s the tech stack, what are we going to build, what are some vague milestones along the way. At this point, we’ve done prep, and you know, no plan survives contact with the enemy. Once the project gets started, things tend to change, but we want to come in with like a really clear direction and hit execution mode, and the team just focuses, they go head down. And they just engineer the crap out of it for like 2 or 3 months. We always pick sort of a fairly strict end date at the start of the project. You know, the fear of like impending deadlines helps everybody stay focused. And the other thing we do throughout the project is we do sort of a show and tell every other week where teams come and say like, hey, this is what we’ve been up to, you know, share with the rest of the lab, get feedback, but that sort of regular cadence of showing your work both helps people to stay focused and on task, but it also gives you kind of like regular mile. Stone so you don’t end up rabbit holing too bad. You know, it’s not like there’s like a law, but you have to show up on this day and have something new to demo. But if you’re going to turn up on Friday, on Monday, you know, this week we’re going to be showing our work, so you sort of make that extra little bit of effort to like make sure things work a little better or to polish something up a little bit or just to make sure you don’t break the build on Thursday kind of thing. So I really like that cadence. And then at the end of that time, it’s sort of like pencils down, project is done. And in the beginning, we really just sort of like at the end of the project, someone on the project, the project lead, would usually write a little internal Google doc talking about what we did, and in the really early days, everybody at the lab was on the same project, so everybody knew what the project did because you did it together. But at the end of the project, these days we’re spending more and more time writing, editing and publishing. And today that process generally takes 2 months, 2 to 3 months of work, and it’s certainly not full time work and often overlaps with pre-infusion for the next project, but it’s very much this kind of like process of not just publishing to share the knowledge with everybody else, but also mining your memories of that experience for insight and figuring out what happened. So that you can tell that story, and the process of writing, I think, really turns the work into knowledge in a really powerful way. And so as valuable as it is to publish this work to everybody outside of the lab, I think it’s at least as valuable to those of us inside the lab because it adds this extra level of rigor and understanding that we all benefit from. And then at the end of the publication, we put up these massive essays with lots of cool interactive elements and links on the sides. And then you dust your hands and take a quick breather and head back into pre-infusion and do another. 00:54:01 - Speaker 2: I think the you can switch essay style is something that developed over time. I think you wrote one of the first pieces just kind of as a medium post, you said, hey, we should publish about this work, and then we’ve gotten more comprehensive over time and really putting a lot of effort, like you said, basically now, at least in terms of wall clock time spending essentially as much time writing. And distilling the results to understand what’s important, what are the real findings, and then put it into this very nicely comprehensible thing that others can read and learn from. And certainly I’ve experienced that thing you talk about, which is taking the time to do that. I feel like I extract more insights from the project through the writing process. And then in terms of remembering it both in terms of institutional memory, but also in terms of just as an individual, I remember the things better or I can go reference my own work. It happens with some frequency of muse where we say a design question comes up or a technical question. I say, you know, actually we researched that exact thing at I can switch, let me go pull up the reference and. Sometimes we have some internal docs, but those tend to be pretty rough and they haven’t been through the same clarifying process of writing for an external audience. But when we’ve published about it publicly, then it’s much easier to both find what you’re looking for, but then also be able to draw from that and our team can use that to make decisions about something we’re working on the product. 00:55:24 - Speaker 1: Oh, it’s great to hear that that stuff is benefiting you and that you’re able to take advantage of that. I mean, obviously you’re very close to the lab, but it’s nice to know that our target audience is able to get that kind of yield. I’m always asking how we can reinvent the lab, you know, I’ve just talked about what the lab is, but I’m always thinking to myself about what’s next. I’m always thinking about how can we change. We’ve gotten much better at writing, we’ve developed this, we call it the academic voice, it’s not academic, academia has too much jargon and It has a really powerful culture around like these latexch publications. We try to make our writing more accessible than academic papers generally are in terms of tone and language, but we try to take a lot of inspiration from academic writing in terms of maintaining a sedate tone, avoiding superlatives, supporting any statements that we make. We do actually publish a lot of our work in various academic venues these days. But first and foremost, we published for the web and for this sort of industry audience and for ourselves, and the academic version sort of follows on from that. 00:56:31 - Speaker 2: Yeah, the academic format, you might think of as being an illustration of how the lab sits on the innovation spectrum between startups and classic academia, where, yeah, academia, you know, you typically have, yeah, these PDFs, they’re published in particular venues, you’ve got peer review, you’ve got a lot of conventions about citations and things designed to enforce rigor. And then in the startup world, people do publish, but it’s usually some engineer tried a framework one time and they wrote a blog post about their insights on that. 00:57:02 - Speaker 1: Right, or the point of it is like this marketing exercise for a product. 00:57:05 - Speaker 2: Yeah, exactly, marketing for startups, yeah. 00:57:08 - Speaker 1: We try to be very sober in our presentation and to be really explicit about trade-offs and shortcomings and open questions, and I think that serves us well and it serves our readers well because we try to make sure that we portray the work we do with the inspiration and the context that we hope will make people excited about it. We also try to be really transparent about what we have and haven’t done and what remains to be done as well. 00:57:35 - Speaker 2: Well, as a place to end, you mentioned what’s next for the lab or how might it expand or reinvent itself, what exactly is on your mind there? 00:57:45 - Speaker 1: Well, to me, the biggest areas where we can improve are both growing the scope of the kind of work that we do in terms of both getting broader and deeper, I want to see us expand into other adjacent areas, hardware, and I’d like to see us expanding into ever more fields of research, but some of that comes down to just sort of like funding bandwidth and people around. But I’m also interested in Expanding the ways that we work and opening up the lab to more people. We have this vision of a new kind of computer, and you know, it’s that vision of a different kind of way of using computing, not just programming, but computing that is more empowering, that makes us better versions of ourselves, that lets us do more things to do better work, to work better together, to think deeper. And I just think that our current working model is doing fine, but there has to be so much more opportunity for us to take what we’re doing to a wider audience and to get more people involved. And I think some of that is writing more about the why behind the

Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: There’s been very little innovation and research more generally into what is a good interface for inputting equations. So I think most people are probably familiar with Microsoft Word or Excel have these equation editors where you basically open this palette and there is a preview and there is a button for every possible mathematical symbol or operator you can imagine. 00:00:28 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad and Mac. This podcast isn’t about Muse the product, it’s about Muse the company and the small team behind it. I’m Adam Wiggins here today with my colleague Mark McGranaghan. Hey, Adam. And joined by our guest Sarah Lim, who goes by Slim. Hello, hello, and Slim, you’ve got various interesting affiliations including UC Berkeley, Notion, Inc and Switch, but what I’m interested in right now is the lessons you’ve learned from playing classic video games. Tell me about that. 00:01:01 - Speaker 1: So this arose when I was deciding whether to get the 14 inch or 16 inch M1 MacBook Pro and a critical question of our age, let’s be 00:01:10 - Speaker 1: honest. Exactly, exactly. I couldn’t decide. I posted a request for comments on Twitter, and then I had this realization that when I was 6 years old playing Organ Trail 5, which is a remake of Organ Trail 2, which is itself a remake of the original. I was in the initial outfitting stage, and you have 3 choices for your farm wagon. You can get the small farm wagon, the large farm wagon, and the Conestoga wagon. I actually don’t know if I’m pronouncing that correctly, but let’s assume I am. So I just naively chose the Conestoga wagon because as a 6 year old, I figured that bigger must be better and being able to store more supplies for your expedition would make it more successful. I eventually learned that the fact that the wagon is much larger and can store a lot more weight means that it’s a lot easier to overload it. Among other things, this requires constantly abandoning supplies to cut weight. It makes the roover forwarding minigame much more perilous. It’s a lot harder to control the wagon. And yeah, I never chose that wagon again on subsequent playthroughs, and I decided to get the 14-inch laptop. 00:02:12 - Speaker 2: Makes perfect sense to me and and what a great lesson for a six year old trade-offs, I feel like it’s one of the most important kind of fundamental concepts to understand as a human in this world, and I think many folks struggle with that well into adulthood. At least I feel like I’ve often been in certainly business conversations where trying to explain trade-offs is met with confusion. 00:02:35 - Speaker 1: They should just play Organ Trail. 00:02:37 - Speaker 2: Clearly that’s the solution. And tell us a little bit about your background. 00:02:42 - Speaker 1: Yeah, so I’ve been interested in basically all permutations really of user interfaces and programming languages for a really long time, so this includes the very different programming languages as user interfaces and programming languages for user interfaces, and then, you know, the combination of the two. So right now I’m doing a PhD in programming languages, interested in more of like the theoretical perspective, but in the past, I’ve worked on I guess, end user computing, which is really the broader vision of notion, I was at Khan Academy for a while on the long term research team. 00:03:18 - Speaker 2: Yeah, and there I think you worked with Andy Matuschek, who’s a good friend of ours and uh previous guest on the podcast. 00:03:24 - Speaker 1: Yes, definitely. That was the first time I worked with Andy in real depth, and I still really enjoy talking to him and occasionally collaborating with him today. So, I guess, prior to that, I was doing a lot of research at the intersection of HCI or human computer interaction and programming tools, programming systems, I guess. So, one of the big projects that I worked on as an undergrad was focused on inspecting. CSS on a webpage or more generally trying to understand what are the properties of like the code that influence how the page looks or a visual outcome of interest, and there I was really motivated by the fact that you have these software tools have their own Mental model, I guess, or just model of how code works and how different parts of the program interact to produce some output and then you have the user who has often this entirely different intuitive model of what matters, what’s important. So they don’t care if this line of code is or isn’t evaluated, they care whether it actually has a visible effect on the output. So trying to reconcile those two paradigms, I think is a recurring theme in a lot of my work. 00:04:30 - Speaker 2: And I remember seeing a little demo maybe of some of the, I don’t know if it was a prototype or a full open source tool, but essentially a visualizer that helps you better understand which CSS rules are being applied. Am I remembering that right? 00:04:43 - Speaker 1: Yeah, so that was both part of the prototype and the eventual implementation in Firefox, but the idea there is The syntax of CSS really elides the complexity, I think, because syntactically it looks like you have all of these independent properties like color, red, you know, font size, 16 pixels, and they seem to be all equally important and at the same level of nesting, I guess, and what that really hides is the fact that there are a lot of dependencies between properties, so a certain property like Z index, you know, the perennial favorite Z index 9999999. Doesn’t take effect unless the element has like position relative, for example, and it’s not at all apparent if you’re writing those two properties that there is a dependency between them. So I was working on visualizing kind of what those dependencies were. This actually arose because I wrote to Burt, who is one of the co-creators of CSS and was like, Hi, I’m interested in building a tool that visualizes these dependencies. Where can I find the computer readable list of all such dependencies? And he was like, oh, we don’t have one, you know, we have this SVG that tries to map out the dependencies between CSS 2.1 modules, and even there you can see all these circular dependencies, but we don’t have anything like what you’re looking for. That to me was totally bananas because it was the basic blocker to most people being able to go from writing really trivial CSS to more complicated layouts. So I was like, well, I guess this thing doesn’t exist, so I’d better go invent it. 00:06:12 - Speaker 2: Perfect way to find good research problems. Now, more recently, two projects I wanted to make sure we reference because they connect to what we’ll talk about today, which is recently worked on the equation editor at Ocean, and then you worked on a rich text CRDT called Paratext at In and Switch. Uh, would love to hear a little bit about those projects. 00:06:34 - Speaker 1: Yeah, definitely. So I guess the Paroex project, which was the most recent one was collaboration with Jeffrey Litt, Martin Klutman and Peter Van Harperberg, and that one was really exciting because we were trying to build a CRDT that could handle rich text formatting and traditionally, you have all of these CRDTs that are designed for fairly bespoke applications. They’re things like a counter data type or a set data type that has certain behavior when you combine two sets, and we’re still at the stage of CRDT development where aside from things like JSON CRDTs like automerge, we don’t really have a one size fits all CRDT framework or solution. You still mostly have to hand design and implement the CRDT for a given application. And it turns out that in the case of something like rich text, it’s a lot harder than just saying, oh, you know, we’ll store annotations in an array and call it a day, because the semantics for how you want different types of formatting to combine when people split and rejoin sessions and things like that are all very complex and it turns out that we have a lot of learned behaviors that arise, even from just like, Design decisions in Microsoft Word, where you expect certain annotations to be able to extend, certain annotations to not extend, things like that. Capturing all of the nuance in that behavior turns out to be really difficult and requires a lot of domain specific thinking. But we think we have an approach that works and I would really encourage everyone to read the essay that we published and try to poke holes in it too. This was like the 5th version of the. algorithm, right? So like months ago, we were like, all right, let’s start writing and then Martin, who has just an incredible talent for these things is like, hey, everyone, you know, I found some issues with the approach and, you know, oh no, 00, and sort of we fix those, we’re like, all right, you know, this one’s good and just repeat this like week after week. So I really have to give him a ton of credit for both coming up with a lot of these problems and also figuring out ways to work around it. 00:08:33 - Speaker 2: We talked with Peter a little bit recently, Peter van Hardenberg, about the pencils down element of the lab, but also just research generally, which is there’s always more to solve, you know, it’s the classic XKCD, more research needed is always the end of every paper ever written, which is indeed the pursuit of the unknown. That’s part of what makes science and Seeking new knowledge, exciting and interesting, but at some point you do have to say we have a new quantum of knowledge and it’s worth publishing that. But then I think if it’s just straight up wrong or you see major problems that you feel embarrassed by, then if you want to invest more. 00:09:09 - Speaker 1: Right, exactly. I think in this case. There was a distinction between, there’s always more we can tack on versus we wanted to get it right, you know, and in particular, the history of both operational transforms or OT and CRDT for rich text, just text in general is such that it’s this minefield of I guess to use kind of a gruesome visual metaphor, just dead bodies everywhere. You’re like, oh, you know, such and such algorithm was published and it’s such and such time and it was new hotness for a while and then we realized, oh, it was actually wrong and this new paper came out which proved like 4 of the algorithms were wrong and so on. And so with correctness being such an important part of any algorithm, of course, but also kind of this white whale in the rich text field, we thought it was important to at least make a credible effort to having a correct algorithm. 00:09:57 - Speaker 2: Yeah, makes sense. Yeah, I can highly recommend the Paroex essay. One of the things I found interesting about it, maybe just for anyone who’s listening, whose head is spinning from all the specialized jargon here, CRDTs are a data structure for doing collaborative software, collaborative documents, and then, yeah, rich text, the Microsoft Word is the canonical example there. You can bold things, you can italic things, you can make things bigger and smaller. Well, part of what I enjoyed about this paper was actually that I felt, even if you have no interest in CRDTs, it has these lovely visualizations that show kind of the data representation of a sentence like the quick brown fox, and then if you bold quick, and then later someone else bolds fox, you know, how do those things merge together. But even aside from the merging and the collaborative aspect, which obviously is the research, the novel research here. I felt it gave me a greater understanding of just how rich text editing works under the hood, which I guess I had a vague idea of, but hadn’t thought about it so deeply. So, highly recommend that paper. Just give them the figures, even if you don’t want to read the thousands of words. 00:11:05 - Speaker 1: I’m glad you like the figures. They were a real labor of sigma. 00:11:08 - Speaker 2: Perfect, yeah, so. 00:11:10 - Speaker 1: The one thing I would add is that CRDTs are a technology for collaboration, but the way they differ from operational transforms or OTs is that a CRDT is basically designed to operate in a decentralized setting, so you don’t need a persistent network connection to all the parts. you don’t need a centralized server. The idea is you can fluidly recover from network partitions by merging all of the data and operations that happened while you were offline, and this turns out to be really important to our vision of how collaborative editing should work because we think it’s really important for people to be able to do things like not always be editing in the same document at the same time as everyone. Maybe I want to take some space for myself to write in private and then have my changes sync up with everyone else thereafter. Maybe I’m, you know, self-conscious about other people editing. are seeing my work in progress, but I think that it would be interesting and helpful to look at what the main document looks like and how that’s evolving while I’m working in private, and you can have that kind of one way visibility with something like a CRDT versus with something like Google Docs, where it’s just sort of always online or always not editing in your own personal editor. Conversely, maybe I’m OK with everyone else seeing the work that I’m doing in progress, but I just find it really visually jarring to have all these cursors and different colors jumping around and People inserting text, bumping my paragraphs down the page. I’ve definitely been there. I’m not particularly precious about people seeing my work in progress, but I just cannot focus on writing when the page is just changing all around me. So in that situation, maybe I would want to allow other people to see my work in progress, so that we don’t duplicate effort or something like that, but I just have like a focus mode where incoming changes don’t disrupt my writing environment and these kinds of fork join one way window. Microgit style branching paradigms are really only enabled by a technology like CRDTs where you have the flexibility to separate and then come back together. 00:13:12 - Speaker 2: And I’m incredibly excited by the design research that needs to go into that. Now at this point, I think we’re still on the technology level, you know, one way to think of it is Google Docs came along, I don’t know, 15, it’s almost 20 years ago now, I can’t even remember, let’s say 15 years ago, and this novel idea that We could both have a shared document or several people could have a shared document, all see the up to-date version and type into it and get, you know, a reasonable response or have that be coherent was an amazing breakthrough at the time and has since been kind of widely copied notion, Figma, many others. But now maybe we can go beyond that, much more granularity, like you said, maybe borrowing from the developer version control workflows a little bit in a lightweight way, giving a lot more control and flexibility, and giving us a lot more choices about how we want to work most effectively. But before we can even get onto those design decisions and how do we present all these different things to the user, what are the different options? We need this like fundamental underlying merge technology, hence the endless fascination that we have the lab and increasingly the technology industry generally has with CRDTs because it has the potential to enable all that. 00:14:23 - Speaker 1: Yeah, when we were working on the Paratax project, Peter was pushing really hard for, don’t make this just a technology project. It’s a socio-technical endeavor and we need to invest a lot of time in the design component, also just doing user interviews, identifying how people interact with and. How people collaborate in the status quo on text and Jeffrey and I actually did do a bunch of user interviews with people from all kinds of backgrounds. We’ve talked to people who write plays, people who produce a dramatic podcast kind of in this style of Night Vale. I love Night Vale. Yeah, people who are in the writer’s room kind of working together with their collaborators on that, people who write lessons, video lessons for educational platforms. And there was a ton of really interesting Insights into user behavior around collaborative text. We ended up just torn because we had this 12 week project and we were like, how should we best spend our time? Clearly, this is not just a technical area and we need to invest a lot in getting the design right, understanding what the design space even looks like since it hasn’t really been explored. I really want to avoid, and this is a recurring theme in my work, I really want to avoid publishing or shipping something. And having it be this like, very broad, very shallow exploration into all the things that are possible. I think that this kind of work plays an important role, and there are a lot of people who do this well, just fermenting the space of possibilities and getting these ideas in a lot of people’s heads, who can then go on and do really cool things with them. My personal style, I never want to feel like something is half baked, I guess, I would much rather ship this cohesive contribution like, here is an algorithm for building rich text. We think that this is a technical prerequisite to all of these interesting design choices, but the alternative with a 12 week period, and in fact, you know, this, the correctness and revision phase extended way over that. So thanks a lot to Martin and Jeffrey for leading during that part. But it’s just already so hard to get it correct that trying to tack on a really substantive design exploration that does the area justice on top of that, I was just really worried it would stretched too thin. So absolutely lots of room for future work in this particular. project. It’s very much a challenge in any area where you have simultaneously this rich design space that’s just asking to be explored with tons of prototypes and things like that, and then also to even realize the most simple of those prototypes, you require fundamentally new technology. 00:16:53 - Speaker 2: Yeah, I’ve been down that same path on many research projects as well, and often it’s that I’m excited for what the technology will enable, but also that in many cases it’s a combination, you know, some kind of peer to peer networking thing, but with that will enable us to provide a certain benefit to the user and I want to explore both of those things, but then that’s too much and then the whole thing is half baked exactly as you said. I’ve never found a perfect or even a good. Way to really manage that tradeoff. You just kind of pick your battles and hope for the best. Yeah, definitely. Well, I do want to hear about the equation editor project, but first I feel I should introduce our topic here, which I think folks could probably have gleaned is going to be rich text and rich text editing, and maybe we could just step back a moment and define that a little bit. I think we know that texts, you know, symbolic representation of language is a pretty key thing, writing and the printing press and all that sort of thing. We wrote about that a little bit in our text blocks memo, which I’ll like in the show notes. But typically, I think computers for a lot of their early time and even now with something like computer code is typically plain text, that’s the dot TXT file is kind of almost the native style of text that you have and then rich text typically layers something on top of that. I don’t know, so maybe you could better define rich text for us to have a more concrete discussion about it. 00:18:21 - Speaker 1: Yeah, I think rich text for most people basically evokes things like bold, italic, underline, the ability to augment plain text with annotations that are useful in formatting, actually, I think. Notepad to word pad is the archetypal jump in software, if you’re thinking about it from the old Windows perspective. In the past few years, I think we’ve started to see a real expansion of what rich text can look like. So, of course, we started out with something like Markdown, which is, of course, a plain text representation. But it’s designed to be able to capture more nuance in plain text and be rendered to something like HTML which very much supports rich text. So in Markdown, you have not only these kinds of inline formatting elements like bold and italic and hyperlinks as well. You also have support for images, which you could think of as more block level rich text elements, I guess, and I don’t think there’s a real clear consensus across editors on how block level rich text elements should be displayed. Of course, in between you have things like bulleted lists and those tend to be handled in a fairly standard manner with nested lists and so on, but it quickly becomes like a question of taste. Which kinds of annotations you support. So in editors like Coto or Notion, you have all these different block types where the block is really the atom of collaboration and editing, and then you can have things like, you know, file embeds or even database views, things like that. So I think we’re at a point now where both block-based editors, I’m using block based editors in like the text or writing sense, not the structured editors for programming sense, although I have other things to say about that, but we’re at a point where you’re starting to see these block-based editors appear and I think that there are a lot of really interesting patterns that this permits that the paragraphs via linear sequence of characters, including new lines and whitespace does not permit, or at least doesn’t allow you to build as structured tooling around. 00:20:30 - Speaker 2: I’m trying to think what is actually the core of the difference between a block-based editor, that’s a notion, a RO uses working on its own block text implementation and a flow of characters, so that’s Microsoft Word, Google Docs, maybe even text editors. I guess it’s sort of like paragraphs are separated by like these sort of nested. Elements or have a parent to the document versus like two new lines embedded in the stream of characters, but I don’t know, that seems too unsophisticated, maybe have a better definition for us. 00:21:03 - Speaker 1: So, I actually think about this very similarly to in the like programming languages and editor tools space. There is a distinction between structured editors and regular plain text editors for programs. The idea is that you might have a text-based programming language and you can write that perfectly fine in any buffer that allows you to put sequential characters, often AI is sufficient for some languages, and then on the other hand, These programs might have a lot of inherent structure. A simple example is with lisps which are built out of these parenthesis S expressions, everything is, you know, an S expression. You can think about like the structure of the tree formed by, I guess a forest, formed by having like these S expressions with subelements and stuff. that, and then you can do manipulations directly on the structure in a way that allows you to always have a syntactically correct program or at least a partial syntactically correct program by doing things like I’m just going to take this subtree, which is a sub-expression and move it somewhere else where there’s room for another subexpression. So, I think of block-based editors as capturing a very similar zeitgeist to structured editors for code, because instead of just having this linear buffer of characters that can have, you know, formatting or things like that, you can have new lines, you actually have more of a forest structure where you have lots of like individual blocks, and then you can have blocks that are children of other blocks and so on, and that allows you to Do things like move an entire subtree representing an outline to another position in the document without selecting all of the characters, you know, cut them and then paste them somewhere else. So things like reparenting becomes a lot easier, things like setting the background of an entire subtree becomes a lot easier. Just in general, you have more structure and there’s more things you can do with that structure, I guess is how I would phrase it. One of my favorite things that you can do with this model in notion is you can change the type of a block very easily. So let’s say I have a bullet list item, and then I hit enter and enter these like subnote or something like that as children of the initial bullet list item. I can turn the bullet list item into a page, and then all of a sudden it’s just a subpage in the document, and the sub bullets that were there before are just like top level bullets in that page. And this is particularly important for my workflow because I care a lot about starting out with something like really rough and sketchy and then progressively improving it or moving up and down the ladder of like fidelity into something more polished. So you might, for instance, start off with just an outline list or even a one dimensional list of to do blocks when you’re trying to do project planning or something. And then later on, let’s say I want to put these into like a tasks database with support for like a conbond view or something like that. I don’t actually want to sit there and like recreate all of these tasks in Jira. I’ve been there, you know, I’ve been the person making all the tasks in Jira after the meeting and then assigning them to people. What the workflow that I think notion is poised to enable and can certainly do a better job in this regard, but already offers some benefits on is like, can I just highlight all of these blocks because everything is a block, move them into some existing database and have them match the schema. That kind of like allowing people to do fast and loose prototyping with very unstructured primitives and then promote them into something more structured like in a relational database setting or similar, I think is the sweet spot, structured editing provides the sweet spot between like just completely unstructured text and these very high fidelity, high effort interfaces that allows you to kind of move between them. 00:24:47 - Speaker 3: Yeah, I really like that direction and framing, and if I can extend it a little bit, I think we can also look at a continuum of richness in terms of the content itself. So you have plain text, what you might classically call rich text with links and bold and underlying. And then you maybe start to throw a few images in, and then what if you can put it in videos and what if you have a whole table, and that table is actually a database query, and you can nest the figment document, and this way you can see that there’s sort of continuum on the richness of the document. One reason I think Notion has been so successful, they’ve been pushing along that continuum while maintaining a sort of foundation of rich textness, which is very familiar and the important basic use case for a lot of people. A related idea is that I think we’re seeing a lot of the classic document types converge. So if you look at a rich text like a Microsoft Word and a PowerPoint and increasingly spreadsheets, those all used to be 3 distinct Microsoft Office applications, and we’re seeing the value of them being in or being the same document. This is actually one of the motivating ideas behind Muse and a lot of the research we’ve done in the lab, and the kind of something Slim was saying, you want to take your idea continuously through different media and different modalities and different degrees of fidelity, and you don’t want to jump between different applications do that. You want to be able to do it on the same canvas. That’s by the way, one of the reasons I like Canvas. It’s not only because it’s a free multimedia surface, but also it evokes this idea of like flexibility and potentiality, and I think that’s one of the things that’s really excited about these mixed media documents. 00:26:16 - Speaker 2: And I know if Jeffrey were here, he might jump in and say that one downside to our current application silo world is that the only way to have this deeply rich text where it’s images, video, a table, a database query, something like that, is to have the Uber application, to have the everything app, and certainly notion has probably gotten pretty far on that, but others kind of in In some ways are forced to do that, like we have to do some of that in Muse as well. People come in and ask for all these different types here as well, and there’s more of like an open doc inspired or Unix inspired future that maybe Jeffrey and others, including me, would hope for, which would be more that applications could be these individual data types and you could put them all together through some kind of more operating system connection. But that is so completely reversed from kind of how all our computing devices work today. It’s hard to see how we might get to that. 00:27:14 - Speaker 3: Yeah, I’m certainly sympathetic to that concern, although I suspect the way out is through, and you get platforms from working killer apps. And so the way we got the whole unit ecosystem was they wanted to build a computer for, you know, writing and running programs and then eventually got all this generalized text processing stuff, but it’s not like they started in like, oh, I’m gonna make a generalized text processing machine. I don’t think that was really the way that they approached it and developed a success. So, I’m still hopeful we could do this, but I think you got to extract it from something that’s already working as an app, but it always helps to have an eye towards that, and I think we’ve done some of that with Muse. 00:27:46 - Speaker 1: I was just going to say that it’s not me talking about texts, unless I bring up my favorite piece of software of all time, which is Pandok. And I think that Pandok actually is very relevant to this discussion. So for those who aren’t as familiar with it, Panok brands itself as this Swiss Army knife for document formats, and it’s sort of headline contribution is that it allows you to convert between all kinds of documents. For instance, I can take a Word document and convert it to a PDF Word documents to something like, I don’t know, IPython notebook, Jupiter notebook, back and forth across this incredible bipartite graph of formats, but I think that the subtler contribution that Pandokc makes, which is extremely significant, is that Pandok has this form of markdown called Pandok markdown that essentially aligns and supersedes all of the different fragments of markdown that we’ve seen before. So the problem with markdown basically is that the original specification is sort of ill-defined. There are several cases in which the behavior is not super clear and then on top of that, it’s not very expressive. There aren’t very many constructs. So things like fenced code blocks, which many people associate very closely with Markdown today, that was only added by GitHubb flavored markdown, which is certainly widely used among the programming community, but not everyone is on GitHub, of course. And then you have things like table formatting or even like strike through really strike Through wasn’t defined in the original markdown specification either. And so you have markdown and then you have like GitHub flavored markdown, common mark is sort of this unifying effort remark down all these different is the markdown cinematic universe. I tried to make a joke about this. I had this joke ready for the markdown Cinematic universe when the last Marvel. Movie came out. But then like, it didn’t get nearly the traction in my timeline as the Dune did, perhaps understandably. So really, I’m just going to have to wait till the next movie comes out. It’s a real, real tragedy. No, but like, I guess you have this real pluralism of forms and it becomes very difficult to use markdown truly as a portable format because the way it renders in one editor or even parses can very much differ from editor to editor. So, Pandoc provides this format that essentially serves as an IR or intermediate representation between all these kinds of documents using a markdown supersets that somehow magically encapsulates everything. 00:30:18 - Speaker 2: And that includes not just markdown, but also like PDFs or Microsoft Word, that seems. 00:30:24 - Speaker 1: Well, so the way it works is it’s this compilation pipeline, I guess, that allows you to go from a markdown document. It compiles it to PDF using PDF Lawtech or something. It outputs Lawtech, it outputs HTML various things, and you can think of it as being this intermediate representation because you start with this like Word document, you can turn that into markdown and you can go from that markdown format into any of these output formats, which turns out to be like really powerful because the main issue with these kinds of conversions is that it’s often lossy, there are features that are supported by Law tech, for instance, that aren’t supported by the web natively, there are features that are part of like Word documents that aren’t necessarily supported by HTML and so on and so forth. So Pandok serves this role of like basically saying, OK, what is an intermediate language that can encapsulate all the different implementations of the same concept across different input and output formats. And what I think is so remarkable about it is that oftentimes when you are using an AP. of software and you’re like, oh darn, you know, now I need to support this other thing too. You quickly end up in a situation where you have the snowball and things start to feel tacked on. So you’re like, Oh man, it’s very clear that they just glommed on this additional syntax for this feature. And with Pandok, everything feels like very principled in its inclusion. And at the same time, whenever I’m using Pandok and I’m like, darn, I really wish there was a construct that I could use to express this. particular thing, I look up in the documentation and it’s always supported. So, as one of my favorite examples, one of the output formats that Handok supports is various slideshow frameworks. So Beamer for people who use Lawtech and Reveal JS for people who use HTML and CSS and these slideshow frameworks basically allow you to replace something like PowerPoint, Keynote, Google slides with essentially like a text-based format. I really like doing slideshows in Pandock markdown. There are a few reasons for that. The first reason is that it’s really useful to be able to reuse some of the same content from like my blog post or essay even in the slideshow. There are some really minor and almost petty, but really significant reasons. Like, I like to have equations or code blocks with syntax highlighting in my slideshows, and there’s not really a good solution to putting like a syntax highlighted code block in Keynote right now. 00:32:39 - Speaker 2: Last I remembered, the gold standard at the Ruby conferences I used to frequent was to take screenshot of Textmate and paste that in. 00:32:47 - Speaker 1: Yeah, it’s awful. I don’t want to see your like monochai editor with like the weird background that contrasts weirdly with the slide background. I just, ah, and it doesn’t scale on a huge conference display anyway, I digress, but The other reason why I really like doing my slideshows in text is actually that there is often a hierarchical structure to my presentations, right? I’ll have like these main top level sections and then I’ll have subsections, and then I’ll have like sub subsections and all of these manifest and slides. But in the gooey thumbnail view of most of these existing Slideshow editors like PowerPoint or Google slides, it reduces it all to like this linear list. It’s like, here are all of your thumbnails in order. And it makes it very hard, as soon as I have like an hour-long conference talk, how do I like jump to this subsection that I know exists, aside from like scrolling past like 117 thumbnails and trying to find the right one, right? And moreover, let’s say I want to Reorder a certain part of the talk because I think it better fits the narrative structure. Now I have to like figure out which thumbnails I need to drag to which other place or worse, go into the individual slide, select the text from that, move that somewhere else, and it’s just way, way clunkier actually than reordering some text in like a bullet list outline in my editor. And then the other part is that I was talking about how Pandok has really great support, expressive support for idioms of different formats, and one thing you often have in slideshows is that I have some element on the screen and then I press, you know, the next button again and then another element will appear. So in Pandoc you can denote this with just like an ellipsis basically so like dot dot dot and then if I have a slide where I have a paragraph and then the dot dot dot and then another paragraph, it will render with just the first paragraph visible and then I press next and then like the subsequent paragraph comes in. And that’s like just a very lightweight way to handle these stepped. Animations compared to going to the animation pane and then clicking the element that I want to animate in and so on and so forth. So it started off with me being like, I’ll just prototype in this format, but then it ended up supporting columns, it supports all these things that you actually want. And I was like, this is in many ways a more ergonomic way to handle long technical slideshows. Anyway, I have to chill for Pandok anytime I talk about rich text, I’m contractually obligated to do so. 00:35:08 - Speaker 2: Yeah, it’s a great piece of software, use it here and there. I think I was doing some Asky doc kind of manuals many years ago and yeah, just in general, it’s also worth looking at the homepage that you mentioned the plot they have where it shows all the different formats that can convert between is quite fun. You click on that, you can zoom in. 00:35:26 - Speaker 1: Yeah, I had this really elaborate plan when I decided to go to Berkeley, that I was going to print out a door-sized poster of like that graph that shows all the formats they convert between and then show up at John McFarlane’s door and ask him to sign it. But then the pandemic interfered with some of those plans. Nonetheless, it remains on my list. 00:35:48 - Speaker 2: Good bucket list item, pretty unique one at that. 00:35:51 - Speaker 1: Also, I found my tweet, or I found the draft of my tweet, which is about eternals, and I said, directed by Chloe Zhao, the latest entry in the Markdown Cinematic Universe features an ensemble cast of multi markdown, GitHubb flavored markdown, PHP Markdown Extra, R Markdown, and Common Mark as they joined forces in battle against mankind’s ancient enemy, Doc X. Nice. 00:36:12 - Speaker 2: Wow. You would have gotten the like from me. 00:36:16 - Speaker 1: Yeah, we’ll see if it ever sees the light of Twitter.com. 00:36:20 - Speaker 2: You briefly mentioned there equations and La tech, and maybe that’s a good chance to talk about the equation project you did for notion. And part of what I thought was so interesting or what I think in general is interesting about equations is that they are obviously an extremely important symbolic format, but in many ways extremely different from the pros we’ve been talking about. So English or other languages, even languages that are right to left or something like that, they all have the same kind of basic flow and the way that we represent sound. So with these little squiggly symbols, even though the symbols themselves and sounds vary and how we put them together into words across languages, that’s a common thing. If you go to the mathematical realm, you have symbolic representation, but equations are the whole own beast, and I think one that has gotten a lot less attention from kind of the software and editing world. So tell us about that rabbit hole. 00:37:16 - Speaker 1: Yeah, so just as context for people, notion and many other applications actually have long supported block equations, an equation that basically takes up, you know, most of the page horizontally. What is much more uncommon in editors is support for inline equations and so this can be something as simple as saying, You want to type let X be a variable, and X should be formatted or stylized mathematically. Being able to refer to elements of a block level equation in inline text is a prerequisite for being able to do any kind of serious mathematical writing, yet because this is kind of this niche area that has historically been the purview of Overleaf and other law tech editors, it’s really not implemented. In most editors. So I pushed really hard to add inline equations and inline math to notion, because I was like, there’s a huge opportunity for people to write scientific or mathematical documents that take advantage of all of notion’s other features like being able to embed FIMA or embed illustrations and things like that, right? So, it turns out that it’s kind of difficult, exactly as you’re describing to do this equation format. There’s been very little innovation and research more generally into what is like a good interface for inputting equations. So I think most people Probably familiar with Microsoft Word or Excel have these equation editors, or even like operating system level sometimes where you basically like open this palette, and there is a preview and there is a button for every possible mathematical symbol or operator you can imagine. And then for composite symbols like the fraction bar or integral or something like that, you find the button for that, you click it, and then you click into like the little subboxes and then you find whatever symbol you want and you put those there too. So it’s kind of a structured editor, but like in an unimaginably cumbersome interface. This is what I used to do my lab reports in high school, for example. And then at the other end of the spectrum, you have things like law tech. Law tech is basically how everyone in at least in computer science and mathematics chooses to typeset their work, typesets complex mathematics. One of the real selling points of law tech, I think is that It turns out that operator spacing is really important, and there’s a big difference between, say, a dash that’s used like a hyphen or a dash character that’s used in text, and a hyphen or a dash character that’s used as a minus sign in an equation, the spacing is subtly different. And one of the big things that Lawtech does is it basically allows you to declare certain operations in certain contexts as like a math operator versus just a symbol versus just like a tagged group of characters, and it correctly handles the spacing depending on what kinds of characters are around the operator in question. And so Lawtech basically produces really nice looking mathematics at the cost of this markdown which looks like I kind of smashed my keyboard that only had like 3 characters. It’s the exact opposite of the equation editors instead of having a button for every imaginable character, you only have 3 buttons. The buttons are backslash, open curly brace, and closed curly brace, and somehow like permuting those characters is supposed to get you like any possible mathematical outfit. There’s just two ends of the spectrum. 00:40:41 - Speaker 3: Yeah, I used to do my analysis homework in college in law tech, and I remember when I first looked up how you would input in law tech these formulas, like, that can’t be right. This is not the best way in the world to do this. In fact, that’s it, that’s the one and only way. 00:40:53 - Speaker 1: It really is, it’s terrifying. It’s the one and only way and the wild part is there are people who are like super, super good at law tech. They can like live tech their lecture notes. I was never nearly like that fast, but some people can do it usually with extensive use of macros, which macros are another selling point of law tech as you can define these kind of custom shorthand for operators you use a lot. But anyway, yeah, so you have a lot of tech sort of at the other end of the spectrum, like really quite unreadable, oftentimes, like, it’s like a right only format, many times. 00:41:23 - Speaker 2: And of a regular expressions come to mind on that as well, yeah. 00:41:26 - Speaker 1: It’s exactly the same zeitgeist, I think. It turns out that figuring out how to have like a combination, gooey, plain text interface that allows you to be like in a rich text editor like notion, then. into an inline equation field to have like an inline symbol and then go back into the GUI editor was like just very unexplored territory. And it kind of makes sense that lots of people don’t prioritize this because many people that notion rightfully had the question like, oh, is this something we should be working on? But first of all, it turned out that if you actually tallied up like our user requests, inline math was like near the top. Of editor feature based requests. And then more generally, it turns out that because this is like a prerequisite for many researchers and for students, you can get a lot of people on your platform who rely on it, you know, as a student to take notes and something like that, because there’s literally no alternative. And then they are able to stick around and use the platform for all kinds of other things. So this is just kind of a plug that more editors should implement this. But Yeah, I thought that this project was really interesting because in the interaction paradigm, you want to capture a lot of the things that are very fluid about editing regular text. So for instance, we knew it was important that you should be able to use the arrow keys to move left and right, kind of straight through a token without editing it if you wanted, or if you wanted to be able to go. Into a token and edit it using the arrow keys, you shouldn’t have to like use the mouse to click, although, of course, you should also be able to use the mouse to click. And when you have this formatted equation, we made the decision that the rendered equation would be represented as this atomic token. So if you were highlighting text to copy and paste and move around, it would be like highlighting a single character that would just be like the whole equation. But of course, you could go in and edit the equation. Any way you want it in kind of this pop up text editing interface. I think another thing that’s the subtle interface challenge here is that like Mark was saying, there is often a Uh, disproportionately large number of characters used to represent the equivalent of like one character with a formatted output. And so that’s something you don’t really take into account. The output is like X with a hat in San Sara font, and then there’s like 25 characters of markup that goes into that, and you just need to like scale the interface appropriately to take that into account. But I think that it’s really interesting because It shows the power of combining different input and output formats in like the same atom, right? So you have like a single line of text, and you want to have rich text that’s formatted and stylized and so on, hyperlinks, and then also equations or whatever inline rendered output of another input format that you have. I think that that’s really where GUI editors and whizzy wig editors can shine is being able to combine these like, Input formats and output formats like in the same line in Chu, yeah, I guess you can’t really do that at all with the terminal or something like that, and I say this as someone who uses like CLIIM for everything. 00:44:34 - Speaker 3: This is bringing back so many memories. I wish I had notion with equation support back when I was a math undergrad. It’s so nice. 00:44:41 - Speaker 1: I’m like the notion math stand guardian, I don’t know, something like that. And I’m always keeping track of like all the cool things people are doing using equations and notion. A lot of people are doing like math blogs in notion, which is really awesome for me to see. Also, I just feel like they’re having tried lots of other things. They’re just like really isn’t. A good alternative short of like actually writing lots like for your blog, which no one really likes. And yeah, I mean, certainly it’s the kind of thing that I implemented originally, kind of, I was like, I’m gonna do this for myself, and then realized that lots of people would be able to benefit from it. It’s been really cool to see a bit of reception it gets, like the inline math tweets on the notion, uh Twitter account overwhelmingly get the most engagement and interaction. And initially, like the marketing team was shocked. They thought this would be the super niche feature, but no, it turns out that people love math and like, they may not be the most vocal proponents or they’re used to no one caring about math type setting, things like that. For a while, I think it was the case that when I did find an editor that had support for equations of some kind, to me, it was overwhelmingly obvious that the people who implemented it did not regularly use equations for writing. I think you can often tell that with different features. So I think that having that kind of Representation is not quite the right word, but being able to see a feature that was designed by someone who really cares about using it themselves is really cool for people who are interested in typesetting, students, researchers, people who are interested in typesetting more mathematical text. 00:46:11 - Speaker 3: Yeah, and I think it’s really important, like you were saying that it’s mixed media because you’re combining the equations, the inline equation and the block equation, by the way, in the world class form, which is a lot tech based with a world class rich text editor with text and images and stuff. It’s really nice. I do think there’s still one frontier here, especially for math, which is the fully gradual process from you’re taking handwritten notes and you’re working out a problem and you’re drawing squiggly diagrams all the way up through your finished homework. I remember when I was at math undergrad. I would basically have to do the homework twice. You do it once on paper. Nobody could read that, including myself, so that, you know, do it in lot again. And I always wish there was a way to do it incrementally. You sort of changed equation by equation and diagram by diagram into the final product. And I know there has been some research on uh turning equations into lot tech formulas with machine learning. I don’t know if I can do handwriting, but perhaps someday we’ll get the new support for equations and you can go all the way to the end. 00:47:02 - Speaker 1: Yeah, like you, I share exactly the same frustration that you have to essentially do lots of things twice, and the relative position of everything is ambiguous, and Lawtech is what allows you to do things like have subscripts of subscripts, which would be really inscrutable in most people’s handwriting, including my own, and, you know, subscripts of subscripts along with super scripts and things like that. There are just so many ambiguous details and it turns out in my experience with like, anything that tries to automate the transition is that I always end up Going through and like really rewriting all of the details to be structured in a readable way. You have this other problem which back in the days of like Wizzy Wig web editors like Dreamweaver and Microsoft Front Page and things like that, you would often end up with this problem where you try to do like any edit in the Wizzy Wig side and then you look at the generated HTML and it’s ridiculous. There’s just like 16 nested empty span tags, and no one would ever be able to maintain that. And my worry is basically that when you automatically create Markup for something that has a very complex graphical representation, it’s really like one way, you know, maybe it will help you produce a compiled output, but it doesn’t actually help you go back in and like edit and tweak the representation later or it’s just so inscrutable if you do that it’s kind of also a reg x type situation. I think we really need to get to some kind of like good intermediate representation that allows you to flexibly go both ways. And that goes back to something that I think Adam and I were chatting about earlier, which is that a lot of people gripe and complain that like law tech is the best we have and, you know, I’m one of them, but It really is the case that, you know, lottech was just this like monumental effort by really a few people and amount of effort that would be like considered really impressive if I were to try to do the same thing but better today and not a lot of people just have like spare time to do this all in one text formatting, packaging, document representation project, even though it would have huge impact on the way people write and publish these kinds of documents. And so in many ways we’re sort of just bottlenecked on the fact that It’s hard to do incremental improvements to this particular area. We really depend on these like software monoliths to keep us afloat. 00:49:19 - Speaker 2: I’m not nearly as mathy as either of you, but I can’t help but make the comparison on these equation editing to what you mentioned earlier with kind of structured editors and programming, where whether there’s lightweight help from your text editor, things like code folding, syntax highlighting and autocomplete, or full structured editing, some of the visual programming stuff we talked about with Maggie Appleton, like Scratch, for example, or these flow based systems that are fully graph. and you sort of can’t have it in a bad state. And I can’t help but to think there might be some direction like that that is not necessarily the right only inscrutable tech, but is not the Microsoft Word one button literally for every symbol you might ever want. It does seem like there might be some other path, and yeah, I agree it’s a monumental effort, but I mean, mathematics is so important and foundational and so much of human endeavor that certainly seems like one worth investing in, although perhaps hard to reap a profit from, and that makes it harder to put concentrated capital behind it. 00:50:20 - Speaker 1: Yeah, I think that there’s definitely very clear demand for I think something exactly like what you’re describing, which is somewhere in between the two extremes, and it is really relevant because ACM, which is the Association for Computing Machinery, the academic and professional body really for computer science, they are currently undergoing this. Fiasco, maybe, I probably shouldn’t go on the record as calling it a fiasco. The ACM is currently undergoing this initiative called TAPS, which is the ACM Publishing System, where they are attempting to revise the template by which all computer science research is published and disseminated, and the idea behind this is that right now, computer science research is published to these PDFs. Initially they were all two column PDFs, now I think there’s some one column PDFs. They want to output HTML as the archival format for various reasons, including that it offers much better reading experience on different screen widths, so like phones or tablets, which are increasingly how people are reading papers, not just printed out. And they are much more accessible than PDFs. PDFs are just like really quite inaccessible, especially to screen readers and other assistive technologies that are trying to parse out all the different math or whatever arbitrary formatting you’ve decided to use. The upshot of this, I guess, is that there are currently a group of very smart people who are trying to figure out how in the world we’re going to get people to start writing all of their papers and outputting them in a different format, in a world where everyone is already used to preparing. Their publications and preprints in law tech. And turns out that even if you solve the problem of like what the input syntax should be, rendering math in the browser is like an extremely unsolved problem. 00:52:05 - Speaker 3: Yeah, isn’t the state of the art that it like generates PNG and sticks it in the web page? 00:52:09 - Speaker 1: Not exactly, but like almost. OK. So MathML, which is like an XML dialect or like mathematical markup language, was this effort to build. HTML XML style syntax for typesetting mathematics. Naturally, it is only implemented in Firefox, so that’s really unfortunate. So in terms of the state of the art, there are basically two libraries that you can use to typeset mathematics. There’s math Jack and Caltech. Mathjax supports basically all valid law tech, including, you know, different. Environments and equations and things like that. The problem is that Mathjacks is very slow. So if you ever go on math overflow or another like related stock exchange and you see like all of these answers with like weird gaps, and then as you watch before you, the page starts to like load all of the rendered equations like bumping everything down one level at a time. That’s math Jackson action. And oftentimes it is doing what you’re describing where it is outputting like an SBG or a PNG or something like that, and it’s just like reflowing the page with every equation. So then you have Caltech, which was a library developed at Konn Academy where they realized that math Jack’s performance was basically just like not satisfactory for their exercises and things like that. Sootte supports a much more limited subset of all of Law tech syntax, but it does it all using CSS basically, and it doesn’t reflow the page for every equation. It’s basically instant surrender. So tech is what we use at Notion, it’s also what’s used in like Facebook Messenger, which supports equations if you ever tried that, and many other websites, and basically it means that your options, if you want to render math are only target Firefox. Use a limited subset of math that’s supported by Kottech and Consign yourself to like extremely slow, dozens of reflow, full expressive power rendering to inline PNG’s. And so that’s just not like a great situation to be in, and we haven’t even gotten to the question of like how people write math. So I would say that people underestimate like how open this problem spaces. 00:54:17 - Speaker 3: Yeah, man. 00:54:19 - Speaker 1: Just take a moment of silence to like recognize the gravity of the situation. 00:54:23 - Speaker 3: This is an aside, I don’t know if you want to put this in the episode, but now I’m curious. It sounds like both of those are interpreted in the sense that the equations are rendered at load time instead of being compiled down to some like HTML and CSS that you can render without JavaScript. Like, basically, do you need JavaScript to render these pages? 00:54:39 - Speaker 1: Yeah, basically, I should say you also need JavaScript, unless you’re doing the pre-compied to MathML and then hope that people are using Firefox. 00:54:47 - Speaker 3: Man, I feel like there’s no way that that stuff loads in 10 years, but we’ll see. 00:54:52 - Speaker 1: I actually had this exact argument, again, I don’t know if you want to put this in the episode. I had this exact argument with Jonathan Aldrich, who’s on the taps committee when we were talking about this, and I think the point was not so much that you can guarantee that the artifact loads. Exactly the same way in 10 years, but that the representation is rich enough that one could feasibly build software that renders it the same way in 10 years. So it’s more about the fidelity of the like underlying representation where like a team of, I guess, digital, you know, archaeologists could recover the work that we were doing and not so much like we trust in the vendors to like keep everything stable, which is obviously never going to happen. You know, the only reason like PDFs are stable is because how many trillions of dollars of IP depend on being able to load the PDF the same way as it was written, you know, 30 years ago. 00:55:45 - Speaker 3: Yeah, interesting. 00:55:46 - Speaker 1: Nice. Going back to this idea earlier that Mark mentioned of the spectrum of like plain text, rich text, Wizzy wig editors. One recurring theme for me is thinking about decoupling this spectrum into like what is the format and then what are like the editors and tools that we can use to interact with this format, so they structured, unstructured, etc. I want to call outAR, which is a native application for Mac OS and iOS that does a really great job with this, which is that Bear is basically Something in between a whizzy wig and a plain text editor in that you’re always editing markdown documents and indeed, when you have something that’s bold, you can see the like asterisks around it that delimits that character. But all of these standard, you know, Control B, U, editor shortcuts work as you would expect. And more importantly, you can see like the formatting applied in real time. So That when you do star star, hello star star, he suddenly becomes bold face in this gooey. And so in many ways it combines like the fluidity and the real-time preview of a rich text editor or previewer with the flexibility of like ultimately just writing plain text characters. And I think this is like really unexplored area. I don’t just mean something like Open VS code or VIM and type characters and then see like different formatting labels attached to the results. I mean like a native application that’s really designed like for end use or end users, that doesn’t fully obscure the input syntax but does real time rendering in place. It’s not even like in monospace font, right? It makes it feel much more like this is actually the output that you’re targeting. And not just like an input step that needs to be pre-processed. I think that there is a lot of room for applications that are kind of in between and in that same spaces where it doesn’t entirely obscure what you are writing, but it does give you a lot of the benefits of previewing things and having like a GUI application outside of the terminal in terms of like capturing the richness of the possible results. 00:57:52 - Speaker 3: Yeah, I like the bear approach a lot. Now, are there particular domains or types of documents that you think would be susceptible to this approach, or it just for rich tech specifically? 00:58:01 - Speaker 1: So I was making a list of like all of the different traditionally graphical outputs that have corresponding plain text representations and a lot of them I was thinking about, for example, in engraving sheet music, right, traditionally you would use a desktop program like Finae or Sibelius nowadays you have options like new score and flat, which are more web-based editors, but you see the staff and you click notes. In the staff like corresponding to where you want the note, and you know you use the quarter note or the 8th note cursor to pick the duration and so on. And then at the other end of the spectrum you have Lily Pond, which is kind of like law tech I guess for engraving sheet music where you type a very like law tech-esque syntax and out comes, you know, beautifully typeset sheet music. For me this

Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: But this totally changes how the data is persisted, and I think that’s important because the only way you get good results on sync systems, especially when you’re talking about offline versus online and partially online, it has to be the one system that you use all the time. You can’t have some second path that’s like the offline cache or offline mode that never works. It needs to be the one true data synchronization persistence layer. 00:00:29 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad and Mac, but this podcast isn’t about Muse the product, it’s about me as the company and the small team behind it. I’m here today with two of my colleagues, Mark McGranaghan. 00:00:43 - Speaker 3: Hey, Adam. 00:00:44 - Speaker 2: And Adam Wulf. 00:00:46 - Speaker 3: Yeah, happy to be here. 00:00:48 - Speaker 2: Now Wulf, you are not at all new to the Muse team, I think you’ve been with us for coming up on 2 years now, but it is your first appearance here on this podcast, a long overdue one I would say. So we’d love to hear a little bit about your background and how you came to the team. 00:01:03 - Speaker 3: Yeah, thanks, it’s exciting. Before Muse, I worked for a number of years with Flexits on their calendar app, Fantastical, both on the Mac and the iPhone and iPad. Really enjoyed that. At the same time, I was also working on an iPad app called Luose Leaf, which was an open source just paper inking app, kind of note taking app of sorts, really enjoyed that as well. 00:01:28 - Speaker 2: And I’ll know when we came across your profile, let’s say, and I was astonished to see loose leaf. It felt to me like a sort of the same core vision or a lot of the same ideas as Muse, this kind of like open-ended scratch pad, multimedia inking fluid environment, but I think you started in what, 2013 or something like that, the Apple pencil didn’t even exist, and you were doing it all yourself and, you know, in a way maybe too early and too much for one person to do, but astonishing to me when I saw the similarity, the vision there. 00:02:03 - Speaker 3: Yeah, thanks. I think the vision really is extremely similar. I really wanted something that felt physical, where you could just quickly and easily get to a new page of paper and just ink, and the, the app itself got out of your way, and it could just be you and your content, very similar to you sitting at your desk with some pad of paper in front of you. But yeah, it was, I think I started when the iPad 2 was almost released. And so the hardware capabilities at the time were dramatically less, and the engineering problems were exponentially harder as a result of that, and it was definitely too early, but it was a lot of fun at the time. 00:02:42 - Speaker 2: And I think one of the things that came out of that, if I remember correctly, is this open source work you did on ink engines, which is how we came across you. Tell us what you did there. 00:02:52 - Speaker 3: Yeah, there’s a few different libraries I ended up open sourcing from that work. One was the ink canvas itself, which that was the most difficult piece for me. The only way to get high performance ink on the iPad at the time was through OpenGL, which is a very low level. Usually 3D rendering pipeline. I had no background in that, and so it was extremely difficult to get something up and running with that low level of an architecture. And so, once I had it, I was excited to open source it and hopefully let other people use it without having to go through the same pain and horror that I did to make it work. But then one of the other things that was very useful that came out of loose leaf was a clipping algorithm for Bezier curves, which are just fancy ways to define ink strokes, basically, or fancy ways to describe long curvy, self-intersecting lines. And that work has also been extremely important for Muse as well. We use that same library and that same algorithm to implement our eraser and our selection algorithms. 00:04:05 - Speaker 2: And when you’re not deep in the bowels of inking engines, or as we’ll talk about soon sinking engines, what do you do with your time? 00:04:13 - Speaker 3: Oh, I live up in northwest Houston in Texas with my wife Christie and my daughter Kaylin. And she is in high school now, which is a little terrifying, and learning to drive and we’re starting that whole adventure, so that’s been fun for us. I try and get outside as much as I can. I’ll go backpacking or hiking a little bit. That can be fun, and the Houston summer, it’s rather painful, but the springs and the falls, we have nice weather for outdoors and so. 00:04:42 - Speaker 2: What’s the terrain like in the day trip kind of range for you? Is it deserty? Are there mountainous or at least hilly areas, or is it pretty flat? 00:04:52 - Speaker 3: It is extremely flat and lots and lots of pine trees, and that’s pretty much it. Just pine trees and flat land. Sometimes I’ll drive a few hours north. We have some state parks that are nice and have a bit of variety compared to what’s immediately around Houston, so that’s a good backup plan when I have the time. 00:05:14 - Speaker 2: Flat with a lot of trees sounds surprisingly similar to the immediate vicinity of Berlin. I would not have expected Texas and northern Germany to have the commonality there. It gave me a lot of appreciation for the San Francisco Bay Area, while that city didn’t quite suit. Me, as we’ve discussed in the past, one thing that was quite amazing was the nature nearby and a lot of that ends up being less the foliage or whatever, but more just elevation change. Elevation change makes hikes interesting and views interesting and I think itself leads to, yeah, just landscape elements that engage you in a way that flatness does not. 00:05:55 - Speaker 3: Yeah, absolutely. I lived in the Pacific Northwest for a while, and the trees there are enormous, and the amount of green and elevation change there is also enormous. And so when we moved back to Houston, it was a bit of a shock almost to see what I used to think were tall trees in Houston are really not very tall compared to what I lived around up in Portland, Oregon. 00:06:21 - Speaker 2: So our topic today is sync. Now Muse 2.0 is coming out very soon. We’ve got a launch date May 24th. Feels like tomorrow for our team scrambling to get all the pieces together here, but the biggest investment by far, even though we have the Mac app and we have text blocks are a part of it, the biggest kind of time, resource, energy, life force investment by far has been the local first sinking engine. And we’ve spoken before about local first sync as a philosophy generally in our episode with Martin Klapman, but I thought it would be good to get really into the details here now that we have not only built out this whole system, both the client side piece and the server piece. But also that we’ve been running it in, won’t quite call it production, but we’ve been running it for our beta for a few months now, and we have quite a number of people using that, some for pretty serious data sizes, and so we’ve gotten a little glimpse of what it’s like to run a system like this in production. So first, maybe Mark, can you describe a little bit how the responsibilities breakdown works in terms of between the two of you on the implementation? 00:07:32 - Speaker 1: Yeah, so I’ve been developing the back end or the server component of our sync system, and Wulf has been developing our iOS client that is the core of the actual app. 00:07:45 - Speaker 2: Yeah, on that side, I kind of think of the client persistence or storage layer as being the back end of the front end. So that is to say it’s in the client, which obviously is a user interface heavy and oriented thing, but then it persists the user data to this persistence layer which in the past was core data, is that right? Well the kind of standard iOS storage library thing. 00:08:08 - Speaker 3: Yeah, that’s exactly right. Yeah, we used core data, which is Apple’s fancy wrapper on top of a SQL light database. And that just stores everything locally on the iPad, like you were saying, so that way the actual interface that people see, that’s what it talks to. 00:08:25 - Speaker 2: And then that persistence layer within the client can talk to this back in the mark has created. And much more to say about that, I think, but I thought it would be nice to start with a little bit of history here, a little bit of motivation. I’ll be curious to hear both of your stories, but mine actually goes back to using my smartphone on the U-Bah, so that’s the subway system here in Berlin, when I was first working with some startups in the city back in, I guess it would have been 2014, so, 8 years ago I had this experience of using different apps and seeing how they handled both the offline state but actually the kind of unstable state because you have this thing where the train car goes in and out of stations and when you’re in the station, you usually have reception, weak reception, and you leave the station that fades off to you essentially fully offline, and so you’re in this kind of unreliable network state all the time. And two that I remember really well because they were really dramatic, was one was pocket, which is the relator tool I was using at the time, and it handled that state really well. If it couldn’t load an article, it would just say you’re offline, you need to come back later, but the things it had saved, you could just read. The other one I was using was the Facebook mobile app, and there I was amazed how many errors and weird spinners, and you go to load a thing and it would get half of it, but not the rest of it, and the app just seemed to lose its mind because the network was unreliable, and I found myself thinking, what would make it possible to make more apps to work the way the pocket does and less the way that Facebook works. And I also had the opportunity to work with some startups here, including Clue and Wunderlust and some others that had their own. Essentially everyone needs this. Everyone needs syncing because they want either one, the user to be able to access their stuff from different devices, or 2, they want some kind of sharing, and I think Vonunderlust was an interesting case because they built out this crack engineering team. To develop really good real-time syncing for a very simple case. It’s just a to do list, and the common case that people use it for, I think was, you know, a couple that’s grocery shopping and they want to like, make sure they don’t overlap and pick the same things in the cart. But it worked really well, but they built this huge, I think it was like a 15 person engineering team that spent years of effort to make really good real-time sin, and it seemed strange to me that you need this big engineering team to do what seems like a simple thing that every app needs. We went down this road of trying CouchDB and Firebase and a bunch of others, and all were pretty unsatisfying. And then that further led in, you know, that kind of idea, the sync problem lodged in my mind and then when we got started at ink and Switch, some of our early user studies there were on sync and how people thought about it. And one thing that stuck with me from those was we looked into just kind of syncing on. And note taking apps and talked to a whole bunch of people about this, and we didn’t have a product at the time, so it was just kind of a user research study, but we went and talked to a bunch of folks, most of whom were using Evernote was kind of the gold standard at the time. And almost everyone we talked to, when I asked what’s your number one most important feature from your notes app, they said sync and said, OK, so that’s why you chose Evernote, and they said, yeah, and they said, how well does it work? And they said terribly, it fails all the time. You know, I write a note on my computer, I close the lid, I go to lunch. Half an hour later, I go to pull it up on my phone. It’s not there. I have no idea why. And so some combination of those experiences sort of lodged this thing in my mind of the technology industry can just do so much better, and this is important and everyone needs it. What’s the missing piece. And I wasn’t really sure, but that led into once I met up with folks in the research world who indeed had been working on this problem for a while, and I got excited about the technologies they had to offer. 00:12:15 - Speaker 1: Yeah, and then I guess I was downstream of that because I got introduced to space by Peter Van Hartenburg with time was a principal at the Inn Switch Research Lab, and it’s now the director of the lab. And he showed me a demo of the Pixel pusher project, and we can link to the article on this, but essentially this is a Pixel art editing tool that was peer to peer collaborative, and the app itself is very standard, but was amazing to me was he had implemented this app and he had 2 devices or 2 windows on the same device, and they were doing real-time collaboration, but there was no server. And I had come from this world of wherever you add a feature to an app, you gotta write the front end and then you gotta write the back end, you gotta make sure they line up whenever anything changes, it’s a whole mess, and it was just magical to me that you could just type up this JavaScript app and have it collaborating with another client in real time. So I went down that rabbit hole, and there was the obvious attractions of the austere locations and, you know, minimal network connectivity and things like that. And also at the time the research was very oriented around P2P, so there was this notion of the user having more control of their data and perhaps not even requiring a central server, but a couple of things became even more appealing to me as I researched it more. One was that Potential of higher performance. And I ended up writing a whole article about software performance that we can link to. But one of the key insights was that it’s not physically possible to have acceptably fast software if you have to go anywhere beyond the local SSD. Now, certainly if you’re going to a data center in Virginia or whatever, you’re totally hosed. So it was very important to incorporate this performance capability into Muse. 00:13:49 - Speaker 2: Yeah, that article was eye opening for me and that you connected the research around human factors, things that looked at what level of latency you needed for something to feel snappy and responsive, and then separately the speed of light, which is how sort of the maximum possible speed that information can travel, and if you add those together or do very simple arithmetic on that, you can instantly see it’s not about having a faster network connection. You literally cannot make something that will feel fast in the way that we’re talking about if you have to make a network round trip. 00:14:21 - Speaker 1: Yeah, and the one other thing that was really interesting to me about this space was the developer experience. I alluded to this earlier with the Pixel Pusher demo, but in the before times there were two ways to develop apps. You had the local model where you were typically programming against the SQL database, and everything was right there and it sort of made perfect sense. You would query for what you need and you write when you have new information and so on. And then there was the remote model of you would make rest calls, for example, out to some service like admit this edit or add a new post or whatever. But then these two worlds were colliding where we always wanted to be adding sync and collaborative capabilities to our apps, we would try to kind of jam one into the other, like you would try to patch some rest onto the database or you try to patch some database on yours and it just wasn’t working, and I realized we need to do a pretty fundamental rethink of this whole architecture, which is what we end up doing in the research lab and then now with Muse. The last thing I’ll mention about my journey here was my background was in back in engineering and distributed systems engineering, and so I had encountered variants of the sync problem several times, for example, at Hiroku, Adam. We had this challenge of we had these routers that were directing HTTP requests to a back end that was constantly changing based on these dinos coming up and down, and the routers needed to maintain in memory router tables based on the control plan that was being adjusted by the API. And so we had a similar problem if you need to propagate consistently in real time state to the in-memory databases of all these router nodes, and sure enough that work kind of came full circle and we were applying some of the same lessons here with Muse. So it’s a problem I’ve had the opportunity, for better or worse, to make a few passes at in my career. 00:15:57 - Speaker 3: Yeah, I think it’s an extremely hard problem that comes up so often across so many projects is eventually you need data over here in Box A to look the exact same as data over here in Box B. and it’s one of those problems that’s just surprisingly hard to get right, and there just aren’t that many libraries and existing solutions for it to drop in and implement. A lot of other libraries you can just go out and find it, and there’s code out there, or you can license it or open source, whatever, but for whatever reason, sync is one of those things that’s for every project, it needs to be custom baked to that project, just about every time. 00:16:38 - Speaker 2: And that’s part of what blew my mind back 8 years ago when I was looking for a sinking layer for clue and realizing that, yeah, I just had this feeling like surely everyone has this problem, everyone needs it, everyone needs the same thing. It’s really hard, you know, an individual company shouldn’t be distracting from their core competency of building their app to create the sinking layer, and yet to my surprise, there really wasn’t much, and that continues to basically be true today. 00:17:06 - Speaker 1: Yeah, and this gets into our collaboration with Martin Klutman on CRDTs. So briefly you can think of there being two pieces to this problem. One is conveying the physical data around, and the other is, OK, you have all this data that synchronize, what do you do with it, because it’s all a bunch of conflicting edits and so on. And that’s where the CRDT technology came in. I think one of the reasons why we haven’t seen widespread standard libraries for this stuff is the thinking problem is hard. We’ll talk more about that. But another is that we haven’t had the computer science technology to make sense of all of these edits. Well, we sort of did. There was like operational transforms, but you literally need to hire a. Team of PhD computer scientists have any shot at doing stuff like that. And so Google Docs basically had it and maybe a few others, but normal humans couldn’t do anything with it. But the CRDT technology and automerge, which we’ll talk more about, made it much more accessible and possible to make sense of all these conflicting edits and merge them into some useful application state. So that’s the kind of why now of why now is a good time I think to be pursuing this. 00:18:06 - Speaker 3: Yeah, and I think almost surprisingly to me, the solution we came up with at Muse, I think is actually really generic, and I think we solve it in a really elegant way that’s even more foundational to the technology than solving just for use. I think the solution we have. Can certainly solve from use in the future and is futureproof in that regard, but is broad enough to be applicable to a whole number of different uses and applications, which I think is really exciting too. 00:18:37 - Speaker 2: Maybe it’s worth taking a moment to also mention why we think local first in the style of sync is important for you specifically. I think certainly Mark and I have had a long time interest in it. Well, if you have an interest in it, so it’s just something that’s more like we’d like to see more software working in this way where the user has a lot more sort of control and literal ownership over the data because it’s on their device. In addition to being mirrored in the cloud, certainly the performance element is huge for me personally, and I think for all of us on the team. But I think Muse, as we go to this multi-device world, on one hand, we think that every device has its own kind of unique mood. The iPad is this relaxed space for reading and annotating, whereas the Mac or a desktop computer is for focus, productivity, you know, the phone is for quick capture, the web is good for sharing. OK, so really you need your work to be seamlessly across all of them. But at the same time, you know, we want that sense of intimacy and certainly the performance and the feeling that it’s in your control and you own it, and it belongs to you. I think that maybe matters less for some consumer products, or maybe it matters less for more kind of B2B, you know, enterprisey products, but for this tool, which is for thinking. Which is very personal, which is very kind of needs to be at your fingertips and friction free. I think the local first approach would be a good fit for a lot of software, but I think Muse needs it even more than most. So that’s why I’m really excited to see how this works out in practice as people try it out, and we really don’t know yet, right? It may be that we’ve made this huge engineering investment and in the end customers just say, I’d be happy with the cloud, yeah, it’s fine. I have some spinners, I can’t access my work offline. I hope not. But that could happen. We could be like falsifying the business hypothesis, but I really believe that for our specific type of customer, you’ll go to use this product with the sinking layer, you know, once we shake out all the bugs and so on and say, you know, this feels really fundamentally different from the more cloud-based software that I’m used to like an ocean and also fundamentally different from the non syncing pure local apps that I might use. 00:20:51 - Speaker 3: Yeah, I really think that with as connected as this world is and is becoming, there’s always going to be places of low connectivity, there’s always going to be places of just dodgy internet, and having an application that you know just always works, no matter what’s going on, and figures itself out later once it has good internet, is just so freeing compared to Those times when, you know, your device is switching Wi Fi networks or the LTE is just not quite what it needs to be to make things happen. I think it really does make a really huge difference, especially when you’re deep in thought, working on your content in use, the last thing you want is to be interrupted for even half of a second with a small spinner that says please connect to the internet. And so just being able to free the application and free the user from even worrying about the internet at all, even if it works 99% of the time, it’s that 1% of the time that breaks your train of thought that is just really frustrating. And I think that’s what’s exciting about being able to be purely offline is it fixes that really huge problem of that really small percentage of time that it happens. 00:22:10 - Speaker 2: Very well said. Now with that, I’ll do a little content warning. I think we’re about to get a lot more technical than we ever have on this podcast before, but I think this is a topic that deserves it. So I’d love to, and me especially as someone who’s not deep in the technology and just observing from the sidelines, I’d love to hear about what’s the high level architecture, what are all the pieces that fit together here that make this syncs when you’re on the internet and lets you keep working even when you’re not? What is it that makes all that work? 00:22:41 - Speaker 1: Yeah, I’ll give a really quick overview and then we can dive into some of the specific pieces. So to start with the logical architecture, the basic model is a user has a bag of edits, so you might have 1000 edits or a million edits where each edit is something like I put this card here or I edit this picture, and over time the user is accumulating all these edits and the job of the sync system is to ensure that eventually all of the users' devices have the same bag of edits. And it passes those edits around as opaque blobs and different flavors of blobs we’ll talk about. Basically there’s a bunch of bits of binary data that all devices need to have the same, and then it’s the device’s responsibility to make sense of those edits in a consistent way. So given the same bag, each device needs to come up with the same view of the muse corpus of that individual user, what boards are alive and what cards are on them and so forth. And then briefly in terms of the physical architecture, there’s a small server that’s running on Hiokku, data is stored in post grass and S3 and it’s implemented in Go, and again the server is just shuffling binary blocks around basically. And then there’s different front ends, different clients that implement this synchronization protocol and present a use corpus model up to the application developers. So the most important of these is the SWF client. We also have a JavaScript client and both of these back to SOI databases locally. 00:24:09 - Speaker 3: Yeah, and I think what’s really interesting about this architecture is that we actually maintain the entire bag of edits. Edits only get added into the bag, but they never really get removed. And so the current state of the application is whatever the most recent edit is. So if I make a card bigger on my Mac, and then I go to my iPad and I make that same card smaller. And then we synchronize those two things. Well, at the end of the day, either the card is going to be smaller on both devices, or the card is gonna be bigger on both devices, and we just pick the most recent one. And that strategy of just picking the most recent edit actually makes conflicts essentially invisible or so small and so easy to fix that the user can just, oh, I want that big, let me make it big again. It’s really easy to solve. For the user side without showing up one of those really annoying, hello, there’s been an edit. There’s a conflict here. Would you like to choose copy A or copy B? Just being able to automatically resolve those is more than half of the magic, I think, of this architecture. 00:25:13 - Speaker 2: I also note this is a place where I think the muse domain, if you want to call it that, of the cards on a canvas model works pretty well with this sort of automated resolution, which is if you moved a card in one direction on one device and you moved it somewhere else on the other device, it’s not really a huge deal which one it picks as long as it’s all kind of like flows pretty logically. By comparison, text editing, so what you have in a Google Docs or certainly I know auto merge team and the incode switch team has done a huge amount of work on this, is a much harder space where you can get into very illogical states if you can merge your edits together, strangely, but I think a card move, a card resize, add remove, even some amount of reparenting within the boards, those things just are pretty natural to merge together, I think. 00:26:02 - Speaker 3: Yeah, I think so, and I think even with the new text block feature in Muse, we end up slicing what would be a really long form text document into much smaller sentences or paragraphs. And so then text edits, even though we’re only picking the kind of the most recent one to win, we’re picking that most recent at the granularity of the sentence or of the the paragraph, and so. Conflicts between documents for us are larger than they would be for automerge or for Google Docs, but are small enough that it’s still ignorable for the user and easily solvable by the user. 00:26:42 - Speaker 2: Which incidentally I think is a trick we sort of borrowed from FIMA, at least on the tech side, which is in FIGA and also in Muse. If one person edits, you know, the red car and someone else edits the blue car, you don’t get the red blue car, you just get one or the other, and it turns out for this specific domain, that’s just fine. 00:27:03 - Speaker 3: Yeah, I think we kind of lucked out having such a visual model, and we don’t need to worry about intricacies of multi-user live document editing. 00:27:13 - Speaker 1: Yeah, I would point to both Sigma and actual budget as two very important inspirations for our work. I would say those are two of the products that were most at the forefront of this space, and thought about it most similarly to how we did. And notably they, as well as us sort of independently arrived at this notion of basically having a bunch of last white wins registers. As the quote unquote CRDTs. So these are very, very small, simple, almost degenerate CRDTs where the CRDT itself is just representing one attribute, for example, the X coordinate of a given card. But this is an important insight of the industrial application of this technology, if you will. That’s a good trade-off to make it. It basically covers all the practical cases, but it’s still very simple to implement, relatively speaking. 00:28:03 - Speaker 2: I also mentioned briefly actual budget, great in the basically made by one person app and recently open source, so you can actually go and read the custom CRDT work there and maybe learn a thing or two that you might want to borrow from. 00:28:17 - Speaker 3: I think one of the really interesting problems for me about the CRDT was Deciding which edit is the most recent because it just makes logical sense to say, oh well, it’s 3 o’clock, and when I make this edit at 3 o’clock and I make a different edit at 3:02, obviously the one at 3:02 wins. But since computer clocks aren’t necessarily trustworthy, sometimes I have games on my iPad that reset every day and so I’ll set my clock forward or set my clock backward. Or if I’m on an airplane and there’s time zones, and there’s all kinds of reasons the clock might jump forward or jump backward or set to different problems, and so using A fancier clock that incorporates a wall clock, but also includes a counter and some other kind of bits of information, lets us still order edits one after the other, even if one of those clocks on the wall is a year ahead of schedule compared to the other clocks that are being synchronized. I don’t know how in depth we want to get on that, but it’s it’s called a hybrid logical clock. 00:29:23 - Speaker 1: Yeah, I think this is another great example along with choosing very simple CRDT structures of industrial style architecture where you could go for a full blown vector clock, and that gives you perfect logical ordering and a bunch of other nice properties, but it’s quite large and it’s expensive to compute and so on. Whereas if you choose a simpler fixed size clock, that can give you all the benefits that you need in practice, it can be easier to implement, it could be faster to run, and so on. 00:29:52 - Speaker 3: Like everything in life, it’s all about trade-offs, and you can get accuracy, but it costs more, or you can get a little bit less accuracy, and it costs a lot less, and for us that was the better trade-off to have a fixed size clock that gives us Enough of the ordering to make sense, but might not be exactly perfect ordering. 00:30:13 - Speaker 1: And we’ve been alluding to trade-offs and different options, so maybe it’s time to address it head on in terms of the other options that we considered and why they weren’t necessarily as good of a fit for us. So I would include in this list both iCloud and what you call like file storage. 00:30:27 - Speaker 2: It might be like cloud kit or something, but yeah, they have one that’s more of a blob, kind of, you know, save files, what people will think of with their sort of iCloud drive, almost kind of a Dropbox thing, and then they also have a cloud kit. I feel like it’s a key value store, but in theory, those two things together would give you the things you need for an application like ours. 00:30:47 - Speaker 1: Yeah, so there’s iCloud as an option, Firebase, automerge. CouchDB maybe, then there’s the role you’re on which we ended up doing. 00:30:57 - Speaker 2: Yeah, the general wisdom is, you know, you don’t write your own, if there’s a good off the shelf solution, you name some there that are commercial, some are built into the operating system we’re using, some are indeed research projects that we’ve been a part of, what ultimately caused us to follow our own path on that. 00:31:15 - Speaker 1: Yeah, so there was a set of issues that tended to come up with all of these, and it was more or less in different cases, but I think it’d be useful to go through the challenge that we ran into and talk about how they emerged in different ones of these other solutions. So one simple one, it would seem it’s just like correctness slash it works. And the simple truth is, a lot of the singing systems out there just do not work reliably. Hate to pick on Apple and iCloud, but honestly, they were the toughest in this respect where sometimes you would, you know, admit data to be synchronized and just wouldn’t show up, and especially with opaque closed source solutions and third party solutions, stuff would not show up and you couldn’t do anything about it, like you couldn’t see what went wrong or when it might show up or if there was some error. And then bizarrely, sometimes the stuff would pop up like 5 or 10 minutes later. It’s like, oh, it’s actually sort of worked, but it’s off by You know, several zeros in terms of performance. So that was a really basic one, like the syncing system has to be absolutely rock solid and it kind of goes back to the discussion Wulf had around being offline sometimes. If there’s any chance that the sync system is not reliable, then that becomes a loop in the user’s mind. Am I gonna lose this data? Is something not showing up because the sync system is broken. Our experience has been that if there’s any lack of reliability or lack of visibility into the synchronization layer. It really bubbles up into the user’s mind in a destructive way, so we want it to be absolutely rock solid. Another important thing for us was supporting the right programming model. So we’ve been working on news for several years now. We have a pretty good idea of what capabilities the system needed to have, and I think there were 4 key pillars. One is the obvious transactional data. It’s things like what are the cards and where are they on the board. This is data that you would traditionally put in a SQL database. Another thing that’s important to have is blob support, to a lot of these binary assets in use, and we wanted those to be in the same system and not have to have another separate thing that’s out of band, and they need to be able to relate to each other correctly. 00:33:09 - Speaker 2: This is something where a 10 megabyte PDF or a 50 megabyte video just has very different data storage needs than the tiny little record that says this card is at this X and Y position and belongs to this board. 00:33:23 - Speaker 1: Right, very different, and in fact you’re gonna want to manage the networking differently. Basically you want to prioritize the transactional data and then load later, or even lazily, the binary data, which is much larger. Yeah, so there was transactional data, blob data, and then real-time data slash ephemeral data. So this is things like you’re in the middle of an ink stroke or you’re in the middle of moving a card around and this is very important to convey if you’re gonna have real time and especially multi-user collaboration, but again, you can’t treat this the same as certainly blob data, but even transactional data, because if you store every position a card ever was under your finger for all time, you’re gonna blow up the database. So you need those 3 different types of data, and they all need to be integrated very closely. So for example, when you’re moving a card around, that’s real time, but basically the last frame becomes a bit of transactional data, and those two systems need to be so lined up to each other that it’s as simple as changing a flag. If you’re going on a 2nd or a 3rd band for real-time data and need to totally change course for saving the transactional data, it’s not gonna be good. It was quite rare. I don’t know if we found any systems that support all three of these coherently. 00:34:33 - Speaker 2: The ephemeral data element I found especially interesting because you do really want that real timey feeling of someone wiggles a card with their finger and you can see the wiggling on the other side. That just makes the thing feel live and Just responsive in a way that it doesn’t otherwise. But yeah, at the same time, you also don’t want hundreds of thousands of records of the card moved 3 pixels right, and then 3 pixels left. And one thing I thought was fascinating, correct me if I misunderstood this, but is that because the client even knows how many other devices are actively connected to the session, it can choose to not even send that ephemeral data at all. It doesn’t even need to tap the network. If no one else is listening, why bother sending ephemeral data? All you need is the transactions over time. 00:35:21 - Speaker 1: Right, this is actually a good example of how there’s a lot of cases where different parts of the system need to know or at least benefit from knowing about other parts. So it becomes costly or or maybe just an outright bad idea to separate them, especially as we’re still figuring out as industry how they should work. I think there’s actually quite a bit of benefits to them being integrated. Another. that we could talk about eventually is prioritizing which data you download and upload, you might choose to first download blobs that are closer to you in board space, like it’s in your current room or it’s in adjacent rooms, and then later you can download other blobs. So that’s something you could do if the application had no notion of the networking layer. It actually brings us to Another big challenge we saw with existing systems, which is multiplexing. So I’ll use an example of automerge here, and this is something we’ve seen with a lot of research oriented CRDT work. It’s very focused on a single document, so you have a document that represents, you know, say a board or whatever, and a lot of the work is around how do you synchronize that document, how do you maintain correctness, even how do you maintain performance when you’re synchronizing that document across devices. Well, the challenge with Muse with our model. You might have, you know, easily 1000, but, you know, potentially tens of thousands up to millions of documents in the system corresponding to all your individual cards and so on. And so if you do anything that’s order and in the number of documents, it’s already game over. It needs to be the case that, here’s a specific challenge that I had in mind for the system. You have a corpus, let’s say it’s a million edits across 10,000 documents or something like that, and it’s 100 megabytes. I wanted the time to synchronize a new device that is to download and persist that entire corpus, to be roughly proportional to the time it would take to just physically download that data. So if you’re on a 10 megabyte connection, 100 megabyte connection, maybe that’s 10 seconds. But the only way to do that is to do a massive amount of like multiplexing, coalescing, batching, compression, so that you’re taking all these edits and you’re squeezing them into a small number of network messages and compressing them and so on. So you’re sort of pivoting the data, so it’s better suited to the network transfer and the persistence layer. And again, you need to be considering all these things at once, like how does the application model relate to the logical model, relate to the networking protocol, relate to the compression strategy, and we weren’t able to find systems that correctly handle that, especially for when you’re talking about thousands or millions of documents being synchronized in parallel. And the last thing I’ll mention is what I call industrial design trade-offs. We’ve been alluding to it in the podcast so far, but things like simplicity, understandability, control, these are incredibly important when you’re developing an industrial application, and you tend not to get these with early stage open source projects and third party solutions and third party services. You just don’t have a lot of control and it was too likely to my mind that we would just be stuck in the cold at some point where system didn’t work or it didn’t have some capability that we wanted, and then you’re up a dead end road, and so what do you do? Whereas this is a very small, simple system. You could print out the entirety of the whole system it would be probably a few pages, well it’s a few 1000 lines of code, it’s not a lot of code, and it’s across it’s a couple code bases, and so we can load the whole thing into our head and therefore understand it and make changes as needed to advance the business. 00:38:38 - Speaker 3: Yeah, I think that last point might honestly be the most important, at least for me. I think having a very simple mental model of what is happening in sync makes things so much easier to reason about. It makes fixing bugs so much easier. It makes preventing bugs so much easier. We’ve been talking about how sync is hard and how almost nobody gets it right, and that’s because it’s complicated. There’s a bajillion little bitty edge cases of if this happens, but then this happens after this happens, and then this happens. What do we do? And so making something really really simple conceptually, I think was really important for the muse sync stability and performance at the end of the day. 00:39:21 - Speaker 2: I’m an old school web developer, so when I think of clients and servers, I think of rest APIs, and you maybe make kind of a version API spec, and then the back end developer writes the endpoint to be called to and the front end developer figures out how to call that with the right parameters and what to do with the response. What’s the diff between a world that looks like that and how the new sync service is implemented? 00:39:50 - Speaker 1: Yeah, well, a couple things. At the network layer, it’s not wildly different. We do use protocol buffers and binary encoding, which by the way, I think would actually be the better thing for a lot of services to do, and I think services are increasingly moving in that direction, but that core model of you have, we call them endpoints. You construct messages that you send to the endpoint and the server responds with a response message. That basic model is pretty similar, even if it’s implemented in a way that’s designed to be more efficient, maintainable, and so on than a traditional rest server. But a big difference between A traditional rest application and the muse sync layer is that there are two completely separate layers, what we call the network layer and the app layer. So the network layer is responsible for shuffling these binary blobs around the transactional data, the ephemeral data, and the big binary assets. And the server knows absolutely nothing about what’s inside of them by design, both because we don’t want to have to reimplement all of the muse logic about boards and cards or whatever in the server, and also because we anticipate eventually end to end encrypting this, and at that point, of course, the server can’t know anything about it, it’s not gonna be possible. So that’s the networking layer and then if you sort of unwrap that you get the application layer, and that’s the layer that knows about boards and cards and edits and so on. And so it is different, and I would say it’s a challenge to think about these two different layers. There’s actually some additional pivots that go on in between them, versus the traditional model of you would like post V1 slash boards directly and you’d put the parameters of the boards and then the surfer would write that to the boards table and the database. There’s a few different layers that happen with this system. 00:41:30 - Speaker 2: So if we want to add a new card type, for example, or add a new piece of data to an existing card, that’s purely in the application layer on the back end, or it doesn’t know anything about that or no changes are needed on the back end. 00:41:44 - Speaker 1: Yeah, no changes are needed. In fact, one of the things I’m most proud about with this project is we basically haven’t changed the server since last year, December, and we’ve been, you know, rigorously iterating on the app, you know, adding features, changing features, improving a bunch of stuff, and the servers, it’s basically the same thing that was up 4 months ago, just chunking along, and that’s a benefit. It’s a huge benefit, I think, of this model of separating out the application model and the network model, because the network model is eventually gonna move very slowly. You basically figure that out once and I can run forever. And the application model has more churn, but then when you need to make those changes, you only need to make them in the client or the clients that maybe you update the application schema so that current and future clients can understand that, and then you just start including those data in the bag of edits. 00:42:26 - Speaker 3: Yeah, I think one thing that’s really nice is that those protocol buffers that you were talking about are type safe and kind of statically defined, so that way it’s when we’re sending that message over the wire, we know 100% we’re sending exactly the correct messages no matter what, and that guarantee is made at compile time, which I think is really nice because it means that a lot of bugs that could otherwise easily sneak in if we’re using kind of a generic JSON framework, we’re gonna find out about when we hit the please build muse button. Instead of the I’m running views and I randomly hit a bug button. And that kind of confidence early on in the build process has been really important for us as well to find and fix issues before they even arise. 00:43:11 - Speaker 1: Yeah, to my mind this is the correct way to build network clients. You have a schema and it generates typesa code in whatever language you want to use. There’s just enormous benefits to that approach. I think we’re seeing it with this on use and again, I think more systems, even more traditional B2B type systems are moving in this direction. By the way, everyone always made fun of Amazon’s API back in the day. I had this crazy XML thing where There’s a zillion endpoints. I actually think they were closer to the truth and the traditional, you know, nice rest crud stuff because their clients are all auto generate and sure enough they have like literally a zillion endpoints, but everything gets generated for free to a bunch of different languages. Anyways, one challenge that we do have with this approach is, you know, one does not simply write a schema when you have these multiple layers. So again, if you look at a traditional application, you have a protocol buffer definition of, say, a board B board and probuffs. And that would have fields like title and width and height or whatever. And when you want to update the board, you would populate a memory object and you would encode this to a protocol buffer and you would send this off to the server. Well, it’s not quite that simple for us because we have this model of the small registers that we call atoms. So an atom is the entity, say a board, the attributes say the title, the value say use podcast, and the time stamp. And your bag of edits is comprised of all these different atoms, but the problem is, how do you encode both how you’re gonna send an atom, which is as those twopos, as well as what a logical board is, you know, what the collection of atoms is meant to look like, you know, it’s gonna have a title and the width and height and so on. So that’s been honestly a pretty big challenge for us where it doesn’t fit into any of the standard schema definition approaches, certainly not the regular protocol buffer schema, which again we use for the network and for encoding the messages that are wrapped up in the network, but you need a separate layer that encodes the application model, as we call it, you know, what is a board, what is a card, what attributes that they have and so on. 00:45:06 - Speaker 2: And Wulf, if I recall you have a blog post about these atomic attributes. I’ll link that in the show notes for folks. 00:45:14 - Speaker 3: Yeah, so unfortunately no relation between my name and Adam. It’s a TOM. 00:45:18 - Speaker 2: Yes, we have two Adams on this podcast. The ADAM is different from the ATOM. 00:45:25 - Speaker 1: Yeah. A big inspiration on this, by the way, is Tomic, I don’t know if we’ve mentioned that yet on this podcast, but Atomic is a database system developed by Rich Hickey and team who is also the creator of Closure. And it uses this model in contrast to the traditional relational model you have tables and columns and rows. The atomic model is more like a bag of time stamped attributes where you have an entity, an attribute, a value and a time stamp. And from that, it could be more challenging to work with that model, but it’s infinitely flexible. You can sort of put whatever model you want on top of that, and it works well for creating a generic database system. You know, you couldn’t have a generic post graphs, for example, that could run any application. You need to first create tables that correspond to the actual application you’re trying to build, whereas with an atom oriented database, you basically have one huge table which is atoms. So it’s useful again for having this slower moving more stable synchronization layer that handles moving data around that you build the application on top of that moving quickly. 00:46:27 - Speaker 3: Yeah, and like we talked about earlier, it’s so much simpler to reason about. All of the problems of my iPad is on version 1, my Mac is on version 2, and my iPad Mini is on version 3. They’re sending data back and forth. At the end of the day, every single database on all three of those clients is gonna look the same, even though they have completely different logic, maybe different features. But all the simplicity of that data store makes it much, much easier to reason about as the application gets upgraded or as two different versions of the client are synchronizing back and forth. 00:47:03 - Speaker 2: How does that work in practice? So I can certainly imagine something where all of the data is sent to every client, but a V1 client just doesn’t know what to do with this new field, so just quietly stores it and doesn’t worry about it. But in practice, what happens if I do have pretty divergent versions between several different clients? 00:47:23 - Speaker 1: Recall some podcasts ago, we suggested that everything you emit should have a UU ID and a version. Well sure enough that’s advice that we take to heart with this design, where all the entities, all the messages, everything has a UU ID and also everything’s version, so there’s several layers of versioning. There’s the network protocol is versioned and the application schema is versioned. So by being sure to thread those versions around everywhere, the application can then make decisions about what it’s gonna do and Wulf can speak to what the application actually chooses to do here. 00:47:54 - Speaker 3: Yeah, exactly. If we’re sending maybe a new version of a piece of data on the network layer that device A just doesn’t physically know how to decode from that work, then it’ll just save it off to the side until it eventually upgrades and then it’ll actually read it once it knows what that version is. 00:48:11 - Speaker 2: So is there someone like, can I make a crude metaphor here, someone emails me a version of a Word doc from a later version that I don’t have yet, I can save that on my hard drive, and later on when I get the new version, I’ll be able to open the file. 00:48:25 - Speaker 3: Yeah, exactly right. It’s very similar to that. And then I think there’s a different kind of upgrade where we’re actually talking the same language, but I don’t know what one of the words is that you said. So let’s say we add a completely new content type to muse called the coffee cup, and everyone can put coffee cups on their boards, right? That coffee cup is gonna have a new type ID attribute that kind of labels it as such. New clients are gonna know what type 75 means coffee cup, and old clients are gonna look at type 75 and say, oh, I don’t know about Type 75, so I’ll just ignore it. And so the data itself is transferred over the network schema and kind of the app schema and understands those versions, but it might not understand the physical data that arrives in the value of that atom. And in that case, it can happily ignore it and will eventually understand what it means once the client upgrades. And so there’s a number of different kind of safety layers where we version something. If we’re unable to even understand kind of the language that’s being spoken, it’ll be saved off to the side. If we do understand the language that’s spoken, but we don’t understand the word, we can just kind of safely ignore it, and then once we are upgraded, we can safely understand both the language and the word. 00:49:47 - Speaker 1: Yeah, so maybe to recap our discussion of the low level synchronization protocol before we go on to the developer experience and user experience, might be useful to walk through a sort of example. So suppose you are doing a thinking session in your nice comfy chair on your iPad, you’re offline, you’re making a few dozen edits to a series of different boards and cards in your corpus. Those are going to write. New atoms in your database, and those are essentially gonna be flagged as not yet synchronized, and then when you go online, those atoms, assuming it’s some plausible number, you know, it’s maybe less than 1000 or so. Those are all gonna be combined into a single network message. So this is that multiplexing efficiency where you certainly don’t need to check every document in your corpus, and you don’t even need to do one network right per every edit or even one network right per document. You can just bundle up all of your recent changes into a single protocol buffer message and could potentially compress it all with GSIP, and then you send that out to the server. The server doesn’t know anything about these edits, you know it’s just one big binary packet. The server persists that, and then it sends a response message back to the client and says, OK, I’ve successfully received this. You can now treat this as synchronized and the server will take responsibility for broadcasting it out to all the clients. And then clients as they come online, if they’re not already online, they will immediately receive this new packet of data called a pack. And then they can decompress and unpack that into its constituent atoms, and once they’ve processed those, tell the server, I have successfully saved this on my device and in the background of the server is essentially maintaining a high watermark of for each device that’s registered for this user, what’s the latest pack or block they successfully persisted, and that way as devices come on and offline, the server knows. What new data needs to send to each individual device, and that works both for essentially conveying these updates in near real time as they happen, as well as for doing big bulk downloads if a device has been offline for a long time. And I know we’ve mentioned a few times, but to my mind this multiplexing and batching and compression is so important, so it’s the only thing that makes this even remotely feasible with the Muse data model of having a huge number of objects. And then I think this leads pretty naturally to a discussion of the developer experience. So we’ve talked about this sort of sync framework, and that essentially is gonna present a developer interface up to the application developer. So Wulf, maybe you can speak a little bit to that. 00:52:19 - Speaker 3: Yeah, we’ve talked some about the simplicity that we’re aiming for, just conceptually and how synchronization works. I think it’s equally important for this to be extremely simple for the end developer to use as we’re building new features in use or as we’re, you know, changing the user interface around. That developer, whether it’s me or Julia or anybody else working on Muse, doesn’t need to be able to think in terms of sync at all. We just need to be able to write the application is the ideal world, needs to be very, very simple. And so keeping that developer experience simple was a really big piece of designing what sync looks like inside of Swift for iOS. Since we had been built on core data beforehand, a lot of that developer interaction ends up looking extremely similar to core data. And so we build our models in Swift, it’s a Swift class. We have all of the different attributes where there’s position, and size, and related document, and things like that, and we just stick what’s called in Swift a property wrapper, it’s just a small little attribute. In front of that property that says, oh by the way, this thing, this thing belongs in the sync database. This property is gonna be merged, and that one little piece of code, that one little kind of word in the code program is what fires up the sync database and the sync engine behind it to make all of this stuff work. And that has been really important both for conceptually building new features, but also for migrating from core data to sync. Because the code that core data looks like beforehand, and the code that sync looks like now, is actually extremely similar. Early on in the development process, our very first kind of internal beta, internal alpha, pre-alpha, whatever version you want to call it. Very early on in the process, we actually ran both core data and the sync engine side by side. So some of the data in Muse would load from core data and other bits and pieces would load from sync, but both of those, because they looked very, very similar from the developer’s perspective, from kind of how we use both of those frameworks. It allowed us to actually slowly migrate use over from one to the other, by replacing bits of core data with bits of sync, and then this little bit of core data with this little bit of sync. I mean there’s, you know, thousands and 10s of thousands of lines of custom logic to make muse muse. And so it was really important to keep all of that logic running, and to keep all that logic separate from the physical data that logic was manipulating. And so making those appear similar to the developer, let us do that. It let us keep all of that logic essentially unchanged in use while we kind of swap out that foundation from underneath it. 00:55:15 - Speaker 2: And I remember when you implemented the first pass at this persistence library, and I forget if Yuli was maybe away on holiday or maybe she was just working on another project, but then she came in to use your kind of first working version and start working on the sort of porting it across and she had a very positive reaction on the developer experience, you know, you are sort of developing the persistence layers so you naturally like it because. Here, maybe the way you like it and you’re thinking about the internals, she’s coming at it more from the perspective as a consumer of it or a client or a user, and the developer experience, and I found that to be promising because I mean, she, like most, I think iOS developers has spent many, many years in her career using core data. Which is a long developed and well thought through and very production ready persistence layer that has a lot of edge cases covered and is well documented and all that sort of thing. So in a way it’s a pretty high bar to come in and replace something like that and have someone just have a positive reaction to using it as a developer. 00:56:21 - Speaker 3: Yeah, I was so happy when she said that she kind of enjoyed using it and kind of understood how it worked, because of course every developer likes their own code, but when a developer can use and is comfortable with another developer’s code, that’s really, really important. And that was absolutely one of my goals is to make sure that it was simple for Julia to use and simple for any other developer that comes onto the Muse team that doesn’t have background in Muse and in our code base. For them to be able to jump in quickly and easily and understand what’s going on, was a really important piece of how this framework was built. 00:56:57 - Speaker 1: Yeah, I think this is a really important accomplishment, and Wulf is maybe even underselling himself a little bit, so I want to comment on a few things. One is, while there’s just this simple annotation of I think it’s at merged is that it Wulf. Yeah, that’s right. Sometimes when you see that, that annotation instructs the framework to do something additionally on the side, on top of the existing standard relational database, you know, like basically do your best, try to synchronize this data out of band with some third party service or whatever. But this in fact totally changes how the data is persisted and managed in the system, so it’s sort of like a whole new persistent stack for the application. And I think that’s important because we constantly see that the only way you get good results on sync system, especially when you’re talking about offline versus online and partially online, it has to be the one system that you use all the time. You can’t have some second path, that’s like the offline cache or offline mode that never works. It needs to be the one, you know, true data synchronization and persistence layer. So I think that’s as important though. There’s another subtle piece here, which is the constraints that you have with the industrial setup. So a lot of the research on CRDTs and synchronization basically assumes that you have one or a small number of documents in memory, and that if you’re going to be querying these documents or managing synchronization of these documents that you have access to the full data set in memory. But it’s not practical for our use case, both because of the total size of memory and the number of documents we’d be talking about. So a lot of critical operations can take place directly against the database or the data layer can smartly manage bringing stuff in out of memory. It’s not like we have the whole new corpus up in memory at any one time, the system has to smartly manage what gets pulled up from disk in the memory and what gets flushed back, and then that. Introduce a w

Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: As software developers, maybe we go towards building a GUI with specialized inputs and forms and controls too soon, because it’s so much easier to explain to the computer what the user means if they use a specialized input tool like a button check box and so on. But if that weren’t the case, if it’s easier for the computer to understand what you mean as you’re typing in your note, then suddenly text input is the primary thing. 00:00:32 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for deep work on iPad and Mac. But this podcast isn’t about Muse product, it’s about the small team, the big ideas behind it. I’m Adam Wiggins, joined today by Jeffrey Litt. Hey. And Max Schoening, great to be here. Now, the two of you are working together with some others on an ink and Switch project we’re gonna talk about today, but first, I understand that there’s some cooking adventures going on in the lit household. 00:01:02 - Speaker 3: Yeah, so I’ve been trying to make my own stock lately. I’ve been reading this incredible book that someone recommended to me on Twitter called An Everlasting Meal by Tamar Adler, and it’s all about how to use leftovers and just like random stuff in your fridge to cook both as a way of not wasting, but also just cause it feels good. So I’ve been, you know, throwing random like carrot tops and stuff into a pot, and it feels really fun. That’s my recent cooking adventure. 00:01:29 - Speaker 1: Inspired by, we’ll get into it a little bit later with the project too, but partially by Jeffrey’s cooking. I’ve also started taking cooking maybe a little bit more seriously than before. Like I think one of the things that sort of distinguishes the amateur from someone who’s more seriously involved in something is consistency and my cooking was never all that consistent cause the loop of how frequently you repeat a dish when you’re just cooking sort of for fun is very long, right? So the learning is slow, so I’ve been getting into sous vide cooking. And just eating way more steak slash anything you can sous vide that I would like, but at least the results are getting better. 00:02:11 - Speaker 3: I’m a sous vide fan as well. It’s a major cheat code, I find. Everything is perfect every time. 00:02:17 - Speaker 1: I wish that had been my experience too. 00:02:21 - Speaker 2: Yeah, consistency and repetition, yeah, short feedback loops. I was inspired by a book, I think it’s called the Food Lab, where basically the author does some, call it like. Amateur science in the sense of taking common cooking claims, like should you salt meat before cooking it, or is it better if you don’t flip it, or you only flip it once versus twice or something, it would essentially just cook several side by side, varying this one thing. And then do a little informal taste test with his, you know, housemates or whatever, and sort of like try to answer that question, and many times found out that, or at least had the finding, let’s call it, that things that people swore by didn’t really actually make a huge difference in the outcome, but that idea for myself, I think even our Mutual friend and colleague Peter Van Hardenberg introduced a version of that in the Hiroku offices when he would do a little coffee workshop and essentially like brew a cup of coffee with several different approaches, you know, here’s the Chemex, here’s the French press, here’s the, and then you could taste them side by side and have new appreciation for the way these different techniques change the taste of the same source bean. 00:03:34 - Speaker 3: Yeah, I love that mindset. I think what I see as the challenge at home cooking is, you know, to bring in some of that idea of getting better and being a little rigorous without making the whole thing too overcomplicated and kind of perfectionist. There’s some aspect of amateurism and just having fun with it, that’s sort of the whole point to begin with. So I think that’s a fun balance to strike. 00:03:57 - Speaker 2: So longtime listeners of Meta Muse will know that we’re shaking up the format a little bit here. This is our first time with two guests. It’s usually me and Mark as co-hosts along with one guest, and this is partially my theory that it’s a little hard for listeners to adapt to two new voices, but in fact, you two are not new to our guests potentially. Max, you are one of our very first guests all the way back in episode 8 when we talked about principal products. And Jeffrey, you joined us for somewhere around episode 34, where we talked about bring your own client. So, anyways, I thought it would be fun, especially because both of you work together on this research project to get you here together. So you can go back and listen to those episodes if you want the full backstory, but maybe you could each give a 32nd summary bio of yourself before we dive into the project itself. 00:04:51 - Speaker 3: Yeah, so I’m a grad student at MIT as well as a collaborator with the In and Switch Research lab, and my research mission is to figure out how to make software more customizable so people can edit the tools that they use and make their own software, and the project we’ll be talking about today has a lot of resonance with that theme, so excited to be here again. 00:05:12 - Speaker 1: And this is my first foray into research. I’m a software designer. I’ve worked on things like Hiroku, GitHub, cloud app, way in the past, and generally I like to summarize. My efforts as I like to make things for people who make where make is the developer build tool. 00:05:33 - Speaker 2: And our topic today will be dynamic documents, which indeed is what the potluck project that you both worked on and recently published about is all about. So we’re hoping to dive into the specifics of that project as well as some of the research process behind it. Maybe we could start out with a description, kind of the, I don’t know if elevator pitch is the right way to talk about a a research project, but a short summary. 00:05:58 - Speaker 3: We’re not raising funding, but I can give a summary, sure. So, Potluck is a substrate that we’ve been developing, where the goal is to turn regular old text documents into interactive tools that help you in your life. And so there’s this idea that you can just start by, you know, jotting a note on your phone like you might in an app like Apple Notes, and then gradually you start enriching that note with little bits of computation and interaction. And if you keep doing that for a while, you might end up with something that looks suspiciously like An app that you might download from the app store, but it’s not like someone else made it for you, it’s sort of organically evolved out of just a note that you started writing, and, you know, some examples of the kinds of things that we’ve thought about in the substrate are You’re writing down a recipe that your mom told you for how she makes her dumplings, and then you decide, oh, I’m gonna have a party, so I want to make 5x the recipe. What’s like 730 g times 5. That’s something that a computer should be able to help you with, right? But if your data is in a text note, how do you bring in the computer to play its role and help you out a little bit? We’ve developed these primitives where you can start injecting these little bits of computation as you need them into your text note. And so, that’s kind of the overall idea of the project. One analogy that I think is helpful to understand the general ethos of it is spreadsheets. I’m a huge, huge fan of spreadsheets. I think they’re a really empowering medium that people interact with pretty typically on a computer these days. And the cool thing about a spreadsheet, right, is that when it starts out, it’s just a bunch of numbers in a table. It’s just data sitting there, and it’s already useful in that state. And then gradually you might add a little formula, you might add a V lookup, and if you keep doing that, by the end, you might end up with this ridiculously complicated app that’s running your whole business, but it didn’t start out that way. It wasn’t planned to happen that way, it just started out as this little bit of data that you were storing, and it naturally evolved, right? So that’s kind of the general idea. 00:08:04 - Speaker 1: Yeah, there’s the well known meme of this insert startup could have been a spreadsheet, and I think in this case, you could probably make the same argument that this app could have been a note. And in fact, I would love to be able to do this at scale, but like if you just open the average users notes apps, what kind of notes do they take and, you know, throughout the course of this research project. That was sort of a grounding force of, oh, what kind of notes do people keep track of and so we started looking at, you know, like Jeffrey was saying recipes. At some point we did workout tracking and plant water tracking and like collecting your favorite hikes and so on, and they all have this sort of very innocuous beginning. You’re not planning to make something big, you’re just sort of planting a little seed as a note and What was frustrating for us is, at some point, if you then want a little bit more help from the computer, you usually have to move it out of the notes app, which is a little bit sad because it’s this big drop off, and so that’s kind of what we’ve been looking at, like, how do you make that go away. 00:09:14 - Speaker 2: And I love the diversity of use cases outlined in the essay. You focus on this cooking use case as a sort of a central one, even baked into the name of the project, but indeed all of these different kind of personal tracking stuff that tends to get scribbled down in notes and and in particular notes in your phone, text notes in your phone, that they’re not very structured, you’re trying to capture them in the moment and move on. And certainly many of those are things I have done, but also there is a whole industry is a way to put it, category of app which is trackers. So, yeah, hike trackers and run trackers and sleep trackers. And yeah, fitness trackers, step counters, weight trackers, you know, and sometimes that’s paired with, I don’t know why, you know, Fitbit has their Wi Fi connected scale, and when you step on it every morning, it automatically records the data, but then a weakness for someone who is both curious and has some light programming capabilities is actually getting that data out or doing something with it in a more flexible tool like a spreadsheet. is often pretty difficult. Actually, Fitbit, I think even famously had a little bit of pushback for the, you had to pay for the feature to kind of like download your data as a CSV and even then it feels like this very discontinuous, OK, I’m exporting now, the data, who knows what format it’s even in, and there certainly can’t be a continuous using of the app, inputting of the data, and then also I’m gonna put it through my own, call it personal analytics. 00:10:43 - Speaker 3: Yeah, and I think another weird thing about this ecosystem of trackers is that it sort of splits up your life into these very specific categories, right? So, for example, after my workout, what if I have a nutrition shake and I’m tracking my nutrition, I need to switch from my workout tracker to my nutrition tracker, and there’s this sort of world that each app considers its space that it doesn’t go outside of, you know? This also happens when, you know, We looked a lot at recipe apps because we were thinking about cooking as one of our main domains with this tool, and a lot of cooking apps start out very simple with tracking your recipes, but then there’s sort of a natural force to bloat them with extra stuff, so, You’ll add grocery list stuff, and you’ll add menu planning, and, you know, meal planning for the week, and all these. 00:11:29 - Speaker 2: All of your friends, what are they cooking? 00:11:31 - Speaker 3: Yeah, like social, you know, and I feel like we’ve all experienced this tool starts out nice and small and grows in weird ways. And what I think is important here is, I’m fine with it growing in the ways that I want it to be useful. What’s annoying to me is having 100 things crammed in there that I don’t need and can’t remove from the tool. And then on the flip side, the one extra thing that I do need, I can’t add myself, right? So, we sort of like, let the developer of each tracker decide what does cooking or what does workouts mean, like, what’s the scope of that activity, and it’s really hard to permeate that kind of boundary that gets set there, and so that’s one of the problems that we were thinking about in developing potluck. 00:12:12 - Speaker 2: So some of the key concepts here, dynamic documents is obviously a spreadsheet is a dynamic document, but the idea here is taking text, plain text, which is incredibly universal. Everybody’s phone has some kind of plain text notes app just kind of built in by default, but then you can use gradual enhancement to add some computation and make it something dynamic while keeping that same basic medium of just simple text you can manipulate. That you also talk a little bit of the essay about personal software, which I think is precisely this concept you’re just describing here, which is rather than my run tracker being an app that I download from the app store and I’m more or less just have to use it as intended by the developers, that I can use the computational medium to build a quote unquote application that just suits my needs, is truly personal. 00:13:05 - Speaker 1: Yeah, personal software is, well, first of all, I think it’s getting more mainstream in the sense that if you look at a lot of people’s notion, usage, and all the other insert, you know, personal knowledge management tool here where people are sort of aggregating all of this stuff in their life into a personal OS and I don’t know where the appetite comes from. I don’t know if it’s tied to increased computer literacy, at least some form of computer literacy, or it’s people have been burned by their favorite app changing either by adding too many features or just being deprecated, but there seems to be a lot of energy around it and so one of the things that is surprisingly Or rather, something that you wouldn’t think about right away is when you start building these apps from scratch from a note, you never really notice that you’re actually making a big complicated thing. You’re just starting out with some text and at some point you start adorning that text with some functionality and you just keep going and going and going, and at some point you wake up and you’re like, wait, this is actually quite complicated logic. Am I a programmer? And for us, that sort of was quite important, right, like embracing this notion of personal software that is truly yours, not from some team somewhere in Silicon Valley or wherever else deciding what’s best for you. And I think Jeffrey, you gave this analogy early on to like imagine our homes were Just furnished completely by other people, and all the objects in there just are sort of almost immutable, like we would not have that, and we do with software, and so I think nudging at that is super interesting. 00:14:53 - Speaker 3: This is one of my favorite ways to Open up my own mind to how weird software is, is to use analogies to other parts of the world, you know, I think we sort of have gotten so familiar with these metaphors of how software is organized. Like, in some sense, in this potluck work, what we’re doing is arguing against the idea of applications, right? Which is a really weird argument to make to a typical computer user, you know, it’s fish and water, like, what do you mean? I love apps. Apps are how we do things on computers, but It doesn’t have to be that way. I mean, Alan Kay, who’s responsible for a lot of the metaphors we use in personal computing, has, I think, said that apps were like the biggest mistake that was made in software ever, or something like that. You know, another analogy to bring it back to the food thing, I think, is restaurant versus home cooking. And the reason I like that analogy is that I think it gets that, I’m not trying to argue that we should ban restaurants. I love going to restaurants. It’s more like, if you imagine a world where All you can eat is restaurant food every day for every meal, and you think about what kind of society that would be, it starts to feel a little weird, right? When you go to a restaurant, you are putting a lot of trust in someone else to give you a good experience. You’re accepting kind of a restriction in choice, whether that’s like a full on oakcase, you know, meal, or even, you know, picking from a menu with 10 items is very different from going to the grocery store, right? But also, you’re acknowledging maybe that chef can do things I can’t, and maybe I’m tired today and don’t want to cook, whatever the reason may be, it’s nice. But it’s also a certain kind of limited experience, I think. And when I look at home cooking, I see a totally different set of trade-offs and values almost, where I’m not trying to become a professional, I’m not trying to make the best thing, I’m just trying to make something nice for myself that I like, and, you know, for my family, whatever. It’s a very different scale and and feeling, and I think that’s sort of the right way to think about, you know. There are always going to be tons of professionals making software, and I think that’s great. I love Apple products where someone in Cupertino has thought for a year about what the width of this button should be. I’m not against that, it’s just that I think there’s also this complementary role for a different way of thinking, especially in these more personal domains. And one last thing I’ll say about the home cooking analogy that I think is interesting is that it’s a very cultural thing. If you imagine a world where everyone always eats at restaurants and you tell someone, you know, why don’t you start cooking in your house? They might be like, well, I don’t know, that seems really hard, like, all these chefs have spent like years in school or whatever, and, you know, you can see the analogy here to, like, currently software is so professional and difficult, that it just seems unthinkable that everyone would be making this stuff themselves every day, but I think we can imagine a culture where that’s a little different, and, you know, try to promote that kind of Thinking and culture more generally, and I think that would be a good thing for software. 00:17:51 - Speaker 2: Yeah, I think the restaurant versus home cooking comparison is a great one, and also just reflects the fact that in the scheme of things, computing is just so new, and we don’t necessarily know how it fits into our lives and our society and how to relate to it, and we’ve ended up in this, you can think of it as a local minima or just a particular circumstance of time, which is that software is built by these professionals who are typically far away and building for many, many users. That’s not where we started with computing, and I certainly don’t think that’s where we’ll end up, but hence the reason to invest in research to take us in this direction. Now one thing I think your project touches on that’s an interest of mine, obviously I would lump this under end user programming, something we’re all interested in essentially bringing programmability of computers to a wider audience, not necessarily in a professional app building context, but just in the sense of embracing the dynamic medium. But I feel one of the big unsolved problems of end user programming is really just getting it into a context where people can use it. There’s many, many really amazing research projects and prototypes and etc. where if you go into there, I don’t know what, here, launch this small talk browser and once you’re within that world, everything is malleable and composable and you have total power, but it’s not connected to anything you do in your life. And one thing I like about how your team went about this project is that You’re starting from text notes, which are on your phone. Now, it’s sort of an unanswered question is how exactly this computational medium gets into the notes app or whatever, that maybe it’s not a part that’s figured out, but very hypothetically, going from, I’ve got this text file or a series of text notes, and I wanna layer this dynamic medium on top of it, feels like a lot less of a jump than many of the other kind of programming accessibility research that I’ve seen. 00:19:47 - Speaker 1: Especially cause if you actually look, for example, Apple Notes, right, it already has hints of these data detectors. If you type a phone number and I don’t know, a few other dozen types of content, it automatically finds them for you and underlines them, and then you can, you know, tap and initiate a call and potluck just takes that notion to an extreme by saying, well, first of all, I can write my own detectors cause I don’t just want to find. A phone number I might want to find the quantity of a recipe and then it also just doesn’t limit you just to the oh I can tap and initiate a preprogrammed action. I can do something else with it, a calculation, fetch some different data and so on, but it’s a very gradual enrichment of the original note and it’s also already somewhat at home on iOS. I don’t know, Jeffrey, if you want to talk a little bit about the data detectors and the origin. 00:20:47 - Speaker 3: Yeah, totally. One of the more interesting kind of related work references that we found while we were thinking about this stuff was, what I think is the original paper describing the seed that has become these, you know, phone number recognition and stuff in modern Mac OS and iOS. But there was a research team at Apple in the late 90s, which included Bonnie Nardi, who’s sort of well known in the end user programming space. And it’s really interesting seeing the original rationale they had for how they got to this idea of data detectors. Their starting point was thinking about, OK, how can computers help us do stuff and be intelligent helpers, and they Sort of draw this distinction between two styles of how the computer can help you. One is the computer just does stuff for you, or like, you know, you sort of vaguely say what you want and it doesn’t, sort of more of an assistant metaphor, you can imagine, you might not even know it’s doing stuff, it’s just behind the scenes. And I think this sort of corresponds to some of the modern ways that people think about, oh yeah, AI will just do it for you type of thinking. But they realized that actually, both at the time that was totally infeasible. Computers weren’t good enough, weren’t smart enough to actually pull that off in a satisfactory way. And they also realized maybe it’s not quite what we want, and they went down another path, which is, let’s just have the computer find stuff for us that we care about, like, dig around in all the things on my desktop and find useful information, and then let me decide what to do with it. And You know, as Max was saying, I think their view of what you can do with the information was relatively like straightforward. You just right click on a phone number and you hit call this number, simple interactions like that. But still, this idea that the user was in control of what to do with the information. And so, I think that’s a really nice kind of design goal for these sorts of systems is carefully balancing what are the parts that we want to be automated versus where the moments that we want to be in control, you know. 00:22:49 - Speaker 2: And data detectors is the term from, I think that paper in the potluck essay, you call it extensible searches, is this a rebrand to be a little more familiar to current audiences, or do you see that as actually, it’s because it goes beyond these more automated kind of default types, like a phone number and address? 00:23:10 - Speaker 1: With a lot of the stuff, it’s very serendipitous about how it happens during a project, and we initially didn’t even start out with potluck having these continuously running searches. It was much more of a manual process. In fact, I think to this day, if you look at the code, it’s still like cold highlighters because we started out with this notion of, well, you have a note and then the sections that you care about, you’ll just highlight and you have different colors for highlighters to start imbuing those highlights with computation. And someone on the project at some point sort of said, oh, well, why don’t we just run a search against it? And at the time, I think we didn’t even call it search, it was just a pattern. But if you think about how mere mortals would maybe think about this as well, I have like a Google doc open. How do I target a specific word in the Google Doc? Well I hit command F and I try and find it, right? And so that’s where this notion of search comes from, which is sort of the Most maybe human way of thinking about these detectors. 00:24:11 - Speaker 3: Another small thing I’ll add is that one of the really cool parts of the original data detector’s vision that we share, but it’s kind of been lost in the modern Mac OS version, is this extensible part of extensible searches is also really important, the idea that you can define your own. You know, in potluck, this means that you can decide that these are the types of ingredients that I want to find in my document, and nothing else. I control the dictionary of what I consider foods, or I control the list of workouts. So if I write, you know, squat, my note will recognize that that is a kind of workout that I do, but all of it’s sort of very tailored to your life. And the original data detectors paper had this too. They had this idea of, for example, you would teach the system, here are all the names of the conference rooms in my office. So whenever I write the name of a conference room anywhere in my OS, the computer will just know that that’s what that means. And of course that doesn’t apply to every Mac OS user, it’s more of a personal data detector that’s tailored to exactly my context. 00:25:08 - Speaker 2: Maybe like adding a word to the dictionary so that it doesn’t show up as a spelling error because it’s some nickname for something in my life that wouldn’t make sense to add to a global dictionary. 00:25:20 - Speaker 3: Yeah, exactly. 00:25:22 - Speaker 1: It’s funny to think about how frequently we have data detectors in the software that we use, right? Like on GitHub, if you want to reference an issue, you do pound 247, and that’s a data detector, famously like Twitter hashtags and at mentions were all not built into the software. They were just ways in which people invented small little microsyntaxes very fluidly. And there is no primitive in the operating system that is not super far down to actually do something fun with those, right? And so by making it super easy right in the context of the note to write a new data detector and super easy, we can get into that a little bit later, is obviously a spectrum. Ours still involves way too much knowledge of programming to be super easy. But the power of inventing those small microsyntaxes is super addictive. Like you just start coming up with small things that only you are familiar with, kind of like in a notebook, you would have some sort of notation, and it’s just flabbergasting to me that operating systems haven’t embraced that at a more sort of a cross app boundary level, right? Like, I think to this day there is a class in Some SDK from Apple NS data detectors where I believe developers of apps can write data detectors for you, but you as a user have no influence over them, which is fine, like I guess some developer could build an app that lets you write your own, but partially what gets left behind there is that the same data detector should run across many applications. If I have that, you mentioned a meeting room. If I have a meeting room name, then you should highlight it in iMessage in mail app in notes and my 23 other apps that I’ve just downloaded from the App Store, and that’s sort of lacking. If you read the paper, I highly recommend it. I’m a huge fan of BonnRD. It’s very sad that we don’t have that in our computers today. 00:27:24 - Speaker 3: And I think this brings it back to what Adam was talking about earlier around integrating with the rest of your tools, right? Sometimes. I think a really important point to make about this research project that we’ve made is that currently, just to be able to move freely, we’ve built this thing as it looks like an app. You open this thing called Potluck, it is, you know, a web app, there’s a text box and you can do all these fancy things with the text, but the final form of this that we envision being good is not a separate app, it’s deeply integrated with all your other tools. You could imagine any app that has text, you should be able to pull this panel of searches over and just start pointing it at any text in your system. And we actually built a little bit of that into our prototype where we do some things where we actually interopt with.txt files on your file system. So you have a little bit of being able to open these text files in the text editor of your choice, work with them, and then when you look at them back in potluck, you see the interaction appear on top, but I think that one of the interesting open questions that we haven’t quite figured out yet is, how does it really work for this to be embedded at more of an OS platform level? Like, where do these search things live? How do you share them with other people? How do you share them across apps? It’s just sort of an interesting design challenge to think about there. 00:28:43 - Speaker 2: I feel like there is a commonality across many research projects that I was involved in and I can switch in maybe in general in the research world, which is if you could do it just in an app, you would try that, but the whole thing that makes a research is really this is something that should probably be operating system level or just cuts across. This tech stacks or the tools you use or the devices you use in a way that isn’t really well supported by the current ways that things are divvied up or the way that we kind of compartmentalize the various elements of our computers and hence the only way to try them and see if they are plausible or good ideas in. or how they feel to use is to do them in this research context where you kind of have to hand wave and say, well, imagine this was built in your text editor or cut across all your apps or you know was there in the browser or you have a good way to share these things. Would we want that? Would we like it? Would that help us? And that doesn’t get you all the way to what it would look like in the real world, but it certainly is a fair sight further than just sketching it out on a whiteboard. 00:29:49 - Speaker 3: The first one is figuring out what we want, prototyping the experience with enough fidelity that we actually have some idea of what platform primitives we would like to have available. And then the second part, which I think is at least as hard, is how would you actually enact that kind of change in the world. If the thing you’re doing is not trying to add another app to the app store, but totally change the structure of the app store, and all the economic incentives and the technical interfaces between things, that’s a very different shape of challenge, and so, yeah, it’s a lot. 00:30:24 - Speaker 2: Now obviously I’ll link the essay in the show notes, and there’s also a live web demo that’s pretty workable, I think, or at least in my experiments with it got pretty far, which is saying a lot for a research prototype, which tend to be, you know, focusing on the learning rather than the polished product. So I’ll link both of those in the show notes and people should certainly check them out. I’d be curious to hear briefly. On the findings and what you learned from building this and trying to use it in practice. Was there anything that stands out as surprising or unexpected? 00:30:58 - Speaker 1: I think there was this distinct moment in time where the prototype was actually good enough, that inventing your own syntax for something was very trivial. You could just say something like find every line that starts with plant emoji, and then suddenly do something with it. And I still remember it having the feeling of why doesn’t all software work this way. And so to me it wasn’t super obvious that personal microsyntaxes should be a thing, and the idea that the same way you can scribble personalized notations into a paper notebook, that we could bring that into software. If you make it easy, right? If you don’t make someone go into some settings screen that’s 4 pages deep to say I’m going to change how this works, right, like usual programming, but just ad hoc, you’re like, oh, I’m just gonna start these next lines with, and, you know, famously look at markdown, like, I’m gonna start the list with asterisks. Well, I can just invent that. That to me was actually a very surprising finding is the ease of creation of a syntax and then the utility. 00:32:07 - Speaker 3: I think for me, one of the surprising things was just how nice it is to work in text. This might be sort of a bit of my programmer brain, you know, speaking, but I’m not typically one of these, you know, everything I do is in plain text kind of people, but I found that We’re so used to editing text. We have really strong muscle memory around, for example, things like, I can select some text, cut it and paste it somewhere else, or I can even paste it into another app, or I can undo, and I understand how Undo is gonna work. And all these little affordances are really mature in the systems we use, and they’re mature in our heads. They’re really strong conventions, and I think One thing we found is that when you build software on top of that really solid foundation that we all have, a lot of things just sort of fall out of that. So, for example, when all of the state of your application and all of its UI live in a text file, you can just snip parts, move them around. If you undo your app has undo for free because it’s state is stored in the text. You get all these things out of that. And I think there’s some lesson there it feels about, I guess it’s about using the same well developed tool for many different things. I’ve used the analogy before of, it’s like a chef’s knife, where it’s like, good at all these different things and someone put a lot of effort into making it really good and versatile. It feels like there’s something similar there going on with text, and It’s not a new insight. I think there’s lots of people out there who do Emacs or there’s all kinds of to do list apps, or, you know, budgeting apps based around text files. I think that’s a thing that some people have been experimenting with for decades, but it was surprising to us just how far you can push that into so many different domains. Of course, you can’t do everything with text. There’s lots of apps that would be ridiculous to even try making them potluck, you know, YouTube is not the target, but I think that’s fine, you know, there’s some Kernel of personal use cases that fits really well with this medium, I think. 00:34:05 - Speaker 1: Yeah, plain text, or just maybe text in general, is a surprisingly good layout engine in the sense that if you want to make personal software very frequently you’re gonna have to go and come up with your own layout. Oh, I’d rather actually have these things at the top and not at the bottom of the screen. And I think maybe because as professional sort of software developers, maybe we go towards building a GUI with specialized inputs and forms and controls and all that stuff too soon because it’s just so much easier to explain to the computer what the user means if they use a specialized input tool like a button check box and so on. But if that weren’t the case, if it’s just easier for the computer to understand what you mean as you’re typing in your note. Then suddenly text input is the primary thing. And if you think about what we do on computers all day, including people who are not sort of in the industry, yes, Emacs and so on, great, but you spend most of your time writing texts to people, right? So if you can’t type on your device, then you can barely use it, which means most people who use devices spend a lot of type typing. And I think we should encourage software designers and developers to lean into text way more than we do, and like you even see that possibly in this resurgence of the command K command lines that every app now implements, right? Like command palettes, which are also just text-based entry. And so I think potluck maybe takes this to the extreme of saying, look, just write whatever you want, and then we’ll just teach the computer with you how to interpret what you wrote, and then you can do awesome things with it, and that’s kind of exciting to me. 00:35:47 - Speaker 3: In some ways, it’s like even one more step towards messy than spreadsheets. Someone at the lab was computing a spreadsheet, I think, to sum up how heavy things would be in like a backpack for a hike, and At some point they realized, oh, I should just do this in potluck, because even the effort to put it in a spreadsheet table was just felt like a little bit of ceremony, like, spreadsheets are sort of clunky to edit on your phone, for example, whereas text, it just kind of, it’s one dimensional, so it resizes onto your phone, you just type characters in, it’s very low ceremony, and so if you can get the interaction you want out of such a messy data substrate, in some ways I think it’s like a good go to before you start adding too much structure. 00:36:29 - Speaker 1: Yeah, there is this, I think we link to it in the essay as well, a paper, deferred formalism, which sort of encourages you to not get into structure really early on, right? and text is great, like I can just put the cursor in the middle of a line, hit return and now I have two lines. And if you think about some of the tools that are extremely popular, notion and so on, they always make that distinction of are you inputting pros and making a list, or do you want more structure to do some computation, which is, oh great, now you have to think like a DBA and the notion of being able to move between those two modes fluently, I think is really cool. And at the same time, if you can afford to push the formalism as far back into the process as possible, right? Like, hopefully without the app hopping, right, of like, oh, I started thinking in Muse, and suddenly I want some more structure. Therefore we have to go get out a spreadsheet and at some point you’re like 6 level deep writing a rails app with a SQL light database and you just don’t, you know, it’s it’s not the way to go. 00:37:34 - Speaker 2: And now when it comes to structure versus free form, I do think there’s a feedback loop when you talk about microformats where you kind of are inventing your own little structure as you go, just naturally, even like writing in a notebook can be something like this. Yeah, some of the trackers you mentioned there, one use case that came to mind for me was in the early days of parenthood, we basically had a log for things like feedings and sleeping and diaper. because it’s very useful, especially with handoff between caregivers to just at a glance, be able to look at this and see when was the last time they ate, when was the last time they slept, because that tells you a lot about trying to figure out whether they’re crying right now, what need they’re expressing when they’re crying right in this moment, as well as other maybe slightly longer term analysis in terms of like, OK, are we getting enough sleep each day, for example. But there does tend to be a feedback loop if you do add the rigor of the computer trying to parse it, even if I’ve written that search for myself, then that is going to enforce as a strong word for it, but encourage me to use a format that can be easily parsed and to be consistent with that because I make my job on the called the programmer side or the adding the dynamic aspect to it a little bit easier. Did you see something like that in your user testing? 00:38:55 - Speaker 3: Yeah, I think there’s a really interesting tension here where it’s exactly what you’re pointing out, where on the one hand, we don’t want it to feel like programming. So in textual programming, especially for beginners, you’re typing in characters, and there’s a very, very strict set of rules defining what’s valid and invalid, right? And if it’s valid, you get nice syntax highlighting and everything, it’s great, and if you have one comma missing, everything falls apart, and so we I thought that it was really important that you don’t start feeling that way in your text notes. It should generally have the sense that you can just type the way you normally would. But of course, on the other hand, we still need to figure out what you meant. And so you need patterns that are accommodating enough to let you write, but also rich enough to figure out what you meant and extract the meaning. I do think one thing we realized is that there’s a big difference between applying patterns later on to some text that’s already sitting there, versus having them being applied live as you type. Because in potluck, as you type, for example, if I type 5 minutes into a note, by default, potluck has this time recognizer built in, which will search for all the durations you add to a note. And when I type 5 minutes, this underline just appears and clicks into place, and I sort of get this live feedback that I’ve typed a duration that the system has understood. And we just found that that felt really good. It feels good to have the system give you that signal that it recognized what you did. And obviously, if you were expecting it to recognize something and it didn’t, then you realize that because of the lack of feedback. And so, what we found in our experience using this thing was that if you have the searches running as you’re inputting the data, it does have this natural nudging force of making you aware of the structure a little bit and maybe being a little more mindful of where you put. New lines or things like that, but again, shouldn’t be too rigid ideally. 00:40:45 - Speaker 1: Adam, you do bring up an interesting point. I think partially why notion is so popular and such a great tool is that it does invoke a little bit like this collector mindset of I’m just going to collect, you know, whatever you’re into and make a nice table so that I can actually reason about it as a collection instead of individual items, right? And like I always joke that sort of computers are really, really good at doing stupid math and for loops. And maybe one way of thinking about this is if you look at the user interface for potluck, on the left hand side you have sort of this messy, I’m just going to type stuff out, and as you write searches that match against the document, it populates a table and that table can have arbitrary metadata, right? So I can add a new column and say actually for this timer, I’m going to add a different property and The idea of having both, both this sort of reasoning about things in collections, large, you know, all ingredients or whatever, and the idea that I don’t have to do that from the beginning, or if I change my mind, it’s not such a big deal, is really appealing to me because I think we usually switch modes from reasoning about the individual thing to the collective thing and back and forth and back and forth and software today just makes you. Sort of jump through hoops if you’re switching between one or the other, and potluck tries to, as best as possible, sort of make that fluid. 00:42:12 - Speaker 2: One thing I wanted to ask about is, in the future work section, you talk about machine learning and language models, which is a pretty hot topic among certainly the tech world broadly and also in the tools for thought space. Since you are focused so much on text as well as detection, what role do you see that as having either now or in the future? 00:42:34 - Speaker 1: It’s really interesting timing because as we were writing the paper and like doing the research project, all these big language models and like stable diffusion and a bunch of other things sort of came out and became sort of accessible to like hackers, I would say. I mean they have been for a while. But at some point we were thinking about, well, we have these searches and the way we’ve implemented searches both sort of from a time perspective and maybe a little bit of a philosophical thing that we can get into, are all, I don’t know, like rejects, we have our own pattern language and so on, and you can if you want to write rejects. It’s obviously not super approachable to mere mortals. So how wouldn’t it be cool if I could just have a note and say, find me all things that are quantities of food. And then GPT 3 goes off and comes back and says, here are the ones that we found. And I think it is so obvious that the data detectors will get so much better the better machine learning gets, right? And you can kind of get a glimpse of that future in the photos app on, I forget the current photos app on on iOS, where if you take a picture of a recipe index card and it says 24 g of sugar. It’ll actually, you can tap and hold and it’ll do a unit conversion for you. Now, it won’t let you do anything else because somebody decided for you what you should do with those 24 g. That’s the part where we would hope some other, like some maybe some more extensibility, but that’s just machine learning, finding the 24 g for you and you don’t have to do it, right? And so I think it seems somewhat obvious to us that all the detectors that are currently patterns will just become much more human friendly ways to describe patterns. 00:44:16 - Speaker 3: I will add one interesting tension that we were thinking about a bit. We didn’t end up implementing AI based stuff in the project since we didn’t have time to get into it, but we thought about, you know, do you want the AI to find the stuff for you, or do you want the AI to essentially write a reject for you? And those actually end up being pretty different things because predictability and speed actually end up mattering a lot. When I’m typing, I wanna be able to learn. You know, if I type this string, is the computer always gonna see that as a food or not? And if you have machine learning in the loop for actually doing the detection, It’s probably pretty hard to get guarantees around, oh, you know, it depends on where it is in the sentence, or how the model’s feeling that day, whereas if you have a more deterministic pattern, that gives you something that you could learn as a human, like how it works, and sort of learn to wield predictably, but there is a tough tension there because the predictable thing probably is gonna miss a bunch of cases that the ML could have found. So, I think there’s an interesting design challenge there and how do you Get a system that does both of those things well. 00:45:22 - Speaker 2: And maybe an example of that from kind of an earlier phase of technology is autocorrect, which on one hand was this huge enabler to be able to type full sentences on a phone. On the other hand, is the source of huge running jokes, you know, it’s basically the butt of jokes, which is like autocorrect, does hilarious things all the time, people are used to that, it’s part of modern life in a way that, oh, I pressed the wrong key on my keyboard. I guess that happens sometimes, but it’s so infrequent for someone who’s a reasonably competent typist, that it’s just not a point of discussion, and, you know, it’s one thing to use autocorrect to bang out a quick text message to someone, but if you’re a book author and you can sit down and write your book, Autocorcrack is not the right solution for you. You’re gonna become a touch typist with a precise keyboard, maybe you get a mechanical keyboard with big chunky keys, because, yeah, you want precision from your tool and you’re willing to invest in that. 00:46:18 - Speaker 1: Yeah, I think it may have been Paul Shan on the team that came up with the funny analogy of, we were arguing about AI cause I think sort of just what role should it play in potluck and so on, and One of the things he referred to current AI models to is like, look, this is like the toddler stage, and if you go and say, hey, go toddler, find me the ingredients on this table, you’re probably not going to just blindly take them and then cook a meal. But at the same time, if you can send off 10,000 toddlers to try and find the ingredients on the table, and then you check their work, seems pretty reasonable, right? And so I think that the idea of having the ML try and suggest something to you. But then you check the work, commit that and say this is the correct thing that you found, then it’s a totally reasonable approach, right? Like, I think GitHub co-pilot does this for programming, like you’re not writing a method call that at run time. Goes to GPT 3 and says please sort this list. It gives you the text to autocomplete that then you commit and run. I say this as now there are examples where GPT 3 calls itself to do stuff, which is both super exciting, but at the same time, you probably wouldn’t want that to be part of your stack all the time cause you can’t rely on, you know, the model upstream changing and suddenly saying that the car is an ingredient and yeah, but I think that tension. is good. I think we haven’t really figured out what the user interfaces for AI and for that interaction looks like, right? Like right now, all these interfaces are just slot machines. Like stable diffusion is just, it’s addictive because it’s a slot machine. You type in a prompt, you have to wait 30 seconds and then you get the variable reward of nice picture or not nice picture. But for a tool, I think you would want something a much more fluid and fast, right? You can’t wait for 30 seconds and you probably also want something much more predictable. I think it’s a future research project waiting to happen to say, in an environment like potluck, what role does AI play and how would you go about designing that? 00:48:23 - Speaker 2: Well, it’s all super fascinating stuff. I highly recommend reading the essay, trying the project, but now I want to switch gears a little bit and ask you both about the process. What does it look like to, I guess, come up with research to work on in the first place and certainly within the can switch container, recruit the team and run the project and how long does it last and who’s on it. And I’m especially interested to get both of your takes cause Jeffrey, you’ve done a bunch of Ink & Switch projects at this point, as well as been in the research world for a while, and Max, this was sort of your first exposure. You’re very accomplished in the commercial world, but this was your first exposure to both the research world and I and Switch. So, yeah, give me the rundown. What does the inside of this box look like? 00:49:08 - Speaker 3: Yeah, totally. I guess I can speak to how the project originated as the person who kind of started bringing things together here. So I can Switch typically these days runs projects that are You know, around 10 to 12 weeks, which is pretty short from a research perspective, and what we try to do is bring together some small team of people for an intense period of time there and just really focus, you know, ideally everyone’s full time and just intensively work on some aspect of a bigger problem. And so, before that, there’s this phase that we call pre-infusion, which I think Peter talked about when he was on Metamuse, where there has to be some prep work to figure out, you know, who do we need on this project, what’s the question we’re asking. In this case, we knew we wanted to do something related to the themes of malleable software, you know, this personal tool stuff, but we spent a while kind of searching for, I think it’s important to have kind of a nucleation point of some kind, something you can latch on to as a place to start, especially, I’m a fan of having some concrete examples or use cases in the mix at that stage, because what I found is that if you start with your prompt being like, how can we reinvent the way people do work or something, it’s easy to get lost in the woods, basically, whereas if you can at least focus on one thing to start and then branch out from there, it makes it easier. And so, I think Peter, the lab director and I were having a conversation, and we’re both big fans of cooking, and so we just started talking about, you know, isn’t it kind of weird that recipe apps are simultaneously so popular and yet seem to do so little and have all these frustrating restrictions, and so we thought it’d be fun to run a project where the original prompt was kind of, could you make a recipe app yourself, and, you know, go from there. And a lot of the ideas that ended up emerging in pot, like, we didn’t really Set out specifically to answer that, you know, specific question, it just kind of more emerged from the original prompt. So that’s kind of on the idea side, and then on the people side, you know, I am a big fan of small teams where everyone can kind of do everything a little bit, generalists, especially in this case. I think one of the tough things about this kind of work is that there’s a lot of context you have to build up, and so I felt that it was important to get a team together that had at least been thinking about these general kinds of problems before. You know, if you bring a typical engineer onto a project and say, let’s get rid of apps, you know, that’s sort of a strange place to start, right? And so, anyway, that led to, obviously Max, as sort of a design focused person, and then Two other people, Paul Shen and Paul Sonnetta, who are both, you know, more engineering focused, but, you know, all four of us had previously thought about these themes, and so it was really fun to get this group together and kind of jam on, you know, each having a different perspective on what it means to make personal tools, but kind of find a way to blend them in a way that made sense. So, that’s kind of the general overview, I guess. 00:52:12 - Speaker 1: I think you had a comment early on when we were doing intros, because most people we hadn’t worked together yet, and I think you made the comment of, oh, it’s well, if any of the people on the team really wanted to, they could just make the whole thing themselves. And I would have actually loved to see a parallel universe where we all separately would have tried to make a malleable recipe app, cause I’m sure it would have been very, very different than what we ended up coming up with. But this idea that you don’t have to spend any time explaining basics and can just go into building right away is really important when you only have 10 weeks or so. And I mean, I loved working on this team, maybe my favorite team working experience I’ve ever had. 00:53:00 - Speaker 2: Wow. Now, how did you perceive Max, this kind of research angle where the end goal is not to ship something to end users, yeah, you want something usable, and even there’s a demo on the web, you can go try, but the goal here is not to build a product and iterate on that and bring it to market. How did that change the experience of building something for you? 00:53:22 - Speaker 1: It was both very refreshing and at times frustrating, so it was a little bit of a palette cleanser. Most of the time when I’m looking at, you know, building software, it’s like, OK, when do you get to product market fit and what’s the economic viability? How many users, how are you going to make money, whatever, right? And this is not the case with research projects. There, I think the goals are much more, can you find a novel take that maybe explicitly wouldn’t work. In the app store right away, because, well, either the tech’s not there yet, or you need to commit access to Mac OS and iOS to actually fix this thing, or Linux or whatever. And so I didn’t really have any notion of what it was gonna be like. The only thing I knew is that all the Ink & Switch essays are badass, and surely something about the way these projects are run contributes to it. And I think it’s that weird tension between both, well, we’re gonna think big and do something that might not be viable right away, and at the same time we’re gonna ground it in that use case of, in this case, Jeffrey’s idea of a, well, let’s just make a recipe app. That’s our use case. How would you make that malleable instead of much more generic and, you know, inventing something that maybe no one will ever want to use. 00:54:47 - Speaker 3: Another part of the research first product thing that I find important is the end goal of this project is kind of idea transmission, like, we succeed if we change the way people think. And so, the way you explain the thing and frame it ends up being super important, which I guess that’s also true of marketing a product or whatever, but I think it’s just When that’s the main artifact that you’re going for at the end, it puts a lot of pressure on that angle of things. So, one process that I think we all agreed was really helpful is typically on lab projects, every 2 weeks, there’s a demo day, basically where you just demo what you’ve been working on to other people in the lab, and I think it’s really important to take those opportunities to sort of practice the story and try to explain what the heck are we doing, what problem are we thinking about, what’s our prototype right now. And just rehearse that every 2 weeks. And if you can’t convince other people at the lab that this thing makes sense or is good, you’re never gonna succeed at convincing anyone else, right? This is like the most high context, sympathetic audience you could find. And we did have a couple demos where people were like, what are you doing? This doesn’t really make sense, we don’t get it. And that was really, really helpful for kind of refining both the way we explain what we’re doing, but also, you know, obviously the work itself and sort of guiding the direction of it. And I think that’s an interesting process question is like, what cadence do you work on? In some ways, 2 week cycles may seem pretty fast. A lot of researchers work on much slower sort of base cadences, but I find that I really like having an intense kind of pretty fast rhythm when you’re in this execution, or kind of intense momentum mode, and then Once you’ve finished this 12 week period, you can spend some time to like, walk around and think about what you’ve done, and think about what you wanna do next, and, you know, have a sort of on-off approach. 00:56:44 - Speaker 1: That tension or the 10 weeks, Jeffrey and I have definitely had some conversations about, is that too short? Is it too long for a research project and sort of, I think my view initially was. It’s like, 0, 10 weeks is too short to do any meaningful research, and I think that’s still true, except that you shouldn’t consider those 10 to 12 weeks as the entire research. It’s a season in an 11 season lost sort of show, right? And there’s this thread across all I can switch projects and Potluck will infuse other projects going forward, and I think if you bring that mindset, then suddenly the 10 weeks are really great because it’s this forcing function of just not wasting 2 years trying to see if there’s a there there. You have 10 weeks, go ship something, publish it, and have it torn to pieces because it’s not good enough, right? And if you’re not embarrassed, you’re shipping too late. I am definitely embarrassed by some of the UI and the UX and the Maybe complexity that exists and it’s not a product, but the idea that it kickstars, you know, a couple of other seasons of development, I think is a good framing, and in that case, the 10 weeks, the intensity, daily stand ups. I was only on it halftime, everybody else, which I do not recommend, everybody else was on it sort of full time, and the intensity is truly what leads to this pressure cooker environment of like building something that’s both good enough that you want to play with it. But not a thing that is ready for any kind of adoption by people outside of the lab environment. 00:58:24 - Speaker 2: I’m curious about the transition from that, yeah, 10 to 12 week more intense building phase to, OK, now let’s take what we’ve learned and turn that into a written artifact or it could be sometimes a talk, but in this case it was an essay. I guess some of the question is, is all the team involved with the essay or just the writing? How do you know when you actually have something good to write about? You’ve learned something useful, which maybe could happen halfway through that 10 or 12 weeks, or maybe you get to the end and actually don’t feel like you have a lot to say. How does that whole transition work? 00:59:00 - Speaker 3: I love the writing phase because it’s where you get to figure out what you’ve done, and I think it’s really funny. This is such a cliche, but like, you start writing and it’s like, wait, what do I want to say? And it can get really confusing, and I think in some sense, even once you’ve done all the work, you haven’t actually done the work yet of figuring out what you’ve learned from it. And so, on this project, what we did is we tried as we were going to Prototype the paper, kind of. We, you know, recorded little talks explaining the project or like, wrote notes of, like, here’s how I would explain it today. But even then, when we got to, you know, the end of this intense period, there was still a lot of mess to work through, and we’ve all been involved in co-writing the piece, and I think that’s sort of important to the extent that, again, the real value that this thing is trying to provide to the world is like, here is what we learned, and the writing process is where that gets clarified, you know. 00:59:53 - Speaker 2: Do you find you wanna go back and make changes to the software as a result of things you’re writing, or especially screenshots or videos you’re including? 01:00:02 - Speaker 1: Yeah, when I read the essay now, I’m like, OK, obviously an exaggeration, but this is all wrong. We have to start again. This is how we would design it, and it’s really not that it’s all wrong. It’s just that you want to do so much more to

Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: Everyone gets into a room, you have a brainstorm and out comes the ideas. The reality is so much messier. You have individual to group back again, you’re bouncing around among individuals, you’re bouncing around among different levels of fidelity. The ideas get mutated, even corrupted, if they get passed from person to person. Almost like this pulsating network, right? With all kinds of weird patterns happening is what’s really needed to produce good ideas. So the substrate, the tool needs to embrace that. 00:00:32 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for deep work on iPad and Mac, but this podcast isn’t about Muse the product, it’s about the small team and the big ideas behind it. I’m Adam Wiggins here with Mark McGrenigan. Hey, Adam. And Mark, I’m excited to say that we’ve given a name to the next major release of Muse. We’re calling it Muse for Teens, and we’ve got the Alpha program underway right now. 00:00:58 - Speaker 1: Yeah, we’ve had this phase penciled into the master plan for years, and it’s great to see us finally bringing it to fruition. 00:01:05 - Speaker 2: Exactly, yeah, it really is a whole other dimension. I think it’s true of most tools, you know, whether it’s a video editor or a word processor or whatever else that you add some kind of multiplayer collaboration or sharing capability, and it really is a whole new dimension to the tool, but I think that’s doubly so for Muse, which is an ideation space. So, you know, when I’m gonna start a new project, for example, the first thing I’m gonna do is make a board to sit down and essentially get my thoughts together on it. And so here, doing that with a team, when that team is starting a project, well, we’re finding it to be very powerful indeed and sort of almost a multiplier effect on the value of the rest of the product. So it’s a lot of fun. We got a little demo video online, I’ll link that in the show notes, and yeah, we have a couple dozen teams in the Alpha program here, really giving the local first sync and sort of the capabilities, the product of solid pummeling here, or we hope it can. Stand up to everyone’s needs, as well as we continue to just discover what are the most interesting things to add in the collaborative setting. You know, we start with the obvious stuff like comments, for example, but I think there’s a lot of non-obvious stuff that we’ll get to pretty quickly, so. Very exciting stuff and of course I’ll put all the necessary links for that in the show notes, but I thought it would be a great chance to talk about something we’ve mentioned in passing in a number of episodes, which is remote work. So that’s our topic for today and of course the muse team is all remote and part of the reason it’s so salient, I think, is the muse for teams. product as it’s shaping up for us in our internal use, but also with our customers in this alpha here is really seeing the role it can play for especially for remote first team. So there’s a lot of interplay between how we personally think about remote work, I think, and where we’re going to go with the product. 00:02:48 - Speaker 1: Yeah, and it’s also a very ripe time in the industry with a lot of companies exploring this way of working, basically whether they wanted to or not, because of the pandemic. And you saw a bit of a phase shift over the past few years towards this approach. It’s also notable that you and I have a lot of personal experience with many pieces of the spectrum. We’ve kind of gone, I think, through almost the whole range. And so I’m sure we have a lot of personal things to say about it as well. 00:03:14 - Speaker 2: You know, the timing topic is a funny 11 thing that occurred to me, or if I was a listener of this podcast and I saw it pop up in my feed, I would think, hm, remote work, wasn’t that a hot topic circa 2016? You know, I seem to remember a lot of blog posts and especially medium posts when that was the hot thing. actually right around the same time that I shifted to remote work, which was we started in Switch in 2015, we started that as an all remote research lab, always figured, well, you know, this will work to get started, but once we scale up, you know, we’ll need to get serious or whatever and get an office, and that never happened and I think the remote nature actually unlocked new possibilities for how we could do these research projects and the kinds of people we could bring in. And it turned out to be, in addition to just having these benefits of letting us focus on the business rather than, I don’t know, office leases also seemed to have these other benefits as well. But at least I remember in that time, the 2015, 2016 window, most of the posts were really from the perspective of individual contributors who were basically saying, hey, I want to reclaim my commuting time, or I want to be able to be home for my kids' bedtime, or I want to eat healthy, you know, listing out the benefits to an individual contributor. And I think the timing there was probably also not a coincidence that that was probably around the time this kind of first generation stack of tools, that’s Slack, Zoom. Google Docs, Figma, and obviously those are all slightly different age pieces of software, but I feel like there was a critical mass if you could put together some subset of those and get a pretty good working collaboration, not certainly at the same level of bandwidth as working in an office, but maybe you kind of crossed a threshold where the benefits started to exceed the cost or where it was even possible, maybe was one way to put it. 00:05:00 - Speaker 1: Yeah, at least for the vanguard of individuals and companies. I think it is true that called around 2016, there was a lot of discussion about it, but let’s say it’s probably from a pretty vocal minority, which I don’t mean in any negative way, but if you look at the bulk of economic production in the software industry, it was done by on location firms, and in the past few years, that has turned over in a big way. So you get a whole new swath of data to talk to. 00:05:26 - Speaker 2: Indeed, yeah, well, I guess it was 2020 that it suddenly seemed that every single person I knew became aware of what Zoom was, and of course we’d been using that piece of software along with many others for some time and had developed habits and techniques. Uh, about social mores and just ways to use them effectively and so the whole world was kind of getting a crash course on that and accelerating the adoption of these tools, and you could argue that there was maybe even an almost an over exuberance, and I don’t exuberance is the right term. I guess it’s just like we were forced into, the whole world was forced into this or as much of the world. feasible to do, which is basically most knowledge workers as well as schools, and that in turn probably caused a lot of Silicon Valley folks and investors and so forth to think, OK, this is a huge market and indeed if you looked at the stock price of Zoom at one point, I mean it was pretty wild in the middle of the pandemic somewhere, its peak, I think I saw some stat that it was something like the Market cap of Zoom was larger than all of the airlines combined in that moment, all the US airlines combined in that moment, and of course their stock was massively down, and you look at many of these companies that did well, e-commerce and so forth in the pandemic, and if you look at the 5 year graph of their stock, they had this huge boom over the pandemic time and essentially they returned a little bit more to earth since then. And so I think in some senses there was almost a boom and investment and new people working on Zoom alternatives and things like that and maybe in some ways here now 2022, 2023 we’re kind of going back to the office and maybe folks are like, OK, maybe that wasn’t as big of a boom as we thought, but I almost feel like this is looking at the hype cycle curve, you know, again, it’s weird to call the hype cycle because it was. necessity, but that peak that we had in the 2020, 2021 period was kind of like that peak in the hype cycle curve and where we are now is maybe a trough where it was overhyped or overdone or something, but actually now we have a lot of data like you said about like what the benefits are, what the downsides are, and we can feed that into how we develop practices and tools. 00:07:36 - Speaker 1: Yeah, and I think it’s a more healthy and honestly more interesting place now during the height of the pandemic, where, you know, you basically weren’t allowed to go outside, you really feel on top of the world if you’re a remote software provider, because people have no choice, right? Or if you’re Uber Eats or something, right, you’re just making money hand over fist cause people don’t have any other option. But now you have to confront the reality of success can’t just be, you can do it and you enjoy working from home in your pajamas or whatever. It has to be you successfully produce valuable software for your customers, and some people are gonna try to do that remotely, some people are gonna try to do that from the office, and your proposed mechanism has to be successful in delivering those goods. 00:08:13 - Speaker 2: Yes, well, we’ll get to see kind of how these companies perform in the market, the companies that choose to be co-located in the same place, invest in an office, get all the benefits that come with that high bandwidth, maybe more personal trust and human connections and things like that, but of course there’s a literal and logistical cost there. Maintaining offices and requiring people to be in the same physical place and so forth and so we can compare the teams that do that against the teams that don’t. And I hope there’s room for both possibilities in the world or maybe we’ll discover certain types of products or ventures, sort of demand, co-location and others it’s less important for. So yeah, the grand laboratory of the free market will give us a lot of information. Maybe we can start with the kind of personal motivations of let’s call them knowledge workers or creative workers. This would have been some of the contents of those medium post circuit 2016, and I think the lifestyle aspect, the flexibility, being able to control your workspace, reclaiming that commute time is obviously part of it. Are there others either for you personally or you’ve heard others discuss? 00:09:25 - Speaker 1: I think a big one is location flexibility, especially as the lifestyle quality in certain American cities was declining, and also some people just didn’t want to live in America, like, you know, you want to move to Germany, there would have been a time where You would have basically written yourself out of most of the software industry if you did that, but now you’re still very much in the game. So I do think location flexibilities, but some people wanted to move closer to their kids or to their parents, right? I think that’s a pretty big one because there was a time where there was only really a handful of cities that you had to be in if you wanted to be at the top tier of pure software firms, and that’s no longer the case, which is great. 00:10:04 - Speaker 2: Yeah, completely, and some of that is just preference. We talked about that in our cities episode in our personal decisions, my case to move to Berlin, yours to Seattle, and certainly many folks have chosen to leave a city altogether and live someplace more in nature. In many cases you do want the ability to live near family or I know the For example, we had Tyler from Cam Fund on our podcast and he talked about that he was in Mexico City because that’s where his wife needed to be for her career. And that’s great that you don’t have to necessarily have this conflict between two people who are pursuing careers if one of them is very flexible at their location. 00:10:42 - Speaker 1: Yeah, and you might put this in flexibility, but I think a big one is just control over your physical work environment, towards the end of the peak of the cycle in San Francisco, it was getting pretty wild with how tightly they were packing people in there, just couldn’t hear yourself think, right? At least I couldn’t. So people would go in with like, you know, earplugs plus noise canceling headphones to try getting your work done. Meanwhile, you’re combating all of the mechanical keyboards anyways. It’s just being able to go to an office that is soundproofed and you know cars driving by all over the place. It was a big win. 00:11:15 - Speaker 2: Yeah, control over your personal space, which includes, yeah, obviously things like desk or chair, noise levels, and honestly, some people like more, right? They got to go to a coffee shop where there’s some hustle and bustle for them to be able to think, whereas, yeah, I’m more of a quiet room kind of person. And then you’ve also got the element of your hardware. So there’s your desk set up, there’s your, again, the mechanical keyboard or not, there’s what kind of headphones do you have that sort of thing, and obviously companies Do potentially give you the option to make purchases, but I think this leads maybe a little bit to the maybe the responsibilities of being a remote worker, which is a lot more self-management. And so that’s something like, yeah, when it comes to hardware, certainly everyone on the Muse team, I don’t know exactly how other teams do it, but we basically say, OK, here’s your budget, basically make sure you have the right hardware to do this job, and sometimes that’s podcasting mics and sometimes it’s iPads and pencils, and sometimes it’s just a really fast computer, but it’s sort of really kind of more up to you and in that sense, you know, close to being a freelancer, you need that ability to make wise decisions about, OK, I’m gonna spend this money for equipment in order to, you know, maximize my productivity as well as my just comfort and enjoyment in the job. And then it’d be remiss if I didn’t mention an idea here that comes from Hilary Maloney, someone we collaborated with a little while back, who had this concept of a work ID list, and she actually discovered this in looking through our customer feedback and kind of some different surveys and things and trying to understand the kind of person that wants to use and purchase Muse, and I found this so interesting. I would not have in any way zoomed. In on this and thinking about our target customer, but she defined it as someone who is not doing the work just for the paycheck if that’s the right way to put it, but they’re driven to be in tech or a creative field of some kind because they feel they can find a lot of meaning there and they want to bring their strategic skills, their creativity, their intellect to the table to work on something they find intellectually interesting, challenging, meaningful. Obviously it’s a great privilege of being in a field where your skills are in demand to be able to kind of go higher up the Maslow’s hierarchy, I guess, in the work you’re doing, but it’s really true. We do have this option and one way you can choose to optimize your career is say, well, I’ve got a set of skills, whether it’s design or software engineering or product manager or whatever, and therefore I’m going to use that to maximize my compensation, which usually is probably going and getting a big comp package from a fang company. But another way to think about it, which of course is the decision I think you and I have made as well as everyone on the Muse team is actually we want a balance of things, we want to be compensated reasonably, but we also want the kind of work life. And meaningful mission in the company and you know, values in the company and frankly started part of that is the flexibility in our day to be able to spend our work time and our creative energy and the time and place of our choosing, if that makes sense, or at least something that finds a balance between the needs of the greater team and the company and what we would like to do personally in terms of how we work best. Another one of the items in her kind of breakdown of this work idealist persona was the concept of actively designing your day, and in particular designing it to maximize your focus work. That could be something like the deep work concept, you need a big block of time, you’re gonna mark that off in your calendar, you’re gonna aggressively defend it from meetings. But that also just connects to the workspace exactly as you said that you have a quiet space at home and you can, unlike in an office, you can turn off distractions by turning off your notifications and choosing to really focus on something and it’s a lot harder to do in an office. There’s some meeting happening, hey, there’s the all hands, hey, we’re going to lunch. And sometimes being connected to that is part of the value of being in an office. You have this ambient energy and this kind of natural background hubbub of activity that you can hook into. But then if you are someone that wants to design your day to be able to spend your precious work hours in the most productive way that you can, that gives you less agency on that front. 00:15:28 - Speaker 1: Yeah, so lots of potential benefits from the staff side. How about looking at it from the point of view of a company going remote? What are the benefits, challenges and considerations there? 00:15:39 - Speaker 2: The huge thing that I didn’t really realize going into what a big deal it would be, but is the ability to hire from the global talent pool. So when we started in Code Switch, and it was just a few of us, and we decided to work, you know, together remotely, and I was really thinking of it in that perspective of that as a person on the team, this is just useful for me and how I want to live my life at the moment. But once I was in the position of staffing up projects and looking for people, particularly in the very, very specific areas we were trying to hire for, I mean, I remember we were going to look for someone to work with on some CRDT projects circa 2016, and, you know, we made a list of everyone who had expertise with that in the world, and the list was like 10 people, right? And they were, of course, spread all over the world as you might expect. And so being able to potentially have the ability to hire any one of them. And especially on a short term basis. So this is something I’ve done a lot of in my career, which is, you work hard to recruit someone, but then getting them to relocate can be a huge deal. I mean, first of all, obviously moving is a big deal for people, it’s expensive, it’s emotionally demanding, but then you often have immigration things, right, where you have folks who are in some cases takes them years to get the visa they need to come work with you. And then if you do get in the thing where someone comes, works with you for a little while, turns out it’s not a fit and you’ve gone through all this and they’ve uprooted their life, boy, it becomes really hard to consider, you know, for them to think about quitting, especially if it’s tied to their immigration, on the employer side to think about letting them go. Because you just know what a huge deal this was to work together, and with remote, you say, what are you available? Well, next week, great, let’s start working together. And it’s just a much more lightweight operation, and you sort of decoupled all of these other life choices from your employment, and so that’s this huge benefit on the employer side, the team builder side, the company side is that global talent pool and the lightweight hiring process, and I think that single benefit is so big that it basically makes up for a huge number of other downsides of remote work. 00:17:50 - Speaker 1: Yeah, that’s a great point, and I feel like it’s still underappreciated in the market. People have spent their whole careers with this baseline unremarked upon assumption of because it’s so expensive in many different senses to relocate someone in order for it to make sense, it has to be a longer term commitment or at least expectation. And we’ve removed that constraint, but it hasn’t fully propagated through the system, I would say. But while that’s the case, it’s to our advantage for sure. 00:18:20 - Speaker 2: Now there’s a, call it administrative piece of this as well, which is increasingly you can kind of decouple the legal jurisdiction of the entity, the employee location, and yeah, the owner location. Which is quite interesting. I think Stripe Alas was the first mover on this first base is another company that makes it easy to just incorporate a US legal entity, whether or not you’re located in the US. You also have up and coming services like Wise, which makes it really easy to do currency conversions and sort of international transfers, or you got something like De DEEL, which is kind of like an international HR kind of platform. And all of these things acknowledge this reality of that I think in some ways probably the legal frameworks that exist haven’t quite caught up to yet, which is, you have what I’ve sometimes heard referred to as micronationals. The Muse team would fit into that, right? We have some folks from Europe, we have some folks from the United States, and historically, if a company got big enough to have teams in two different countries, let alone two different continents, you would be huge. And so of course you could set up maybe, I don’t know, all kinds of HR process and things like that to kind of manage the. Relationship between the legal entities and the employees and comply with all the local labor laws and things like that. But now it’s quite common, even just a founding team, and just two people who are gonna work together might be from two different countries, and they don’t have any plans to relocate or whatever. Where do you incorporate, where is your bank account? And I think increasingly it’s become possible and even a common practice to think of the jurisdiction where the company lies is, yeah, so completely independent of where the employees may happen to be located. Now, you still have to deal with lots of complexity potentially moving between them. So as one example, The fluctuating USD to euro currency conversion rates in the later part of 2022 is a challenge for the Muse team, but it really is possible to have a small team where people are located in different countries, and yeah, you can kind of make so much of this virtual and do all that in a way that’s legal and practical. 00:20:31 - Speaker 1: Yeah, it’s definitely very doable now and only getting better with these various services that you’ve mentioned. Frankly, it’s a bit of a mess, like currency conversion and tax law and employment law, it’s like it’s kind of all over the place, but just grind through that and it’s very doable. 00:20:45 - Speaker 2: There’s a great article I read a couple of years back called The Legal Implications of Remote, which I think was someone looking at the UK specifically, but I think the general concepts are broadly applicable, which is honestly, it’s not a fully well fleshed out area of law because it is so new and especially if you think of something like workplace. Safety, which isn’t really a huge concern for knowledge workers for the most part, but you know you have someone like our colleague Julia, you know, she’s a German citizen. We’re a US based company. She spends several months of every year in the winter months, usually in some place like Mexico or someplace in Central or South America, and if she has a workplace injury. When she is a citizen of one country employed by a company based in another country while she is physically in a third country, which labor laws apply there. And yeah, it’s a brave new world. Now one thing we considered when we set up Muse was the compensation question. Gitlab has some nice documents on this where they have their kind of weighted. They have a waiting relative to basically where you live because of course it’s pretty normal to pay rates that are relative to your local market. So this is a bit of a debate, you know, is it do you just pay everyone the same, or do you wait it according to where you happen to live? Does that create opportunities for people to move somewhere, you even have companies who have paid you to move someplace less expensive. What do you think about that debate? 00:22:10 - Speaker 1: Folks understandably develop very strong opinions about this matter, but a lot of what I’ve seen is a little bit, I think, too shallow and doesn’t address the dynamics. I think you need to understand this is a process that’s playing out over time. So let me use a little economic story example. Let’s say that initially, You have like two markets, you have the high-end software market and the regular software market, and those are strictly geographically co-located, or people on the high end software market get paid twice as much for whatever reason, you know, cost of living, make something out due to where they are, and you can’t work across those boundaries, and then some single individual. Invented a magical technology, let’s call it voom, and they can work on either side. What should their compensation be? Now there’s two kind of legitimate arguments. There’s the argument of, I’m Doing the same work and even though I’m from a moderate cost area, since I’m doing the same work as your highly paid employees in the new area, I should be paid twice as much, or it should be your cost of living or whatever you want to make up is only half of our other employees in this high cost area. Therefore, you should be paid your old wage which corresponded to your old cost of living. And what this shows that the actual issue is that there’s a lot of surplus generated. That’s an economic term, which is basically a difference between the value that’s being produced and the cost of producing it, right? And the question becomes how do you allocate that surplus? Does it all go to the employer? Does it all go to the employee, or is there some mix? And when you phrase it in that way, you see that the idea that it should be exactly equal to one of those two extremes is, uh, it’s a little bit doubtful to me. So what I expect is Over time, the markets blend. So while you’re in that initial step of the process where there’s very few people who are crossing geographic boundaries, there’s big surpluses that are unlocked, but it’s also very contentious to negotiate the salaries because deciding how to split up that pie. And we’ve seen that play out with, you know, very strongly worded statements about, you know, you should definitely pay full SF rate or you should definitely pay cost of living rate. But what’s gonna happen over time. I this is basically gonna become one market, I would think, where in the fully remote world, your salary is gonna be a function of your effectiveness or your be believed effectiveness, and if it’s really the case, you know, asterisks, if it’s really the case that there’s no difference on your Impact and productivity for the company based on where you live, that will be reflected in salaries. Now, by the way, that goes both ways. It might be the case that it becomes uneconomical to be a software developer in San Francisco because it’s too expensive versus the market rates in the same way it’s uneconomical to be like a textile factory in San Francisco. Now, I think we’re far from that, but I do expect and If it’s true, if the premise is true that we’re moving to a fully remote world and that that’s just as effective as the local world, then I think things will equilibrate and that will have some winners and losers. But it’s not gonna be that everyone in the world gets paid what was formerly the very top rate. I think that’s unlikely. And by the way, this also connects nicely to an element of personal responsibility and it ties into a little bit of how we approach Muse. A company can say, we think kind of a fair global market value for Software engineering services is X and you can choose to live wherever you want with that. You know, if you want to live in Mexico, for example, very low cost of living, and you’re able to work there and it’s in the right time zone, great. If for whatever reason, like say you have family in New York City, you really want to live there, you know, OK, you know, we’re also not obligated to support you and wanting to live closely to your family. Maybe you should find another job. So there’s kind of an element of personal responsibility and finding a good match with the company in the market. 00:25:49 - Speaker 2: Right, so we’ve sort of described here why a knowledge worker or a creative person would be motivated to work remotely, a lot of which has to do with flexibility and autonomy and their lifestyle. We’ve talked about the company’s motivation, namely around hiring, accessing a global talent pool, perhaps even this compensation. Piece of the puzzle, but we’re sort of talking about it as if, well, obviously this is something that can and should be really broadly distributed, but in some ways we’ve seen a quite a retraction in recent time from the peak of remote work. People are going back to the office, so to speak, and we mentioned kind of towards the beginning that part of what made this start to become possible indeed what made us founding and switches and a remote first team, what made us found Muse’s remote first team was the tool chain. That Zoom plus Slack plus GitHub plus Figma plus Notion plus a few other of these products, you put those together in the right combination and with the right set of practices, and you have something where you can get to 60, 70, 80% of the productivity of an in-person team, but with all these other benefits and that sort of cross some threshold of like, OK, this is the cost exceed the benefits. But that brings us to Muse for Teams, so we’re working on this product here now, and we always knew we wanted a multiplayer component of Muse, but in the process of actually starting to roll it out to our first users and customers and using it for ourselves and realizing how much, how we think about remote work and how much we work as a company is baked into the Product vision is too concrete a word, more like our set of problems that we want to work on and the territory that we want to operate in, I think is really a lot about saying, hey, we think we have something we can contribute to the remote work tool chain, something that is missing right now. 00:27:42 - Speaker 1: Yeah, and in particular we see Muse as a tool to help you and now your team have better ideas to idea, and there’s good remote tools for more transactional and production oriented work. You can have collaborative databases and spreadsheets, and you can produce things like presentations and UI designs together. Obviously you can convey transactional messages in something like email or Slack, but what replaces The work that used to be done over the whiteboard, around the punch table, as you’re taking a walk outside with your colleague, that’s a place where we see music video. 00:28:21 - Speaker 2: Yeah, I think one thing that’s missed in the discussion of two office or not to office is the fact that different parts of the work benefit from being a person quite differently. And there’s a lot of intangible things about like culture transmission and so forth, but putting that aside for just a moment, I do think that just looking at the, I had the first spark of an idea to, I shipped it to customers or to a client. There are certain parts that are more production oriented and heads down and individual that probably are just as good to go, for example, go back and forth on a pull request in GitHub, whereas there’s other parts that are more loose, sketchy, still trying to figure it out, you need the high bandwidth of being together and kind of gesturing, and we often talk about being in front of a whiteboard and partially that’s about the whiteboard, but I think we use it as a stand-in for that kind of meeting where You’re trying to get together with your collaborators and figure out what you’re even, but even there’s a problem or you know, really trying to develop an idea, and that’s the sort of thing that I think is very hard to do in these tools, which as you said, are typically designed to be transactional. You send the email, you send the slack message. I think people tend to use, or certainly we’ve seen this from our customer interviews and so forth, they use a Google Docs notion to some extent, kind of write up. Ideas and then they go back and forth in the comments, but it’s all just very structured and it’s all very kind of flat in a way, and yeah, I think that is sort of the big gap in the tool chain right now. 00:29:57 - Speaker 1: Yeah, and we’ll talk more about this when we turn to how well and whether remote works, but importantly this ideation thing, you can get away for a while without doing it, or in particular having coasted on your previous ideas. So if you’re in an office together and you’re coming up with all these great ideas, high level designs, directions, then you can go and produce and transact for, I don’t know, a year or two, basically in this direction and it can work quite well. But it’s only when you’re 2 or 3 years in that you realize, wait, we need better ideas, but we can’t do it because we don’t have the appropriate medium and tools. So I think part of the reason why we’re as an industry, only slowly starting to realize the gap here is that it actually takes a while for it to become a parent. 00:30:40 - Speaker 2: So mentioning whiteboards naturally leads one to talk about another category of software, which is the infinite canvas kind of collaborative whiteboards. I feel like there’s quite a few of these, some of which have been really successful in the last few years. Miro is probably one of the biggest ones. FigMA launched Fig Jam a couple of years ago, and there’s numbers of others as well. So one question would be, we still feel the need to build Muse. And obviously we can talk about the personal tool and what we do there, but I guess the question would be, why doesn’t Miro scratch the itch? If we’re saying we need to have good ideas in front of a whiteboard, Miro gives you a virtual whiteboard, case closed. 00:31:18 - Speaker 1: Well, I certainly think there’s something there with tools like Miro. I had also used Mylonote in the past, but I found myself using those more for visual presentation of multimedia ideas and collecting multimedia data, like mood boards and doing almost like PowerPoint type presentations where you had something you wanted to share, but it wasn’t appropriate for something like a linear notion document. But it’s also quite polished and rectilinear and high fidelity, and we’ve talked about how that isn’t always conducive to ideation. It’s also a very focused on the desktop, doesn’t really have a strong iPad presence. So I think there’s something there, and there’s a lot of overlapping elements that we share, but I think there’s a slightly different focus and emphasis. 00:32:10 - Speaker 2: Yeah, I posed this question to myself over the last couple of years we’ve been working on Muse whenever I think about when we get to that stage of multiplayer, which again was always the kind of step 3 in our master plan, and we’ve tried using these products ourselves internally for yeah, team planning and things like that, including, yeah, exactly Millinode, Myro, fig Jam. Apple’s got free form now, yeah, there’s a long tail of these that we’ve tried out, and yeah, they never really, in some cases, I’m like, oh, that’s pretty neat, but they don’t really stick. I don’t find myself wanting to come back to them or reference it again. You certainly can’t use them, in some cases literally can’t use them, but perhaps you just see they aren’t built for personal thinking. So I’m never sure what to think when I try out a product like this, but it doesn’t really stick for me. Does that make me go, huh, maybe this whole idea of an infinite canvas with multiplayer capability is not as useful as I would have thought. Maybe we shouldn’t bother to build it. But the other interpretation is more the now famous story of what the Dropbox founder told investors when they asked him why are you building this? There’s hundreds of products that purport to do this exact same thing in the market. And he basically says, well, do you use any of them? And they say no, and he says, well, that’s cause no one’s done it right yet. I’m gonna do it right, and indeed he did. So whether Muse can be as useful and successful as Dropbox is remains to be seen, but one of my takeaways from me is like, OK, there’s something there with those products, and indeed I have used some of them somewhat extensively, but in the end, I feel like they don’t quite hit the mark for me, and so, yeah, we’re gonna take our swing at what it could be. Now, the vision of what use for teams will be, what actually happens when you have multiplayer capability to this previously, more kind of private ideation space is something that we’re discovering as we go. But I think already based on what we talked about here and ideas we’ve developed on the team generally, you can see there’s already some kind of principles that are emerging, right? We talked about the benefit of an office and being in an office for those early ideation. Stages, well, one thing that we’re finding ourselves thinking of Muse as is kind of like a virtual office where it’s this place you can go where you can get ambient awareness of what everyone’s working on, for example. And once we have that frame, it leads us to implementing features like for example, the fact that the avatars for your colleagues are always visible no matter where they are in the workspace, so it has this kind of one continuous world feeling. Whether that’s the right thing or not, you know, we’re actually gonna find that out, obviously through real world usage, but I think that’s an example of something where we can take what we’ve learned from those first generation tools. For example, FIMA, I think one of the reasons it does so well or struck such a chord is it has the sense of place, you feel like you’re gathering with your colleagues on this document, but of course that’s within the document, it’s within that one document. If you go to a different document, you’ve lost track of them. And so with the muse kind of world, you are able to have ambient sense of where people are and what they’re doing, you see where they are, and you kind of peek in if you want, but that’s sort of rude a little bit, and yeah, it actually gives me a lot of energy to see y’all’s avatars just kind of move around on this big kind of space of like nested whiteboards, if you want to think of it that way. And yeah, it’s kind of like a fun way to meet. It feels like a place to meet and You know, how much can that be a replacement for what we get out of offices? I’m not sure, but that’s what we’re gonna find out through this process. 00:35:43 - Speaker 1: Yeah, I think it’s really important to dial in carefully to why and how ideation works. I think the high level answer for why not tool X in the past has been, it doesn’t quite resonate with how ideation really works, and importantly, the reality of that has no obligation to You know, basically makes sense to you or to be fair, or to be simple, or to be straightforward. It might be, for example, that seeing little circles with your friends' faces on them next to a document makes you much more inclined to go there and look at it, you know. And that regardless of the document itself, and that’s just the way people are, people are messy. And there’s all kinds of weird stuff like that with ideation. Another one of my favorites is, maybe you have better ideas when you’re sitting down in a couch than when you’re at your desk, you know. Maybe not, but you gotta be open to weird stuff like that. And what we try to do with Muse is really tune into those weird principles of ideation that maybe been lost to the rectangles in the screen focused that is traditional for software, and I think we’ve had some good success with it, but like you said, the proof is really in the market, so we’ll see. 00:36:47 - Speaker 2: Another potentially counterintuitive piece of how ideation works, particularly ideation across a set of people, is what I would call the asynchronous component. I think when you naturally think of group ideation, you think of live brainstorming, a very real-time aspect, and indeed a lot of when we think of collaborative tools like a Google Docs, we are thinking of that very real-time nature you’re seeing someone typing in the document. But I think for sure a big part of having good ideas and developing them over time is that like you said, the taking a walk and that has this asynchronous or spread out across time. You often have talked about things like letting stuff stew or feeding your sleeping mind and you literally sleep on the problem and come up with another idea, and I think there’s a version of that within a group as well. bouncing ideas back and forth in a kind of virtual sense, and that’s a very interesting overlap with something that I think is a big part of the emerging best practices around remote work, which is embracing asynchronous and some of that comes from this practical aspect of like, hey, you’ve got people across time zones, so if everything has to happen in synchronous meetings, then it makes it real tough for people. And so there’s a practical element of it, but I actually think that when it does come to many types of the work pipeline and that early stage of ideation is one piece of it. There are parts that really benefit from real time live, energy, and there’s other parts that actually suffer from that, that if you don’t have the time and space to go off and have your own thoughts separate from the group, the combined group idea is going to be worse than it could be. 00:38:31 - Speaker 1: Yeah, this to me is very important, especially as we get into muse for teams, again this is very caricatured model of ideation, which is everyone gets into a room, you have a brainstorm and out comes the ideas. The reality is so much messier. You have individual to group and back again, you’re bouncing around among individuals, you’re bouncing around among different levels of fidelity. The ideas get mutated, even corrupted, if they get passed from person to person. Sometimes they bounce like all the way around the circle and come back to you in a different form. Style, there’s all kinds of wild stuff that happens and that full process, almost like this pulsating network, right? With all kinds of weird patterns happening is what’s really needed to produce good ideas. So the substrate, the tool needs to embrace that. And that’s one thing that I think is doing pretty well. 00:39:18 - Speaker 2: Now it’s no secret that we’re gonna have a lot of these kind of big ideas or counterintuitive insights or philosophies behind what we’re building here with the collaborative product. That’s also true, of course, with the personal tool in that element. Many of those same ideas are obviously gonna come across like ideation being a little bit being freeform or even messy, but one question that came from someone on our Discord, that’s Antoine RJ Wright. In his question he asked about tools, but I think the underlying thing is that if you have a group working together and they have different styles or different approaches, how do you resolve that? And so, for example, we think that spatial visual, this nested board approach is a great way to explore. is, but if you’re someone that prefers plain text, top to bottom, don’t give me a bunch of fancy pictures. I’m confused or overwhelmed by this kind of big open space, which is very reasonable. Different people’s brains work different ways. OK, well, for a personal tool that’s fine because of course you can just pick the one that fits your brain, but once you’re on a team, you kind of all need to agree. about a tool but also working practices. So to answer Antoine’s question, how do we see about trying to have a team come together around tools if indeed when it comes to something like thinking tools, it’s so personal and so about what fits with your mind? 00:40:47 - Speaker 1: This is such a fascinating question, and I’m not surprised that it’s come from Antoine, one of our earliest and best customers. I almost challenged the kind of framing that you had of how do we get people who are currently using disparate tools to use a more unified approach, which, you know, I’m sure is probably one personally likes and approves. So the question could actually mean different things. It could mean, how do we help the group converge on a tool or set of tools, or it could be how do you manage the chaos and complexity of people using different tools, and I think there’s different answers to both of those, maybe we can take the framing of how do we get some convergence. I have a couple of thoughts here. One is a very powerful truism that I heard about management is people don’t show up to work to do a bad job. It’s one of those that sounds so simple when you say it, but it’s very easy to catch yourself basically making that implicit assumption. And so why are these people coming in to work using old tools and there’s some reason, so you gotta have some curiosity about what their context is, what their personal history is, why they think this is the best way for them to do a good job. So a counsel curiosity there, which is hard to take much further without additional context on the team, but that’s one idea. Another sort of management pattern that I might advise here is starting with a single person. So often people present these leadership challenges of, there’s this group, and I want the group to do something different, I can’t group X. The thing is groups don’t do things, people do things. So the way to start is to find one individual human being and to convince them and help them have success with a new path. And this actually has several important benefits. One is it forces you to confront concrete details cause it’s easy to speak in abstractions when you’re talking about the group. You know, the group is using old tools, the group is using too many tools. The group is using tools like, well, when you talk about what Alice specifically is using and why, again, you’re getting grounded in the details. Another thing is that it’s much easier to convince a group when there’s already one person convinced they become a sort of lieutenant who could help you advocate for the tool and affect the roll out when there’s often a lot of mechanical stuff that needs to happen. I don’t know how well that actually answers his questions, but those were some of the things that came to mind for me. 00:42:55 - Speaker 2: Well, I think this is why it’s interesting to think about this question in the frame of, we have a bunch of Weird, hopefully interesting, hopefully compelling ideas about what a group ideation space could look like or remote first group ideation space could look like, but you could imagine that there are some folks that that resonates with and others that it doesn’t, and I think maybe that’s OK, maybe they have again, their minds work differently or they have different kind of motivations for how to hook into the work. But part of the idea is that you know, if you develop ideas or part of our hypothesis, if you develop ideas together as a group, you have shared ownership over those ideas and then when you go to implementation, you’re more on the same page in a kind of figurative and literal sense, but then if different tools just don’t Suit everyone on the team and now you just need to find some consensus around that. I think there’s always going to be some potential level of friction on that and some folks will just end up going along with tools they don’t love or aren’t the perfect fit for them vibe wise, but you know, that’s just what the rest of the team is using, so that’s fine. And by the way, this is our Discord, which has been running for a while, some great discussion there. It has been up until now just for pro members. You get a link from your backstage pass, but by the time this episode airs, it should be possible for anyone to join. So I’ll put a link there in the show notes and pop in there and you can propose questions for future episodes slash comment on this one. Now another question from Discord is from Robert Stevens and he basically asks, how do we think about hybrid in office and remote. Mark, you had referenced earlier that we’ve had experience with all pieces of the spectrum, so, what do you stand on the feasibility of that or the techniques that work there, or maybe that’s the future that actually blends the best of both worlds. 00:44:51 - Speaker 1: Yeah, it made me I actually have less experience with this. I mean, everyone who used to work in an office has some nominal experience of just didn’t go to the office one day for whatever reason. This one’s interesting cause I think it’s pretty easy, and I think it’s likely that firms will evolve from the all local position into this. This is the, OK, we can see after the pandemic that the whole world didn’t stop, so therefore, Tuesdays and Thursdays, you can work from home, right? But it’s kind of a one-way ratchet, like, not only can you not Easily bring that back in, by the way, there’s a whole sub thread on like the Wall Street firms trying to bring people back to the office 5 days they’re having a really tough time. But even more obviously you can’t bring a globally distributed firm and say, oh, now we’re gonna do partially remote and partially local. It’s kind of all or nothing to be able to have more than 0 days at a given local office. So, I think there’s certainly a future to this. I think there’s a lot by volume to this, of a lot of currently all or mostly local firms are gonna adopt some element of working remote part of the time, but I think it’s harder to see, yeah, existing highly distributed groups coalescing around single locations, but I wouldn’t right off the possibility. There’s also the mechanism of the summit, which maybe we could talk a little bit about where you get this, but in a different way. Which is you are remote part of the time, you know, maybe it’s 7 out of 8 weeks and then 1 out of 8 weeks you meet up somewhere, but that place isn’t where you maintain your primary residence, right? It’s some place that you pick off Airbnb. 00:46:21 - Speaker 2: Yeah, my personal experience with Hybrid, which we did quite a bit of at Hiroku towards the end of my time there. was trying to kind of plug remote people into an in-office culture was really challenging. First, you get into all kinds of just AV stuff, trying to like mic up conference rooms and things, and we spent a lot of money, if I recall correctly, trying to get the perfect setup there in the end, the thing that worked best was for everyone to be on their own laptop with their own headset, even if they were in the same room, for example. And in that sense, what you’re describing, which is starting from a remote first or distributed team kind of as the baseline and then you come together in some location, whether that’s a co-working space or an office pod or a team summit or something like that where you kind of go from remote as the default and then Choose to gather at certain times and places, and those kinds of places could be a lot. It could be an office 2 days a week or 3 days a week, but that’s the kind of, I don’t know if you would call upgrade or the escalation of both bandwidth and cost to the individual people that come together and that your default state is virtual. 00:47:31 - Speaker 1: Yeah, and now I’m realizing there are at least two very different meanings of hybrid, which at least I didn’t differentiate my answer, so I wasn’t even sure if I’ve answered the original question correctly, but there’s hybrid in the sense of everyone is on the same local remote schedule, or at least on some local remote schedule, like everyone in the office 3 days a week and everyone not in the office 2 days a week. And there’s hybrid of 70% of people live in San Francisco and 30% of the people live somewhere else. So the former, I think there’s there’s quite a future for. The latter, I shared a sentiment that that was very difficult. Not only was it difficult, it can be a little bit corrosive, because if people who uproot their lives to move to San Francisco might do that because they enjoy and value the in-office collaboration environment. And so, Adding the remote element can be a detraction for them, just in and of itself, not to mention it’s incredibly difficult for the people who are remote and the firm overall to metabolize that. So it can be done. It’s just it’s really against the grade. Like, just to give you one example, it’s very often the case that the senior. Leadership of the company, you know, is coincidentally, all located in the HQ. It’s often the case that a lot of important decisions and meetings don’t have the correct conveyance via the remote channels like Zoom and Google Docs or whatever, for people who are remote to fully plug into those decisions. It’s kind of like our friend Peter Van Hartenburg’s statement that diligence doesn’t work. Like, if there’s a way for this stuff to go off the rails, it will. And so the only way to make it work is like basically force everyone through the remote channels, even if you’re in the office, go into a phone booth and dial into Zoom like everyone else, that I think can work, it just gets kind of weird at that point. 00:49:07 - Speaker 2: Yeah, it’s always funny when you see, you know, some open office plan office with a bunch of folks sitting at their computers with their noise canceling headphones on Zoom calls and sort of begs the question of why we need these bodies together in the same physical place. And again, you could probably talk about hallway conversations and lunch bonding and so forth, and the ability to in some cases, kind of upgrade to meet in person, but yeah, I agree the synchronization on when you’re going to be together and when you’re not. is quite key to success. Well, maybe we could just take a moment then to briefly talk about the mechanics. I don’t think we need to go too deep here, but we have a few techniques that worked pretty well for us on the Muse team. You wanna describe those briefly? 00:49:52 - Speaker 1: Yeah, maybe we can focus on the ones that I think are a little bit more unique or differentiated versus, you know, write stuff down on Slack so people can see it, you know, yes. One is what we call core hours. So this is a set of shared hours, usually about 3 hours where folks have overlap in their time zones and we set the expectation that you’re available for more synchronous work during that time. So that’s when the team planning meetings are scheduled, that’s where you do a lot of real-time collaboration and discussion. And that way people know that there’s these kind of 3 hours where they are expected to typically be online, but so are their collaborators and so you can get all of your synchronous work done during that period, and then you have the rest of your day, A for flexibility in your personal life as we talked about as a I see benefit, but also to do asynchronously your heads down focus work without distractions. 00:50:46 - Speaker 2: And the core hours concept was when we came up with that Ink & Switch, and even we have a special notation for it. It always sort of rubbed me the wrong way a little bit to declare a particular time zone as the company time zone, that sort of implies that that place is the center of the universe and everything else orbits around it. 00:51:05 - Speaker 1: Yeah, unless it’s UTC, which just makes everyone mad, right. 00:51:08 - Speaker 2: At least then no one is the center of the universe, just everyone has to suffer. But yeah, so we have this little notation, which is basically SOC, which we’ve declared as noon US East Time, which also suits the particular distribution of our team. I suppose that if you had quite a lot of folks who are based out of Australia or India or Singapore, you might want to do something a little different, but for us it works at noon Eastern time, start of core, and then we can declare something as, you know, most of the time you can have a meeting, let’s do it at start of. Or we’ll do the demo. Let’s start a core plus one, something like that, and that works pretty well and that the expectation from team members is that you’re available for synchronous work during that time. It’s not to say it’s back to back meetings, in fact, hopefully it should not be, but the idea is during core hours, if you say, oh, you know, I have a bunch of questions about this code review you gave me, can we just jump on a quick programming session that there’s High likelihood that they will be available, kind of in the same way with a 9 to 5 in an office, those are sort of these, you call them working hours, that’s not quite correct, they’re really collaborative, synchronous collaborative hours, and that you do the rest of your work on whatever other time of day you want to. 00:52:23 - Speaker 1: I still remember very vividly when I was an engineer at Hirou, and we had one day a week, I think it was Wednesdays, maybe it was Thursdays, where I can make it Thursdays, yeah, I think it was Thursdays, 00:52:35 - Speaker 1: where there were no meetings, and I would look forward to that day every week because even one meeting in the middle of your working block really throws you off as an engineer. This goes back to the old PGSA which I’m sure we can link, but it’s so true. But the nice thing about the core hours is you have a big block every single day for doing a maker work, and it makes a huge difference. 00:52:58 - Speaker 2: Yeah, absolutely. I think it’s sort of a feature, maybe an embrace the constraints type of thing that you have to fit all your synchronous meetings into this more limited chunk of time, you know, for me it’s around 2.5, 3 hours. I gotta fit all my meetings for the day into 3 hours, and the rest of the time is essentially by default open, and that means First of all, of course, getting to work when I want to, when is the most productive and creative time for me, but also it implies that, you know, if you think of a, say, a 7 hour workday, 3 hours are the synchronous time, well then you got 4 hours. That’s a really solid block or 2 really pretty solid blocks of deep work and focus. And yeah, that’s just an incredible thing. Now you mentioned the summits previously, how do those work? 00:53:48 - Speaker 1: The intuition with summits was that you weren’t gonna have enough very high bandwidth collaboration and relationship development if everything was totally remote, if you never saw your collaborators face to face. But we didn’t want to solve that by having everyone in the company moved to San Francisco or whatever. So the idea that we had, and I think we borrowed this from Inc and Switch who’s been doing something similar for a while, is summits where everyone works. Remotely and then with some frequency every 2 months or 10 weeks or whatever, the whole team meets at some location, which could be different each time. It might be Mexico City or Philadelphia or Aspen or whatever, right? You can kind of pick a location that’s convenient for the whole team to get to, and then you do, you know, 234 days, maybe, maybe it’s about a week with travel on either side. Where you take advantage of everyone being in the same place. So that’s where you might do things like, you know, relationship development, bringing new members into the team, road mapping, making strategic decisions, making big calls as a group, things like that can happen at summits, and then you take that back for the next 8, 1012 weeks and build on that day to day with your work, and then it starts a new. With the next summit, and then also naturally leads into a sort of chapter rhythm, as we call it, where corresponding to each summit interval, you’ve taken this heads up moment, you’ve got a refreshed and clarified direction corresponding to what we call chapters. 00:55:13 - Speaker 2: Yeah, I think the summit technique works really well. It creates a natural rhythm. It kind of takes some elements of what you get from being in the office together, those human bonding moments, the gaining of ambient contexts, the culture transmission. Sort of packs it all into this one week every 2 months or 4 months or half year, whatever your rhythm is, which is probably not as good in some ways, but I think it’s probably like 80/20, it’s probably 80% is good for 20% of the effort. You still get all the value of flexibility. You do have this challenge of travel, depending on where folks live, and you need to be sort of able to travel, which is not totally possible or easy for everyone, but sort of compared to moving someplace, it’s certainly vastly easier and so you get to get a lot of that and by the way you put it together with, yeah, going to an inspiring destination, whether it’s an urban place, we’ve done a few cities, whether it’s a rural place, we’ve done some nice nature retreats, and that’s something about being in an inspiring creative space with folks that you don’t get to see in person all that often, you’re doing these big Zoom out, yeah, strategic, you know, what’s the next N months gonna hold? What do we want to accomplish as a team, all that stuff, that that combination of things is just a really potent brew. I’ve come to quite look forward to them and I just find it to be a, not necessarily a complete replacement for the in-office culture, but kind of a parallel thing that serves a lot of the same purposes, better in some ways, certainly worse in others, but also just has its own. Perks and benefits that I’ve come to quite like, including, by the way, we’ve talked about in how to have good ideas that in many cases just being in a new place and a novel surroundings can spark new ideas, and I even remember in many cases a particular thing that developed into a major new product or feature or initiative that we had and I associated with the place that we thought of it, because we are going to these new places all the time for these kind of strategic big picture ideation sessions. 00:57:24 - Speaker 1: I do feel that how often you do these will tend to vary with the nature of the company. Basically how many cr