@crafti PleromaFE does use birthdays but not scrobbles. You'll need to add scrobbling information to MastoAPI as well. Feel free to contribute on our gitlab.
@hj I have expressed interest in being like the first client to support/display tracks. Pleroma-FE afaik itself doesn't even use it (alongside birthdays?)
@crafti because PleromaFE uses MastoAPI, if you want to show latest scrobble on user profile or show scrobbles in timeline in some way you have to add extensions to respective things (timelines, user profiles) in MastoAPI
@crafti we already fetch too many things when visiting profile - profile, relationships, posts, followers/followees, i would much prefer this data to be bundled with some of the requests (i.e. either profile or relationship).
Not markdown as everything in fedi (apart from MFM) is in HTML.
But anyway - yeah. If there's interest and use and also someone works and improves on it then it can be un-deprecated as I said. Even if we know how to do it, the question remains is who's gonna do it.
@hj Oh, I see. I don’t see it as important because you can also just fetch it when you visit a user profile.
That’s what Sharkey does at least with ListenBrainz.
Obviously it would be beneficial if we can somehow represent the Listen activity as a standard Markdown post in the home timeline, and make Pleroma-FE display the post differently if pleroma.scrobble is provided or something.
===> Fetching rebar3_hex v7.0.1\
===> Version cached at /var/lib/pleroma/.cache/rebar3/hex/hexpm/packages/rebar3_hex-7.0.1.tar is up to date, reusing it\
escript: exception error: undefined function erlang:get_stacktrace/0\
in function rebar3:main/1 (/rebar3/src/rebar3.erl, line 72)\
in call from escript:run/2 (escript.erl, line 750)\
in call from escript:start/1 (escript.erl, line 277\)
in call from init:start_em/1 \
in call from init:do_boot/3 \
** (Mix) Could not compile dependency :quantile_estimator, "/var/lib/pleroma/.mix/rebar3 bare compile --paths /opt/pleroma/_build/prod/lib/*/ebin" command failed. You can recompile this dependency with "mix deps.compile quantile_estimator", update it with "mix deps.update quantile_estimator" or clean it with "mix deps.clean quantile_estimator"
Had to run this to fix it:
sudo -Hu pleroma MIX_ENV=prod mix local.rebar
Not sure on the what or why, but might be helpful to note.
It’s already implemented on my fork of Soapbox. It displays the most recent scrobble under the username. @hj would something like this be appropriate for BalormoFE?
Also @alex rejected the PR because he’s refactoring a bunch of shit in SoapboxFE and doesn’t want to add features. I might put that same PR in again soon.
@NEETzsche@crafti@alex@hj >@hj would something like this be appropriate for BalormoFE? I assume. The feature likely got deprecated due to lack of usage, which by itself can be attributed to lack of support in mainstream clients.
I generally don’t agree with removing features without a compelling reason to, and “none of the FEs use it” isn’t a compelling reason. It takes effort, even if small, to do such removal. It closes doors. It doesn’t open them.
@NEETzsche@crafti@alex@mint >@hj would something like this be appropriate for BalormoFE? Sure, why not? As long as you can turn it off/hide it. I guess it would be cool to have "rich presence" thingy in general for folks who want it.
>It takes effort, even if small, to do such removal. It closes doors. It doesn’t open them. From perspective of a developer it reduces complexity and development burden. Less moving parts. Imagine if your bedroom had two doors - you'd be confused why there's two doors, you'd have to keep in mind to keep both doors closed instead of one, you'll have another hole for cold air to sneak in if window is open in adjacent room, you always use one door but not the other don't know anybody who'd even use the other door, you'll end up blocking the door with stuff and furniture just because you forgot it's there. Unless you know the reason for its existence* it's more of a burden than a benefit.
Putting a "deprecation notice" perhaps is the best way to get attention and answers about feature. It's not removed but it is deprecated, which means it might get removed if it gets in the way and/or causes trouble, so if someone uses the said feature they would raise voice, like in this thread. So now we at least know that some folks are using it at least, and it's not dead code nobody knows about. Still no idea if it even works right or not though.
>(*ahem* scheduled posts in pleromafe *ahem*). I don't know, PleromaBE and PleromaFE development aren't exactly in sync, and either I'm not informed about certain features being implemented in backend side (because they were implemented specifically for soapbox during "gleason era") or were implemented as some experiment by someone, or I was informed but it slipped my mind eventually. There are so many things left to be done and I'm only beginning to try to organize and manage the project "properly", on top of actually coding.
*: my bedroom does have two doors and initially I was confused to why, but once I put a double bed in the room I realized that bed essentially takes entire "depth" of the room, so to get to the other side of it you'd need to climb over the bed, making the second door act as an easier access, letting you walk around bed (and part of wall) instead.
It works well enough here. That being said, as far as I'm aware, mine is the only instance that actually uses it.
I was initially going to write one for PleromaFE after it got merged into SoapboxFE, and if PleromaFE devs didn't add it on their own. But it didn't get merged into SoapboxFE and consequently I kind of just moved on. I'll check out PleromaFE and see if it's self-explanatory in how it works. Last I checked I think it uses VueJS, which I've only used a little bit in the past.