Displaying the latest scrobble now in BalormoFE: https://git.pleroma.social/pleroma/pleroma-fe/-/merge_requests/1865
Thanks @hj
Displaying the latest scrobble now in BalormoFE: https://git.pleroma.social/pleroma/pleroma-fe/-/merge_requests/1865
Thanks @hj
I wrote a little bash script that moves Last.fm scrobbles to BalormoBE. I run a cron job. You don’t necessarily need to use my script but it should at least give you an idea.
I think adding ListenBrainz and/or Maloja support would be phenomenal, but for me it’s one step at a time. Right now I have an open PR into PleromaBE to make it so that the account/pleroma section in the AccountView JSON has a scrobbles entry, which is an array of the most recent five scrobbles, if any. You can see that PR here: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3975
I’m doing this because as it stands, my implementation in the FE requires hitting the endpoint, and in order to make it avoid absolutely inundating it, I have to throttle it. This would obviate that completely and allow me to just look at the returned account data normally, as with most of the rest of the API.
So far Lanodan seems reluctant to add it, saying that Listen is in itself a “hack” that first (he stresses that word) must be redone. Basically, the complaints about scrobbling are that they aren’t supported by FEs, but then efforts to support it get rebuffed.
So, this is the person “reviewing” my code. It’s not going to be accepted, not because of the content of it, but because of who I am. Any basis for rejection will be entirely pretextual at best.
@LukeAlmighty @ChristiJunior @CumskinFoidPuncher69420 I just wanted to make free software
@NEETzsche @ChristiJunior @LukeAlmighty @lewdthewides @hj
so basically we’re not getting scrobbling because @lanodan doesn’t like you because you’re you which is disappointing at a baseline. Why are we removing features when the point is to be adding them. If we’re worried about ‘security risks’, at that point, none of us should even be allowed to post anything but text since any attachment can also attack security vulnerabilities (ie; the way that Claire from Chudbuds got hacked via a minecraft mod pack).
They didn’t even mention “security risks,” assuming there even are any. There are no “security risks” to delivering a little bit of JSON from a scrobbles table that only has text in it, and there definitely aren’t any new “security risks” considering this exact content can be retrieved from another endpoint.
Here’s the goalpost for technical basis to reject this PR. It must meet ALL of the requirements:
I’m not setting this goalpost because I think it will be met, I’m setting it because I want to give those who aren’t technical a baseline for evaluation here. If ANY of these requirements aren’t met, we can conclude that it’s not about any technical issue. It’s about who made the PR.
Scrobbling is literally a function
@colonelj @NEETzsche @hj sometimes your opinions are unnecessary, but we still have to see them and hear about them.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.