Bob Swift, derat I had this also yesterday. I don't exactly now what I did, but I reloaed, navigated back to translations.metabrainz.org or such things and eventually I got in.
But weblate has become rather slow. So probably they have some technical trouble.
<outsidecontext[m> "But weblate has become rather..." <- That could have been it. I just tried now and was able to get in okay.
dvirtz[m] has quit
Jade[m] joined the channel
Jade[m]
Hey all! Assignments are done, half term has started and I now have much more free time!
I'm writing up my GSoC proposal right now and wanted to ask which [BrainzBot plugins](https://github.com/metabrainz/brainzbot-core/tree/master/botbot_plugins/plugins) people used?
The ones I see the most are GitHub, Jira and !m
minimal joined the channel
mayhem[m] waves at Jade
mayhem[m]
lucifer: ^^
lucifer[m]
Jade: not sure. but i think the three you mentioned are probably it.
fwiw if this is about the Matrix archiver, I think you won't need to implement any plugins. the archiver itself would be enough.
Jade[m]
Yeah, I've just posted my proposal, sans-timeline.
<lucifer[m]> "fwiw if this is about the Matrix..." <- Those the Jira and `!m` plugins are pretty simple! `!m` is about 6 LoC. There's a pre-existing GitHub plugin. Might as well go for a complete replacement, given that!
And maubot is pretty easy to host, too. It uses sqlite, and has a web interface you can use to upload plugins and manage bot accounts.
Of course, a secondary priority compared to the rest of the project :)
vardhan__ has quit
lucifer[m]
Jade: I think doing this project in rust is a bad idea. There is no benefit to it than doing it in python. and doing it in rust making maintaining it in future hard.
Flask + React for frontend is the preferred tech stack for this project.
as that's the common tech stack between most of our projects.
julian45[m] joined the channel
julian45[m]
<lucifer[m]> "Jade: I think doing this project..." <- i would counter that there is at least some benefit to doing it in rust: as far as sdks from the matrix foundation itself go, `matrix-rust-sdk` is [considered production-ready](https://github.com/matrix-org/matrix-rust-sdk?tab=readme-ov-file#status), esp. as it backs prominent client implementations; on the other hand, `matrix-python-sdk` seems to be [effectively
unmaintained](https://github.com/matrix-org/matrix-python-sdk?tab=readme-ov-file#project-status), though there is a [separate library referenced in the readme](https://github.com/matrix-nio/matrix-nio) which seems to see more maintenance
Jade[m]
<lucifer[m]> "Jade: I think doing this project..." <- I went into more detail on the justification in the pre-proposal, but julian45 has the main justification for not using python
julian45[m]: (One person I know working with matrix-nio is very much regretting it, too)
julian45[m]
may i ask how so?
because i do think lucifer's point that python is already used a lot across our projects' stacks is important to consider
* because i do think lucifer's point that python is already used across a lot of our projects' stacks is important to consider
Jade[m]
julian45[m]: It's also relatively unamintained and has multiple bugs with handling state. Apparently the sans-io design makes it very difficult to maintain and fix these bugs, too
julian45[m]: Absolutely
lucifer[m]
julian45: Jade: we can use the http api directly if the python sdks are unmaintained
Jade[m]
lucifer[m]: That's... a bad idea. The Matrix API is complex and changes steadily over time in both significant and subtle ways.
I didn't really consider React, because the aim was to create static HTML files. React's not really intended for that usecase, although it can do it
But the ideal with picking Rust is it would be very low maintenence, like the mail service has been
lucifer[m]
if static HTML + jinja2 suffices then its fine
Jade[m]
MeB also has quite a few Rust projects, and that + Rust having a far better SDK situation + me personally knowing the Rust ecosystem better was enough for me to chose it
lucifer[m]: Yeah, that would have been what I chose
The most maintained Python SDK is the one maubot uses
So mautrix-python + jinja2 + sqlite might be a viable stack for this?
lucifer[m]
FWIW, the matrix devs at FOSDEM suggested me to just use the HTTP API if it works for us but if there is a maintained sdk then that makes sense ofcourse.
sqlite sounds good but I am not familiar with how good its full text search is. if there are no special reasons, postgres makes more sense to me.
suvid[m] has quit
Jade[m]: in my opinion, yes. but others might differ so let's hear from them as well.
julian45[m]
lucifer[m]: postgres must run as a separate service; as jade pointed out in her [pre-proposal](https://community.metabrainz.org/t/gsoc-pre-proposal-matrix-archiver/748262/6), that means "a bunch of data that's separate, easy to forget to backup, and not so easily accessible to the public anymore... chances are that a whole bunch of state ends up stored there."
lucifer[m]
julian45: if we store the data in the main postgres cluster, all the data will be backed up properly.
a different database in the same postgres cluster.
(sorry i haven't read the pre-proposal yet so don't have all the context.)
Jade[m]
<Jade[m]> "https://github.com/mautrix/..." <- More context on this one is that it powers Beeper's telegram and google chat bridges. However, Beeper/Mautrix have been rewriting their bridges in Go for a while now, and the Telegram rewrite is almost done. That would leave the SDK as community supported, and there's a fair chance it could fall into the same state as the other Python SDKs
julian45[m]
lucifer[m]: i think this could be decently viable, especially considering that the secondary element of the proposed project (maubot implementation) is within the same development family as mautrix-python, so could result in increased reuse of common fundamental components), _but_ at the same time that would need to be worth risk/reward tradeoffs the proposed rust-based approach
Jade[m]: ah, good to know
s/)//
lucifer[m]
Jade: while generating HTML pages is fine, i also think we should be storing all of the data in the database.
Jade[m]
Basically the most supported and complete SDKs are the Rust SDK (Matrix Foundation / Element), Go (Mautrix/beeper), and the Javascript SDK (Matrix Foundation / Element).
lucifer[m]
so that if we want to regenerate the html pages at any time with a new UI or fix, we can use the data from the database. also it would help in adding all sorts of filtering.
Jade[m]
lucifer[m]: Regenerating from the database is a pretty good reason. I kind of ignored this because the Rust SDK maintains a transparent event cache that avoids calling back to the server when the data is already known
lucifer[m]
is it an in memory cache?
Jade[m]
It would be much more important with the python SDK, as that doesn't have a cache AFAICT
A SQLite cache on disk
lucifer[m]
i see, is that the sqlite db in question?
Jade[m]
Jade[m]: It also uses that to maintain encryption state, although that's less relevant for bots
lucifer[m]: Which do you mean?
lucifer[m]
yeah, i think encryption is not an issue for us since all of the data is public anyway.
Jade[m]
<lucifer[m]> "sqlite sounds good but I am..." <- To answer the first part of this, it's... OK? Not as good as dedicated search, but not bad
lucifer[m]
Jade[m]: i mean is this the only SQLite db being used in this project or is this an internal sdk one and there will be another one used by the archiving service?
