Favorites for Albums, Artists

It might be nice if we could lean on the Musicbrainz API to connect things like Wikipedia links to grab info about artists and albums, maybe also links to stores.

I want playback position sync, which would be a base to remote-control another listening session

6 days later

To do this can we proced as follow ?

For new api endpoints :

  • we create the views and reffence them in a urlV2.py file
  • when we abandon V1 we only have to merge urlV2.py with url.py

For changed api behaviour :

  • we create another view with the same name has tthe old one but we add V2 suffix. Oldwiewset OldwiewsetV2
  • we reference the V2 views in urlV2.py

This will mostly induce this change on our config :

config.api_urls.py

v2_patterns += [
    url(
        r"^federation/",
        include(("funkwhale_api.federation.api_urlsV2", "federation"), namespace="federation"),
    )
]

urlpatterns = [
    url(r"^v1/", include((v1_patterns, "v1"), namespace="v1")),
    url(r"^v2/", include((v2_patterns, "v2"), namespace="v2"))

What do you think ?

ps : there is a related gitlab issue here : https://dev.funkwhale.audio/funkwhale/funkwhale/-/issues/1808

Maybe playback position sync can be used with a gpodder compatible API, this way antennapod could sync the position on android and Kasts on Desktop.

    Hi all,
    Just chipping in as gcrk pointed me (indirectly) to this thread in a conversation on Mastodon

    Personally I think Funkwhale's potential is on the side of the media consumer, rather than that of the publisher (podcaster). The latter would be possible too, building on the functionality of 'channels'. But given that developments in that area go fast and that there already is an open source project that fulfils that role perfectly (Castopod) I don't think it's worth pursuing that. The former (consumer) is also where the option to synchronise playback position is relevant. So I guess Georg was thinking in that direction anyway 🙂

    So, focussing on the consumer side, what would Funkwhale's role be then; client or server? E.g. if it was supposed to synchronise with the AntennaPod app, do you envision Funkwhale to be

    • the 'server' where the data is stored, the central point through which listening progress is synchronised
    • the 'client' through which podcasts can be viewed/subscribed to, and episodes can be played (like AntennaPod)
    • both; 2-in-1

    Given that there already is an interface for playback plus a way to follow RSS-feeds, I reckon there's a (very) solid base for the 'client' part. But depending on the state of the back-end which makes this client role possible, the step to 'server' might not be far away either.

    Then, in the context of APIs, I think it's a question of functionality: what (client) features might be there, what might be missing (if anything, I'm not fully up to speed with the FW functionality).

    That discussion about (synchronisation) functionality and the necessary APIs is what we (over at AntennaPod) will be having quite soon (mid-October). We're reaching out to other client and server projects to get their input, to see if we could agree on a successor of the gPodder API (the field has advanced a bit since then, and we want a new standard to be app-agnostic). In fact, Funkwhale was one of the projects that we wanted to reach out to, so the timing of your discussion and Georg's toot couldn't be better. Once we have a datepicker, I'll share it here as well so that interested folks can fill it in & join the call.

    (I realise this is quite a long post that focuses really on podcasting, though FW APIs would probably need to be able to do much more than that. So feel free to move my post to a new thread 🙂 )

    • gcrk replied to this.

        keunes Personally I think Funkwhale's potential is on the side of the media consumer, rather than that of the publisher (podcaster). The latter would be possible too, building on the functionality of 'channels'. But given that developments in that area go fast and that there already is an open source project that fulfils that role perfectly (Castopod) I don't think it's worth pursuing that. The former (consumer) is also where the option to synchronise playback position is relevant. So I guess Georg was thinking in that direction anyway 🙂

        I actually did, but its just because I am a consumer, not a podcaster and I lack the insights there. From the idea of Funkwhale, being an audio publication platform, publishing podcasts fits in as well and I don't mind thinking about how to improve there as well. Even if Castopod is around, its always good to have an alternative. I am a bit skeptical about Castodpod anyways because of their investment in Crypto, and others might be as well. I wouldn't mind agreeing with them on a common API spec, though.

            gcrk Even if Castopod is around, its always good to have an alternative.

            Very true :-) That focus on one or the other is something the FW community needs to make. So I'm curious what direction(s) FW will take!

            gcrk I am a bit skeptical about Castodpod anyways because of their investment in Crypto, and others might be as well.

            I am skeptical of cryptocurrencies as well, mainly for environmental reasons. But I hope that a project's involvement in that area won't be a reason for folks to completely ignore that project's work. (Personally I feel crypto ≠ attacks on human rights like racism would be. So for me I don't see a ground to block all collaboration.)

            With the risk of sounding/being defensive:
            There's much to gain also: Using Castopod you don't have to use the crypto features, but can benefit from great ActivityPub integration, as well as RSS features like 'transcript' that could help the hard-hearing, 'location' that could make content discoverable by travellers, 'person' that could help make hosts and guests from marginalised communities more visible & easier to discover.

            gcrk I wouldn't mind agreeing with them on a common API spec, though.

            Glad to hear :-) (Side note: our API spec focuses on the consumer side, so Castopod wouldn't be involved. But there are other players on the consumer side that are involved in crypto, which might or not also get involved at some point in the API spec.)

                    keunes I am skeptical of cryptocurrencies as well, mainly for environmental reasons. But I hope that a project's involvement in that area won't be a reason for folks to completely ignore that project's work. (Personally I feel crypto ≠ attacks on human rights like racism would be. So for me I don't see a ground to block all collaboration.)

                    I didn't make an argument to block the collaboration, I actually tried to have a call with the castopod people a few months ago, but it didn't worked out. I just wanted to point out a reason why one might not want to use castopod and having an alternative is a good idea. There could be other reasons: Castopods development stops, license issues, social troubles. So even if there is something out there doing a great job, we can work on another implementation.

                    keunes There's much to gain also: Using Castopod you don't have to use the crypto features, but can benefit from great ActivityPub integration, as well as RSS features like 'transcript' that could help the hard-hearing, 'location' that could make content discoverable by travellers, 'person' that could help make hosts and guests from marginalised communities more visible & easier to discover.

                    Yes, the Community did a great job and did quite some innovation, which is amazing and probably not possible in the scope of Funkwhale, since we maintain a huge codebase with a lot of other features and its not too easy for us to do experiments. So I am happy to leave the innovation part of the business to them, but we can consider some of those features to be valuable for Funkwhale as well.

                    On the other side it might be a path to remove the publishing of Podcasts from Funkwhale altogether, focusing on consuming podcasts. But I don't think this is something we want to do.

                    keunes Glad to hear :-) (Side note: our API spec focuses on the consumer side, so Castopod wouldn't be involved. But there are other players on the consumer side that are involved in crypto, which might or not also get involved at some point in the API spec.)

                    I wouldn't mind if those bits are optional and we are able to just ignore this.

                          I have little to no knowledge about podcast but I will be glad to read your conclusions and implement the endpoints to ApiV2 of funkwhale if its needed o/

                          For API v2 I would like to consider endpoints to solve the usability issues related to library management1.

                          We would need to allow people to:

                          • push content once
                          • store all music in a single bucket
                          • rename uploaded files, sort them, and edit their metadata
                          • group any track, album, or playlist with others, for organizing
                          • associate permissions with any with any group or item, for sharing
                          • add any group shared with them to their library

                            keunes Thanks for the invite : )
                            Though I don't know the technical details, I added myself to the poll.

                                mjourdan
                                I'm sorry I don't get a lot of things :s

                                • what do you mean by push, upload ?
                                • why do you mean by bucket ? You want to access all music owned by user ?
                                • I don't get how and why we would like to group albums and playlist : you want a page with selected albums or selected playlist ? Group tracks for me it's done in a playlist but is there another way to do it ?
                                • we have groups in funkwhale ? like family, friends etc ? What other items than libraries are you thinking about (tracks, album, artist) ?

                                    petitminion fair questions!

                                    Yes, by "push" I mean upload. By bucket I mean the datastore or whatever: the place where content will be kept. Those two things are necessary to solve the limitations of libraries. See uploading and organizing user stories as described in epic1 for more details.

                                    Organizing the library into collections of (somehow related) albums and playlists is essentially one half of what libraries are used for. Mockup in #1448 illustrates how it could be done in a much more straightforward way than what we currently have with libraries.

                                    By group I meant collections, as above. Ie I was speaking of following remote libraries replacement so that they would appear in your own library, alongside the content you uploaded yourself.

                                    I Hope this is clearer : )

                                        mjourdan Yes, by "push" I mean upload. By bucket I mean the datastore or whatever: the place where content will be kept. Those two things are necessary to solve the limitations of libraries. See uploading and organizing user stories as described in epic1 for more details.

                                        You are suggesting a way to upload all file in a general bucket/folder, then a way o dispatch theses files between libraries/subfolders ?

                                        mjourdan Organizing the library into collections of (somehow related) albums and playlists is essentially one half of what libraries are used for. Mockup in #1448 illustrates how it could be done in a much more straightforward way than what we currently have with libraries.

                                        Okey so, libraries would be for rights management (everything in this library is open to all pod, only to this pod or only to me) and for personal content only. While collections would be a personal way to organize and navigate through all the content a user own or follow.

                                        Thanks for the calrifications ! 🙂 I think we need a specific thread about this because its very important and could induce a lot of changes. Is there a forum thread already or only the gitlab epic ?