It’s been a while since I’ve posted here, but I thought I would share this.
When backing up a failing hard drive, I came across a mockup I made around 10 years ago of what I thought HaikuDepot Server could look like if it also acted as a web store for HaikuDepot. So basically Flathub, but before that came into existence.
So before I delete the mockup for good, I thought I would share it here for anyone interested.
As for the rationale of having HaikuDepot Server act also as a web store, this is to aid in the discoverability of new software and to allow users who have not yet installed Haiku to discover available software.
The idea would be that clicking on the install button on the website (while using Haiku) would open up the HaikuDepot app using a bespoke URI scheme or a reference file (à la Flathub). This would cause HaikuDepot to prompt the user with permission to download and install the requested application.
I see this as having the best of both worlds: having an app store, but let the package management system handle the dirty work.
What’s missing is maybe an installation protocol and handler, but that doesn’t seem much effort to me. I wonder if we would want to improve the GUI somewhat of the website however
The Haikudepot site already has a link to download the latest HPKG. Changing that to an Install button should be easy enough.
Add a cut-down version of Filer to the default installation image, with rules to watch the Desktop and Downloads* folders for new HPKGS, and automatically open them in HaikuDepot, same as if the HPKG had been double-clicked.
Not quite sure I see the advantage over the HD app, though. In the app, installation is a one-click affair (assuming no new dependencies). From a website, it is still a minimum of two, one to start the download and another to confirm installation.
* I know, Haiku doesn’t actually have a default Downloads folder. I’ve been meaning to talk about that …
Way too convoluted. This behaviour is not nice, what if you want to download a package to bring it over to another pc via sneakernet? it would open every time?
The solution here is one that specifices semantic intent, so that the website knows the user really wanted to install the package. Adding a new uri scheme to be forwarded to webkit is not that difficult.
Basically something like haikudepot:install?repo_url=blah?package_name=blah Or something similar.
Could also do a haikudepot:add_repository?repo_url= So that third party repos have an easier time beeing added to user systems. Likewise the installation update instructions could have the repos directly “clickable” to add them to your system, etc.
EDIT: with regards to your two clicks, that can be mitigated. WebPositive would have to remember a user choice that specific sites are “safe” to install packages directly from. e.g the user accepts this for depot.haiku-os.org or so. Haikudepot can then skip asking for confirmation when on these specific sites.
Are we now talking about a web store that only works in WebPositive? I love WP, use it whenever I can, but we have a lot of browsers now and they all have their fans. You’d have to have a button that says “Install” when viewed in WP but “Download” from other browsers.
Third party browsers are out of scope. Installing from them (when on Haiku) works just aswell if they properly forward uris to the system, but remembering “safe” sites to download from would be a webpositive feature. Other browsers could of course implement that just aswell…
The goal is to upgrade depot.haiku-os.org with enhanced app store functionality and introduce a URL scheme that allows websites to directly communicate with the HaikuDepot application installed on a user’s system
This would allow someone recommending software to simply share a link to the application’s page on the HaikuDepot server. The recipient could then review the software and, if they wish to install it, click an ‘install’ button on the webpage. This action would trigger the local HaikuDepot software to take over and install the application on their computer.
For example, if you do not have news feed application this link will not work, but if you do it will add this feed. If you click this and you have an email client on your device, this will open it up and start an email to Bob Smith. If you have a phone client, then clicking this will try to ring PizzaHut New Zealand. If you have IRC chat installed, this link will make you join the Haiku IRC channel.
A more sophisticated one is the one that used to be used for the eDonkey peer-to-peer file sharing service. If anyone, for instance, still has this ancient software installed on their computer, then clicking this link would start downloading a trailer for the Lord of the Rings. That’s if this example link from Wikipedia actually works:
On other operation systems, custom URI schemes can be registered for browsers like Firefox just fine. I guess the Iceweasel port (for example) would just need to be hooked up to Haiku’s MIME database (where URI schemes are handled) if it isn’t already.
The situation is a bit wierd, it’s not as straightforwad. Some uris are registered as mime types (though they aren’t as such) but some are not. and they are routed through “urlwrapper”… perhaps we should add a better mechanism for this
It looks like our Discourse forum software is mangling/disabling those links apart from the mailto link. I was not able to open the tel (phone) link with my Android device.
On a side note, I was able to find a simplified version of this idea used on the web version of Elementary OS’s AppCenter.
If you go to this page and click on the ‘Open in AppCenter” button, it actually just provides this link:
appstream://com.github.phase1geo.outliner
As mentioned by nephele, Haiku would require a bit more sophistication than this for our use case with our diffrent software repositories.
If we want a dedicated one, something like hpkg:... for example, we should register it with the IANA as documented in RFC 7595: Guidelines and Registration Procedures for URI Schemes (to make sure no one else uses the same scheme name for something else). But it looks like people rarely bother to do this (for example the above mentionned appstream: scheme is not registered there…).
It looks like using a scheme based on a DNS name would also be allowed, possibly without registration. So, something like org.haiku-os.hpkg:... may work
Another option is to use tag: URIs, these are also based on domain names and add a date at which the organization owned the domain name (to make sure there are no conflict if someone reuses the same domain name later on). In that case, it would look like: tag:haiku-os.org,2025:packages/... or tag:packages.haiku-os.org,2025:...
That last option needs no registration at all, but it requires us to implement some knowledge about tag: URIs in our APIs. We cannot associate the entire tag: URI scheme with a single application, because it could be used for many different things. So maybe one of the other two options is preferable.
After the scheme is decided, what do we need in these URIs? I think it is:
The repository where the package is found. This can be identified in two ways: the “identifier” URI or the “base-url” URL
The package name (that part should be no problem)
Possibly the package version (that should be optional I guess)
For the repository, using the “identifier” allows people (or HaikuDepot) to check if they already have that repository available, either the “main” one or one of its mirrors. But if you don’t have it, the identifier doesn’t tell you where to get it. On the other hand, the “base-url” allows you to reach the “main” place where the repo is stored, but does not allow you to enumerate mirrors or check if you already have a mirror of that same repository activated.
The “identifier” itself does not enforce a specific URI scheme. Some repositories use an http URL, some use a tag: URI, and it should also be possible to use an uuid: one.
So, we may need to provide both the base-url and identifier of the repo in the URI to cover for all possibilities
I fundamentally like the idea of a shop in HaikuDepot and HaikuDepot Web, because not everyone wants to release their software for free or have it available via source on haikuports. This way, non-free software could also find its way to haiku, even if that’s unlikely given the current distribution.
However, one must ensure that haiku-depot and the website are free of legal responsibility for the sources or have this responsibility as a disclaimer. Because if the software comes from other repositories, it’s not certain that they always respect the rights (we at besly are very strict about this). Abandonware for example is not free, even if perhaps no one is currently paying attention. It would be unpleasant if various things suddenly appeared in haikudepot that were not legally correct, and one could therefore sue haiku for it.
While I deliberately didn’t bring up proprietary software earlier to keep things straightforward, Besly was forefront in my mind when I considered how Haiku and HaikuDepot should handle it. I believe this should be outsourced to and managed by a third party like Besly, rather than being included in the HaikuPorts repository.
This way, a responsible and ethical organisation like Besly could act as a gatekeeper for proprietary software distribution. They could allow freeware and shareware while specifically excluding undesirable software such as adware, freemium, malware, shovelware, and scareware.
So maybe the other option is therefore using a download reference file, similar to what Flathub employs (though they use container manifests). This could be a better approach, even if it’s not perfectly seamless. A standard like Metalink, which explicitly supports multiple download locations and integrity checks, could be a good fit for HaikuDepot.
Sadly, whichever way we proceed, it won’t be as seamless as I had envisioned.
