#metabrainz

reosarevok: always happy to help with posting to Mastodon/Bluesky - what can I do? (it’s a shame we can’t literally schedule posts there, I don’t think..)

Well, that was the first question, does it have scheduling

Apparently bluesky does not but they suggest using "Buffer" (https://bsky.social/about/blog/07-30-2024-sched...)

"Connect up to 3 channels" for free only tho

The document suggests we should post:

I tend to avoid third-party schedulers when we have multiple services to post to, it adds so many logins etc

Hmm maybe I should look into that but I can’t help but think it’s easy enough to pop in to post something in Mastodon and Bluesky. Shall I put it in my literal calendar?

Oh, 1 hour before might need to be done by you devs I guess, depending on timezone

Yeah, 1h before you wouldn't be around

The reason we schedule it generally is just so we don't forget with all the other stuff :D

But I guess writing it in advance and just posting it will have to do

Did we/you ever schedule it?

I can look into Buffer, I see it includes Mastodon and Bluesky - my only question is if this leaves more room for error, e.g. forgetting to de-schedule stuff if plans change. You might want to pop in to manually post that things are back up again, anyway

[listenbrainz-android] 14hemang-mishra opened pull request #566 (03main…add-to-playlist): Implementation of "Add to Playlist" & "Remove from playlist" in dropdown https://github.com/metabrainz/listenbrainz-andr...

m getting this error while loading feed in local server.

Hi , I am getting this error while loading feed section in my local server.

<aerozol[m]> "Did we/you ever schedule it?" <- Basically last year it suggested we did, but I dunno if we did or not

In the end it's fine to post manually, I think the point of scheduling these was that 1 day before it's easy to forget and 1 h before we're stressed as is :D

But then let's at least come up with something that can be just copy-pasted

I can make an account in Buffer, we will just have to share an email login (unless we decide the service kicks ass and is worth $), as the “team plan” starts costing

Want to link me the doc and I can write some copypasta?

OK, Buffer looks pretty rad actually

Buffer is cool, but it charges per channel, and MetaBrainz has… 4 x 2 channels, making it all rather complicated. The free account only lets us connect 3 anyway, so I have just connected the MB ones (x2) for now. I added the login details to the syswiki if anyone wants to have a play, but since all sites are impacted there will have to be some manual sharing across channels for this schema change anyway.

ask if non-profits get a free account or more channels.

I added some copypasta to the upgrade doc reosarevok, hopefully that’s easy enough to copy and paste before you get going, and then share on the others

Looks like they offer a 50% discount mayhem. If we wanted to hook up 8 channels that’s $40 /month with team access, or $20 /month for single login (we don’t have approval systems etc so I don’t think we need the team one). I personally don’t really need it, but maybe reo and others would like it

I’m off for the night but ping me any time, peeps

k, let me know what the consensus is

not sure tbh

bitmap zas mayhem : new thing ready for SSO integration testing - please try going to outline dot meb dot org in your browser. (free self-hosted copy of [outline](https://www.getoutline.com/))

if you have an active session with authentik already, you should get logged into the thing pretty quickly; if not, you should get redirected for auth and then sent back soon after

no implication of obligation to use this outline instance at all going forward (unless there's interest); outline just happened to be easy to spin up & integrate

🤣

julian45: I logged into outline -- looks interesting. Is the idea to migrate syswiki there?

lucifer: on said dump PR -- how carefully do I need to read that code? is it mostly moving code around?

mayhem[m]: if there was enough interest and justification, yes that'd be a good use case

[@mayhem:chatbrainz.org](https://matrix.to/#/@mayhem:chatbrainz.org) yes that PR is only moving code around, but the next one that I intend to finish later today and is based on this refactors a lot of stuff. So if you want can skip this one and just review the coming one.

normally my attitude to a lot of these things is to avoid self hosting where possible, but docker makes all of this so much easier.

although gating behind auth helps, i'm iffy about putting stuff like passwords into something like outline bc those credentials are ultimately still getting stored/handled in plaintext

fair point.

currently looking into hashicorp vault/openbao (linux foundation fork) to see if they'd be viable for credential management; if not, there are both traditional solutions like bitwarden/vaultwarden/1password and some alternatives like passbolt

Is there such a thing as a team password manager?

yes indeed, which is what i was starting to get into

ok, great. then we can separate the two types of content.

i'm a happy user of 1password in both my personal life and at $dayjob, but it's pricey and not (as) open source

yep, same here.

and striking up more general long term plans... the writing is on the wall that one day will come where us using google workspace isn't going to be a good fit for us going forward.

I'm very much eyeing proton here -- for just about everything google.

I'm watching proton keenly as they develop more apps. and the swiss are just the type of people you want to be running this stuff.

serious to a fault. lol

lucifer: https://github.com/metabrainz/metabrainz.org/pu... a question for you on this PR -- please also check the OAuth related bits.

<lucifer[m]> "monkey: this is the sporadic..." <- I am in favor of whatever solution we can come up with to solve this issue.

Perhaps we could add a flag if the DB scan stops early (i.e. the 12 months you suggested) and do a separate call after page load to load more listens (count = 25 - early-return-listen-count, max_ts= early-return-earliest-listen-ts). Do you think something like that could work?

Now we have the query manager in the front-end (and a bit more experience using it) it's a bit easier to have these advanced scenarios

mayhem: as said on the PR, let's implement it as a user_preferences table instead. like we have a separate user and user_preferences table in LB.

monkey: i think the frontend call the api for extra listens if the listens are less than 25 and the last listen ts is not equal to the earliest listen ts?

As in already does that?

i see, so no changes should be needed on the frontend then? the backend can just restrict the search to last 12 months for the initial load?

lucifer[m]: Small changes required on f-e: basically, if the aforementioned flag is in the api response (early-return or whatever), we react to it and try to load the "missing" listens with the information we have, i.e. number of listens in the first response, ts of the earliest one in those listens, and the earliest_listen_ts as constraint

lucifer: we store client_id and client_secret in client table, but how do i to verify that the request sent to the endpoint is from the actual projects(like do i need to create a custom decorator which checks if the request was made from a client with specific client_id and client_secret?).

@fettuccinae:matrix.org: i remember implementing that already for oauth tokens in lb or meb, i'll try to find it. i'll add the the client credentials grant to our oauth provider and then you can use it to obtain oauth tokens in the projects and use those tokens to call the notification endpoint.

does that make sense?

if yes, i can add that grant in a couple of days and in the meanwhile you can skip auth checks.

lucifer[m]: yup, makes sense. 👍 for the time being, ill create the endpoint without decorators.

yup sounds good, just add a todo to add it later.

monkey: yes makes sense but i don't understand the additional value provided by the early return flag?

lucifer[m]: yes

fwiw i don't intend to do early returns or searches on normal api calls or navigation calls, just the initial load.

which sends listens through props no?

I don't think we load listens through props on first load anymore, let me check

Oh, but otherwise we wouldn't have the 504s, huh

Yeah, of course we do. Sounds sane to restrict to a year (or even less? how long is a scan for 12 months?) for this first load

And I suppose I can detect if a user has no listens at all if their oldest_listen_ts/earliest_listen_ts is not set? I'll have to check what the default value is if any.

monkey[m]: i think we already do that, if min_ts and max_ts are not set, we render that import listens prop

fettuccinae[m]: Not sure I understand the "import listens prop" bit, but it looks like we default to 0 in the front-end if those values are not set: https://github.com/metabrainz/listenbrainz-serv...

Ah, I see, do you mean this? https://github.com/metabrainz/listenbrainz-serv...

monkey[m]: yess

!listens.length

This is if listens = 0, which might happen oin those cases too. Thanks for pointing that out

This bit here will need some modifications to only be shown if we have reached the oldest listen, if we have some listens but not the expected 25: https://github.com/metabrainz/listenbrainz-serv...

monkey[m]: https://github.com/metabrainz/listenbrainz-serv...

i think ive made changed in the frontend for the required.

Yeah, some of those !listens.length conditions will need to be refactored based on the absence of min_ts and max_ts values instead

s/changed/changes/

Right, I see your changes on the same lines, I'll need to review it. I think we want to remove the !listens.length parts for some conditions because we can have some listens in the response, just not the expected 25.

(and `latestListenTs === 0 && oldestListenTs === 0` already suggests that the user has no listens at all)

monkey[m]: yeah, for such conditions, we render a button which makes the api call for listens in next 12 months.

yvanzo: tested search-690 now with 2to3 and the latest packages

Well, looks like you've done all the required front-end changes! :)

I'll need to review everything, but at a glance it looks good

yvanzo: https://github.com/metabrainz/sir/pull/157/comm... neeeds to be changed to work like https://github.com/metabrainz/sir/pull/160/comm...

But if you do that it works

(etc)

yvanzo: let me know what else I can do of use at the moment, I have a few hours available :)

Hello, I've written an email to MetaBrainz support recently, tried to send, but it's not sending. Why? I didn't make any typos in the recipient section, I've double-checked

Rachel: that's strange - if need be you can PM me for now (I'm the one who primarily checks support anyway)

(solved)

yvanzo, bitmap: I started drafting the upgrade instructions blog post. Since we have nothing else than the schema change this time and no beta, it's a bit shorter than other times.

Not sure whether we will have info on the blog post about updating solr and sir and the like in-place, or whether we will only support that for musicbrainz-docker users?

[bookbrainz-site] 14MonkeyDo merged pull request #1169 (03master…update-dompurify): chore: Update DOMPurify https://github.com/metabrainz/bookbrainz-site/p...

[bookbrainz-site] 14MonkeyDo merged pull request #1170 (03master…update-superagent): chore: update Superagent https://github.com/metabrainz/bookbrainz-site/p...

[bookbrainz-site] 14dependabot[bot] opened pull request #1173 (03master…dependabot/npm_and_yarn/babel/helpers-7.27.1): chore(deps): bump @babel/helpers from 7.20.7 to 7.27.1 https://github.com/metabrainz/bookbrainz-site/p...

Oh my.

@fettuccinae:matrix.org: since you worked on the original dashboard speed up and we haven't moved forward with it for api reasons, would you like to work on fixing it for just the profile page? we are thinking of restricting the initial load search to last 12 months. so updating the profile page (https://github.com/metabrainz/listenbrainz-serv...) to

set min_ts = current - 12 months if both min and max ts are not defined.

<lucifer[m]> "@fettuccinae:matrix.org: since..." <- On it. Should i change max passes back to 10 and keep the search_ _start and end_ts

* On it. Should i change max passes back to 10 and keep the search_ start_ts and end_ts

@fettuccinae:matrix.org: i would suggest to work on a new branch from master and just change the search limit in profile page.

for the passes, you can optimize one thing when the total window has exceeded the max time range possible for the user's listens stop searching.

i forget if we do that at the moment.

lucifer[m]: I don't think we do that

MB_DATABASE_URI how to get this?

m.amanullah7: you need to have a local MB db setup for that.

what are you trying to work on?

<mamanullah7[m]> "i was going through [LB-1790](..." <- lucifer: i'm just trying understand this issue on my local!

i'm not confident as i cant able to recreate this issue!

LB-1790: Album links of CB review feed events are broken https://tickets.metabrainz.org/browse/LB-1790

i see, yes its possible it needs a MB setup or at least mapping data.

i would suggest working on something else for the time being, i am working on sample data dumps which might help you debug this locally.

lucifer[m]: okay sure!!

is there any way i can do mb setup locally?

[mb-solr] 14yvanzo opened pull request #65 (03master…upd-docs): Update the documentation https://github.com/metabrainz/mb-solr/pull/65

Hi bitmap and reosarevok: That should be the final documentation update before releasing MB Solr, up for review ^

More updates to come to the repository musicbrainz-docker.

yvanzo: I'll check it tomorrow morning. I started a mb-docker PR, feel free to take it over if useful

<mamanullah7[m]> "okay sure!!..." <- lucifer: my exams are over and i'll travelling back to home on 17th, i'll be fully available. One more thing i tried to do local setup for funkwhale but i'm not able to fully run on my local! i've shared u the documentation i've followd. i'll try to re-setup and will update u!

reosarevok: I see, I have separate PRs on the way for updating SIR and MB Solr in musicbrainz-docker, don't worry about it.

reosarevok: We will have info in the blog post mainly about MB Solr upgrade which is a breaking change (also dropping existing Solr data.) SIR upgrade can be mentioned but it isn’t a breaking change (to Docker users at least.)