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

ActivityPub
1

Hello,

There’s a new idea for podcasts: ActivityPub-based cross-app episode comments. TL:DR – each episode (of podcasts taking part) has a ‘root’ object. Replies can be posted to it as usual. Example: Linux + Open Source News, by TLE's post - the episode is an AP Object on which I can comment/post a reply.

In AntennaPod, the open source podcast player for Android, we would like to make it easy to access & join listener conversations.

  • we do not want to implement a UI/UX to interact with the Object (too much functionality we’d have to implement)
  • we do not want another way to do stuff with/on the Object (we’re not interested in just having the interface to, for example, ‘boost’ and then offload the AP stuff to another app which does it on our behalf)
  • we DO want a way to open the root Object in a dedicated app, so that the user can use all the ActivityPub features they’re used to

Initial announcement/request: AntennaPod: "Dear Fedilab (@apps@toot.fedilab.app), @Tusky@mas…" - Fosstodon

I’m aware there have been previous discussions on Server-to-Server communication, within the context of a single web browser. This request is explicitly not that. Here, we’re looking for a common way for a non-ActivityPub Android app to open an Object in a dedicated ActivityPub Android app.

The solution may be the same, but I suspect it’ll be simpler.

What those with technical expertise (I’m not one of 'em) have discussed, are, for example an implicit intent like web+activitypub://object/${encoded object uri}. Those discussions have taken place here:

The suggestion was to turn it into a FEP. I’m the initiator, but not having the technical expertise and without a clear conclusion on the way forward, I don’t feel comfortable (yet) to register an official FEP.

Hence this post, with the encouragement to everyone to share their thoughts and viewpoints on this topic. So we can hopefully prepare an FEP that AntennaPod and interested ActivityPub clients can implement together!

2 Likes
2

Thanks for the new thread.

Will my previous proposal meet the above requirements?

web+activitypub://post/${encoded AP object URI}

example: web+activitypub://post/https%3A%2F%2Ffosstodon.org%2F%40AntennaPod%2F109844984567859264

I’ll explain again why I structured each part of the URI that way.

scheme part

it would be nice to PWA or Web app can open the link, because those has a lot of users.
The schema names they can be registered by web apps are limited.

web+** style is for it.
ht tps://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler#permitted_schemes

(TBD) in this example I use activitypub for scheme suffix, but this is too generic and it may raise name confliction for other links. is there something more good?

authority(host) part

Google currently requires a server-side assetlinks.json when opening a combination of http, https schemes and specific hostnames from app.

documentation: Verify Android App Links  |  Android Developers

Since it is practically impossible for an SNS app to request many servers to install it, currently there are restrictions on how to open the Fediverse URI with an SNS app.

That constraint is currently limited to the http,https schema, but Google may extend it to any schema.

The workaround is not to write a character string that can be interpreted as a host name in the authority (host) part of the URI.

So what should we write in this part?

I think it’s keyword that identify data types in terms of Client-Server API concepts.

  • object (from AP’s data type)
  • actor (from AP’s data type)
  • post (more short for human readability)
  • user (more short for human readability)

(in this example: I’m assuming a variation like web+activitypub://user/@user@domain)

(TBD) I have no idea which one is better in AP’s data type or human readability.

encoded AP post URI

Strictly, SNS client apps may not use ActivityPub directly. they use Client-Server API for each servers.
But SNS servers have a lookup/import API from AP URI to a post entity.

Those allows AP URI or acct (@user@domain), but some servers have different API for users and posts. then app may need information about data type. In this proposal, it is in the host part. See previous section.

Keep it simple

This proposal excludes elements such as including the version in the URI. Who wants a version number in a mailto: URI?

Ensure future scalability

This proposal does not use the query part at all. It is left for future extension.

Also, I think that it is possible to extend the host part by including a version specification separated by :. (not discuss now)

test implementations

Simple URI converter ht tps://juggler.jp/test/fedilink/ that allow convert URI and open from web browser.

Subway Tooter 5.518+ can receive URI that genereted by converter.
ht tps://github.com/tateisu/SubwayTooter/releases/tag/v5.518

caller’s implementation of native-app is not yet exists.

There was an issue that the caller app might not handle well.
If there is no app on your Android device to open it, your web browser will try to open web+activitypub://. If there is no protocol handler on the browser side, it just shows a blank page.
If this is a problem you might want to remove “web+” from the schema name, but that would also eliminate the possibility of PWAs and web apps opening URIs.

(some links in this reply is broken by restriction of this site.)
(temporary I can not reply in this thread due to restriction of this site that allow just 1 comment in a thread.)

1 Like
3

Hi. First welcome resp. welcome back to SocialHub.

While I appreciate the intend of the idea, the current proposal of web+activitypub is horrible and would hopefully lead to all kinds of trouble down the road. At least if ActivityPub becomes more popular.

The bad case scenario

Imagine the following situation. In 2023, three popular ActivityPub services emerge:

  • Microblogging aka Mastodon. Objects correspond to short Status messages
  • Offerbot sees a sudden surge in development and becomes the de facto standard marketplace
  • Sound bites: A service that allow people to share short audio segments, either newly recorded or as a pointer to a segment of a podcast

All three services use web+activitypub to refer to open objects and as they all have equal right to it being ActivityPub implementations. This leads to only one of these services being usable on the same device.

Solution

Use a less generic name.

Sidebar

I actually don’t think that there is a use case for ActivityPub objects being handled by an end user device not used by a developer (defined as someone who likes to get his or her JSON-fu on). Thus a schema of the form:

web+fedi+microblog
web+fedi+offer
web+fedi+audiosegment

might be the thing to do.

2 Likes
4

I’m not sure I understand. Are you saying that there’s no functional need for a random AntennaPod user (who is not a developer) to open an Episode object?

5

You actually leave out the important part of my quote: Defining a developer as someone getting his JSON-fu on. Without it the quote is highly misleading.

Somebody not into JSON-fu, doesn’t want the ActivityPub object. They want a contextualized object, i.e. resolved linked data. Otherwise even displaying a username is impossible. That’s why I suggested a way that would allow you to contextualize the ActivityPub object, so a proper viewing form can be chosen.

To further make my point, if you enter the id of an ActivityPub object in the Mastodon Web UI, while the network tab is open, you will not be able to find the ActivityPub object in the responses, only what Mastodon thinks it should look like.

6

I’m sorry, I honestly didn’t understand it.

I think I understand now, thanks :slight_smile:

I have two other questions, though:

  • You seem to imply (at least that’s how I understood it now) that if we’d use web+activitypub, we’d only get the ‘raw data’ (the JSON) and not the user interface. But doesn’t that depend on which intent filters are registered on the phone?
    • I.e. Subway Tooter already implemented an intent and it shows the object in the expected UI, rather than the raw data.
    • If there’s no intent registered on the phone, I understood (from @tateisu’s comments) that it’ll fall back to the web intent just using the target URL.
  • I see your point about further specifying the type of ActivityPub object. But
    • I believe I read in some of the other discussions (possibly in the Server-to-Server domain) arguments for not specifying further the type of content; that they’re all ActivityPub objects and that they should all be able to interact (regardless a ‘sub’ type)
    • if there are three apps that include the above intent and all have the equal right - doesn’t Android show all apps you can open the intent with? I see such list of ‘possible apps’ all the time - or is that something else?
7

Now, I’m saying web+activitypub is a bad name for what you want. You want something like web+fedi+FORMAT. For almost all Android Apps, including Subway Tooter, the ActivityPub objects are irrelevant. So let’s use a type name that actually describes what they are doing (querying APIs of things that spec ActivityPub with each other).

As far as I’m concerned, there should be no web+activitypub type.

Also to say it again, I’m all for this proposal. My only problem with it, is that web+fedi describes what is happening better.

1 Like
8

I completely agree with you about the need for uniqueness. That scheme name I mentioned is a random abstraction from past discussions, and it’s not a serious proposal.

The first part of the schema name “web+” requires testing that the calling app handles exceptional conditions well, it’s technical matter.

The rest part of schema name is discussed about uniqueness. frankly, anything that doesn’t clash with other people’s ideas of names is good. But will you don’t like randomly name?

1 Like
9

In the thread over at Fedilab, @silverpill noted the following - which I read as ‘objects are more relevant terminology than posts’. So I updated my initial post accordingly:

But it’s not my expertise and I’m probably misunderstanding it again. To my untrained ears, web+activitypub sounds as good as web+fedi. Anyway, I don’t have any opinion about it :slight_smile:

So, how can we turn this into a ‘proper’ proposal?

fep/fep-a4ed.md at main - fep - Codeberg.org notes we need (in addition to some other things):

  • A title
  • Summary: A short (no more than 200 words) summary of the proposal
  • Implementations: If applicable an overview of services or applications that implement the proposal at time of submission

Now, I’m not sure about the actual contents; how to approach it. Maybe we can start drafting something together? fep/fep-400e.md at main - fep - Codeberg.org seems to be quite extensive - not sure if the proposal for this use case might be simpler/shorter?

10

Yes, if you pick web+activitypub scheme, I think it would be better to use ActivityPub’s terms (such as “object”). But if you go with web+fedi then “post” is totally fine.

Personally I’m in favor of generic solutions (that’s why I like GitHub - activitypub-schema/proposal: Interact with others without coping URLs!) but I’m not familiar with Android development.

There are no rules regarding the length. Your proposal can be short and even non-technical (see fep/fep-c118.md at main - fep - Codeberg.org for example).

11

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

FEP-10c4: Fediverse URL Scheme

Summary

This proposal introduces the URL Scheme: web+fedi:object to address elements of the FediVerse. By using this URL Scheme, websites or applications, can easily provide links such as “Reply on the FediVerse” or “Like in the FediVerse”, that allow the user to achieve this with a single click instead of having to enter their server URL.

Problems to be solved (FIXME)

  • How do we want to actually convey the intention to Like / Reply?
  • Should we allow a way to convey something’s type, e.g. microblog?

Implementations

For an Android proposal see, [Android]. Registering a website to handle this can be done following [WWG-CH] by

navigator.registerProtocolHandler('web+fedi', 'open?url=%s')

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

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

[Android] tom97: #792 - Declare intent filter to open a post - Fedilab - Codeberg.org
[WWG-CH] 8.9.1.4 Custom scheme handlers: the registerProtocolHandler() method HTML Standard

12

As noted at #792 - Declare intent filter to open a post - Fedilab - Codeberg.org, you can achieve what you want without introducing a new URL scheme.

To do this, 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.

AntennaPod can then document how clients like Tusky or Fedilab are supposed to interpret the data portion of an intent with that MIME type. Then those clients can implement intent filters for that data and present it to their users in the appropriate fashion.

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.

Then you can come back here with a proposal that is informed by real-world experience.

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

2 Likes
13

Thanks!

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.
}

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.

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.

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.)

14

I’m saying you shouldn’t create a new URI scheme yet. You can achieve what you want, now, without one, and using a MIME type initially will let you get valuable information to inform a future, better proposal for a URI scheme.

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?

First, it’s not “branding”, any more than an app processing the “image/jpeg” MIME type is somehow “branding” the code with the Joint Photographic Experts Group.

Second, yes, if FunkWhale wants to achieve the exact same thing then they should use the same MIME type.

There are two reasons why they might not do that.

a. They consider it a branding issue. If they come to an open source project and say "Hey, we want you to duplicate this code that you’ve already got, but use audio.funkwhale instead of org.antennapod[1] then see point 1, and they’ll get laughed at.

b. They want functionality that you don’t want[2], and/or is not expressible in your content:// URL schema. In which case they should first be encouraged to work with AntennaPod to extend the schema in a useful way. Hopefully AntennaPod and FunkWhale work together constructively to do that. If they don’t, FunkWhale can approach the open source projects and say “Hey, we’d like this functionality, we tried to work with the AntennaPod folks with it but they refused to add it to the schema, so we want to send intents with vnd.audio-funkwhale to express that. Here’s a PR.”

Either way, after some time has passed we have real-world experience with one or more Android intents that use the vnd. prefix, and that experience can be used to inform a future FEP.

[1] My previous message used application/vnd.com-antennapod as the example MIME type, I should have used org instead of com.

[2] This is why I’m wary of your claims that this will only have a very small set of use cases. AntennaPod might only have a very small set of use cases, but other apps might have a larger set. Doing a trial with a vnd. prefixed MIME type allows you to discover those use cases safely.

1 Like