keunes commented

Mastodon
Pleroma
Friendica
Pixelfed

There's a new idea for podcasts: cross-app comments based on ActivityPub (https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md#social-interact). TL:DR – each episode (of podcasts taking part) has a 'root' post. Replies can be posted to it as usual. Example: https://podcast.thelinuxexp.com/@tlenewspodcast/posts/3be3bb49-690d-4deb-84e7-66da3c4567df

In AntennaPod, the open source podcast player for Android, we would like to make it easy to access & join listener conversations. But rather than including a full interface to view and post comments, the idea is to let dedicated apps handle this. Concretely: from AntennaPod you hit a button to open an episode's root post in your favourite ActivityPub/Mastodon app. You then have all the great features you're used to. And if you don't have such app installed, we'll display a short explanation and guide you to some options.

We could just link to the root post URL, but that's not guaranteed to open the right app if installed. And we wouldn't be able to give the user an explanation if such app is not installed.

So, we need an alternative. As I understand, declaring an intent filter is the best alternative. AntennaPod can then send an implicit intent in order to open a post. For example: web+activitypub://post/${encoded post uri}

Long story short - it would be great if Fedilab could implement an intent filter to open posts, so that AntennaPod can call such intent. Curious to hear your thoughts. (Other apps should do the same for this to work well, of course. But Fedilab as a start would be a great start, but great for me to test as I us it actively.)

[x] - I read the contributing page

- [x] Mastodon - [ ] Pleroma - [ ] Friendica - [ ] Pixelfed  There's a new idea for podcasts: cross-app comments based on ActivityPub (https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md#social-interact). TL:DR – each episode (of podcasts taking part) has a 'root' post. Replies can be posted to it as usual. Example: https://podcast.thelinuxexp.com/@tlenewspodcast/posts/3be3bb49-690d-4deb-84e7-66da3c4567df In AntennaPod, the open source podcast player for Android, we would like to make it easy to access & join listener conversations. But rather than including a full interface to view and post comments, the idea is to let dedicated apps handle this. Concretely: from AntennaPod you hit a button to open an episode's root post in your favourite ActivityPub/Mastodon app. You then have all the great features you're used to. And if you don't have such app installed, we'll display a short explanation and guide you to some options. We could just link to the root post URL, but that's [not](https://issuetracker.google.com/issues/258270055) guaranteed to open the right app if installed. And we wouldn't be able to give the user an explanation if such app is not installed. So, we need an alternative. As I understand, [declaring an intent filter](https://developer.android.com/guide/components/intents-filters#Receiving) is the best alternative. AntennaPod can then send an [implicit intent](https://developer.android.com/guide/components/intents-filters#ExampleSend) in order to open a post. For example: web+activitypub://post/${encoded post uri} See also: https://fosstodon.org/@AntennaPod/109844984567859264 https://github.com/tuskyapp/Tusky/issues/3321 https://github.com/activitypub-schema/proposal/blob/main/PROPOSAL.md https://github.com/fedi-to/fedi-to.github.io/blob/main/webap.md Long story short - it would be great if Fedilab could implement an intent filter to open posts, so that AntennaPod can call such intent. Curious to hear your thoughts. (Other apps should do the same for this to work well, of course. But Fedilab as a start would be a great start, but great for me to test as I us it actively.)  [x] - I read the [contributing page](https://codeberg.org/tom79/Fedilab/src/branch/main/CONTRIBUTING.md)

tom79 commented

2023-02-13 14:48:08 +00:00

Owner

So, you want that we add that on our code to deal with custom scheme to open dedicated messages?

web+activitypub://post/${encoded post uri}

<intent-filter android:label="AntennaPod">
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />
    <data android:scheme="web+activitypub"
          android:host="post" 
          android:path="*" />
</intent-filter>

So, you want that we add that on our code to deal with custom scheme to open dedicated messages? `web+activitypub://post/${encoded post uri}` ```xml <intent-filter android:label="AntennaPod"> <action android:name="android.intent.action.VIEW" /> <category android:name="android.intent.category.DEFAULT" /> <category android:name="android.intent.category.BROWSABLE" /> <data android:scheme="web+activitypub" android:host="post" android:path="*" /> </intent-filter> ```

tom79 added the

discussion

label 2023-02-13 14:48:32 +00:00

keunes commented

2023-02-15 07:37:49 +00:00

Poster

I'm not a developer myself so I can't say much about the details or the code/intent that you prepared. But yes, in general the idea would be to ask all ActivityPub-driven apps (incl. Tusky, Mastodon, Subway Tooter, Tooot, etc) to register such intent, so that other apps (like AntennaPod) can open an ActivityPub post/object.

The purpose is not to make it AntennaPod-specific; the idea is that it would work for any other app that wants to open a post :-) (So maybe the intent name should be changed to 'OpenPost' or something?)

I'm not a developer myself so I can't say much about the details or the code/intent that you prepared. But yes, in general the idea would be to ask all ActivityPub-driven apps (incl. Tusky, Mastodon, Subway Tooter, Tooot, etc) to register such intent, so that other apps (like AntennaPod) can open an ActivityPub post/object. The purpose is not to make it AntennaPod-specific; the idea is that it would work for any other app that wants to open a post :-) (So maybe the intent name should be changed to 'OpenPost' or something?)

tom79 commented

2023-02-15 18:50:10 +00:00

Owner

Does AntennaPod suggest a guidelines for that? What should we follow to be aware of that?

keunes commented

2023-02-15 21:28:03 +00:00

Poster

Does AntennaPod suggest a guidelines for that? What should we follow to be aware of that?

Guidelines for what exactly?

In general I can say that, as this is a new area of work, I guess we need to agree between us (and, ideally, the wider ActivityPub app space). If you have specific ideas for how the intent should work (in order to open a post/object), AntennaPod can follow suit.

> Does AntennaPod suggest a guidelines for that? What should we follow to be aware of that? Guidelines for what exactly? In general I can say that, as this is a new area of work, I guess we need to agree between us (and, ideally, the wider ActivityPub app space). If you have specific ideas for how the intent should work (in order to open a post/object), AntennaPod can follow suit.

tateisu commented

2023-02-16 08:00:46 +00:00

I think the content of the proposal is appropriate.

Using web+** allows registering protocol handlers from the web site or PWA web app. https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/protocol_handlers
Not including the actual host name in the authority(host) part is reasonable given the increased restriction by Google. If it contains a real hostname, Google will force you to put a file on the server side to authorize it. For many apps that is impractical.
It's okay to put the post URI in the path part after post/ . If you want to add parameters later, the entire query clause can be used.

However, we need to test this works on real device.

I think the content of the proposal is appropriate. - Using `web+**` allows registering protocol handlers from the web site or PWA web app. https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/protocol_handlers - Not including the actual host name in the authority(host) part is reasonable given the increased restriction by Google. If it contains a real hostname, Google will force you to put a file on the server side to authorize it. For many apps that is impractical. - It's okay to put the post URI in the path part after post/ . If you want to add parameters later, the entire query clause can be used. However, we need to test this works on real device.

tateisu commented

2023-02-16 08:04:40 +00:00

I'm following this issue at https://github.com/tateisu/SubwayTooter/issues/231

nikclayton commented

2023-02-16 12:41:43 +00:00

Following up from the same issue posted over at https://github.com/tuskyapp/Tusky/issues/3321 because I think it's helpful to try and have the discussion and feedback in one place so we don't repeat ourselves. Fedilab folks, hi, I hope you don't mind. If you do, please say so and I'll fork the discussion back to the Tusky issue.

Some initial thoughts:

Version numbers

Please include version numbers as explicit items in protocols.

Custom intent and MIME type?

Could this be implemented / prototyped as something that is AntennaPod specific. If it proves to be worthwhile there's then real world evidence that it should be made more "standard".

For example, AntennaPod could create implicit intents with a MIME type of application/x-antennapod and send content: scheme intents, to be processed with:

<intent-filter>
  <data android:mimeType="application/x-antennapod" />
</intent-filter>

Bonus points if you provide a small library that Fedilab, Tusky, etc can depend on that provides functions for parsing content from the intent in a consistent fashion.

Webfinger?

Could this be implemented with existing webfinger Well-Known URIs (WKU) instead of a new scheme?

Instead of web+activitypub://post/${encoded post uri}, something like:

https://{somehost}/.well-known/webfinger?
  resource=${encoded_post_uri}
  protocol=activitypub

I think (but have not checked) that Android apps can catch this with:

<intent-filter>
  <data android:host="*"
        android:pathPrefix="/.well-known/webfinger?"
        android:pathPattern="protocol=activitypub" />
</intent-filter>

Prior art

Have any of the proposers read https://www.rfc-editor.org/rfc/rfc7595 (Guidelines and Registration Procedures for URI Schemes) and https://www.rfc-editor.org/rfc/rfc8615 (Well-Known Uniform Resource Identifiers)? The previous documents (PROPOSAL.md and webap.md) don't mention them, nor does this, so it's not clear.

New Well-Known URI?

Instead of a new URI scheme or webfinger, could this be achieved with Well-Known URIs like https://{anything}/.well-known/activitypub/v1/...? There's a list of existing registered WKUs at https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml

That community and the associated mailing list at https://www.ietf.org/mailman/listinfo/wellknown-uri-review should also be consulted, as I'm sure they'll have very relevant feedback.

Intended supported activities?

Is there an enumeration of all the different activities that would be supported by this? 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).

For example, you could want to allow users to boost an episode by sending an intent that an app receives, boosts the post in the background, and the app returns a success/failure response to AntennaPod. The user never sees the app's UI in this scenario.

Multiple accounts

What is the UX supposed to be if the user has multiple accounts configured in their client?

UX when no app is installed

Re this:

And if you don't have such app installed, we'll display a short explanation and guide you to some options.

Can't the post be opened in the user's browser instead?

Hope that's all helpful food for thought.

Following up from the same issue posted over at https://github.com/tuskyapp/Tusky/issues/3321 because I think it's helpful to try and have the discussion and feedback in one place so we don't repeat ourselves. Fedilab folks, hi, I hope you don't mind. If you do, please say so and I'll fork the discussion back to the Tusky issue. Some initial thoughts: # Version numbers **Please** include version numbers as explicit items in protocols. # Custom intent and MIME type? Could this be implemented / prototyped as something that is AntennaPod specific. If it proves to be worthwhile there's then real world evidence that it should be made more "standard". For example, AntennaPod could create implicit intents with a MIME type of `application/x-antennapod` and send `content:` scheme intents, to be processed with: ``` <intent-filter> <data android:mimeType="application/x-antennapod" /> </intent-filter> ``` Bonus points if you provide a small library that Fedilab, Tusky, etc can depend on that provides functions for parsing content from the intent in a consistent fashion. # Webfinger? Could this be implemented with existing webfinger Well-Known URIs (WKU) instead of a new scheme? Instead of `web+activitypub://post/${encoded post uri}`, something like: ``` https://{somehost}/.well-known/webfinger? resource=${encoded_post_uri} protocol=activitypub ``` I think (but have not checked) that Android apps can catch this with: ``` <intent-filter> <data android:host="*" android:pathPrefix="/.well-known/webfinger?" android:pathPattern="protocol=activitypub" /> </intent-filter> ``` # Prior art Have any of the proposers read https://www.rfc-editor.org/rfc/rfc7595 (Guidelines and Registration Procedures for URI Schemes) and https://www.rfc-editor.org/rfc/rfc8615 (Well-Known Uniform Resource Identifiers)? The previous documents (PROPOSAL.md and webap.md) don't mention them, nor does this, so it's not clear. # New Well-Known URI? Instead of a new URI scheme or webfinger, could this be achieved with Well-Known URIs like `https://{anything}/.well-known/activitypub/v1/...`? There's a list of existing registered WKUs at https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml That community and the associated mailing list at https://www.ietf.org/mailman/listinfo/wellknown-uri-review should also be consulted, as I'm sure they'll have very relevant feedback. # Intended supported activities? Is there an enumeration of all the different activities that would be supported by this? 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). For example, you could want to allow users to boost an episode by sending an intent that an app receives, boosts the post in the background, and the app returns a success/failure response to AntennaPod. The user never sees the app's UI in this scenario. # Multiple accounts What is the UX supposed to be if the user has multiple accounts configured in their client? # UX when no app is installed Re this: > And if you don't have such app installed, we'll display a short explanation and guide you to some options. Can't the post be opened in the user's browser instead? Hope that's all helpful food for thought.

❤️ 1

tateisu commented

2023-02-16 16:26:45 +00:00

https://{somehost}/… is not good for common custom url schema that is not bind to specific app and specific site.

because Google requires "Digital Asset Links JSON" that indicate HOST allows which APP can open the link. https://developers.google.com/digital-asset-links/v1/getting-started

to open android apps, using URL that schema is http, https and bind to specific host, it is meanful only in case of app and host is strongly bind, but fediverse app is not so.

https://{somehost}/… is not good for common custom url schema that is not bind to specific app and specific site. because Google requires "Digital Asset Links JSON" that indicate HOST allows which APP can open the link. https://developers.google.com/digital-asset-links/v1/getting-started to open android apps, using URL that schema is http, https and bind to specific host, it is meanful only in case of app and host is strongly bind, but fediverse app is not so.

tateisu commented

2023-02-16 16:48:48 +00:00

What nikclayton is talking about is overall far from the essence of the proposal.

The proposal is to wrap the AP post URI in a custom URL schema so that it can be opened by many apps. avoid http,https, avoid specific host part.
Apps can respond to the AP post URI in several ways.
- That works base on post URI is AP compatible.
- The easiest way is that client app send URI to Mastodon's search API.
- also we can traverse WebFinger if you want to directly use AP, but I think this is rare case. In many cases, we need to import the post into reader user's server before they can react to it. most case it means using server's search API or similar.
The MIME type indicates the type of content, but what kind of content is a depends on post URI, actually returns is a server-specific issue. And it is not really necessary for the application to know that, because our app just send URI to server's search API (or similar). in this case content-type is not a matter.
Automated actions can be abused.

Translated with www.DeepL.com/Translator (free version)

What nikclayton is talking about is overall far from the essence of the proposal. - The proposal is to wrap the AP post URI in a custom URL schema so that it can be opened by many apps. avoid http,https, avoid specific host part. - Apps can respond to the AP post URI in several ways. - That works base on post URI is AP compatible. - The easiest way is that client app send URI to Mastodon's search API. - also we can traverse WebFinger if you want to directly use AP, but I think this is rare case. In many cases, we need to import the post into reader user's server before they can react to it. most case it means using server's search API or similar. - The MIME type indicates the type of content, but what kind of content is a depends on post URI, actually returns is a server-specific issue. And it is not really necessary for the application to know that, because our app just send URI to server's search API (or similar). in this case content-type is not a matter. - Automated actions can be abused. Translated with www.DeepL.com/Translator (free version)

❤️ 1

tateisu commented

2023-02-16 17:04:28 +00:00

What the app should do when it receives this URL:.

Determine which saved account to open the post with.
- There is a different policy for different apps.
Request the server with that account to perform an import operation on the post.
- (In Mastodon, the search API does this. Other services may have similar operations.)
- the post may not found (blocked, network issue, etc…)
Display the post on reader's server.
- The user may be able to react to it, but it is not guaranteed.

What the app should do when it receives this URL:. - Determine which saved account to open the post with. - There is a different policy for different apps. - Request the server with that account to perform an import operation on the post. - (In Mastodon, the search API does this. Other services may have similar operations.) - the post may not found (blocked, network issue, etc…) - Display the post on reader's server. - The user may be able to react to it, but it is not guaranteed.

tateisu commented

2023-02-16 17:48:24 +00:00

testing implementation in Subway Tooter.
https://mastodon.juggler.jp/@SubwayTooter/109875655056667836

long ago we used to be able to open some https://host/@user/numId style URLs, but due to Google's restrictions we couldn't open them now.
this time handling the proposal is just to rewrite it a little, and there is no difficulty at all.

testing implementation in Subway Tooter. https://mastodon.juggler.jp/@SubwayTooter/109875655056667836 long ago we used to be able to open some https://host/@user/numId style URLs, but due to Google's restrictions we couldn't open them now. this time handling the proposal is just to rewrite it a little, and there is no difficulty at all.

❤️ 1

tateisu commented

2023-02-16 18:21:56 +00:00

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.
Is this something the calling app can handle?

please try https://juggler.jp/test/fedilink/ on your android device.

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. Is this something the calling app can handle? please try https://juggler.jp/test/fedilink/ on your android device.

nikclayton commented

2023-02-16 18:50:36 +00:00

@tateisu:

to open android apps, using URL that schema is http, https and bind to specific host, it is meanful only in case of app and host is strongly bind, but fediverse app is not so.

What happens if the android:host part of the filter is *, as in:

<intent-filter>
  <data android:host="*"
        ... />
</intent-filter>

?

@keunes:

The proposal is to wrap the AP post URI in a custom URL schema so that it can be opened by many apps. avoid http,https, avoid specific host part.

All of that could be done with a custom intent and mime type. I haven't seen anything that requires a new URI scheme.

Just in case I wasn't sufficiently clear above, to view the root post AntennaPod could construct an intent like this:

val i = Intent().apply {
    action = Intent.ACTION_VIEW
    setDataAndType(
        "content://org.antennapod/v1/post/$encodedPostUrl",
        "application/x-antennapod"
    )
}

and apps would have this intent filter:

<intent-filter>
  <android:scheme="content" />
  <android:mimeType="application/x-antennapod" />
</intent-filter>

This:

Embeds a version number in the content:// URL, so it's easy to evolve over time
Is extendable to other actions (boost, favourite, bookmark, etc)
Requires no new WKU or scheme, the combination of scheme + mimetype is sufficient

@tateisu: > to open android apps, using URL that schema is http, https and bind to specific host, it is meanful only in case of app and host is strongly bind, but fediverse app is not so. What happens if the `android:host` part of the filter is `*`, as in: ``` <intent-filter> <data android:host="*" ... /> </intent-filter> ``` ? @keunes: > The proposal is to wrap the AP post URI in a custom URL schema so that it can be opened by many apps. avoid http,https, avoid specific host part. All of that could be done with a custom intent and mime type. I haven't seen anything that requires a new URI scheme. Just in case I wasn't sufficiently clear above, to view the root post AntennaPod could construct an intent like this: ``` val i = Intent().apply { action = Intent.ACTION_VIEW setDataAndType( "content://org.antennapod/v1/post/$encodedPostUrl", "application/x-antennapod" ) } ``` and apps would have this intent filter: ``` <intent-filter> <android:scheme="content" /> <android:mimeType="application/x-antennapod" /> </intent-filter> ``` This: 1. Embeds a version number in the content:// URL, so it's easy to evolve over time 2. Is extendable to other actions (boost, favourite, bookmark, etc) 3. Requires no new WKU or scheme, the combination of scheme + mimetype is sufficient

nikclayton commented

2023-02-16 18:54:04 +00:00

long ago we used to be able to open some https://host/@user/numId style URLs, but due to Google's restrictions we couldn't open them now.

That doesn't work either though, even with host="*". I have Fedilab on one of my devices, and it has this intent filter.

The effect is that it hijacks links to Medium article, because they look like https://somedomain.com/@authorname/path-to-post. (e.g., https://medium.com/@Zhuinden/an-update-to-the-fragmentviewbindingdelegate-the-bug-weve-inherited-from-autoclearedvalue-7fc0a89fcae1)

It got so bad I went in to the Android settings and disabled Fedilab's ability to do this.

> long ago we used to be able to open some https://host/@user/numId style URLs, but due to Google's restrictions we couldn't open them now. That doesn't work either though, even with `host="*"`. I have Fedilab on one of my devices, and it has this intent filter. The effect is that it hijacks links to Medium article, because they look like `https://somedomain.com/@authorname/path-to-post`. (e.g., https://medium.com/@Zhuinden/an-update-to-the-fragmentviewbindingdelegate-the-bug-weve-inherited-from-autoclearedvalue-7fc0a89fcae1) It got so bad I went in to the Android settings and disabled Fedilab's ability to do this.

tateisu commented

2023-02-16 19:56:34 +00:00

What are the advantages of using MIME types instead of URL schemes?

tateisu commented

2023-02-16 20:01:22 +00:00

In many cases, we are not aware of the MIME type when opening links.
The suggested URI doesn't use the query part at all, so we can add it later if we want. I have no reason to add it now. who want add version spec in mailto: URI ?

- In many cases, we are not aware of the MIME type when opening links. - The suggested URI doesn't use the query part at all, so we can add it later if we want. I have no reason to add it now. who want add version spec in mailto: URI ?

tateisu commented

2023-02-16 20:06:52 +00:00

What happens if the android:host part of the filter is *, as in:

We experienced that when Android 12 came.

> What happens if the `android:host` part of the filter is `*`, as in: We experienced that when Android 12 came.

tateisu commented

2023-02-16 20:16:45 +00:00

Although it may be superfluous to state this for the given example. The content:// schema is used to manage ContentProvider on Android devices, and the authority part is managed by the OS. Having multiple apps with the same authority is extremely bad. A schema that has other legitimate uses should not be used for completely unrelated uses.

tateisu commented

2023-02-16 20:34:27 +00:00

I am totally against automating actions. What he calls for is "a backdoor that spreads favorites and boosts without authentication". Those actions should be performed by explicit user manipulation, but receiver app can't trust sender that checked user's will.

I think it's the limit of acceptable to show message "{app name} is requesting boost this post". In other words, the suggestion text from sender is acceptable, but action is not.

I am totally against automating actions. What he calls for is "a backdoor that spreads favorites and boosts without authentication". Those actions should be performed by explicit user manipulation, but receiver app can't trust sender that checked user's will. I think it's the limit of acceptable to show message "{app name} is requesting boost this post". In other words, the suggestion text from sender is acceptable, but action is not.

circlebuilder commented

2023-02-17 07:16:01 +00:00

Wrt this subject I would strongly recommend considering following the Fediverse Enhancement Proposal process, that is picking up steam currently.

The repository sits here at Codeberg at: https://codeberg.org/fediverse/fep
And discussions take place at SocialHub, the ActivityPub developer community at: https://socialhub.activitypub.rocks

The FEP's main purpose is to avoid fragmentation and ad-hoc interoperability that is prevalent on the Fediverse, and the process will continue to be improved.

Wrt this subject I would strongly recommend considering following the Fediverse Enhancement Proposal process, that is picking up steam currently. The repository sits here at Codeberg at: https://codeberg.org/fediverse/fep And discussions take place at SocialHub, the ActivityPub developer community at: https://socialhub.activitypub.rocks The FEP's main purpose is to avoid fragmentation and ad-hoc interoperability that is prevalent on the Fediverse, and the process will continue to be improved.

👍 2

nikclayton commented

2023-02-17 12:36:44 +00:00

What are the advantages of using MIME types instead of URL schemes?

MIME types already have a standard mechanism for conducting experiments and creating potentially vendor-specific extensions before any standardisation attempt, with either the x- prefix (or, actually better) the vnd. prefix on the MIME subtype.

See https://www.nih-cfde.org/resource/intro-mime-type for example.

So it's easy to conduct limited experiments without risking polluting a global namespace, and/or stomping on anyone else who's working in the same area.

To the best of my knowledge, new schemes do not have this property (https://html.spec.whatwg.org/#web+-scheme-prefix).

It is possible that these experiments will demonstate a use for a web+activitypub prefix. But I think to try and use that scheme first, when safer options exist, is irresponsible.

In many cases, we are not aware of the MIME type when opening links.

I think you may be confused about the purpose of the MIME type in the intent.

The MIME type in an Android intent refers to the MIME type of the data carried in the intent, not the MIME type of the data referenced by the intent.

Proof: Look at https://developer.android.com/guide/components/intents-common#ViewUrl. The MIME type is one of text/plain, text/html, application/xhtml+xml, or application/vnd.wap.xhtml+xhtml. However, the URI in the data portion of the intent could be a URI to an image, or a video file, or a PDF, or any other MIME type.

So there is no need to know the MIME type of the data at the other end of the link.

Although it may be superfluous to state this for the given example. The content:// schema is used to manage ContentProvider on Android devices, and the authority part is managed by the OS. Having multiple apps with the same authority is extremely bad. A schema that has other legitimate uses should not be used for completely unrelated uses.

This is only partially correct.

Yes, Android Content Providers use content: URIs to resolve content.

No, their use is not restricted to just this. It is entirely possible for apps to create intents with content: URIs.

However, implementing this as Content Providers would also be a valid approach. Specifically, Fedilab, Tusky, etc would be Content Providers from AntennaPod's perspective.

That probably makes Fedilab et al more complicated, so I'm not sure that's worthwhile for an experiment, but it would be possible.

[Edit: the more I think about this, the more I think it might be a good end-goal. If Fedilab, Tusky, etc exposed a hypothetical "MastodonApiContentProvider" this would allow apps like AntennaPod to query through that instead of needing to write their own code that talks to the Mastodon API]

who want add version spec in mailto: URI ?

Good question. The mailto: scheme has gone through multiple revisions since it was first introduced in RFC 1738, via RFCs 2368 and 6068.

Because the original design did not include a version component each of those revisions had to ensure strict backwards compatability. That could have been avoided.

I am totally against automating actions. What he calls for is "a backdoor that spreads favorites and boosts without authentication". Those actions should be performed by explicit user manipulation, but receiver app can't trust sender that checked user's will.

That is a gross mischaracterisation of what I said. I'm going to assume that that is because we have different native languages, and not deliberate.

Here's a sketch of how that could work the first time the user clicks "Boost" in AntennaPod.

AntennaPod exposes a UI element to boost a podcast post
The user clicks it
AntennaPod constructs a "boost this post" intent, and sends it using startActivityForResult()
The app (Fedilab, Tusky, etc), receives the intent
The app uses getCallingPackage() or getCallingActivity() to, unspoofably, find the package name or component that sent the intent
The app uses this info, and methods from https://developer.android.com/reference/android/content/pm/PackageManager to display a dialog or similar:

The dialog message is something like "{Application} wants to boost {post} on your behalf".
Using PackageManager this can also include the sending application's logo
The user can approve or deny the request
The dialog includes a checkbox or other mechanism to allow the user to say "And trust future boost requests from this application"
If the user sets that option, the app writes the info about the sending package to an allowlist

The app returns a result to AntennaPod indicating whether or not the post was successfully boosted.

Now the user clicks "Boost" on a different post in AntennaPod.

Everything proceeds as before. Except this time, between steps 5 and 6 the app also checks the allowlist. If the sending package is listed as trusted then it performs the boost without needing to show any UI, and control returns back to AntennaPod. If it's not in the allowlist then the user sees the confirmation dialog.

The app would also need to provide a UI to allow the user to view the allowlist, and remove items from it.

And there is scope for more nuance, like "Trust this app for 90 days", or similar.

But this is entirely achievable in a way that is opt-in, preserves user choice, and allows the user to make the decision about which apps they trust.

> What are the advantages of using MIME types instead of URL schemes? MIME types already have a standard mechanism for conducting experiments and creating potentially vendor-specific extensions before any standardisation attempt, with either the `x-` prefix (or, actually better) the `vnd.` prefix on the MIME subtype. See https://www.nih-cfde.org/resource/intro-mime-type for example. So it's easy to conduct limited experiments without risking polluting a global namespace, and/or stomping on anyone else who's working in the same area. To the best of my knowledge, new schemes do not have this property (https://html.spec.whatwg.org/#web+-scheme-prefix). It is possible that these experiments will demonstate a use for a `web+activitypub` prefix. But I think to try and use that scheme first, when safer options exist, is irresponsible. > In many cases, we are not aware of the MIME type when opening links. I think you may be confused about the purpose of the MIME type in the intent. The MIME type in an Android intent refers to the MIME type of the data carried in the intent, not the MIME type of the data referenced by the intent. Proof: Look at https://developer.android.com/guide/components/intents-common#ViewUrl. The MIME type is one of `text/plain`, `text/html`, `application/xhtml+xml`, or `application/vnd.wap.xhtml+xhtml`. However, the URI in the `data` portion of the intent could be a URI to an image, or a video file, or a PDF, or any other MIME type. So there is no need to know the MIME type of the data at the other end of the link. > Although it may be superfluous to state this for the given example. The content:// schema is used to manage ContentProvider on Android devices, and the authority part is managed by the OS. Having multiple apps with the same authority is extremely bad. A schema that has other legitimate uses should not be used for completely unrelated uses. This is only partially correct. Yes, Android Content Providers use `content:` URIs to resolve content. No, their use is not restricted to just this. It is entirely possible for apps to create intents with `content:` URIs. However, implementing this as Content Providers would also be a valid approach. Specifically, Fedilab, Tusky, etc would be Content Providers from AntennaPod's perspective. That probably makes Fedilab et al more complicated, so I'm not sure that's worthwhile for an experiment, but it would be possible. [Edit: the more I think about this, the more I think it might be a good end-goal. If Fedilab, Tusky, etc exposed a hypothetical "MastodonApiContentProvider" this would allow apps like AntennaPod to query through that instead of needing to write their own code that talks to the Mastodon API] > who want add version spec in mailto: URI ? Good question. The `mailto:` scheme has gone through multiple revisions since it was first introduced in RFC 1738, via RFCs 2368 and 6068. Because the original design did not include a version component each of those revisions had to ensure strict backwards compatability. That could have been avoided. > I am totally against automating actions. What he calls for is "a backdoor that spreads favorites and boosts without authentication". Those actions should be performed by explicit user manipulation, but receiver app can't trust sender that checked user's will. That is a gross mischaracterisation of what I said. I'm going to assume that that is because we have different native languages, and not deliberate. Here's a sketch of how that could work the first time the user clicks "Boost" in AntennaPod. 1. AntennaPod exposes a UI element to boost a podcast post 2. The user clicks it 3. AntennaPod constructs a "boost this post" intent, and sends it using `startActivityForResult()` 4. The app (Fedilab, Tusky, etc), receives the intent 5. The app uses `getCallingPackage()` or `getCallingActivity()` to, unspoofably, find the package name or component that sent the intent 6. The app uses this info, and methods from https://developer.android.com/reference/android/content/pm/PackageManager to display a dialog or similar: - The dialog message is something like "{Application} wants to boost {post} on your behalf". - Using PackageManager this can also include the sending application's logo - The user can approve or deny the request - The dialog includes a checkbox or other mechanism to allow the user to say "And trust future boost requests from this application" - If the user sets that option, the app writes the info about the sending package to an allowlist 7. The app returns a result to AntennaPod indicating whether or not the post was successfully boosted. Now the user clicks "Boost" on a different post in AntennaPod. Everything proceeds as before. Except this time, between steps 5 and 6 the app also checks the allowlist. If the sending package is listed as trusted then it performs the boost without needing to show any UI, and control returns back to AntennaPod. If it's not in the allowlist then the user sees the confirmation dialog. The app would also need to provide a UI to allow the user to view the allowlist, and remove items from it. And there is scope for more nuance, like "Trust this app for 90 days", or similar. But this is entirely achievable in a way that is opt-in, preserves user choice, and allows the user to make the decision about which apps they trust.

silverpill commented

2023-02-17 15:02:56 +00:00

web+activitypub://post/${encoded post uri}

Note that there's no such thing as "post" in ActivityPub. We have actors, objects and activities, so web+activitypub://object/ would probably make more sense.

https://github.com/activitypub-schema/proposal

This is even better. A similar proposal was discussed here: https://socialhub.activitypub.rocks/t/suggestion-a-custom-url-scheme-handler-as-a-streamlined-ux-for-cross-instance-interactions-on-the-web/504. The topic of AP URI scheme actually comes up quite often, but these conversations are scattered across the Fediverse and various issue trackers. I agree with @circlebuilder that FEP and SocialHub are the best places to propose and discuss fediverse standards.

>web+activitypub://post/${encoded post uri} Note that there's no such thing as "post" in [ActivityPub](https://www.w3.org/TR/activitypub/). We have actors, objects and activities, so `web+activitypub://object/` would probably make more sense. >https://github.com/activitypub-schema/proposal This is even better. A similar proposal was discussed here: https://socialhub.activitypub.rocks/t/suggestion-a-custom-url-scheme-handler-as-a-streamlined-ux-for-cross-instance-interactions-on-the-web/504. The topic of AP URI scheme actually comes up quite often, but these conversations are scattered across the Fediverse and various issue trackers. I agree with @circlebuilder that FEP and SocialHub are the best places to propose and discuss fediverse standards.

tateisu commented

2023-02-17 16:57:34 +00:00

There are several things that need to be said.

Perhaps Action-related suggestions will seem abrupt to many app authors.
What is being discussed in this thread is specific to the Android app situation, unlike existing proposals for web browsers.

But overall I agree that this discussion is unlikely to converge in this thread.

There are several things that need to be said. - Perhaps Action-related suggestions will seem abrupt to many app authors. - What is being discussed in this thread is specific to the Android app situation, unlike existing proposals for web browsers. But overall I agree that this discussion is unlikely to converge in this thread.

keunes commented

2023-02-17 19:34:34 +00:00

Poster

Thanks all for your contributions! Some parts of the discussion go beyond my technical knowledge, but I did want to make some comments. CC @tateisu, @nikclayton, @silverpill

Is there an enumeration of all the different activities that would be supported by this? 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).

For example, you could want to allow users to boost an episode by sending an intent that an app receives, boosts the post in the background, and the app returns a success/failure response to AntennaPod. The user never sees the app's UI in this scenario.

This sounds cool, but the request here is explicitly the opposite. If we wanted to support boosting, replying, commenting etc. in AntennaPod, we should just directly implement support for it (requiring the user to log in on AntennaPod with an ActivityPub account). This request is explicitly not about that

We want to externalise and let a dedicated app do the work. We need to facilitate direct communication from a sender (in this case AntennaPod, but could also be Funkwhale for Android) and a receiver (in my case it'd be Fedilab).

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.
Is this something the calling app can handle?

That's an important question. Not knowing much about Android development, I was kinda hoping that AntennaPod could implement a check if there's a receiver for the intent. And if not, guide the user (first display explanation about Mastodon, then open remote 'root post'/object).

The proposal is to wrap the AP post URI in a custom URL schema so that it can be opened by many apps. avoid http,https, avoid specific host part.

All of that could be done with a custom intent and mime type. I haven't seen anything that requires a new URI scheme.

That was not my comment, and all I can say is that I don't know the differences between the two approaches (again: not my area of expertise).

the more I think about this, the more I think it might be a good end-goal. If Fedilab, Tusky, etc exposed a hypothetical "MastodonApiContentProvider" this would allow apps like AntennaPod to query through that instead of needing to write their own code that talks to the Mastodon API

Frankly, this feels like the lazy approach. If an app developer wants to implement ActivityPub support, do it from scratch or use a library. This partial offloading to other apps feels wrong. But again: that different request, different discussion :-)

Note that there's no such thing as "post" in ActivityPub. We have actors, objects and activities, so web+activitypub://object/ would probably make more sense.

Thanks for pointing that out. I wasn't fully aware when creating the original post.

A similar proposal was discussed here: https://socialhub.activitypub.rocks/t/suggestion-a-custom-url-scheme-handler-as-a-streamlined-ux-for-cross-instance-interactions-on-the-web/504

I was thinking indeed: the discussions about cross-server communication within a webbrowser is something else than Android app-to-app communication, no?

I agree with @circlebuilder that FEP and SocialHub are the best places to propose and discuss fediverse standards.

Yeap. I'll create a thread on SocialHub.

Thanks all for your contributions! Some parts of the discussion go beyond my technical knowledge, but I did want to make some comments. CC @tateisu, @nikclayton, @silverpill > Is there an enumeration of all the different activities that would be supported by this? 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). > > For example, you could want to allow users to boost an episode by sending an intent that an app receives, boosts the post in the background, and the app returns a success/failure response to AntennaPod. The user never sees the app's UI in this scenario. This sounds cool, but the request here is explicitly the opposite. If we wanted to support boosting, replying, commenting etc. in AntennaPod, we should just directly implement support for it (requiring the user to log in on AntennaPod with an ActivityPub account). This request is explicitly _not_ about that We want to externalise and let a dedicated app do the work. We need to facilitate direct communication from a sender (in this case AntennaPod, but could also be Funkwhale for Android) and a receiver (in my case it'd be Fedilab). > 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. Is this something the calling app can handle? That's an important question. Not knowing much about Android development, I was kinda hoping that AntennaPod could implement a check if there's a receiver for the intent. And if not, guide the user (first display explanation about Mastodon, then open remote 'root post'/object). > > The proposal is to wrap the AP post URI in a custom URL schema so that it can be opened by many apps. avoid http,https, avoid specific host part. > > All of that could be done with a custom intent and mime type. I haven't seen anything that requires a new URI scheme. That was not my comment, and all I can say is that I don't know the differences between the two approaches (again: not my area of expertise). > the more I think about this, the more I think it might be a good end-goal. If Fedilab, Tusky, etc exposed a hypothetical "MastodonApiContentProvider" this would allow apps like AntennaPod to query through that instead of needing to write their own code that talks to the Mastodon API Frankly, this feels like the lazy approach. If an app developer wants to implement ActivityPub support, do it from scratch or use a library. This partial offloading to other apps feels wrong. But again: that different request, different discussion :-) > Note that there's no such thing as "post" in [ActivityPub](https://www.w3.org/TR/activitypub/). We have actors, objects and activities, so `web+activitypub://object/` would probably make more sense. Thanks for pointing that out. I wasn't fully aware when creating the original post. > A similar proposal was discussed here: https://socialhub.activitypub.rocks/t/suggestion-a-custom-url-scheme-handler-as-a-streamlined-ux-for-cross-instance-interactions-on-the-web/504 I was thinking indeed: the discussions about cross-server communication within a webbrowser is something else than Android app-to-app communication, no? > I agree with @circlebuilder that FEP and SocialHub are the best places to propose and discuss fediverse standards. Yeap. I'll create a thread on SocialHub.

silverpill commented

2023-02-18 00:17:38 +00:00

I was thinking indeed: the discussions about cross-server communication within a webbrowser is something else than Android app-to-app communication, no?

To solve the problem of cross-instance interaction on the web (remote follows, replies etc) we need to connect two web clients. In both cases we're dealing with app-to-app communication, but you're right, the optimal solution could differ depending on the platform (Web / Android).

>I was thinking indeed: the discussions about cross-server communication within a webbrowser is something else than Android app-to-app communication, no? To solve the problem of cross-instance interaction on the web (remote follows, replies etc) we need to connect two web clients. In both cases we're dealing with app-to-app communication, but you're right, the optimal solution could differ depending on the platform (Web / Android).

tateisu commented

2023-02-18 22:08:25 +00:00

no one create thread in other place?

The lengthy mechanism proposed by nikclayton doesn't convince me "why should the boost button be on the caller" and "why the callee should return the result".
I think that users will be satisfied if there is "Open post in another application".
There is no reason to need a uselessly complicated mechanism.
Is it because the calling app wants to track user behavior?

no one create thread in other place? The lengthy mechanism proposed by nikclayton doesn't convince me "why should the boost button be on the caller" and "why the callee should return the result". I think that users will be satisfied if there is "Open post in another application". There is no reason to need a uselessly complicated mechanism. Is it because the calling app wants to track user behavior?

tateisu commented

2023-02-18 22:15:49 +00:00

The plugin system is very prone to vulnerabilities. In particular, the proposal this time includes a procedure for "the user authenticates the caller app", but all the information that the user sees can be freely set by the caller app. Attackers can set icon and name as they want, also how many users will notice a one-letter difference in package name.

I am not impressed with the idea of using only convenient parts of other apps as plug-ins.

The plugin system is very prone to vulnerabilities. In particular, the proposal this time includes a procedure for "the user authenticates the caller app", but all the information that the user sees can be freely set by the caller app. Attackers can set icon and name as they want, also how many users will notice a one-letter difference in package name. I am not impressed with the idea of using only convenient parts of other apps as plug-ins.

tateisu commented

2023-02-18 22:33:50 +00:00

the proposed action flow is fully intended for native apps. Web browser apps and PWA cannot handle this. That's a complete mismatch with the web+** schema illustrated at the beginning of this proposal.

the proposed action flow is fully intended for native apps. Web browser apps and PWA cannot handle this. That's a complete mismatch with the `web+**` schema illustrated at the beginning of this proposal.

tateisu commented

2023-02-19 06:22:52 +00:00

Some services offer emoji reactions instead of favorites. Another service may offer both of quote boost and normal boost. The idea of "the caller app providing a common UI without being aware of the type of service" will probably only work for a limited range of services.

keunes commented

2023-02-20 22:47:48 +00:00

Poster

@tateisu @nikclayton @silverpill @circlebuilder: I have created a post to start the discussion about a possible FEP:
https://socialhub.activitypub.rocks/t/possible-fep-proposal-cross-android-app-way-to-open-object/2985

Hope you're willing to chip in there also!

@tateisu @nikclayton @silverpill @circlebuilder: I have created a post to start the discussion about a possible FEP: https://socialhub.activitypub.rocks/t/possible-fep-proposal-cross-android-app-way-to-open-object/2985 Hope you're willing to chip in there also!

👍 1

Declare intent filter to open a post #792

Version numbers

Custom intent and MIME type?

Webfinger?

Prior art

New Well-Known URI?

Intended supported activities?

Multiple accounts

UX when no app is installed