Discussion for podcast:socialInteract tag

[dellagustin]

Related issues

• Proposal - ⚡️ Lightning Comments #347
• Cross-app comments: a crazy idea for easier uptake #327

Related links and References

• Structure update announcement by @daveajones on March 26th, 2022 - https://podcastindex.social/@dave/108024659993951728
• Podcasting 2.0 Dev Meetings
  • March 26 2022 Part 1 of 1
  • March 26 2022 Part 1 of 2
• RSS 2.0 comments tag - definition - usage example - for historical reasons

[dellagustin]

Hello @daveajones , I created this issue for discussion on the podcast:socialInteract tag.
The Phase 5 entry on the README.md file currently points to #327 as discussion issue, but that issue has a bigger scope then just the tag and I see it more as a supporting issue for discussing the tag itself, and it could be hard to follow due to its long history. Would you please consider using this issue instead?

[dellagustin]

Subject: tag name, socialInteract vs comments

Hello All,

I have missed the dev meeting mentioned by @dave on his announcement on March 26th, was it recorded?
Update: Yes => #357 (comment)

I have one fundamental question about the socialInteract tag.
I understand it stems from the podcast:social spec proposal, and originally had a broader scope:

This element allows listeners to interact with (comment, share, like, review…) an episode, or a podcast.

The currently proposed scope is focused on comments. There are some social interactions inherited from the comment platforms we have in mind (e.g. like, retweet, bookmark for twitter, favorite, boost, bookmark for mastodon...).

I have the feeling the intent and use case would be better represented if we renamed the tag to podcast:comments. I'm sure this was already discussed before elsewhere , but I could not find such discussion.

[dellagustin]

Subject: redundancy on the attributes accountId and accountUrl

We currently have 3 protocols under consideration, ActivityPub, Twitter and Lightning. For lightning, as far as I know, the attributes accountId and accountUrl would not be meaninful. For ActivityPub and Twitter, the account that posted the Root Post could be determined from the Root Post URL (either by "decoding" the URL, if the format is known, or by fetching the URL according to the API that corresponds to the protocol). That makes accountId and accountUrl redundandant.

Do we have use cases that justify this redundancy? Given that these are not required attributes, unless we have clear use cases that justify the redundancy, I would suggest to keep them out of a first version for the tag. They can always be added later in a backwards compatible way if needed.

[benjaminbellamy]

I have the feeling the intent and use case would be better represented if we renamed the tag to podcast:comments. I'm sure this was already discussed before elsewhere , but I could not find such discussion.

Interactions can have several forms: comment, share, like.

ActivityPub allows us to create new ones (even though these three seem to be enough… for now 😉).

I would stick to socialInteract if you ask me.

[benjaminbellamy]

I have missed the dev meeting mentioned by @dave on his announcement on March 26th, was it recorded?

They're all here:
https://noagendatube.com/accounts/brianoflondon/video-channels

[benjaminbellamy]

We currently have 3 protocols under consideration, ActivityPub, Twitter and Lightning. For lightning, as far as I know, the attributes accountId and accountUrl would not be meaninful. For ActivityPub and Twitter, the account that posted the Root Post could be determined from the Root Post URL (either by "decoding" the URL, if the format is known, or by fetching the URL according to the API that corresponds to the protocol). That makes accountId and accountUrl redundandant.

Do we have use cases that justify this redundancy? Given that these are not required attributes, unless we have clear use cases that justify the redundancy, I would suggest to keep them out of a first version for the tag. They can always be added later in a backwards compatible way if needed.

The idea here is to make sure that things are super simple for podcast apps.

We want them to show interactions even if they don't understand 100% of how these protocols work.

Moreover, all ActivityPub networks don't have the same URL patterns: for instance Mastodon and Castopod add a "@" before the account handle, PeerTube and PixelFed do not.

Adding one extra field costs nothing and is useful.
Not having this extra field will cause pain all around the world and I do not want to be responsible for that. 😬

[dellagustin]

I have the feeling the intent and use case would be better represented if we renamed the tag to podcast:comments. I'm sure this was already discussed before elsewhere , but I could not find such discussion.

Interactions can have several forms: comment, share, like.

ActivityPub allows us to create new ones (even though these three seem to be enough… for now 😉).

I would stick to socialInteract if you ask me.

Hello @benjaminbellamy , I understand that more interactions are possible, but as mentioned in my original message (#357 (comment)) the main intent is to allow commenting - liking and sharing (Boost in Mastodon vocabulary, Announce in ActivityPub[1]) seem to be a happy side effect. Anyway, I still feel divided with this topic and I can live with socialInteract.

[1] - https://docs.joinmastodon.org/spec/activitypub/

[dellagustin]

Subject: redundancy on the attributes accountId and accountUrl
Reply to #357 (comment)

The idea here is to make sure that things are super simple for podcast apps.

We want them to show interactions even if they don't understand 100% of how these protocols work.

My reason for asking is that, as an podcast aggregator/player dev, I don't know what to do with those attributes. I would not show anything based on them before fetching the replies of the root post, so they would be useless to me.

Are there any concrete use case for the accountId and accountUrl attributes?

either by "decoding" the URL, if the format is known
Moreover, all ActivityPub networks don't have the same URL patterns: for instance Mastodon and Castopod add a "@" before the account handle, PeerTube and PixelFed do not.

I think I was considering only twitter here when I spoke about decoding the URL, but for ActivityPub, once the root post is fetched the account that posted it will come with the root post, as far as I know.

[daveajones]

@dellagustin Yes we have discussed these issue quite in depth. We mainly discussed them in the second to last dev meeting. I think this was it:

Dev meeting recording

@johnspurlock would probably have a better summation on why the accountId and accountUrl can’t be removed if it’s not clear from the meeting discussion.

On the idea of changing the name, we have thrown this around too. In the end we decided the word “comments” had potential conflict with other things possible in the future and this is, after all, a sub-tag of podcast:social in function. I don’t really care much about naming. Rules For Standards Makers says:

“It totally doesn't matter what we call it. We can learn to use anything. There are more important things to spend time on.

Think of people whose first language isn't English. To them the names we choose are symbols, they don't connote anything.”

I agree with that 100%. After all, ActivityPub is a terrible name that doesn’t mean much, but we still know what it’s supposed to do.

[johnspurlock]

Thanks for creating a new issue focused on finalizing the tag, agree this is better than those other two threads. @daveajones , maybe GH discussions would be more appropriate for these?

• <podcast:socialInteract> vs <podcast:comments>: I don't have strong opinions on this, so I've been deferring to others with strong opinions. As mentioned above, commenting does not necessarily encompass all of the interactions that can flow over the channel (likes/retweets/comments/ratings/reviews), but the camel case socialInteract is grating to look at and to type. Perhaps interact would be better? Again I don't care too much since these tags are 99.999% generated/consumed by tools, not by humans (except us) - and it's probably most important for tag names to be crystal clear on definition/scope vs raw length. If the other proposed tags <podcast:social> or <podcast:socialSignUp> end up getting included in the namespace in the future, the social prefix becomes "namespace with a namespace" to group these (i.e. "the tags related to external social media systems").

• accountId/accountUrl: They are optional, and as you say, usually redundant for developers that can introspect the root post url and derive the attributed-to entity. I don't use them currently, but here are three arguments for them I can think of:

1. Feed is the source of truth for something as important as declaring an external identity (what if the comment post is hacked etc)
2. Required when the identity of the root post entity is not the podcaster itself, which may come up in a shared hosting environment (or a podcast network / group of people), or any system that autogenerates them.
3. Useful when a podcast app hasn't or can't or won't implement a protocol, and thus cannot derive it. The url in particular is a fallback for the external podcast entity on that external system

[theDanielJLewis]

About the name of the tag, I also don't like the camel-case socialInteract. I think comments, discussion, or engage/engagement could be better.

[yassinedoghri]

Hey all, thanks for the thread!

I think that ultimately, the term discussion as proposed by @theDanielJLewis is the best choice.

Here's my reasoning:

👉 Originally, the tag in itself was created to reference a place to discuss an episode.
👉 Whether it is on Twitter / Mastodon / Fediverse (with ActivityPub) shouldn't really matter.

So, with that in mind:

• socialInteract, interact, engage or engagement are too vague for what it is.
• comments is to specific --> one would expect a list of comments as value for example.

--> <podcast:discussion> is the way to go.

[benjaminbellamy]

I agree with @yassinedoghri!
+1 for <podcast:discussion>