Possible FEP proposal: cross-Android app way to open Object

[keunes]

@helge

Sure, the following is a quick shot. It probably doesn’t cover everything needed:

Thanks!

@helge

which will then allow other websites to use links of the form

<a href="web+fedi:https://url">Like on the Fediverse</a>

Hmm. The purpose of the proposal/discussion was to allow Android apps to open an AP object in a dedicated app. So let’s try and turn this example away from ‘websites’ and <a> tags, and only include an Android app example instead. (Other discussions already focus on cross-website communication.)

An attempt, blatantly copied from the Android docs & adjusted with the help of ChatGPT:

// Set the ActivityPub object URL
String postUrl = "web+fedi://post/${encoded post uri}";

// Create the intent.
Intent openObjectIntent = new Intent();
openObjectIntent.setAction(Intent.ACTION_VIEW);
openObjectIntent.setData(Uri.parse(postUrl));

// Try to invoke the intent.
try {
    startActivity(openObjectIntent);
} catch (ActivityNotFoundException e) {
    // Show dialog explaining what the Fediverse is and an OK button, pressing on which opens the web browser to view the object.
}

---

@nikclayton

You can start this today – you don’t need approval, or a formal FEP proposal at this time to do this.

If I understand correctly, your main point is that we shouldn’t create a new URI scheme, because we’d be (quote) “risking polluting a global namespace, and/or stomping on anyone else who’s working in the same area”.

For these reasons, I guess, I was strongly recommended to start the process for an FEP.

Now you’re telling me to do the opposite. But OK, opinions differ. I have no technical expertise so I’m neutral on the chosen solution.

Instead, you say, we should use the content:// scheme and MIME types, because it doesn’t have the above risk, offers more flexibility and allows to experiment with functionality.

@nikclayton

Do this, roll it out, and wait a few months.

During that time you will undoubtedly discover that there is additional functionality that would be helpful, better ways of referencing the posted content, and so on.

Just to note on the additional functionality: in the Fedilab thread you gave some examples: “Is it just opening a post? Or is composing, replying, boosting, etc also in scope? If not in scope now, could they conceivably be in scope in the future (and if so, any proposal should be clearly extensible to do that).”

Let me add a reminder again that the functionality that we’re looking for here, and which should be the purpose of a proposal, is to offload functionality & UX/UI – not to integrate it.

In other words: no composing/boosting/liking inside the caller app. (If there are apps/folks interested in that, let them make their own proposal and convince client apps to use their work without ever surfacing their app.)

The only thing I can think of right now in terms of functionality, is that, in addition to opening a read view (for a post/user), it might be handy to also have a way to open a compose view, so you can directly start writing your message.

@nikclayton

AntennaPod can create Android intents with the MIME type application/vnd.com-antennapod, action set to ACTION_VIEW, and the data portion set to a structured representation of the content to view, almost certainly expressed as a content:// URI.

So let me note what I don’t like about your suggestion: it has the AntennaPod brand name in the technical stuff. If today AntennaPod implements the caller side and tomorrow Fedilab and Subway Tooter implement reception, then what should Funkwhale for Android (FfA) do when I ask them next week to implement the same functionality? Use the AntennaPod branding in their code? Make a FfA-specific implementation and ask Fedilab & Subway Tootet to implement that, too? Neither sounds desirable.

In other words: can we make your suggested approach app-neutral? (I honestly have no idea.)