I think it's fair to say that sharing is one of the most time-saving interactions on our phones. So I was more than thrilled when I've heard about the Share Target API.

If you wanted to share your content using the share-interface of your operating system you can easily use the Web Share API, which has been around for quite some time and was just recently published as editor's draft for the w3c standard. It's a pretty simple call where you could pass some data you want to share and the OS would then show a list of all the apps that are able to receive that data.

But what if your web app is on the other end of the sharing? That's where the new Share Target API comes into play. Just like most of the Project FUGU capabilities it looks quite easy to use, but it has a super powerful background.

I fully understand that for a lot of websites out there don't need such an API. But as soon as you leave the "normal" path and start to create rich and interactive web applications it makes a lot of sense to allow the user to share their content from another web app or a native app to your application.
Calendar invitations, links, messages... whenever it could make sense to copy/paste something, it could be way faster to share it directly.

YTAudio

And that was exactly my use case for YTAudio.
The web app needs a YouTube Video to fetch the audio file and the metadata. I could now let the user copy/paste the URL, but if I could just use the share prompt that the YouTube App uses anyways it would be way more user friendly.

Implementation

First of all your web app needs to have a manifest.json, it also needs to pass all the other criterias for installability and the user must have added it to his/her homescreen.

Now, inside your manifest.json you can simply add a new entry called share_target. This entry accepts some params that somehow feel a lot like the HTML-form element. You basically define an action, which serves a target-endpoint, a method (GET, POST) and your data. Note that you are completely free to use the params you like. But it makes sense to stay compatible with the web share API:

// manifest.json
{
  "name": "MyApp",
  "share_target": {
    "action": "share.html",
    "params": {
      "title": "name",
      "text": "description",
      "url": "link"
    }
  }
}

This example will in the end just open an URL: https://myapp.com/share.html?name={webshare.title}&description={webshare.text}&link={webshare.url}.
In your application you can now process those values. In YTAudio for example I'm taking the text property from the YouTube App (which contains the video URL) and I'll pass this to the videolink-GET param, so it will open an URL like this: https://ytaud.io/?videolink=https://www.youtube.com/watch?v=lNOP5dcLZF4.
My web app will then look for the video link param, it will parse the video id and it can then open the player for the audio file.

Or in a very basic React component:

import React from 'react';

const ShareTargetHandler = () => {
  const videolink = parsedUrl.searchParams.get('videolink');
  return <p>Videolink: {videolink || 'none'}</p>
});

As you can see this is a pretty basic example. But the same API can also be used to generate POST-Requests and therefore also for files. In that case make sure you handle those requests either on the server-side or in your ServiceWorker.
Unfortunately I haven't had a case yet where I could use this. So I have no first-hand experience with Share Target Post requests. But there is a great article that explains this in detail:
https://web.dev/web-share-target/#accepting-files

State of the proposal

Right now the Share Target API is a very experimental API. Chrome on Android is the only browser that supports it at the moment and the w3c proposal is still an early draft: https://wicg.github.io/web-share-target/

It's quite possible that there will be changes to the API. But the feature itself is just so useful that I'm pretty sure it will evolve to a web standard in the near future.