Implement a review backend

[razzeee]

Basically mirroring odrs, I think.

Here's an example call for firefox:
https://odrs.gnome.org/1.0/reviews/api/app/org.mozilla.firefox

Should then be used in:
flathub-infra/linux-store-frontend#311

[bilelmoussaoui]

Odrs contains reviews submitted by people using the same software but packaged differently. A bunch of issues could be caused because of that.

Showing those reviews doesn't make sense to me.

[barthalion]

I don't see a field designating flatpak packages, so I agree, it doesn't make much sense as it is.

[barthalion]

In fact, none of the reviews in the example call for Firefox are actually about Flathub, as we're using lowercase org.mozilla.firefox as agreed with Mozilla, while all entries are either Snap, distro (firefox.desktop) or Fedora (org.mozilla.Firefox).

[razzeee]

yeah, I've briefly talked about us not being able to separate the different packaging providers in the flatpak matrix channel.

I guess there are tree ways forward:

1. Accept that we can't do it
2. Update odrs to be able to hold this data and make sure that distros will send this at some point -> then implement it based on that.
3. Have our own non odrs backend (which has a bunch of other implications)
4. Mix them up and don't care about packaging causing reviews (you could argue, that most reviews shouldn't be about packaging)

[razzeee]

Thinking about this again, Gnome Software seems to somehow differentiate reviews between rpm, flatpak (fedora) and flatpak (flathub) so I guess it's possible somehow?

[razzeee]

This would need to also add the reviews/ratings from the linked provides->id
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-provides

[barthalion]

Thinking about this again, Gnome Software seems to somehow differentiate reviews between rpm, flatpak (fedora) and flatpak (flathub) so I guess it's possible somehow?

Do you have screenshots that show this? GS is able to change the repo to install from, but it seems to me that reviews stay the same.

[razzeee]

Not sure if I remember right and this might be totally invalid:

I tried to look into that when I reported it, but I don't think the code is easy to follow, it might just be due to the app id and the provides->id accumulating differently as we're switching the metadata file.

[barthalion]

Yeah, I think it's something with provided ID but ultimately the same reviews to a degree.

[razzeee]

Still feels quiet misleading and shouldn't they load up those reviews too? Not just in the sum?

[razzeee]

I still think ratings would be cool, even if we just show the stars and nothing else.

Then again, I think most people that are looking for apps, will not care about how it's packaged (they might, but I think that assumption is due to us working on this exactly) and the reviews are mostly not mentioning how it's packaged.

[razzeee]

Should wait for https://gitlab.gnome.org/Infrastructure/odrs-web/-/merge_requests/17 so that we can filter for actual reviews of the flatpak versions

[sonnyp]

odrs lack features that are important for publishers, such as replying to reviews publicly or privately contacting a review author to ask for more details.

Would these be doable wth odrs?

[razzeee]

I'm wondering if just starting with stars would be any improvement.

[mijorus]

Hi @razzeee, I would like to contribute to this feature.

Is this #50 (comment) this a blocker for you?
I know that mixing reviews from multiple sources is not ideal, but as a user and an app developer it would be great to see all my reviews on a single place.

I basically had to make my own implementation of that, just to see the reviews of my app

[razzeee]

hey,

Is this #50 (comment) this a blocker for you?

I at least thought so, as I suspect reviews heavily diff between the way something is packaged.

I know that mixing reviews from multiple sources is not ideal, but as a user and an app developer it would be great to see all my reviews on a single place.

Not sure why as a user - I do get that as a developer, but thought you could also just login to odrs for that (I've only patched that thing a few times, never really used it)

[mijorus]

I think it makes sense to show reviews and star ratings at least for verified apps, as the developer is actively targeting Flathub, so there shouldn't be issues related to sandboxing.

but thought you could also just login to odrs for that

Can I? Not really sure where or how, their website says I can "request an account if you think it is required", without clarifying where to ask for.

[razzeee]

I think it makes sense to show reviews and star ratings at least for verified apps, as the developer is actively targeting Flathub, so there shouldn't be issues related to sandboxing.

There still might be issues with the snap, appimage or native packages (dependencies) - while the flatpak still works fine

Can I? Not really sure where or how, their website says I can "request an account if you think it is required", without clarifying where to ask for.

In theory, but I guess hugsie was adding people, so nobody might be doing that.
Anyway, there is a web interface, where you can moderate comments etc, but I've only seen it in my local dev env

[mijorus]

I'll send a pr anyway, then you can decide what you think about it

[razzeee]

Please wirte an outline of what you are planning to do first

[mijorus]

Sure. This sis my proposal

1. We start by implementing the rating system first, comments and reviews later, as we need to decide how to handle multiple languages
2. Only verified apps should have visible reviews: since the developer is officially publishing the Flathub release, I think we can assume that the app should work flawlessly and is being developed with Flatpak's limitations in mind
3. We can create a backend api that caches ratings from ODRS, say once a day, with redis: the API responds with the average rating already computed
4. We can then show a little star followed by the average rating on Flathub, maybe close to the app icon
5. (Optional) We can also computer our own average, by filtering out all the reviews published before the flathub release, but we need to verify if ODRS apis can handle such queries. (I know it doesn't natively, it just responds with all the reviews at once; but can we rely on huge responses for popular apps?)

[razzeee]

Sounds good. Just trying to figure out if your proposal would conflict with this https://github.com/flathub-infra/gsoc#flathub-rating-system

[mijorus]

Sounds good. Just trying to figure out if your proposal would conflict with this https://github.com/flathub-infra/gsoc#flathub-rating-system

Well, ODRS apis are definitely a bit rough. They don't support timestamps queries, search or pagination: they return the full payload every time, which is not great.

Also, /ratings/<app_id> doesn't work, which means you need to download the full list just to get ratings for one app. It was not really designed with scale in mind.

[razzeee]

you don't have to explain that :)

but we should probably keep those endpoints around, if we manage to redo it, breaking every software center app is likely a nogo

[mijorus]

you don't have to explain that :)

but we should probably keep those endpoints around, if we manage to redo it, breaking every software center app is likely a nogo

So, do I have green light on this one? Can I open a PR with a sample implementation? Let me know what you think.
(Like I said before, I would start by implementing the rating system first, aka the stars)

[razzeee]

Yeah, as that would still rely on having odrs to consume it, that would not make the gsoc proposal invalid. (making it invalid would also be fine, but then I should remove that pitch)

[mijorus]

HI @razzeee , I'm having an hard time figuring out where to refresh app ratings.
I tough it could be a good idea to queue the refresh to any cronjob worker you might already have.

I came across backend/app/worker.py update(), but I'm not really sure 100% if this is the right place. Is it invoked regularly?

[razzeee]

It is invoked multiple times a day, but at this point, we could probably just have a once per day job and we will figure out it being called once per day on the server. So feel free to create such a thing.

[mijorus]

It is invoked multiple times a day, but at this point, we could probably just have a once per day job and we will figure out it being called once per day on the server. So feel free to create such a thing.

All right, I guess it should always be an http endpoint or can we run python scripts directly?

[barthalion]

https://dramatiq.io/cookbook.html#scheduling-messages