@boopboop is writing a welcome guide for developers building in the Resonate ecosystem!
This is a coordination thread for the task until the guide is ready to go. Then I’ll add it to the Handbook and we can add a link on Github (or vice versa if that makes more sense for the devs)
just FYI, my goal on this would be to encourage the reader to work on their own projects and keep the community informed and engaged, not to work on the resonate platform itself (aside from ones tagged as open to volunteers on github).
The process of working on the platform itself, aside from those pre-masticated issues on github, requires a lot more social effort than what a weekend warrior would be able to offer, just due to time constraints. If our weekend warrior is able to work on something on the roadmap, however, then they’d know the platform well enough (at least in theory) to be able to pitch in.
@brndnkng any feedback on ideas / inspirations for the ecosystem developer building for the listener?
This is what I put but this is placeholder:
Example projects that we would be interested in:
Any sort of prototype mobile streaming app (get wierd with the aesthetic)
Chat app integrations
Track curation tools
A stand-alone playlist explorer
example ecosystem project could be pretty much anything, if someone wants a random song to play every time the use their smart microwave that would count, or some people have very specific UI preferences for their music apps, or me struggling to find anything on the platform (so i made this)
hey @boopboop thank you soo much for drafting this up! feel like it’s v clear and makes it easy for ppl regardless of engagement so far to plug in.
in terms of ecosystem ideas for the listener, i def believe we could make space to brainstorm more at our next @community team meeting.
but yeah, i feel like there’s a couple of things ecosystem related that could enhance the listeners experience/community connection
listener dashboard (profile w/ ability to share fav music on player & interests w/ others utilizing player) similar to early myspace
logging and tracking streams (scrobbles) last.fm style plug-in —connecting to community forum and listeners finding one another based on similar music interests based on tracked streams (optional ofc) also may could be used in tandem with a tagging system
listeners have access to artists dashboards where they can access physical merch, and other media (videos/art etc), know about shows, the ability for listeners to subscribe to artists for live virtual events and exclusive material
listeners be able to engage in decentralized peer to peer exchange hopefully in a way that’s scale-out-able. @zetto.plus told me about https://scuttlebot.io/ which might make sense to check out as a starting point
those are some of my initial ideas off top. really like the random track tracker thing you made. it’d be really cool for listeners to be able to manage their experience in that kind of detail
but yeah, i hope i’m not off n this is kind of feedback you’re looking for?
thank you @brndnkng I’ll incorporate those into the list (update: this is done)
Also, now that there’s some healthy competition in the ‘we need dev volunteers for our online music coop’ arena, developer marketing should be a pillar of the (revived) marketing strategy (imo).
As practical next steps, how about this
For each of these items, we could define the smallest, most tiny prototype version and make a little marketing campaign around them? Like ‘Hack on the Resonate API. Build a < item 1> , < item 2 >, let’s grow together’.
I would love to prioritize some sort of ‘playlist manager’ / ‘playlist player’ on a different platform (mobile, something else) since it would expose those things that one would assume just work, but don’t, but prioritizing something else would have its own benefits. Update: or perhaps something like this https://www.blackartistdatabase.co. It seems like people complain that bandcamp doesn’t have XYZ feature, but something that bandcamp does seemingly do well is provide an environment in which apps like https://www.blackartistdatabase.co can do well.
ps I recently tried out scuttlebut ecosystem and it’s pretty cool (also scary since there’s no delete at the moment)
To make this type of thing a reality there is still a lot of back end api work needed beyond what we have achieved with the user api (and payments… we will have basic subscriptions available soon). Tracks api, stats, security hardening, monitoring and so on to make this easier for weekend developers to consume and potential partner orgs to build on.
Thanks so much for your work on these guides @boopboop
Yes - we have already done a lot of outreach to organisations in the ecosystem … lots of interest in working with Resonate as part of the co-op credentials movement for example. However, I think its the ecosystem of individual developers that we’re talking about here… making it easier to get started and feel good enough about it to put their trust and time into it.
yea, I’m struggling with the internal elevator pitch. There’s already an ecosystem, but not really a developer ecosystem of developers who are currently working on their own projects using the Resonate API.
How about “Resonate API ecosystem”
In order to reach out to a wider developer ecosystem, the ecosystem has to be actively supporting individuals, businesses, and schools with their projects that use the Resonate API.
Support in this case would mean basic technical support and realistic feedback or instructions on how to request changes or updates to the API.
@merefield and @auggod have made a great start with user-api and other api areas in setting up generated documentation to the OpenAPI specification version 3 - see OpenAPI Specification - Version 3.0.3 | Swagger …and then we could build on that with test datasets, tips and snippets.
Also conscious that we said we’d do some work on the ‘good first issue’ tagging in git…
Some nice linking between git and forum (for more discussion on requirements) would be cool too…
Ok, to work on the “what does support mean” statement:
Support
For me, support means “support for the next person”, not closing out an individual support ticket or money (though it can mean these things too).
Highlighting the API documentation (which is great btw) and making clarifying changes as needed ← this can be powerful if we put the API docs link in the footer
Regularly updating the Handbook based on FAQs from users
If API changes are requested, providing a clear path towards proposing and enacting the change, or receiving a “no”
If an API bug is found, providing feedback and transparency on the work needed to fix it and its status
Making a good-faith attempt to bring attention to the needs of the project (testers, developers, users)
Working with ecosystem developers to demo their work either in community assemblies or the Resonate blog, so the greater ecosystem can learn from their work
A huge one would be redesigns of the Library area on the Player or the Favorites page so that folks can bookmark links to Artists, Labels, Playlists, Releases they like rather than having the Library/Favorites be built around saving individual tracks.
I would love if we had a better Library system, with an easy way to star things other than tracks and be able to find them again easily. This would increase revenue too, since our whole earnings model orbits around trying to get folks to listen to a song 9 times.
Even if it were just a long list of alphabetized links under headers of Artists, Albums, Playlists, etc I’d find it utopian compared to the existing Favorites feature.
Pivoting Favorites to being more like “Bookmarks” or “Following” would really help.
good example. Anyone who wants this functionality (important: as a weekend project) has some paths.
Request endpoints to be created to allow favoriting artists and playlists (or whatever, as long as they’re not tracks). This is a dead end (edit: for the weekend project), but sure, the ecosystem can start here.
But if the developer doesn’t have the time or social skills to advocate for functionality through various community meetings, there are other options (only the first one is currently possible):
Build a separate app that connects to the Resonate API and has its own database that stores favorites. I could be “logged in” to my individual Resonate account with the authentication information hardcoded, but any other user would also be using my (or the apps) resonate account, if at all. The platform doesn’t really need to be logged into resonate at all, since anything a user would want to favorite is public anyway.
Path that isn’t yet possible since people can’t register their apps with the ID server: Build a new frontend with its own other database for favorites, Resonate users can create accounts and log in to the app + resonate simultaneously, their favorites get saved to this second database, their other information and the tracks are drawn from the resonate API.
The second item here would be possible if the ecosystem developer feels like advocating for this through the coopcreds project, since just being able to log in to this second app “resonate faves manager” would be a successful implementation of coopcreds.
@boopboop In the last paragraph, switch #proposal to #new-proposals and this will be ready to go! If you feel it makes most sense on Github, add it there and then I’ll link to it from the Handbook. Or vice versa, whatever you think is best.
This looks great. I’ve created a pull request to add this as a quick little link among the other resources in the Readme of the stream repository here: stream!137.