Detecting appstream scheme support ; end-user-oriented "About AppStream" page (was: Re: Add "Install via AppStream" links to applications on kde.org)

Mon Dec 19 02:38:54 UTC 2016

Moving to kde-devel for more input by app developers:

For the current testing entry with an appstream: url on KDE pages see the 
right box on https://www.kde.org/applications/utilities/okteta/

But it is unclear if "AppStream" works here with most end-users. Please read 
on below and then give your comments/2 cents :)

Am Montag, 19. Dezember 2016, 01:30:39 CET schrieb Matthias Klumpp:
> 2016-12-19 1:00 GMT+01:00 Friedrich W. H. Kossebau <kossebau at kde.org>:
> > Am Sonntag, 18. Dezember 2016, 22:50:23 CET schrieb Albert Astals Cid:
> >> El dissabte, 17 de desembre de 2016, a les 0:17:22 CET, Friedrich W. H.
> >> 
> >> Kossebau va escriure:
> >> Is it possible to detect if the browser has a handler for the appstream:
> >> scheme and if not don't show the link at all?
> > 
> > At least from a quick search there is no simple querying of the supported
> > protocols possible. Only saw hacks of the kind which made me try to stay
> > out of web development.
> > 
> > I would agree only showing the link active in browsers where the protocol
> > works would be nicer. I can just tell myself e.g. irc:// urls in the same
> > box also have a similar fate.
> 
> I am actually rather happy about that, the less information a browser
> exposes to the webpage by default, the harder it gets to use the
> information for tracking or to detect vulnerable systems.
> 
> > @Matthias & Co: What other web pages/sites are already making use of such
> > appstream links? How do they handle it?
> 
> So far I've only seen very few, mainly on Wiki pages or private pages
> at GNOME. All of them show these links unconditionally.
> What you could do is detect whether the user is running Linux and if
> not, hide the link. As of no, there is no Windows client consuming
> this data that I know of.
> 
> > That left aside, most people surely still have no clue what "AppStream"
> > is.
> > 
> > So it could make sense to have a small note mark to the right of the
> > appstream:id link for the "What the heck is Appstream" use-case, so people
> > could click/tap the button and learn about AppStream (or already learn a
> > little in a tooltip, though a separate note mark still is needed for
> > discovery and touch UI browsing).
> 
> About that: I wonder whether it would actually make more sense to show
> a link like "Open in Software Center" or "Open in KDE Discover" or
> anything more descriptive... AppStream is a rather technical term, and
> if users need to read a page to know what it does, the links are less
> useful.

The issue here is that we do not know what handler is invoked by the 
appstream: scheme. Only the browser knows. If lucky, it perhaps might be nice 
enough to show some information on cursor hovering (at least in a mouse-driven 
UI, no idea how touch UI can preview info about url handling on linked 
elements).
Given the variety of names of the software installation managers on all the 
systems, I fear there is no generic enough name, which might not result again 
in people also thinking "Does not work for me" or wrongly thinking "Works for 
me".

IMHO the distro-agnostic appstream thing is an implementation detail and 
concept which can/should _not_ be hidden from the user here in the case of the 
distro-agnostic app pages. That would be trying to make things more simple 
than they are, and this will only result in more than less confusion.

So similar like flatpak or snap this is a concept which needs to be understood 
by those people who want to become independent of what is only available 
inside their distro's software manager. They have to know this is an appstream 
link to know if it is working for them (like they will have to know if flatpak 
or snaps work for them).

Everyone else, who is not smart enough to learn about appstream links, should 
not try to install something from the internet anyway, unless they also fancy 
shooting their parts of their own body ;)
So IMHO the motivation for putting the name "AppStream" on the button images 
offered on
https://www.freedesktop.org/software/appstream/docs/sect-AppStream-Services-UrlHandler.html was correct, "AppStream" is a term/concept to be used here.

> > @Matthias: is there some distro-agnostic end-user website/page this "About
> > AppStream" symbol could link to?
> > Only found
> > https://www.freedesktop.org/software/appstream/docs/chap-AppStream-About.
> > html but that is not really consumable by Sue and Joe -No-Code-Please-
> > User.
> 
> We could make one...
> https://www.freedesktop.org/wiki/Distributions/AppStream/ exists, but
> since AppStream is a rather technical project, I don't think we even
> should attempt to explain it for users who will never see the metadata
> (what is metadata anyway? - we'd even need to explain that first).
> IMHO some short explanation maybe in form of a small "what is this?"
> info on the webpage or a tooltip which shows something like "Open the
> page of this application in the software center of your operating
> system" would be much more useful. And since at time *every* software
> center on Linux, including the one on Ubuntu, uses AppStream metadata
> and appstream-IDs, we can simplify and generalize a lot :-)

Ah, what I meant was an explanation for just the appstream: link and what it 
is used for: that it is a distro-agnostic way to activate the software manager 
of one's operating system to try to install a version of that very software if 
available from a location trusted/used by that very software manager, by the 
means of that unique identifier for the software as used in the url.

No mentioning of any other metadata stuff, just this. I would assume a person 
who already learned what a link is should be able to get this.

This discussion makes me wonder if such links should not be having a different 
separate (marketing) name. That would allow to promote the concept of such 
links completely separate from the implementation detail of the distro-
agnostic appstream metadata and all the other stuff it allows inside the world 
of software managers.

So to summarize:

Given this very use-case:
Us upstream (source-code developers) wants to point the end-users to packages 
of our software provided by downstream (distributions). Either because 
upstream cannot provide such packages themselves or because the end-user only 
trusts their distribution.
This needs to be doable in a distro-agnostic way. Also does it need to be 
processable by software, so end-users do not have to retype something and know 
where to retype this exactly.
(So this is not about e.g. software manager internal communication, e.g. with 
web pages for the UI which talk back to the core by urls.)

Proposed solution:
An url seems a good approach, with a dedicated scheme and the generic, distro-
agnostic app identifier being encoded in the rest of the url, with the address 
space being inside the world of the respective software manager handling this. 
Such urls would work in web pages, but also other places like documentation or 
text-based communication (email, chat).

The appstream: urls are an existing scheme here and already supported by some 
software manager apps (which also install handlers for the scheme into the 
system).

Disadvantage of the term "Appstream" is that is also refers to the app 
metadata system in general, so end-users/developers searching for explanations 
will only be confused and useless discussions held (cmp. e.g. existing 
wikipedia page or similar docs about "AppStream").
Also might it be not too descriptive for the given use-case, and Amazon 
occupying the term for something different but slightly related adds to the 
problem.

Thus a new dedicated name, both used in the url scheme and for marketing such 
urls, might be good. As user-facing appstream: urls have not yet appeared a 
lot in public places, there is still time for starting with a new specially 
designed name.
AppStream metadata then would just be the implementation detail for this, 
providing one way to define the id that should be used by the software manager 
for resolving any incoming app urls as discussed here.
Same like telephone uri, email uri, or geouri just point to an id, whose 
metadata is then resolved by the system processing the uri.

If we could rule the scheme world, this would be best, by example of Okteta:
	app:org.kde.okteta

It would perhaps even allow to use path?query#fragment for specifying a 
version and even action intends, e.g. 

	app:org.kde.okteta/0.23.0/?action=install

which could be used in release announcements to allow users to query their 
software managers by a simple mouse click if the new version is already 
available from the trusted/registered package stores.

Having such a separate non-appstream url should only need minimal adaption 
with the software manager apps, they only will need to also support the new 
scheme (additionally).

So what name to use? Ideally both the scheme and the technology should have 
the same name, so there is not a lot to know. Something based on english terms 
might help as well.
It would need to be cross-desktop, cross-platform, cross-license.
"app", "appid", "application" come to mind, but conflict with schemes in use 
or terms otherwise occupied.
Global App id, universal app id, ... too tired now to pass some good proposals 
here, will do in a later post.

Meanwhile... What do you think?

Cheers
Friedrich