#metabrainz

Inside this css class you can define `&.timeline-event-sub` (meaning elements with both .timeline-event and .timeline-event-sub classes) and defined your style.

The horiwontal bar before the icon was based on https://github.com/metabrainz/listenbrainz-serv... but changes width, height and positioning (top/left)

[listenbrainz-server] 14MonkeyDo merged pull request #3161 (03master…friends-feed): "My Network" feed — new follows and similar users listens feed page https://github.com/metabrainz/listenbrainz-serv...

lucifer: for the notifications back-end that I speccing for GSoC right now, it stipulates that the notification endpoints be private AND with oauth scope for sending/receiving notifcations.

come to think of it, that is probably not necessary to make it private. If your account doesn't have the scope, you can't auth to the endpoint. thoughts?

reosarevok: ping

Was on a bike, let me read

dumb question: why *don't* we call the people we follow "friends" ?

(on listenbrainz)

I haven't said anything yet, reosarevok :)

are you near a computer now, reosarevok ?

Because an Estonian could only follow two people then, Jigen (IRC):

I will be in 5 to 10 min, parking the bike

what is our goal with "followrrs" though? I mean I only follow like, peopel i actually consider well that I know. maybe "folks I know"? :P

(Thought you were pinging about the notifications bit, sorry)

"buds"

my buds. my people, my guys, pals, chums

idk.

Jigen (IRC): Ready to chat :)

reosarevok: I am, but now something entirely new

maybe that's why i follow liek 35 peopel and only have like 5 followers back (laughing on the inside)

monkey[m]: ! ok

But if you just call it follow then each person can decide what it means to them :)

monkey[m]: wanna do it in pm?

Yus

mayhem: pong

k, the topic is now how to deal with the mail templates. so far we've got jade's work which is available as an API, but requires rust templates to be compiled into an API for each template IIRC.

and each template change. which is quite annoying -- but it supports i18n, which is a big bonus.

my main question is this: should we force the MB style templates on all projects or do we let python based projects to user jinja2? so, the notification creator can choose which sending engine to use?

I mean, ideally it probably makes sense for all emails to share a look and feel if possible, and localization would be a good thing too.

I understand https://github.com/metabrainz/mb-mail-service/b... looks a bit scary, but how often do you change the email content once the message is ready?

but getting from point A to full implementation will take a while, methinks.

(and I understand if you just change a string content the template file stays the same)

Yeah, not saying it won't, we are still migrating some of the MBS emails while others already use it

Seems fine to use what you have for now, with the goal to slowly move towards this - bitmap and Jade (try @jade:ellis.link) could probably help set it up as needed

what I have now being Jinja2 and mb-mail-service, with the creator deciding which to use?

Well, I am not sure if for example in LB you have any basic functions to actually use the mail-service, stuff like this in MB https://github.com/metabrainz/musicbrainz-serve...

we do in Brainzutils which is used by all python projects

Ah, ok

In that case it seems that yes, you could say that for now people can keep using jinja2 but anyone who wants to try can already test the new service

And have a longer term goal to migrate the existing ones to the new service and improve them a bit

the jinja2 and mb-mail have two different workflows that I need to reconcile.

(and once you're doing that I guess you'd say "that's it, now all new stuff must use the new one")

mb mail keeps the templates in that project, (which feels really weird to me) whereas jinja will require the template and arguments to be passed to the notification API call.

I mean, yes, you'd need to either call the "mail via jinja" or the "mail via mail-service" method - we have both and they look fairly different

See https://github.com/metabrainz/musicbrainz-serve... which changes one specific mail from one to the other

But I don't see a reason why both methods cannot live side by side at least for now

aside from the workflow issue I mentioned.

I mean, the same template should of course always be sent only in one way

So for a specific email you should always know what workflow to follow

The parameters you're still passing to the email service either way, the difference is on the way you do it

Am I missing something? :)

I just realized another thing about this really weird mb-mail flow -- we now have content that needs to be translate in two separate repos. that seems like a really bad decision to me.

I agree that the flow is a bit weird, I'm not 100% sure about why it had to work that way

We already have content for translation in different repos though - for example, we are going to have a separate doc repo

anyways, chatted with monkey, and I think the right way forward is for the notification creator to pass one of the two: 1). to fully processed body, ready to send OR 2) the template ID and then template values.

I can see the doc/code split, but a doc/code/code split is dumb.

how about we put the subjects into one repo, bodies into another?

Well, one could argue email templates are as separate from website stuff as docs are

unless its a notification about documentation, in which case the notification needs to come from the docs repo.

But I don't disagree it's a bit odd, I just think it matters less than it feels

and if it is a notification about dev docs, it needs to come from there. lets just take this to the logical conclusion.

In the end for translation for example the stuff is going to be separate anyway

(different projects for emails, docs, web strings, probably also split the web strings in projects if there's a lot, like we do for stats vs main stuff)

are subject lines also stored in mb-mail?

or do those need to be passed in?

they are part of the template, ok.

I think that's part of it, yes :)

IIRC there's some templates that allow a subject to be passed?

Ah, yeah, send_message_to_editor in MB allows passing a subject because the way mailing is built in MB allows the user to write their own subject

But that's not localized, of course

It's literally a DM by email

ffs

Checking Sentry, "Attempt to register more than 5 accounts in one day" -> "Total in last 14 days 6.5k"

Isn't spam lovely

reosarevok: bitmap and monkey I've now updated the spec with the latest discussions and I think I covered everything. please re-read and see what else needs improving: https://docs.google.com/document/d/1jK2OreDzYq_...

mayhem: I'll admit I have no idea what "pr_end_of_file_error" is about :)

What am I missing?

fuck if I know!

tell them to try another browser? reboot the internet?

mayhem: what should be the url for "contact us"? https://listenbrainz.org/about/ or https://musicbrainz.org/doc/Communication/ChatB...