From 5a0d79462e67eabd4981e91c1d745da3ab690220 Mon Sep 17 00:00:00 2001 From: jinhojang6 Date: Wed, 16 Aug 2023 22:30:17 +0900 Subject: [PATCH] feat: add episode channels --- .../Episode/Header/Episode.Channels.tsx | 67 +++ .../Episode/Header/Episode.Header.tsx | 3 + .../GlobalAudioPlayer/GlobalAudioPlayer.tsx | 10 +- .../GlobalAudioPlayer/episode.state.ts | 17 + .../ApplePodcastsIcon/ApplePodcastsIcon.tsx | 27 + .../Icons/ApplePodcastsIcon/index.ts | 1 + .../GooglePodcastsIcon/GooglePodcastsIcon.tsx | 27 + .../Icons/GooglePodcastsIcon/index.ts | 1 + .../Icons/SpotifyIcon/SpotifyIcon.tsx | 27 + src/components/Icons/SpotifyIcon/index.ts | 1 + src/pages/podcasts/episode-temp-data.json | 542 +++++++++--------- 11 files changed, 442 insertions(+), 281 deletions(-) create mode 100644 src/components/Episode/Header/Episode.Channels.tsx create mode 100644 src/components/GlobalAudioPlayer/episode.state.ts create mode 100644 src/components/Icons/ApplePodcastsIcon/ApplePodcastsIcon.tsx create mode 100644 src/components/Icons/ApplePodcastsIcon/index.ts create mode 100644 src/components/Icons/GooglePodcastsIcon/GooglePodcastsIcon.tsx create mode 100644 src/components/Icons/GooglePodcastsIcon/index.ts create mode 100644 src/components/Icons/SpotifyIcon/SpotifyIcon.tsx create mode 100644 src/components/Icons/SpotifyIcon/index.ts diff --git a/src/components/Episode/Header/Episode.Channels.tsx b/src/components/Episode/Header/Episode.Channels.tsx new file mode 100644 index 0000000..3a38b1b --- /dev/null +++ b/src/components/Episode/Header/Episode.Channels.tsx @@ -0,0 +1,67 @@ +import { Typography } from '@acid-info/lsd-react' +import styled from '@emotion/styled' +import { LPE } from '../../../types/lpe.types' +import { ApplePodcastsIcon } from '@/components/Icons/ApplePodcastsIcon' +import { GooglePodcastsIcon } from '@/components/Icons/GooglePodcastsIcon' +import { SpotifyIcon } from '@/components/Icons/SpotifyIcon' +import Link from 'next/link' + +export type EpisodeChannelProps = { + channels: LPE.Podcast.Channel[] +} + +const renderChannel = (channel: LPE.Podcast.Channel) => { + switch (channel.name) { + case LPE.Podcast.ChannelNames.Spotify: + return ( + + + Spotify + + ) + case LPE.Podcast.ChannelNames.ApplePodcasts: + return ( + + + Apple Podcasts + + ) + case LPE.Podcast.ChannelNames.GooglePodcasts: + return ( + + + Google Podcasts + + ) + default: + return null + } +} + +const EpisodeChannels = ({ channels }: EpisodeChannelProps) => { + return ( + + {channels.map((channel, idx) => renderChannel(channel))} + + ) +} + +const EpisodeChannelContainer = styled.header` + display: flex; + gap: 24px; + align-items: center; + margin-top: 32px; + + @media (max-width: 768px) { + padding-top: 32px; + } +` + +const Channel = styled(Link)` + display: flex; + align-items: center; + gap: 8px; + text-decoration: none; +` + +export default EpisodeChannels diff --git a/src/components/Episode/Header/Episode.Header.tsx b/src/components/Episode/Header/Episode.Header.tsx index ee544be..a199120 100644 --- a/src/components/Episode/Header/Episode.Header.tsx +++ b/src/components/Episode/Header/Episode.Header.tsx @@ -7,6 +7,7 @@ import { default as Stats } from '@/components/Article/Article.Stats' import { LogosCircleIcon } from '@/components/Icons/LogosCircleIcon' import { useHookstate } from '@hookstate/core' import { playerState } from '@/components/GlobalAudioPlayer/globalAudioPlayer.state' +import EpisodeChannels from './Episode.Channels' export type EpisodeHeaderProps = LPE.Podcast.Document & { url: string @@ -18,6 +19,7 @@ const EpisodeHeader = ({ description, publishedAt, tags, + channels, url, readingTime, }: EpisodeHeaderProps) => { @@ -55,6 +57,7 @@ const EpisodeHeader = ({ Network State Podcast {tags && } + {channels && } {description && ( (null) const [episode, setEpisode] = useState({ title: '', @@ -36,7 +34,7 @@ export default function GlobalAudioPlayer() { useMemo(() => { const getAudioSource = async () => { - const response = await getAudioSourceFromEpisode(TEMP_EPISODE_ID) + const response = await getAudioSourceFromEpisode(epState.value.episodeId) setEpisode({ title: response.title, @@ -47,7 +45,7 @@ export default function GlobalAudioPlayer() { } getAudioSource() - }, [episodeId]) + }, [epState]) const [showVolume, setShowVolume] = useState(false) diff --git a/src/components/GlobalAudioPlayer/episode.state.ts b/src/components/GlobalAudioPlayer/episode.state.ts new file mode 100644 index 0000000..39775d6 --- /dev/null +++ b/src/components/GlobalAudioPlayer/episode.state.ts @@ -0,0 +1,17 @@ +import { hookstate } from '@hookstate/core' + +// Hasing it out episodes: https://api.simplecast.com/podcasts/b54c0885-7c72-415d-b032-7d294b78d785/episodes?preview=true +const TEMP_EPISODE_ID = '30d4e2f5-4434-419c-8fc1-a76e4b367e20' + +export type EpisodeState = { + episodeId: string +} + +export const defaultEpisodeState: EpisodeState = { + episodeId: TEMP_EPISODE_ID, +} + +export const episodeState = + typeof window === 'undefined' + ? hookstate(defaultEpisodeState) + : hookstate(defaultEpisodeState) diff --git a/src/components/Icons/ApplePodcastsIcon/ApplePodcastsIcon.tsx b/src/components/Icons/ApplePodcastsIcon/ApplePodcastsIcon.tsx new file mode 100644 index 0000000..f805766 --- /dev/null +++ b/src/components/Icons/ApplePodcastsIcon/ApplePodcastsIcon.tsx @@ -0,0 +1,27 @@ +import { LsdIcon } from '@acid-info/lsd-react' + +export const ApplePodcastsIcon = LsdIcon( + (props) => ( + + + + + + + + + + + ), + { filled: true }, +) diff --git a/src/components/Icons/ApplePodcastsIcon/index.ts b/src/components/Icons/ApplePodcastsIcon/index.ts new file mode 100644 index 0000000..387c244 --- /dev/null +++ b/src/components/Icons/ApplePodcastsIcon/index.ts @@ -0,0 +1 @@ +export * from './ApplePodcastsIcon' diff --git a/src/components/Icons/GooglePodcastsIcon/GooglePodcastsIcon.tsx b/src/components/Icons/GooglePodcastsIcon/GooglePodcastsIcon.tsx new file mode 100644 index 0000000..a8ac249 --- /dev/null +++ b/src/components/Icons/GooglePodcastsIcon/GooglePodcastsIcon.tsx @@ -0,0 +1,27 @@ +import { LsdIcon } from '@acid-info/lsd-react' + +export const GooglePodcastsIcon = LsdIcon( + (props) => ( + + + + + + + + + + + ), + { filled: true }, +) diff --git a/src/components/Icons/GooglePodcastsIcon/index.ts b/src/components/Icons/GooglePodcastsIcon/index.ts new file mode 100644 index 0000000..297668c --- /dev/null +++ b/src/components/Icons/GooglePodcastsIcon/index.ts @@ -0,0 +1 @@ +export * from './GooglePodcastsIcon' diff --git a/src/components/Icons/SpotifyIcon/SpotifyIcon.tsx b/src/components/Icons/SpotifyIcon/SpotifyIcon.tsx new file mode 100644 index 0000000..c279ef4 --- /dev/null +++ b/src/components/Icons/SpotifyIcon/SpotifyIcon.tsx @@ -0,0 +1,27 @@ +import { LsdIcon } from '@acid-info/lsd-react' + +export const SpotifyIcon = LsdIcon( + (props) => ( + + + + + + + + + + + ), + { filled: true }, +) diff --git a/src/components/Icons/SpotifyIcon/index.ts b/src/components/Icons/SpotifyIcon/index.ts new file mode 100644 index 0000000..600402e --- /dev/null +++ b/src/components/Icons/SpotifyIcon/index.ts @@ -0,0 +1 @@ +export * from './SpotifyIcon' diff --git a/src/pages/podcasts/episode-temp-data.json b/src/pages/podcasts/episode-temp-data.json index 7e4ca0a..8b9cf26 100644 --- a/src/pages/podcasts/episode-temp-data.json +++ b/src/pages/podcasts/episode-temp-data.json @@ -1,277 +1,269 @@ { - "data": { - "id": "b415119a-6550-5577-b850-eaa61684edeb", - "slug": "title-that-will-become-slug", - "title": "Title of the Episode; a nice and eye catching title", - "authors": [ - { - "name": "@testperson", - "emailAddress": "test@domain.com" - } - ], - "description": "Here we can have a summary of the podcast episode. Here we can have a summary of the podcast episode. Here we can have a summary of the podcast episode. Here we can have a summary of the podcast episode.Here we can have a summary of the podcast episode.Here we can have a summary of the podcast episode.Here we can have a summary of the podcast episode.Here we can have a summary of the podcast episode.Here we can have a summary of the podcast episode.Here we can have a summary of the podcast episode.", - "publishedAt": "2023-07-11T20:30:00.000Z", - "episodeNumber": 1, - "tags": ["Tools", "Cyber Punk", "Docs"], - "credits": [ - { - "id": "6bd84ceb-1f22-41f4-a229-306356306da7", - "type": "text", - "html": "

Episode hosts - Annie McEwen and Molly Webster

", - "text": "Episode hosts - Annie McEwen and Molly Webster", - "classNames": [ - "c1" - ], - "footnotes": [], - "order": 9, - "tagName": "p", - "labels": [] - }, - { - "id": "97c48663-da36-4c11-be41-b3a507aa2e21", - "type": "text", - "html": "

Produced by - Annie McEwen and Becca Bressler

", - "text": "Produced by - Annie McEwen and Becca Bressler ", - "classNames": [ - "c1" - ], - "footnotes": [], - "order": 10, - "tagName": "p", - "labels": [] - }, - { - "id": "c481e411-165f-4fb0-a5da-e73b05f1b7b7", - "type": "text", - "html": "

With help from - Matt Kielty

", - "text": "With help from - Matt Kielty", - "classNames": [ - "c1" - ], - "footnotes": [], - "order": 11, - "tagName": "p", - "labels": [] - }, - { - "id": "ef86751f-06d3-4468-a2aa-a97dd378438d", - "type": "text", - "html": "

Original music and sound design contributed by - Jeremy Bloom, Annie McEwen, Matt Kielty

", - "text": "Original music and sound design contributed by - Jeremy Bloom, Annie McEwen, Matt Kielty", - "classNames": [ - "c1" - ], - "footnotes": [], - "order": 12, - "tagName": "p", - "labels": [] - }, - { - "id": "d42cfb64-3b8a-4b82-b7db-d80b3346f441", - "type": "text", - "html": "

Mixing by - Jeremy Bloom

", - "text": "Mixing by - Jeremy Bloom", - "classNames": [ - "c1" - ], - "footnotes": [], - "order": 13, - "tagName": "p", - "labels": [] - }, - { - "id": "82fb6107-bde7-43bf-921b-f310d62c9280", - "type": "text", - "html": "

With dialogue mixing by - Arianne Wack

", - "text": "With dialogue mixing by - Arianne Wack ", - "classNames": [ - "c1" - ], - "footnotes": [], - "order": 14, - "tagName": "p", - "labels": [] - }, - { - "id": "bc6bd5f9-a50a-48be-bf2a-fb600a611f99", - "type": "text", - "html": "

Fact-checking by - Diane Kelly

", - "text": "Fact-checking by - Diane Kelly", - "classNames": [ - "c1" - ], - "footnotes": [], - "order": 15, - "tagName": "p", - "labels": [] - }, - { - "id": "81b77086-18a6-41a4-8938-888958d53aef", - "type": "text", - "html": "

And edited by - Alex Neason

", - "text": "And edited by - Alex Neason", - "classNames": [ - "c1" - ], - "footnotes": [], - "order": 16, - "tagName": "p", - "labels": [] - } - ], - "transcription": [ - { - "html": "

You ready to get into it?

" - }, - { - "html": "

Everybody. Welcome back. Bringing you another amazing interview, hashing it out, interview, doing it the way we love. I'm here solo dolo today. Well, not so well, though. I'm interviewing someone, but as far as hosts go, I'm so low on this one. Today we're going to talk a little bit about centralized messaging.

" - }, - { - "html": "

And I'm joined with Franck Royer, and he wanted it now. He’s a Waku guy. So we're going to call him Waku guy. Before we do that, Franck, because you introduce yourself. To the audience.. So I'll try not to just dive straight into Waku, but I feel like that's the only way to do it, right?

" - }, - { - "html": "

So for those unfamiliar with what Waku is, could you give us like a  quick brief message, like a brief overview of Waku and then we're going to try to peel away the layers and get a little bit deeper. All right. I like that. So it's a if this were to have trouble with an ephemeral communication network.

" - }, - { - "html": "

Okay. So I do know that there's a lot of projects working on decentralized messaging. But when you say decentralized messaging, I don't think a lot of people quite understand what it is and why it's needed. So I guess we could start there. Like what is the centralized messaging in comparison to what people are used to? And then we'll go to the tail end of that question and so yeah.

" - }, - { - "html": "

Mm hmm. So that's the biggest part about it is just removing what we're saying, the centralize or removing the server, its user got it. Many, not many servers, but many different failure points. And then you can't just boot people off, right? If they want a message, they can message. Okay, that's good. Now, I guess moving it to logos, right?

" - }, - { - "html": "

We've mentioned logo several times before on the podcast and guess what? Audience We're going to continue to mention logos because it's what we do. But Wakue was considered one of the foundational projects or logos was that hmm, yeah. Okay. So why is secure ephemeral messaging like so foundational to these decentralized applications? Right? Like, why is this needed? Like, it's absolutely needed.

" - }, - { - "html": "

Oh, we can I was going to ask you that would go straight into some use cases. Let's give us some examples.

" - }, - { - "html": "

All right. So we're back for round two of the Franck interview. I've been saying your name wrong for what appears to be years now. I mean, I've been saying it right as an American, but from way back for round two, I wanted to get a piece of the interview because for those who don't know, I also am peripherally a part of Waku.

" - }, - { - "html": "

And we're actually all are in some way, shape or form. And I have additional context or questions that I'd like to kind of dive into in this. And I think in the first interview, we got a really good foundation as to why Waku exists, what is decentralized messaging, how it fits into the ecosystem and kind of what's wrong with the Internet as it is today.

" - }, - { - "html": "

But I wanted to dive further into some of the details on how it works and maybe some of the tradeoffs as you build up from like Waku Relay into the different protocols that are available that are built on top of Waku relay. So to start, can you give me like the concept of a gossip network, Like what is a gossip network and how are messages passed around this?

" - }, - { - "html": "

So we should probably address the cat in the room here. Jesse has decided that he is now an anon person and would be doing all videos with some virtual avatar and a process of doing that. He's also put up a graphic of a gossip network here, which is basically, if I were to repeat that back to you, a well-connected group of nodes that everyone's connected to all people, you connect to a specific number of people.

" - }, - { - "html": "

So you have a select number of neighbors for gossip sub that is six people. So every person tries to maintain six connections and then when a message gets passed, it passes to it's it passes that message to all of its six neighbors, so on and so forth, until basically the entire network has been saturated with that message. Right.

" - }, - { - "html": "

So that allows some redundancy and some sensors like some censorship resistance, some some resiliency in the network. So if one person goes out, the message still gets routed and saturates the network. And I think that was an important distinction that needs to be made here, is that like Wendy was asking a question in the previous episode, I'm not sure if it'll make it into the air.

" - }, - { - "html": "

It was, I'm sending a message to someone, right? And that's not necessarily what we're doing with Gossip Sub or Whacko. I'm broadcasting a message and someone knows where to listen. I think that's an important distinction to make and add to that more generally speaking, that the tradeoff you're making here is bandwidth consumption or redundancy and computation, like how much work it takes to propagate a message.

" - }, - { - "html": "

And I'll fast that message gets propagated. So if you look at it from each extreme right, if you just start with one, each person maintains one connection in the network, right? That means that you have a very inefficient network in terms of how message gets propagated across right? Because if everyone relays a message, then you basically have to wrap that message to every single person with the in number of hops in being the size of the network.

" - }, - { - "html": "

Right. But there's no redundancy. So basically everyone gets that message once. But if we do the opposite of that and everyone is connected to everyone else, that's a fully connected mesh or fully connected network, then everyone receives that message in a number of times. Basically, they just keep just you just redundantly keep receiving it, but you get it really, really fast.

" - }, - { - "html": "

And so there's a tradeoff somewhere in the middle of like how many how do we maintain the minimum out of connections and message redundancy while maximize what while minimizing the latency, the time it takes to completely saturate the network with that as it's right? And so you're looking for somewhere in the middle so that you get this sense of sender receiver anonymity while also still having some reasonable like latency and bandwidth consumption associated with sending a message.

" - }, - { - "html": "

And so based on those simulations that protocol labs have done, six was a good way. It was a good number. It was the best number they found for Gossip sub, and that's what Waku was built on for gossip. So so now we can assume, you know, we have this, this gossip sub network right. That is what is, what is the difference between the P2P gossip sub and what Waku provides?

" - }, - { - "html": "

Why don't people just use the peer to peer gossip So like, why would they why would they want to use Waku at least like, well, we're going to start with just relay, right? Relay is the kind of foundational protocol for how Waku works. What does that add on top of a gossip sub network? Get them getting. Yeah, there's there's a little subtlety there right.

" - }, - { - "html": "

So like if a if a light client or mobile phone. Right. Can't handle the main network and it wants to try and ask a node for a specific set of messages, there's some level of obfuscating what those messages are right need so they can use bloom Filters are typically the way of doing this, saying I'm I'm looking for messages that look like A, B and C, and the more detailed you are, the more accurate exactly what the more narrowed down the messages you're looking for.

" - }, - { - "html": "

If you're really broad, you can say, give me all the messages that have the word two in them. Or like, you know, something that allows for the node to answer that while not exposing the details of the message to they can't read them, they're just setting encrypted messages. But like there is some level of privacy loss if you're asking for a group of messages because you just said it gives you the IP and whatever whatever you've asked for, they can make that connection.

" - }, - { - "html": "

So if you're routing as a full node and doing full relay and parsing things on, then you've, you've, you've, you, you're not giving me that information. Whenever you ask for whatever messages you're listening to. And that's a layer of good. Now it's a that's a developer choice. So the people who build the applications kind of choose how these content topics could be used.

" - }, - { - "html": "

And eventually we'll have one of the things we're currently working on in doing research and within VAC is kind of automating this sharding or automating the way in which people belong to specific content topic as the network scales out so that you maintain this level of reasonable anonymity or anonymity anonymity while keeping the resources required to do messages low Codex as it stands today and like this is part of ongoing research, is how do we scale walk properly?

" - }, - { - "html": "

Because if you if you can you can misuse these kind of content topics pretty pretty bad. So if you spam the network with a bunch of pictures, then everyone passes things on, it degrades the quality of the network, right? But like, there's ways of like status now currently uses, sends pictures and so on and prior profile settings and a bunch of other things across a crosswalk which are in some cases larger than one megabyte.

" - }, - { - "html": "

So there's a bunch of kind of efficiency tweaks you can do to keep specific media sensible via Waco and, and not like mitigating things whether that you have like this kind of media content shard. So like you just you propagate media through a different part of the network and that's this distinction I think is worth making that developers who are thinking about using Waku should should consider when they're thinking about how to use walk, who is used different.

" - }, - { - "html": "

If you think about a gossip tub topic that's ostensibly a network, that's the entire network. And then if you think about content topics, those are basically contents, right? Those are conversations that are being happened. And so what you're trying to do is strategically use content topics so that you're listening and propagating things you want to do to various people so you can be kind of selective on where you send things and who should be listening to it.

" - }, - { - "html": "

So you're not so not everyone is listening to everything or propagating everything. People are able to kind of pick and choose what they to pay attention to and contribute to when they're when they're contributing to the network. Right? If at some point we can maybe get into like as a if I run a if I run a node, I'm only propagating messages associated with these things because that's what I care about.

" - }, - { - "html": "

That's what I'm trying to support from the network. And so you have a network of nodes that are just doing the work that they think is important while not being inundated with all of the work of the entire network, which allows kind of this large, amorphous network to scale autonomously.

" - }, - { - "html": "

Jesse Yeah, I think that's perfect. And also like Jesse, that's a good analogy for how status plans to use Waku and it's also highlights this kind of optionality that developers have to leverage different classes of topics and content topics to efficiently serve their their users in the way they want to and hopefully pass on those options to them to do things the way they want to.

" - }, - { - "html": "

Like what you just described was status users getting to choose quite a bit of options, not only and potentially who relays messages and the latency versus privacy aspect of it, but also options for incentivization within their own community as well. So we're like by providing options to developers, they're able to choose a lot of pass those options on to their users to then let them do what they want to do.

" - }, - { - "html": "

And I think that's an important aspect of this. They're not pigeonholing people into a specific set of things. We're passing on a lot of options, though. The last point of this that I think we haven't gotten to. One of the protocols built on top of relay is the store protocol. Can you kind of dive into what that is and why it exists?

" - }, - { - "html": "

Jesse Just jumping in…

" - }, - { - "html": "

This is a reasonable place to wrap, I think. What's the what do you want people to do? Like if people listening to you, how do they learn more? What do you want it to go? How do they contribute it? Let it run a walk through node Like what are they like? How do they figure more out

" - }, - { - "html": "

Thanks, Frank.

" - }, - { - "html": "

Frank My bad.

" - } - ], - "channels": [ - { - "name": "youtube", - "url": "https://www.youtube.com/watch?v=vmx_oOb2On0" - }, - { - "name": "youtube", - "url": "https://www.youtube.com/watch?v=vmx_oOb2On0" - } - ], - "coverImage": { - "id": "08bd8535-d7b5-459e-85a0-183feb502e08", - "type": "image", - "alt": "", - "url": "https://images.cdn.unbody.io/00f8908f-9dff-456e-9640-13defd9ae433/image/a04e5542-d027-44d5-b914-bd4cadf17d25_image1.png", - "height": 1223, - "order": 7, - "width": 1999, - "labels": [] - }, - "show": { - "id": "426d4e4a-98db-5ba2-a9e6-a9d989a34022", - "slug": "hashing-it-out", - "title": "Hashing It Out", - "numberOfEpisodes": 1, - "hosts": [ - { - "name": "Host", - "emailAddress": "host@gmail.com" - } - ], - "url": "/podcasts/hashing-it-out", - "description": "", - "logo": { - "alt": "", - "url": "https://images.cdn.unbody.io/00f8908f-9dff-456e-9640-13defd9ae433/image/d4ecc97f-bcef-411d-b31a-639261623b25_image1.png", - "width": 1999, - "height": 1123 - }, - "episodes": [] - }, - "featured": false, - "highlighted": false + "data": { + "id": "b415119a-6550-5577-b850-eaa61684edeb", + "slug": "title-that-will-become-slug", + "title": "Title of the Episode; a nice and eye catching title", + "authors": [ + { + "name": "@testperson", + "emailAddress": "test@domain.com" + } + ], + "description": "Here we can have a summary of the podcast episode. Here we can have a summary of the podcast episode. Here we can have a summary of the podcast episode. Here we can have a summary of the podcast episode.Here we can have a summary of the podcast episode.Here we can have a summary of the podcast episode.Here we can have a summary of the podcast episode.Here we can have a summary of the podcast episode.Here we can have a summary of the podcast episode.Here we can have a summary of the podcast episode.", + "publishedAt": "2023-07-11T20:30:00.000Z", + "episodeNumber": 1, + "tags": ["Tools", "Cyber Punk", "Docs"], + "credits": [ + { + "id": "6bd84ceb-1f22-41f4-a229-306356306da7", + "type": "text", + "html": "

Episode hosts - Annie McEwen and Molly Webster

", + "text": "Episode hosts - Annie McEwen and Molly Webster", + "classNames": ["c1"], + "footnotes": [], + "order": 9, + "tagName": "p", + "labels": [] + }, + { + "id": "97c48663-da36-4c11-be41-b3a507aa2e21", + "type": "text", + "html": "

Produced by - Annie McEwen and Becca Bressler

", + "text": "Produced by - Annie McEwen and Becca Bressler ", + "classNames": ["c1"], + "footnotes": [], + "order": 10, + "tagName": "p", + "labels": [] + }, + { + "id": "c481e411-165f-4fb0-a5da-e73b05f1b7b7", + "type": "text", + "html": "

With help from - Matt Kielty

", + "text": "With help from - Matt Kielty", + "classNames": ["c1"], + "footnotes": [], + "order": 11, + "tagName": "p", + "labels": [] + }, + { + "id": "ef86751f-06d3-4468-a2aa-a97dd378438d", + "type": "text", + "html": "

Original music and sound design contributed by - Jeremy Bloom, Annie McEwen, Matt Kielty

", + "text": "Original music and sound design contributed by - Jeremy Bloom, Annie McEwen, Matt Kielty", + "classNames": ["c1"], + "footnotes": [], + "order": 12, + "tagName": "p", + "labels": [] + }, + { + "id": "d42cfb64-3b8a-4b82-b7db-d80b3346f441", + "type": "text", + "html": "

Mixing by - Jeremy Bloom

", + "text": "Mixing by - Jeremy Bloom", + "classNames": ["c1"], + "footnotes": [], + "order": 13, + "tagName": "p", + "labels": [] + }, + { + "id": "82fb6107-bde7-43bf-921b-f310d62c9280", + "type": "text", + "html": "

With dialogue mixing by - Arianne Wack

", + "text": "With dialogue mixing by - Arianne Wack ", + "classNames": ["c1"], + "footnotes": [], + "order": 14, + "tagName": "p", + "labels": [] + }, + { + "id": "bc6bd5f9-a50a-48be-bf2a-fb600a611f99", + "type": "text", + "html": "

Fact-checking by - Diane Kelly

", + "text": "Fact-checking by - Diane Kelly", + "classNames": ["c1"], + "footnotes": [], + "order": 15, + "tagName": "p", + "labels": [] + }, + { + "id": "81b77086-18a6-41a4-8938-888958d53aef", + "type": "text", + "html": "

And edited by - Alex Neason

", + "text": "And edited by - Alex Neason", + "classNames": ["c1"], + "footnotes": [], + "order": 16, + "tagName": "p", + "labels": [] + } + ], + "transcription": [ + { + "html": "

You ready to get into it?

" + }, + { + "html": "

Everybody. Welcome back. Bringing you another amazing interview, hashing it out, interview, doing it the way we love. I'm here solo dolo today. Well, not so well, though. I'm interviewing someone, but as far as hosts go, I'm so low on this one. Today we're going to talk a little bit about centralized messaging.

" + }, + { + "html": "

And I'm joined with Franck Royer, and he wanted it now. He’s a Waku guy. So we're going to call him Waku guy. Before we do that, Franck, because you introduce yourself. To the audience.. So I'll try not to just dive straight into Waku, but I feel like that's the only way to do it, right?

" + }, + { + "html": "

So for those unfamiliar with what Waku is, could you give us like a  quick brief message, like a brief overview of Waku and then we're going to try to peel away the layers and get a little bit deeper. All right. I like that. So it's a if this were to have trouble with an ephemeral communication network.

" + }, + { + "html": "

Okay. So I do know that there's a lot of projects working on decentralized messaging. But when you say decentralized messaging, I don't think a lot of people quite understand what it is and why it's needed. So I guess we could start there. Like what is the centralized messaging in comparison to what people are used to? And then we'll go to the tail end of that question and so yeah.

" + }, + { + "html": "

Mm hmm. So that's the biggest part about it is just removing what we're saying, the centralize or removing the server, its user got it. Many, not many servers, but many different failure points. And then you can't just boot people off, right? If they want a message, they can message. Okay, that's good. Now, I guess moving it to logos, right?

" + }, + { + "html": "

We've mentioned logo several times before on the podcast and guess what? Audience We're going to continue to mention logos because it's what we do. But Wakue was considered one of the foundational projects or logos was that hmm, yeah. Okay. So why is secure ephemeral messaging like so foundational to these decentralized applications? Right? Like, why is this needed? Like, it's absolutely needed.

" + }, + { + "html": "

Oh, we can I was going to ask you that would go straight into some use cases. Let's give us some examples.

" + }, + { + "html": "

All right. So we're back for round two of the Franck interview. I've been saying your name wrong for what appears to be years now. I mean, I've been saying it right as an American, but from way back for round two, I wanted to get a piece of the interview because for those who don't know, I also am peripherally a part of Waku.

" + }, + { + "html": "

And we're actually all are in some way, shape or form. And I have additional context or questions that I'd like to kind of dive into in this. And I think in the first interview, we got a really good foundation as to why Waku exists, what is decentralized messaging, how it fits into the ecosystem and kind of what's wrong with the Internet as it is today.

" + }, + { + "html": "

But I wanted to dive further into some of the details on how it works and maybe some of the tradeoffs as you build up from like Waku Relay into the different protocols that are available that are built on top of Waku relay. So to start, can you give me like the concept of a gossip network, Like what is a gossip network and how are messages passed around this?

" + }, + { + "html": "

So we should probably address the cat in the room here. Jesse has decided that he is now an anon person and would be doing all videos with some virtual avatar and a process of doing that. He's also put up a graphic of a gossip network here, which is basically, if I were to repeat that back to you, a well-connected group of nodes that everyone's connected to all people, you connect to a specific number of people.

" + }, + { + "html": "

So you have a select number of neighbors for gossip sub that is six people. So every person tries to maintain six connections and then when a message gets passed, it passes to it's it passes that message to all of its six neighbors, so on and so forth, until basically the entire network has been saturated with that message. Right.

" + }, + { + "html": "

So that allows some redundancy and some sensors like some censorship resistance, some some resiliency in the network. So if one person goes out, the message still gets routed and saturates the network. And I think that was an important distinction that needs to be made here, is that like Wendy was asking a question in the previous episode, I'm not sure if it'll make it into the air.

" + }, + { + "html": "

It was, I'm sending a message to someone, right? And that's not necessarily what we're doing with Gossip Sub or Whacko. I'm broadcasting a message and someone knows where to listen. I think that's an important distinction to make and add to that more generally speaking, that the tradeoff you're making here is bandwidth consumption or redundancy and computation, like how much work it takes to propagate a message.

" + }, + { + "html": "

And I'll fast that message gets propagated. So if you look at it from each extreme right, if you just start with one, each person maintains one connection in the network, right? That means that you have a very inefficient network in terms of how message gets propagated across right? Because if everyone relays a message, then you basically have to wrap that message to every single person with the in number of hops in being the size of the network.

" + }, + { + "html": "

Right. But there's no redundancy. So basically everyone gets that message once. But if we do the opposite of that and everyone is connected to everyone else, that's a fully connected mesh or fully connected network, then everyone receives that message in a number of times. Basically, they just keep just you just redundantly keep receiving it, but you get it really, really fast.

" + }, + { + "html": "

And so there's a tradeoff somewhere in the middle of like how many how do we maintain the minimum out of connections and message redundancy while maximize what while minimizing the latency, the time it takes to completely saturate the network with that as it's right? And so you're looking for somewhere in the middle so that you get this sense of sender receiver anonymity while also still having some reasonable like latency and bandwidth consumption associated with sending a message.

" + }, + { + "html": "

And so based on those simulations that protocol labs have done, six was a good way. It was a good number. It was the best number they found for Gossip sub, and that's what Waku was built on for gossip. So so now we can assume, you know, we have this, this gossip sub network right. That is what is, what is the difference between the P2P gossip sub and what Waku provides?

" + }, + { + "html": "

Why don't people just use the peer to peer gossip So like, why would they why would they want to use Waku at least like, well, we're going to start with just relay, right? Relay is the kind of foundational protocol for how Waku works. What does that add on top of a gossip sub network? Get them getting. Yeah, there's there's a little subtlety there right.

" + }, + { + "html": "

So like if a if a light client or mobile phone. Right. Can't handle the main network and it wants to try and ask a node for a specific set of messages, there's some level of obfuscating what those messages are right need so they can use bloom Filters are typically the way of doing this, saying I'm I'm looking for messages that look like A, B and C, and the more detailed you are, the more accurate exactly what the more narrowed down the messages you're looking for.

" + }, + { + "html": "

If you're really broad, you can say, give me all the messages that have the word two in them. Or like, you know, something that allows for the node to answer that while not exposing the details of the message to they can't read them, they're just setting encrypted messages. But like there is some level of privacy loss if you're asking for a group of messages because you just said it gives you the IP and whatever whatever you've asked for, they can make that connection.

" + }, + { + "html": "

So if you're routing as a full node and doing full relay and parsing things on, then you've, you've, you've, you, you're not giving me that information. Whenever you ask for whatever messages you're listening to. And that's a layer of good. Now it's a that's a developer choice. So the people who build the applications kind of choose how these content topics could be used.

" + }, + { + "html": "

And eventually we'll have one of the things we're currently working on in doing research and within VAC is kind of automating this sharding or automating the way in which people belong to specific content topic as the network scales out so that you maintain this level of reasonable anonymity or anonymity anonymity while keeping the resources required to do messages low Codex as it stands today and like this is part of ongoing research, is how do we scale walk properly?

" + }, + { + "html": "

Because if you if you can you can misuse these kind of content topics pretty pretty bad. So if you spam the network with a bunch of pictures, then everyone passes things on, it degrades the quality of the network, right? But like, there's ways of like status now currently uses, sends pictures and so on and prior profile settings and a bunch of other things across a crosswalk which are in some cases larger than one megabyte.

" + }, + { + "html": "

So there's a bunch of kind of efficiency tweaks you can do to keep specific media sensible via Waco and, and not like mitigating things whether that you have like this kind of media content shard. So like you just you propagate media through a different part of the network and that's this distinction I think is worth making that developers who are thinking about using Waku should should consider when they're thinking about how to use walk, who is used different.

" + }, + { + "html": "

If you think about a gossip tub topic that's ostensibly a network, that's the entire network. And then if you think about content topics, those are basically contents, right? Those are conversations that are being happened. And so what you're trying to do is strategically use content topics so that you're listening and propagating things you want to do to various people so you can be kind of selective on where you send things and who should be listening to it.

" + }, + { + "html": "

So you're not so not everyone is listening to everything or propagating everything. People are able to kind of pick and choose what they to pay attention to and contribute to when they're when they're contributing to the network. Right? If at some point we can maybe get into like as a if I run a if I run a node, I'm only propagating messages associated with these things because that's what I care about.

" + }, + { + "html": "

That's what I'm trying to support from the network. And so you have a network of nodes that are just doing the work that they think is important while not being inundated with all of the work of the entire network, which allows kind of this large, amorphous network to scale autonomously.

" + }, + { + "html": "

Jesse Yeah, I think that's perfect. And also like Jesse, that's a good analogy for how status plans to use Waku and it's also highlights this kind of optionality that developers have to leverage different classes of topics and content topics to efficiently serve their their users in the way they want to and hopefully pass on those options to them to do things the way they want to.

" + }, + { + "html": "

Like what you just described was status users getting to choose quite a bit of options, not only and potentially who relays messages and the latency versus privacy aspect of it, but also options for incentivization within their own community as well. So we're like by providing options to developers, they're able to choose a lot of pass those options on to their users to then let them do what they want to do.

" + }, + { + "html": "

And I think that's an important aspect of this. They're not pigeonholing people into a specific set of things. We're passing on a lot of options, though. The last point of this that I think we haven't gotten to. One of the protocols built on top of relay is the store protocol. Can you kind of dive into what that is and why it exists?

" + }, + { + "html": "

Jesse Just jumping in…

" + }, + { + "html": "

This is a reasonable place to wrap, I think. What's the what do you want people to do? Like if people listening to you, how do they learn more? What do you want it to go? How do they contribute it? Let it run a walk through node Like what are they like? How do they figure more out

" + }, + { + "html": "

Thanks, Frank.

" + }, + { + "html": "

Frank My bad.

" + } + ], + "channels": [ + { + "name": "youtube", + "url": "https://www.youtube.com/watch?v=vmx_oOb2On0" + }, + { + "name": "apple_podcasts", + "url": "https://podcasts.apple.com/us/podcast/franck-royer-decentralized-messaging/id1376906132?i=1000618673846" + }, + { + "name": "spotify", + "url": "https://open.spotify.com/show/3WkYBYaZ4W1Z8gzBlOvr7y" + }, + { + "name": "google_podcasts", + "url": "https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5zaW1wbGVjYXN0LmNvbS9xd0d2bGoyag/episode/OGQ5ZmE0NzgtMGUxNy00YWIzLTk1NzgtYTNiYTEyMjMwY2Jm?sa=X&ved=0CAUQkfYCahcKEwiwz7SVoeGAAxUAAAAAHQAAAAAQNQ" + } + ], + "coverImage": { + "id": "08bd8535-d7b5-459e-85a0-183feb502e08", + "type": "image", + "alt": "", + "url": "https://images.cdn.unbody.io/00f8908f-9dff-456e-9640-13defd9ae433/image/a04e5542-d027-44d5-b914-bd4cadf17d25_image1.png", + "height": 1223, + "order": 7, + "width": 1999, + "labels": [] }, - "errors": null -} \ No newline at end of file + "show": { + "id": "426d4e4a-98db-5ba2-a9e6-a9d989a34022", + "slug": "hashing-it-out", + "title": "Hashing It Out", + "numberOfEpisodes": 1, + "hosts": [ + { + "name": "Host", + "emailAddress": "host@gmail.com" + } + ], + "url": "/podcasts/hashing-it-out", + "description": "", + "logo": { + "alt": "", + "url": "https://images.cdn.unbody.io/00f8908f-9dff-456e-9640-13defd9ae433/image/d4ecc97f-bcef-411d-b31a-639261623b25_image1.png", + "width": 1999, + "height": 1123 + }, + "episodes": [] + }, + "featured": false, + "highlighted": false + }, + "errors": null +}