Relaxing treatment of non-notes by Mastodon
-
samsethi@podcastindex.socialreplied to thisismissem@hachyderm.io on last edited by
@thisismissem @pfefferle @julian @hongminhee @johnonolan We wanted to originally publish the activity out of Truefans using the Summary verb but it marked everything as sensitive. After some digging and help from the AP community it was a known bug so we switched to using Notes. We also tried the Listen verb but that didn't work in Mastodon or clones so we abandoned that idea. TreuFans will now build our own full AP client and support the verbs and display them correctly in our app.
-
julian@community.nodebb.orgreplied to samsethi@podcastindex.social on last edited by
@samsethi@podcastindex.social open to supporting
as:Listen
if you publish it. Can you send me a sample activity, and what you expect? Embedded audio player, etc? -
samsethi@podcastindex.socialreplied to julian@community.nodebb.org on last edited by
@julian thanks, Yes an embed player so users can hear a clip in situ. I am not sure we want users to hear the full podcast episode in the AP client.
-
jenniferplusplus@hachyderm.ioreplied to samsethi@podcastindex.social on last edited by
@samsethi @julian this seems like a weird expectation to me. As:Listen is an activity. It's a thing that the (sending) actor did, or is doing. It would make sense to put an audio clip in an audio object, but not directly in a listen activity.
Anyway, since I'm not building a podcast app, I would be inclined to interpret a listen activity as a kind of presence update. Like an AIM away message. If you want something like a share or recommendation, I would expect that to be an announce activity
-
julian@community.nodebb.orgreplied to jenniferplusplus@hachyderm.io on last edited by
@jenniferplusplus@hachyderm.io @samsethi@podcastindex.social yeah,
as:Listen(object)
or some such.I'd have to refactor a bit since my code pretty much expects either Announce or Create, but it's for the better anyway.
-
johnonolan@mastodon.xyzreplied to lkanies@hachyderm.io on last edited by
@lkanies @thisismissem @julian @hongminhee @pfefferle and I think this reasoning has been explained to you in some detail by several people. Hopefully you can see that
-
lkanies@hachyderm.ioreplied to johnonolan@mastodon.xyz on last edited by
@johnonolan @thisismissem @julian @hongminhee @pfefferle definitely a situation where neither of us is convincing the other โ๏ธ. But Iโm just some guy with opinions on the internet (and experience in other OSS projects). My opinions deserve no weight here, so I will slink away
-
silverpill@mitra.socialreplied to jenniferplusplus@hachyderm.io on last edited by
@jenniferplusplus @samsethi @julian Pleroma uses
Listen
activities to display "currently listening" status: https://docs-develop.pleroma.social/backend/development/API/pleroma_api/#get-apiv1pleromaaccountsidscrobbles
I think this activity can also be used for counting podcast listeners. -
julian@community.nodebb.orgreplied to silverpill@mitra.social on last edited by
@silverpill@mitra.social Very cool, thank you!
Hopefully @samsethi@podcastindex.social will reconsider and perhaps federate out
as:Listen
in addition -
samsethi@podcastindex.socialreplied to julian@community.nodebb.org on last edited by
@julian @silverpill we will we have two more changes ot make to our AP client tomorrow. We just enabled any AP user/client to follow any podcast and get their new episode, play, comment etc actvitiy. But next week we will publish with the listen verb for clips and see what happens ... thank you
-
tennoseremel@lor.shreplied to julian@community.nodebb.org on last edited by
@julian // There is no target="_top", only target="_blank". Well, you can use _top, but it is just a normal name and any new link opened will replace a page previously opened, which will likely be not what a user wanted.
-
dariusk@community.nodebb.orgreplied to julian@community.nodebb.org on last edited by
Just coming across this now, hello everyone -- I wanted to say that Hometown has implemented what @julian proposes in the OP for its entire existence, since about 2019. It's worked quite well!
More content types
A supported fork of Mastodon that provides local posting and a wider range of content types. - More content types ยท hometown-fork/hometown Wiki
GitHub (github.com)
-
julian@community.nodebb.orgreplied to dariusk@community.nodebb.org on last edited by
@dariusk @darius@friend.camp Thanks for sharing this, I think it's fantastic that this is already adopted in a Mastodon fork.
May I ask whether there have been attempts in the past to get these changes back upstream to Mastodon?
-
dariusk@community.nodebb.orgreplied to julian@community.nodebb.org on last edited by
@julian This was ~4 years ago but I asked someone on the team (I forget who) if it would be a welcome PR and I was told that it probably wouldn't be, so I didn't make the PR.
Of course that was a long time ago! Also of note, this was completely and totally a hack and I don't think my actual implementation is what I would want to put upstream at this point. What's more interesting is that it hasn't been the cause of any UI concerns; basically what you postulate above, that the "hide long content behind a cut" functionality pretty much solves the problem, is true.
-
julian@community.nodebb.orgreplied to dariusk@community.nodebb.org on last edited by
@dariusk I may be overly optimistic, but I'd like to move forward thinking that perhaps that was then and this is now.
Let's chat tomorrow (?) about the merits of your implementation and see whether we can make some waves!