flathub / website Goto Github PK

We need to tighten up and even out the padding and margins on the homepage between the top section, quick setup and the first app section. In particular to balance the needs of the user who doesn't yet know about flathub with the user looking for their first app.

It has been repeatedly mentioned that trust and authority are very important for a website that distributes software. We should provide clear information about

• who is responsible for flathub, the website
• what organizations are backing flathub
• who is reponsible for content on flathub
• review processes and guidelines for content on flathub

• flathub-infra/frontend#162
• flathub-infra/frontend#163
• flathub-infra/frontend#164
• flathub-infra/frontend#165
• flathub-infra/frontend#166

Instead of removing the EOL'd apps, we should instead have some kind of is_eol and just hide those from any results. Although an api request to an eoled app would redirect to the new app-id instead of just returning 404

There seem to be some apps, that don't host their pictures on flathub. Probably apps, that can directly publish?
The icon here is an example https://flathub.org/apps/details/com.airtame.Client

Haven't found any more.

This is a problem, if we want to optimize the images in nextjs

We should consider new copy for the architecture list on an app page. e.g. " 'aarch64, arm, i386, x86_64'" on a page like this https://flathub.vercel.app/apps/details/org.gnome.Connections

Something like aarch64 is quite arcane to even technically inclined users. I can't immediately think of better copy but will continue to think.

We should also think about how to highlight if an app is available on the architecture of the device you're browsing from, or perhaps more importantly not available in the context of aarch64 devices.

Just happened to try this while checking issue notifications this weekend. Currently in staging when trying to delete my account the request returns status 500 and I see

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://flathub.org/api/v2/auth/deleteuser. (Reason: CORS header 'Access-Control-Allow-Origin' missing).

This was working fine in development so perhaps that's a misleading message and there's some edge case error happening server-side.

Just a short suggestions: Currently the old backend repo is pinned. Since development has moved to this monorepo, you should replace the pinned backend repo with this.

1. For applications that are available on Flathub for a long time, the graph does not seem very useful right now, as there were fewer downloads in the past than now. As these numbers aren't very indicative of anything (as we don't track machine-id or IPs), would it make sense to limit them to past few months, 3, 6 or 12?

2. The spikes in the graph above are most likely caused by updates. Should we graph only downloads with updates subtracted, to flatten it a bit? Alternatively, should we apply some "weight" to make the graph appear less suspicious? This is done now thanks to Kolja.

3. In the past, we haven't agreed on displaying graphs at all to avoid disappointing new developers that their applications aren't very popular (more or less). Not sure if that's something we want to stick to for new submissions.

cc @nedrichards

In order for app authors to set up donations/payments we need:

• Backend support for onboarding a Stripe Express Account, including dashboard access
• Frontend support for that flow
• Backend support for defining payment/donation levels and creating transactions based on them
• Rudimentary frontend support for defining payment/donation levels for applications
• Backend support for noticing when a transaction completes for a payment and logging ownership

In the attached screenshot the alignment of the button and title seems quite off, it leads to a less composed presentation for the section.

I'm open minded about the new order for sections on the homepage (where 'editors choice' goes at the top now).

It was previously considered important that getting Firefox or an app tile that users knew on their first view was a good social proof that flathub was safe to use and relevant for the user. I'd be keen to vary this order and see what kinds of influence it may or may not have on the number of apps downloaded. It may be that flathub is now famous enough that highlighting 'hidden gems' works - although as previously mentioned in flathub-infra/frontend#171 we may also need simultaneous improvements in our curatorial workflow.

I'm filing this here since the results are not the same between this and the current site - feel free to close if there's no ordering done in this codebase and we'll refile it in the correct place.

We should include a higher rating for popularity in search e.g. newsflash has about 10x more downloads than hackup on https://flathub.vercel.app/apps/search/news but is much lower down. We want to ensure that users get high quality apps by default.

We currently have https://flathub.org/api/v2/stats/{appid}](https://flathub.org/api/v2/stats{appid} which provides a simple download count (sone install count) for apps. This is good for the Frontend and things like Badges, but it would be good to have a additional API which provides more information. A example of more information is the site https://klausenbusk.github.io/flathub-stats. You can switch between updates, installs and the sum of both. And you can see the stats split by Architecture. The data come from https://flathub.org/stats, which provides a JSON file with all Apps for each day. It would be nice, if there was some API to query this data for a App, so you don't have to parse hundreds of JSON files.

I also saw that https://flathub.org/stats provides a count for Countries and Flatpak version. Would be nice, if this data could added two.

The new API respond could be look like this:

• days
  • 1970.01.01
    • updates
      • architecture
        • x86_64: 42
      • countries
        • DE: 10
      • flatpak_versions:
        • 1.13.2: 5
      • total: 100
  • installs
    • same structure as updates
  • downloads
    • same structure as updates, sum of installs and updates
• total
  • same structure as per day

This new API could be used by 3rd party software to visualize all Data that Flathub has of a App. This informations would be interested for developer.

The URL has currently the Language. e.g.https://beta.flathub.org/de/apps/details/org.mozilla.firefox. This is really bad if people want to share Links. Most people will just copy the URL and don't remove the Language part, so users will be land on a Site in a Language they don't speak, which is a really bad user experience. I would suggest the following instead:

If the User visits https://beta.flathub.org/languages and change the Language this is saved in a Cookie.

If a Site is loaded check if the cookie exists:

• If yes:
  • Use the Language from the Cookie
• If no:
  -Check if Flathub has the Browserlanguage
  • If yes:
    • Use the Browerlanguage
  • If no:
    • Use Englisch

Not sure what we want to do, but a nice graphic would be cool

On smaller screens (smartphone/tablets) search bar should disappear and be replaced with search icon - same way it is working right now on https://flathub.org/

When following the local setup instrcutions from the README I get this error (using toolbox on Fedora 35):

⬢[tobias@toolbox backend]$ docker-compose up
Traceback (most recent call last):
  File "/usr/lib/python3.10/site-packages/urllib3/connectionpool.py", line 699, in urlopen
    httplib_response = self._make_request(
  File "/usr/lib/python3.10/site-packages/urllib3/connectionpool.py", line 394, in _make_request
    conn.request(method, url, **httplib_request_kw)
  File "/usr/lib64/python3.10/http/client.py", line 1276, in request
    self._send_request(method, url, body, headers, encode_chunked)
  File "/usr/lib64/python3.10/http/client.py", line 1322, in _send_request
    self.endheaders(body, encode_chunked=encode_chunked)
  File "/usr/lib64/python3.10/http/client.py", line 1271, in endheaders
    self._send_output(message_body, encode_chunked=encode_chunked)
  File "/usr/lib64/python3.10/http/client.py", line 1031, in _send_output
    self.send(msg)
  File "/usr/lib64/python3.10/http/client.py", line 969, in send
    self.connect()
  File "/usr/lib/python3.10/site-packages/docker/transport/unixconn.py", line 30, in connect
    sock.connect(self.unix_socket)
FileNotFoundError: [Errno 2] No such file or directory

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.10/site-packages/requests/adapters.py", line 440, in send
    resp = conn.urlopen(
  File "/usr/lib/python3.10/site-packages/urllib3/connectionpool.py", line 755, in urlopen
    retries = retries.increment(
  File "/usr/lib/python3.10/site-packages/urllib3/util/retry.py", line 532, in increment
    raise six.reraise(type(error), error, _stacktrace)
  File "/usr/lib/python3.10/site-packages/urllib3/packages/six.py", line 718, in reraise
    raise value.with_traceback(tb)
  File "/usr/lib/python3.10/site-packages/urllib3/connectionpool.py", line 699, in urlopen
    httplib_response = self._make_request(
  File "/usr/lib/python3.10/site-packages/urllib3/connectionpool.py", line 394, in _make_request
    conn.request(method, url, **httplib_request_kw)
  File "/usr/lib64/python3.10/http/client.py", line 1276, in request
    self._send_request(method, url, body, headers, encode_chunked)
  File "/usr/lib64/python3.10/http/client.py", line 1322, in _send_request
    self.endheaders(body, encode_chunked=encode_chunked)
  File "/usr/lib64/python3.10/http/client.py", line 1271, in endheaders
    self._send_output(message_body, encode_chunked=encode_chunked)
  File "/usr/lib64/python3.10/http/client.py", line 1031, in _send_output
    self.send(msg)
  File "/usr/lib64/python3.10/http/client.py", line 969, in send
    self.connect()
  File "/usr/lib/python3.10/site-packages/docker/transport/unixconn.py", line 30, in connect
    sock.connect(self.unix_socket)
urllib3.exceptions.ProtocolError: ('Connection aborted.', FileNotFoundError(2, 'No such file or directory'))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.10/site-packages/docker/api/client.py", line 214, in _retrieve_server_version
    return self.version(api_version=False)["ApiVersion"]
  File "/usr/lib/python3.10/site-packages/docker/api/daemon.py", line 181, in version
    return self._result(self._get(url), json=True)
  File "/usr/lib/python3.10/site-packages/docker/utils/decorators.py", line 46, in inner
    return f(self, *args, **kwargs)
  File "/usr/lib/python3.10/site-packages/docker/api/client.py", line 237, in _get
    return self.get(url, **self._set_request_timeout(kwargs))
  File "/usr/lib/python3.10/site-packages/requests/sessions.py", line 542, in get
    return self.request('GET', url, **kwargs)
  File "/usr/lib/python3.10/site-packages/requests/sessions.py", line 529, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/lib/python3.10/site-packages/requests/sessions.py", line 645, in send
    r = adapter.send(request, **kwargs)
  File "/usr/lib/python3.10/site-packages/requests/adapters.py", line 501, in send
    raise ConnectionError(err, request=request)
requests.exceptions.ConnectionError: ('Connection aborted.', FileNotFoundError(2, 'No such file or directory'))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/docker-compose", line 33, in <module>
    sys.exit(load_entry_point('docker-compose==1.29.2', 'console_scripts', 'docker-compose')())
  File "/usr/lib/python3.10/site-packages/compose/cli/main.py", line 81, in main
    command_func()
  File "/usr/lib/python3.10/site-packages/compose/cli/main.py", line 200, in perform_command
    project = project_from_options('.', options)
  File "/usr/lib/python3.10/site-packages/compose/cli/command.py", line 60, in project_from_options
    return get_project(
  File "/usr/lib/python3.10/site-packages/compose/cli/command.py", line 152, in get_project
    client = get_client(
  File "/usr/lib/python3.10/site-packages/compose/cli/docker_client.py", line 41, in get_client
    client = docker_client(
  File "/usr/lib/python3.10/site-packages/compose/cli/docker_client.py", line 170, in docker_client
    client = APIClient(use_ssh_client=not use_paramiko_ssh, **kwargs)
  File "/usr/lib/python3.10/site-packages/docker/api/client.py", line 197, in __init__
    self._version = self._retrieve_server_version()
  File "/usr/lib/python3.10/site-packages/docker/api/client.py", line 221, in _retrieve_server_version
    raise DockerException(
docker.errors.DockerException: Error while fetching server API version: ('Connection aborted.', FileNotFoundError(2, 'No such file or directory'))

The OARS informations are currently missing on the Website

On https://beta.flathub.org/userpage I see:

This is because the img src is http://meh:

<button class="ProviderLink_provider__muLZ7"><img src="http://meh" width="60" height="60" alt="Login with Google">Login with Google</button>

In order to facilitate donations, payments, etc. for flatpaks, we will need to use a payment processor. Stripe looks pretty good for this, but we need to determine the full set of responsibilities that Flathub will have as a result of facilitating payments.

The outcome of this issue should be a document covering:

1. Options for how to arrange payments
2. What legal/financial implications they would have on Flathub (or a sponsoring organisation such as GNOME)
3. What kinds of payment rulesets these options would facilitate.
4. How we would handle subscriptions or recurring donations.
5. Anything else we can find which seems useful.

Once we have that document in place, we can look to define the implementation plan.

When reviewing #21 I was struck again that for many users there may not be enough information visible on first glance to give confidence before hitting an install action. Not quite sure on the best way forward here - I'll review some competitive examples as well and we may close if there's no good option but a lot of the available screenshots don't tell a compelling story and we've moved the subhead 'below the fold' in this design.

Since the github oauth flow can result in an error, extend the POST /auth/login/github API to support that type of return and correctly clean out the flow tokens.

In order for the Stripe integration to proceed, we need the main Stripe backend to be implemented.

This includes:

• Database models for transactions, etc.
• StripeWallet implementation
• Stripe webhook implementation
• Enough frontend in a hacky branch to prove it out

The padding and margins in the manual install section seem perceptually inconsistent with different spacing between all the items and edges. More consistency would tighten things up (this may also be to do with the copy icon, so could be partially addressed in flathub-infra/frontend#181 )

It would be esier for users to file issues with flatpak if there would be a link to GitHub repository hosting the flatpak on the package page. Currently there isn't any way to get to GitHub repo from flatpak details page.

It would be nice to be able to have a neat placeholder for our bigger images like screenshots. For that it would be sweet to have the backend supply us with a blurhash.

See https://github.com/woltapp/blurhash for some examples.
The next.js as we're using it in the frontend already supports this, if we can get hashes.

There are/will-be a number of oauth client secrets etc. held by the backend's repository for the purpose of permitting developers to test the code. These oauth applications should be migrated to be under flathub org control, whatever platform they serve.

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

Currently flathub-beta is pretty much non-existent to regular users. We don't mention it anywhere on the website (for valid reasons), however it would be nice idea to show a "this app has beta program" sign on applications both in stable and beta repos, similarly to what Play Store does.

This means we need a /beta endpoint, either returning full appstream or just true.

Currently, the api endpoints are desktop-app specific. We should expose at least cli, extensions & sdk's. This also would be a step forward to support displaying extensions of an application.

This has been on my backlog for a bit while prioritising donation checkout flow. Opening an issue so it's not forgotten.

Currently the account deletion button is situated at the top of the user page alongside logout and (in development) the wallet link. I have a few thoughts on how to improve it:

• I think a destructive action that will only be ever used once doesn't belong here where there's no convenience in it being at the top of the page. I'd probably opt to move it to the bottom of the page where it's still easy to access, but out of the way.
• An additional benefit to moving the button is that the confirmation dialog could then easily be made inline on the page which would look nicer than the current fixed positioning (used to avoid spending time re-working or squeezing it into the top grid layout).
• Another idea is to introduce a new styling for buttons associated with destructive actions (of which more will exist, e.g. saved payment card deletion). This would help to differentiate them from the much more common actions used throughout the site.

I'm not that happy with the current structure for screenshots.

I also want caption to be included, if it's there.

https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-screenshots

As part of the Flathub contract, 2022, we need to add login support to the backend such that we can enable developers to perform certain flat-manager type actions and other to enable other work toward supporting payments for flatpaks.

• flathub-infra/backend#94
• flathub-infra/backend#95
• flathub-infra/backend#96
• flathub-infra/backend#97
• flathub-infra/backend#98
• flathub-infra/backend#134
• flathub-infra/backend#99
• flathub/backend#100

The Inter font seems to work in local testing. But on https://beta.fluthub.com it seems to not load.

Exactly as the title says. I raised a bug report there and was directed here: https://gitlab.gnome.org/World/lollypop/-/issues/2671

Our primary goal is to convert web browsers into performing a positive action on an item page (eg. install, donate, contribution). We have a lot of space in the header with quite small action areas. Even for long app titles like "PulseAudio Volume Control" there's plenty of space.

We should move the donate and install buttons to side by side rather than on top of each other and double the size.

It might be nicer to move the content of manual install to a modal, so that we can just show it when users need it. It's very static and probably not helpful for most users.

The https://beta.flathub.org/apps/details/org.gnome.gitlab.YaLTeR.VideoTrimmer page shows a downscaled screenshot even when zoomed in:

The image file it links seems already downscaled and with extra transparent padding: https://dl.flathub.org/repo/screenshots/org.gnome.gitlab.YaLTeR.VideoTrimmer-stable/752x423/org.gnome.gitlab.YaLTeR.VideoTrimmer-fd9a1ceec26394cda35f73a3f8c27ec4.png

The original image from metainfo is https://gitlab.gnome.org/YaLTeR/video-trimmer/uploads/e840fa093439348448007197d07c8033/image.png

I noticed that beta.flathub.org sometimes appears in the results of the different Search engines. This Website is only for testing reasons and for people, who explicit want to see the new upcoming frontend. There should be a robots.txt to prevent random people who just want to go to Flathub from landing on the beta site.

The AppStream Standard allows setting , & tags. The Developer can say., e.g. that the App requires a Keyboard or that the App supports a Gamepad. or the App needs at least a medium Screen to work probably or the App need at least 6GB RAM. There a wider Range of Devices which run Linux e.g. Smartphones or the SteamDeck, so having this information displayed on the Website would be useful.

The website header and footer feels out of place for the dark variant. The blue needs to be considerably darker for the dark variant.

We have considered what's sensible and decided that the initial donation support for the flathub website will be permitting US dollar donations to Flathub itself. This is the least likely to be problematic with tax and so should allow us to iron out the Stripe flows etc. ready for when we want to widen the net.

• Implement core Wallet API and FakeWallet including a fake webhook
• #33
• Organise an official Flathub Stripe account
• Deploy to beta with official account test keys
• Validate in "beta"

Background

Flathub allows third parties to upload apps which are not their own, similar to traditional distro packagers. However, for several reasons, we want to be able to mark apps which are uploaded by their developers. For example, donation integration should only be available if it's the upstream developer packaging the app.

Of course, we also want to do this in a way that doesn't require a huge amount of work for the admins. Some amount of human moderation will always be required, but we can try to minimize it.

Proposal: Verify based on RDNN app ID

App IDs already contain information about the upstream developer: usually either a website or a GitHub/GitLab user or organization. We should extract that information from the app ID and verify it.

• Websites (e.g. org.gnome.Maps): Developers need to place a .well-known file on their domain (or possibly a DNS record?)
• GitHub (e.g. com.github.flxzt.rnote): The developer with that username or an owner of that organization needs to log in with GitHub and confirm.

Flathub admins will need to ensure that apps are submitted with the correct ID. They will be able to manually verify apps or block them from being verified.

To support the basic donation support outlined in #36 we need the following frontend work doing:

• Add basic wallet (cards) and transactions/orders page to user info
• Support retrieving keys and constructing Stripe objects lazily
• Add flow for completing a new or retry status transaction
• Come up with a basic "Make a donation to Flathub" UI
• Deploy this to beta

Probably due to the switch to incremental build.

iamvishnusankar/next-sitemap#31 (comment)

While the sitemap would be nice, I don't think it's that important, I've only added it, cause it was easy.

KeePassXC should be displayed on both searches. Same goes when I type "keepa":

I think most of you know about Shields.io. For those who are not: It's a Site who provide Bages, that you can e.g. include in a Readme. These Badges show information about the Software e.g the download count or if the build has passing. A lot of people using them.

A Badge which shows the Flathub Downloads was requested by a lot of People around the Internet. I would also like to has one. This became more important the more Flathub grows in popularity. So I decided to make a PR which added a Downloads Badge. It uses the Stats API (https://flathub.org/api/v2/stats/{appid}. In the correspondending Issue came the Question, if this API is safe to use.

I don't know the Answer, so I asked it here. If it not safe to use, you should add a API for public use.