Proposal: <podcast:chat> tag

[daveajones]

Proposal: <podcast:chat> tag

Purpose

The <podcast:chat> tag allows a podcaster to attach information to either the channel or an item about where the
"official" chat for either the podcast or a specific episode is to be found. Just like <podcast:socialInteract>
functions for social media, the chat tag will function for ephemeral chat. There are many protocols in use across
the internet for chat based communication. This tag is meant to be flexible enough to adapt to whichever protocol the
podcaster wants to use.

This tag can exist at the channel or item level. It's presence at a particular level governs how it should be
treated. If found at the item level, this should be treated as the information for that specific episode,
overriding what is at the channel level. If this tag is found at the channel level, it would be considered the
chat for the entire podcast and is recommended to be an "always on" chat room experience.

If a podcast has an "always on" style chat service it is recommended to link that at the channel level and do not
use the <podcast:chat> tag at the item level.

Chat Element

<podcast:chat>

Parent

  <podcast:liveItem>

Count

  Single

Attributes

• protocol (required) The protocol in use on the server.
• accountId (recommended) The account id of the podcaster on the server or platform being connected to.
• server (optional) The fqdn of a chat server that serves as the "bootstrap" server to connect to.
• space (optional) Some chat systems have a notion of a chat "space" or "room" or "topic". This attribute will serve
  that purpose.
• embedUrl (optional) A url to an html rendered version of the chat for loading in a web page or web view.

Example (IRC):

<podcast:chat 
    server="irc.zeronode.net" 
    protocol="irc" 
    accountId="@jsmith" 
    space="#myawesomepodcast" 
    embedUrl="https://map.example.org/chat/iframe.html"
/>

Example (XMPP):

<podcast:chat 
    server="jabber.example.com"
    protocol="xmpp"
    accountId="[email protected]" 
    space="[email protected]" 
/>

Example (Nostr):

<podcast:chat 
    server="relay.example.com" 
    protocol="nostr" 
    accountId="npub1pvdw7mm7k20t9dn9gful8n5xua5yv8rmgd9wul88qq5dxj80lpxqd39r3u"
    space="#myawesomepodcast_episode129" 
/>

Example (Matrix):

<podcast:chat 
    server="jupiterbroadcasting.com"
    protocol="matrix"
    accountId="@chrislas:jupiterbroadcasting.com”
    space="#general:jupiterbroadcasting.com" 
/>

Full proposal doc:

• https://github.com/Podcastindex-org/podcast-namespace/blob/main/proposal-docs/chat/social.md

[theDanielJLewis]

I think this should be limited to only LIT. Otherwise, this becomes yet a third P2.0 place where conversation happens (Boostagrams, cross-app comments, and now this).

How will this handle web-embedded chats, like from Chatroll, YouTube Live, and such?

(I'd much rather we focus on cross-app comments before live chat.)

[daveajones]

I think this should be limited to only LIT. Otherwise, this becomes yet a third P2.0 place where conversation happens (Boostagrams, cross-app comments, and now this).

I can see restricting it to <channel> more than <podcast:liveItem>. The reality is there are more than a few podcasts out there that have 24/7 chat rooms attached to them.

[thebells1111]

Chat is fundamentally about real time communication so is a very different experience than comments.

A chat room is awesome during a live show, but doesn't need to be limited to a live show.

Imagine having a listening party scheduled for Friday at 6pm, when a lot of people finally get off of work and all agree to listen to the show at the same time. Even though it's not technically live, the people in the chat are able to communicate with each other in real time while having a shared experience.

Or maybe there's a tribe built around a podcast, and people want to just get together and chat, and the podcast has a chatroom setup to connect the tribe.

Chat accomplishes the real time element much better than comments do. It's like asking why text message when email works just as well, and at it's core, you're just sending a message to someone. Well, they're different experiences, that's why.

[genebean]

@daveajones matrix example:

<podcast:chat 
    server="jupiterbroadcasting.com"
    protocol="matrix"
    accountId="@chrislas:jupiterbroadcasting.com”
    space="#general:jupiterbroadcasting.com" 
/>

This follows your layout but would more logically (to me) be something like this as matrix includes rooms within spaces:

<podcast:chat 
    server="jupiterbroadcasting.com"
    protocol="matrix"
    accountId="@chrislas:jupiterbroadcasting.com”
    room="#general:jupiterbroadcasting.com" 
    space=“https://matrix.to/#/#jupiter-broadcasting-space:matrix.org”
    link=“https://matrix.to/#/#general:jupiterbroadcasting.com”
/>

I used a real room in a real matrix space as an example so others could see how this translates in more than just theory. The JB crew promotes their matrix a lot too so it’s a good example of a 24/7 room. More details at https://www.jupiterbroadcasting.com/community/matrix/

[daveajones]

What function does "link" serve?

[dhk2]

If a client app doesn't know how to programmatically deal with a particular chat protocol, they can send the user off to the link to access the chat.

I'm not seeing any particular value in adding the matrix "space" value when the tag is for referencing a specific chat room.

Though "space" as defined in the spec seems needlessly abstracting when 90%+ of chat apps call it a "room"

Agree with agates that Server should not be requires since many protocols include it in the room name. IE A minimal functional matrix entry should just be

<podcast:chat 
     protocol="matrix"
     space="#general:jupiterbroadcasting.com" 
/>

Or a one off webchat some podcaster developed on their own could be referenced with.

<podcast:chat 
     protocol="custom"
     link="https://aweseomepodcast.org/webchat" 
/>

[genebean]

Here’s a Discord example too:

<podcast:chat 
    server="https://discord.gg/U3Gvr54VRp"
    protocol="discord"
    accountId="alexztz”
    space="#lounge" 
/>

This is for Self Hosted

[jamescridland]

So... now we have...

• Boostagrams - a way for listeners to send comments to podcast hosts, while supporting them with sats
• Cross-app comments - a way for listeners to send comments to podcast hosts, while not supporting them with sats
• Chat - a way for listeners to send comments to podcast hosts, while not supporting them with sats and being impermanent

Sorry to be Debbie Downer on this, but all we need is one more messaging system, and we turn full Google.

I would agree with Daniel that, if we're really going to look at another form of messaging, we limit this only to live streams.

[adamc199]

I would be delighted to have comments and chat implemented the way Fountain does it across the board based on boostagrams.
No one else seems to want to implement. I don't know why. All I read here about that is "Privacy issues" and "Moderation Issues".

Neither have been a problem for me.

Boostagrams work just fine with IRC chat and the boostbot in the LIT environment and are a huge value driver, codifying how chat works doesn't change that and our chat runs 24/7, not just during live shows.

Ultimately, whatever devs choose to build matters. Not what is determined to be "Live only" on github.

Can't put the cart before the horse.

[jamescridland]

Another point to make: how sensible is a live chat service for most podcasts? I suspect that live chat works for the top 1% of podcasts. Absolutely, it'll work for No Agenda; it'll possibly work for Podcasting 2.0; but for the majority of shows, it just simply won't work. Data from Buzzsprout:

Even per-episode comments are pushing it for many shows. I'm keen to avoid the "empty pub" scenario. Podnews's daily podcast - consumption data here - seems to have no per-episode comments at all. That's partly of course because I'm not asking for them; but also I suspect a typical per-episode download figure of about 2,000 really doesn't give enough people to comment on an individual episode. And Podnews is in the top 5%.

Those wanting ephemeral live chat as a separate thing seem to misunderstand the point of podcasts: that they're on demand. Timezones don't always work. Listeners have other lives.

I'd like to see cross-app comments for shows, with the ability to split that into episodes if the creator wants (put the element in the channel tag normally, but shift it into the item tag if you want to have per-episode comments).

To look at a live chat service seems pointless for 99% of all podcasts - inescapably, they don't have the numbers to make it succeed.

[dhk2]

Even if only useful to the top 99% of popular podcasts, due to that very popularity it will be useful for the preponderance of podcast listeners.

My experience with the Matrix community around Jupiter Broadcasting's podcasts makes me think you are greatly overestimating the podcast size needed to benefit from a chat. Probably highly variable around the type of podcast and listener demographics.

[thebells1111]

Talk to Behind the Sch3m3s and Bowl After Bowl to see how valuable chat is for even a very small community. Chat isn't about numbers, it's about community. A small community that loves the podcast can provide enough value for the podcasters to be sustainable, and chat can be a huge part of that.

[adamc199]

Chat is not comments

The noagenda stream irc chat is very beneficial to even the smallest of shows. Especially in V4V the numbers are much bigger than you think.

Chats often have extra functionality, like boost bots and ISO generators. Different sounds getting fired off from different boost amounts.

I will actually argue that a smaller chat like Behind the Sch3m3s is more fun than No Agenda with 2000 participants.

These chats often go on 24 hours a day even when the podcast is not live.

[daveajones]

Hopefully I can clear up some confusion. There are 3 items at play currently in the namespace:

• Comments (cross-app, un-paid)
• Boostagrams (payment based)
• Chat (live, un-paid)

Those three things cover the bases of what is needed for a live, fully immersive experience like you would find on YT and other places. The Comments live "forever", the Boostagrams deliver bits of money to the creator and the Chat is ephemeral/replayable.

The chat tag isn't yet another chat type system. It's part of the 3 legs that get us to the superchat finish line.

[daveajones]

[theDanielJLewis]

Also keep in mind that boostagrams could cross-post to both chat and comments.

[ryan-lp]

There are many protocols in use across the internet for chat based communication. This tag is meant to be flexible enough to adapt to whichever protocol the podcaster wants to use.

My concern is that this doesn't really consider the impact on the app developer. I'm not sure if it is desirable for app developers to implement a growing number of different chat protocols, for each of iOS/Android/web where an app has been ported to multiple platforms. I wouldn't want to implement 7 protocols, and I also wouldn't want to increase the app size as a result, since that increases app build times, app download times, install times, memory usage, surface area for bugs, development time, testing time, etc. etc.

I would have no problem with supporting multiple protocols if either:

1. There is negligible overhead to implementing the additional protocols, or
2. each protocol serves a specific real world need.

I'm not sure if we have either here, but I would like to be convinced.

I think rather than making the goal to support "whichever" protocol the podcaster wants to use, which is rather open ended, a standards body should be setting the standard so that podcasters actually know which protocol to use, and apps know which protocol to implement. The real goal is not to integrate with every existing chat deployment under the sun (e.g. a podcaster happens to have an existing Discord server and so apps must support a way to integrate with that and every other possibility). The real goal is not that, but rather, to provide a well-integrated in-app chat experience FOR the podcast app itself. And for that, you don't need support for all protocols, you only need support for one.

A similar issue arises with having multiple file formats for the same thing when that set is open ended. If the set of protocols and file formats is open ended, apps will be encouraged to have the most support for the most formats and the most protocols (except in cases where there is little overhead) which is a wasted effort and will lead to bloat. And if a podcast happens to use a chat protocol that a particular app doesn't support, this will be a poor user experience and users will submit poor reviews to reflect that.

If a client app doesn't know how to programmatically deal with a particular chat protocol, they can send the user off to the link to access the chat.

A link would also be a poor user experience compared to in-app chat, but in-app chat will only be realistic if we can agree on a standard set of protocols that should be supported (ideally "one" protocol). Also, links may work for modern chat systems like Discord, although I don't think the old-school protocols like IRC were really designed with hyperlinks in mind, considering that the invention of IRC predates the invention of the world wide web. Or, while it is possible for an IRC server to expose an interface on port 80 or 443, I don't think you can universally rely on such a link being available to use as the target of the link attribute.

(Please take my thoughts above with a grain of salt. I'm probably not the intended audience for this feature. As a listener, I wouldn't use it, so from that perspective I have no stake in it. But as a developer, I would rather see a fewer, not greater, number of standard protocols and file formats unless there is little overhead or a real-world need can be demonstrated.)

P.S. Another kind of bloat that stems from this is the bloat to the RSS feed, particularly if this is added per item. Unless we keep this in check, it will stress bandwidth, storage requirements, download times, crawler efficiency, parser CPU usage, etc. impacting on speed and monetary costs. Maybe pagination is important to get in place first in order to cope with bloated feeds. I think there are more fundamental things to get in order before chat, IMHO. (Including fixing issues with existing tags.) It would give you a chance to ensure that new tags are well thought out before formalising them.

[jmazzahacks]

Initial thoughts, chatrooms like IRC don't have have an off switch. Even if in the app we just said "LIT" only, that's not going to turn off a irc channel, end existing chat sessions or prevent others from joining through 3rd party clients. (Unless a podcaster wants to spin up special "per show" IRC channels, and get really fancy)

I think we need room / freedom to experiment and see what shakes out.

Now if I could just find that old -cDc- IRC script...

[johnspurlock]

For IRC, you need server (required), port (optional), and tls (optional boolean)

Some irc servers I've already seen in podcast feeds do not support tls, and although there are default ports for tls vs not, the port number can't be assumed in all cases either (ie servers should have the option to run on non-default ports).

[theDanielJLewis]

(Can you tell I'm finally catching up on old threads?)

What if we make this tag have two potential options?

1. IRC
2. Embedded (probably limited to iframes to prevent JavaScript security concerns)