Web-based protocol handlers

helge commented

2023-03-24 09:32:32 +00:00

Owner

Idea

We all are familiar with protocol handlers, e.g.

<a href="mailto:name@email.com">Email</a>

The idea here is to use Web-based protocol handlers in the form

<a href="web+fedi???:object_id">Object</a>

to offer the option to link to ActivityStream objects such that they can be opened by an appropriate application.

Goal

Increased interoperability between FediVerse applications. The following actions should be simplified:

Reply to content on another FediVerse application
Announce content from another FediVerse application
Like content from another FediVerse application

Currently, they require finding the items id and then looking it up using your own FediVerse application.

Difficulties

Given the various use cases of the FediVerse, e.g. link aggregation, microblogging, or photosharing, one might want to specify more than just web+fedi. According to registerProtocolHandler, one can just specify a list of lower case letters after web+. So some thoughts should be given to interoperability concerns.

Links

For a discussion for Android and more links, see
Possible FEP proposal: cross-Android app way to open Object

Fedi-Go

## Idea We all are familiar with protocol handlers, e.g. ```html <a href="mailto:name@email.com">Email</a> ``` The idea here is to use [Web-based protocol handlers](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler/Web-based_protocol_handlers) in the form ```html <a href="web+fedi???:object_id">Object</a> ``` to offer the option to link to ActivityStream objects such that they can be opened by an appropriate application. ### Goal Increased interoperability between FediVerse applications. The following actions should be simplified: - Reply to content on another FediVerse application - Announce content from another FediVerse application - Like content from another FediVerse application Currently, they require finding the items `id` and then looking it up using your own FediVerse application. ### Difficulties Given the various use cases of the FediVerse, e.g. link aggregation, microblogging, or photosharing, one might want to specify more than just `web+fedi`. According to [registerProtocolHandler](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler), one can just specify a list of lower case letters after `web+`. So some thoughts should be given to interoperability concerns. ### Links For a discussion for Android and more links, see [ Possible FEP proposal: cross-Android app way to open Object ](https://socialhub.activitypub.rocks/t/possible-fep-proposal-cross-android-app-way-to-open-object/2985) - [Fedi-Go](https://github.com/fedi-to/fedi-to.github.io)

👍 5

helge added the

Protocol

FEP

Interoperability

labels 2023-03-24 09:32:33 +00:00

tchambers commented

2023-04-15 21:49:02 +00:00

I assume would solve the issues of remote follows, remote social interactions not working unless you had an account on that local server?

helge commented

2023-04-16 07:25:24 +00:00

Poster

Owner

I ASSUME WOULD solve the issues of remote follows, remote social interactions not working unless you had an account on that local server?

"Assume would" is the wrong wording here. A worked out proposal SHOULD consider these issues and attempt to solve them. I think the formulation as a goal above would be

Following a remote account should be a one click action on the remote server.

> I ASSUME WOULD solve the issues of remote follows, remote social interactions not working unless you had an account on that local server? "Assume would" is the wrong wording here. A worked out proposal SHOULD consider these issues and attempt to solve them. I think the formulation as a _goal_ above would be - [ ] Following a remote account should be a one click action on the remote server.

👍 1

tchambers commented

2023-04-18 22:52:23 +00:00

BTW, what I'm about to paste in no was is a "solution" to the need for a protocol. But curious what folks think of this as a "kludge" or band aid that would be better than now until that new protocol is in place?

See this client side code? Is trying to get around the issue of "remote follows" and see if you see any problems with this javascript based solution.

It tries to get around the "remote follow" problem for account links using a javascript dialog box - but only ONCE. Once you answer who your local server is once for the page, it doesn't ask again and opens all links on that page, as it remembers your local server in the client side cookie.

All other links just work after that: each taking you to your local server where you can follow hashtags or users with one click.

For right now it assumes you are logged into a mastodon server somewhere, but IF this works well and no issues, we can work around coding for users who are not.

What do folks think?

https://partners.deweydefend.com/mastodon-hashtag-click-test/

BTW, what I'm about to paste in no was is a "solution" to the need for a protocol. But curious what folks think of this as a "kludge" or band aid that would be better than now until that new protocol is in place? See this client side code? Is trying to get around the issue of "remote follows" and see if you see any problems with this javascript based solution. It tries to get around the "remote follow" problem for account links using a javascript dialog box - but only ONCE. Once you answer who your local server is once for the page, it doesn't ask again and opens all links on that page, as it remembers your local server in the client side cookie. All other links just work after that: each taking you to your local server where you can follow hashtags or users with one click. For right now it assumes you are logged into a mastodon server somewhere, but IF this works well and no issues, we can work around coding for users who are not. What do folks think? https://partners.deweydefend.com/mastodon-hashtag-click-test/

tchambers commented

2023-04-24 02:04:20 +00:00

Also see this discussion here: on this same topic:

https://indieweb.social/@north@fosstodon.org/110251295619156210

Also see this discussion here: on this same topic: https://indieweb.social/@north@fosstodon.org/110251295619156210

jeherve commented

2023-04-24 16:42:44 +00:00

I really like this proposal. 👍

The following actions should be simplified

Ideally, I think we should aim to find a solution that supports most activities supported by ActivityPub:

Create
Update
Delete
Follow
Add
Remove
Like
Block
Undo

That said, I think some of those activities do not need to be supported right away, or ever, because they're actions that are typically closely tied to your own account.

I think that the following would be a great start:

Creating content from any website (think "Share to Fediverse" button on any website, or replying to an activity created by a remote account. Create activity)
Following a remote account (Follow activity)
Like content from a remote account (Like activity)

I should point out WebActions, an initiative that was pointed out to me a few weeks ago when we were discussing a share to Fediverse button.

I really like this proposal. 👍 > The following actions should be simplified Ideally, I think we should aim to find a solution that supports *most* [activities supported by ActivityPub](https://www.w3.org/TR/activitypub/#client-to-server-interactions): - `Create` - `Update` - `Delete` - `Follow` - `Add` - `Remove` - `Like` - `Block` - `Undo` That said, I think some of those activities do not need to be supported right away, or ever, because they're actions that are typically closely tied to your own account. I think that the following would be a great start: - Creating content from any website (think "Share to Fediverse" button on any website, or replying to an activity created by a remote account. `Create` activity) - Following a remote account (`Follow` activity) - Like content from a remote account (`Like` activity) ------------- I should point out [WebActions](https://wiki.mozilla.org/WebActions), an initiative that was pointed out to me a few weeks ago when we were discussing [a share to Fediverse button](https://jeremy.hu/the-case-for-native-handling-of-fediverse-actions/).

silverpill commented

2023-04-24 17:19:36 +00:00

@jeherve This URI schema proposal uses activity types so it might be a good starting point: https://github.com/activitypub-schema/proposal/blob/main/PROPOSAL.md

jeherve commented

2023-05-12 16:30:48 +00:00

Here is another blog post on this topic:

https://paul.kinlan.me/thoughts-on-web-follow/

The author also suggests protocol handlers, and suggests general handlers such as web+share or web+follow or web+subscribe. This aligns with @helge's initial proposal:

According to registerProtocolHandler, one can just specify a list of lower case letters after web+. So some thoughts should be given to interoperability concerns.

Here is another blog post on this topic: https://paul.kinlan.me/thoughts-on-web-follow/ The author also suggests protocol handlers, and suggests general handlers such as `web+share` or `web+follow` or `web+subscribe`. This aligns with @helge's initial proposal: > According to registerProtocolHandler, one can just specify a list of lower case letters after web+. So some thoughts should be given to interoperability concerns.

👍 2

tchambers commented

2023-05-12 19:21:52 +00:00

Can someone help me quanitfy precisely which browsers ALREADY support everything they would need to listen to the protocol handler code if it were well implemented? I think in the past, the hold up on considering this on the Mastodon level was browser support. I have heard anecdotally, that 3/4ths of modern browsers could handle this today but I'd like to verify that and quantify that very clearly.

jeherve commented

2023-05-13 01:38:38 +00:00

Can someone help me quanitfy precisely which browsers ALREADY support everything they would need to listen to the protocol handler code if it were well implemented?

You can check this here:
https://caniuse.com/?search=registerProtocolHandler

Safari and Chrome for Android are 2 big missing players right now.

I think in the past, the hold up on considering this on the Mastodon level was browser support

This used to be enabled in Mastodon, but was removed because of the UX:
https://github.com/mastodon/mastodon/pull/8127

There have been multiple discussions to suggest enabling it again. Here are some:

It's been discussed for other platforms as well, like for Misskey:
https://github.com/misskey-dev/misskey/issues/9504

Ideally, if we could agree on a standard name, this would be a good incentive for platforms to give it a try, and then to browsers to improve support / UX, or start supporting it.

> Can someone help me quanitfy precisely which browsers ALREADY support everything they would need to listen to the protocol handler code if it were well implemented? You can check this here: https://caniuse.com/?search=registerProtocolHandler Safari and Chrome for Android are 2 big missing players right now. > I think in the past, the hold up on considering this on the Mastodon level was browser support This used to be enabled in Mastodon, but was removed because of the UX: https://github.com/mastodon/mastodon/pull/8127 There have been multiple discussions to suggest enabling it again. Here are some: - https://github.com/mastodon/mastodon/issues/14187 - https://github.com/mastodon/mastodon/issues/19679 It's been discussed for other platforms as well, like for Misskey: https://github.com/misskey-dev/misskey/issues/9504 Ideally, if we could agree on a standard name, this would be a good incentive for platforms to give it a try, and then to browsers to improve support / UX, or start supporting it.

👍 2 ❤️ 1

matthias.pfefferle commented

2023-05-15 10:16:24 +00:00

@tchambers I think it is mainly a chicken/egg problem. If there is no adoption, why should browsers support it and vice versa. The nice thing with the protocol handler is, that it could be on top, besides the current solutions (which are not really better atm.).

One of the biggest issues in the fediverse is the missing central part, to search for customers, define your plaform of choice for sharing, ... 2010, Chris Messina wrote an interesting series about the browser as "Social Agent" for Mozilla https://web.archive.org/web/20101126234012/https://mozillalabs.com/conceptseries/identity/social-agent/

It is over 10 years old, but I still think this is the reight way to go. We need something like WebIntents or Custom-Protocol-Handler, to tell the Browser what we want to use for following, sharing, login, ... otherwise we always have to answer the question "tell me your pod/plattform/..." to get the correct dialogue or we end up with the NASCAR problem https://indieweb.org/NASCAR_problem

Using the browser is nice, because it is a central hub, without beeing a central hub :) and you can set it up without sharing that kind of data with some central service!

@tchambers I think it is mainly a chicken/egg problem. If there is no adoption, why should browsers support it and vice versa. The nice thing with the protocol handler is, that it could be on top, besides the current solutions (which are not really better atm.). One of the biggest issues in the fediverse is the missing central part, to search for customers, define your plaform of choice for sharing, ... 2010, Chris Messina wrote an interesting series about the browser as "Social Agent" for Mozilla https://web.archive.org/web/20101126234012/https://mozillalabs.com/conceptseries/identity/social-agent/ It is over 10 years old, but I still think this is the reight way to go. We need something like WebIntents or Custom-Protocol-Handler, to tell the Browser what we want to use for following, sharing, login, ... otherwise we always have to answer the question "tell me your pod/plattform/..." to get the correct dialogue or we end up with the NASCAR problem https://indieweb.org/NASCAR_problem Using the browser is nice, because it is a central hub, without beeing a central hub :) and you can set it up without sharing that kind of data with some central service!

👍 2

wesleyac commented

2023-05-20 14:19:12 +00:00

This seems like a good idea. A few thoughts:

fedi is a poor name, since it's a informal name, not referring to anything specified. ap or activitypub is probably better.
I think a different handler for each ActivityPub action is a good idea, like web+ap-like, web+ap-follow, etc. This will allow for a more seamless experience.
Mobile browser support is probably not a huge problem, since mobile apps can support these schemes (I think, unless web+ schemes are restricted — I haven't seen evidence of that but I haven't tested it)
Currently, mastodon pops up a UI asking the non-logged in user what to do if they try to do something like this (see attached image). Changing that to have a "detect automatically" button that would use the custom protocol handler, as well as set a cookie to default to that in the future would offer the better UX for people on servers that support it, while avoiding unsupported links and confusing UI for people who don't. Some thought should be put into ways to detect if the link was opened successfully, but that might be tricky or impossible (at least, impossible in a privacy-preserving way)

This seems like a good idea. A few thoughts: * `fedi` is a poor name, since it's a informal name, not referring to anything specified. `ap` or `activitypub` is probably better. * I think a different handler for each ActivityPub action is a good idea, like `web+ap-like`, `web+ap-follow`, etc. This will allow for a more seamless experience. * Mobile browser support is probably not a huge problem, since mobile apps can support these schemes (I think, unless `web+` schemes are restricted — I haven't seen evidence of that but I haven't tested it) * Currently, mastodon pops up a UI asking the non-logged in user what to do if they try to do something like this (see attached image). Changing that to have a "detect automatically" button that would use the custom protocol handler, as well as set a cookie to default to that in the future would offer the better UX for people on servers that support it, while avoiding unsupported links and confusing UI for people who don't. Some thought should be put into ways to detect if the link was opened successfully, but that might be tricky or impossible (at least, impossible in a privacy-preserving way)

2023-05-20_10.07.43_619x599.png

61 KiB

👍 1

wesleyac commented

2023-05-20 14:33:27 +00:00

Actually, the activitypub-schema proposal linked above seems better thought out than my suggestion to have different handlers per-type. All the rest of my points stand, though :)

It seems worth going ahead and making a patch for Mastodon to add support for that in the way I described above. I won't have time to look at that for at least a few days probably, but I will try to dig into it when I get a chance.

Also worth noting that supported browsers can be detected, either by looking for registerProtocolHandler (untested, but I assume this would work?) or by user agent, so it's easy to fall back to the status quo in that particular case.

Actually, the [activitypub-schema proposal](https://github.com/activitypub-schema/proposal/blob/main/PROPOSAL.md) linked above seems better thought out than my suggestion to have different handlers per-type. All the rest of my points stand, though :) It seems worth going ahead and making a patch for Mastodon to add support for that in the way I described above. I won't have time to look at that for at least a few days probably, but I will try to dig into it when I get a chance. Also worth noting that supported browsers can be detected, either by looking for `registerProtocolHandler` (untested, but I assume this would work?) or by user agent, so it's easy to fall back to the status quo in that particular case.

wesleyac commented

2023-05-20 15:15:03 +00:00

For people curious about the browser UI, here's a simple page to test it.

A few papercuts, with Firefox on Linux:

No way for a website to deregister itself (you'd want to do this on logout, maybe?)
Very unclear how to deregister a handler as a user (you need to dig in about:preferences)
You need to approve it in three different places:
- Once to register the handler (this is permanent, though)
- Once on the remote site to allow it to open web+activitypub links (can be made permanent at user discretion, but will be separate for each remote server)
- Once to select the site to use to open the link (can be made permanent at user discretion, if so you only need to do it once globally)
If you click a link with no handler installed, nothing happens (maybe there is a way to detect this with JS? tbd)

Overall, even with those downsides, I'd prefer it to the status quo, and I think many other users would as well.

For people curious about the browser UI, here's [a simple page to test it](https://wesleyac.com/masto-protocol-handler-test.html). A few papercuts, with Firefox on Linux: * No way for a website to deregister itself (you'd want to do this on logout, maybe?) * Very unclear how to deregister a handler as a user (you need to dig in `about:preferences`) * You need to approve it in three different places: * Once to register the handler (this is permanent, though) * Once on the remote site to allow it to open `web+activitypub` links (can be made permanent at user discretion, but will be separate for each remote server) * Once to select the site to use to open the link (can be made permanent at user discretion, if so you only need to do it once globally) * If you click a link with no handler installed, nothing happens (maybe there is a way to detect this with JS? tbd) Overall, even with those downsides, I'd prefer it to the status quo, and I think many other users would as well.

BANO commented

2023-05-20 16:56:16 +00:00

@wesleyac

Some thought should be put into ways to detect if the link was opened successfully, but that might be tricky or impossible (at least, impossible in a privacy-preserving way)

There's already implementation of similar problem. That's t.me links linking to telegram. If you go to https://t.me/banonotit and checkout page source code you'll see they just use simple

try { window.href = 'tg://' } catch (e) {}

Regarding privacy concerns -- browser only allow navigating links when they are activated by user. That's the mechanic introduced to defeat ad modals back in the days. So I don't really see any way to breach privacy here.

@wesleyac > Some thought should be put into ways to detect if the link was opened successfully, but that might be tricky or impossible (at least, impossible in a privacy-preserving way) There's already implementation of similar problem. That's t.me links linking to telegram. If you go to https://t.me/banonotit and checkout page source code you'll see they just use simple ```javascript try { window.href = 'tg://' } catch (e) {} ``` Regarding privacy concerns -- browser only allow navigating links when they are activated by user. That's the mechanic introduced to defeat ad modals back in the days. So I don't really see any way to breach privacy here.

BANO commented

2023-05-20 16:58:17 +00:00

Mobile browser support is probably not a huge problem,

Yeah. I've checked with my friends that both iOS and Android allow registering and handling any uri scheme regardless of prefixes. web+activitypub was tested and works.

> Mobile browser support is probably not a huge problem, Yeah. I've checked with my friends that both iOS and Android allow registering and handling any uri scheme regardless of prefixes. `web+activitypub` was tested and works.

matthias.pfefferle commented

2023-05-21 18:12:05 +00:00

Why does it have to be web+activitypub (or web+ap-follow or anything ActivityPub branded)? This is very limiting to platforms/software that uses this spec. But a like or a share is very generic and should be handled like that. I do not need to be part of the fediverse, to like an article, using my blog, or to follow a Mastodon profile via my RSS-Reader. If we start using web+activitypub:Follow.. and web+rss:Follow and ... (you name it) or web+ap-follow then we generate the same issue, we have today... multiple buttons, or multiple steps to knwo what to do https://indieweb.org/NASCAR_problem

I would vote for a more generic solution, like web+like, web+follow, ...

I recommend the article of Paul Kinlan, that was already shared by @jeherve https://paul.kinlan.me/thoughts-on-web-follow/

Why does it have to be `web+activitypub` (or `web+ap-follow` or anything ActivityPub branded)? This is very limiting to platforms/software that uses this spec. But a `like` or a `share` is very generic and should be handled like that. I do not need to be part of the fediverse, to like an article, using my blog, or to `follow` a Mastodon profile via my RSS-Reader. If we start using `web+activitypub:Follow..` and `web+rss:Follow` and ... (you name it) or `web+ap-follow` then we generate the same issue, we have today... multiple buttons, or multiple steps to knwo what to do https://indieweb.org/NASCAR_problem I would vote for a more generic solution, like `web+like`, `web+follow`, ... I recommend the article of Paul Kinlan, that was already shared by @jeherve https://paul.kinlan.me/thoughts-on-web-follow/

BANO commented

2023-05-21 19:04:17 +00:00

@matthias.pfefferle you can't introduce new generic schemas for every action you want because fediverse have for example special likes with smiles in misskey. ICANN wouldn't be happy with that :D

I suggest web+activitypub because I think it's better to employ AP server-client interaction and json-ld extensibility to simplify integration and implementation in fediverse. Using web+activitypub you can do cat likes in misskey or even introduce new interaction types just by employing mechanics and protocols defined by W3C.

And yeah, web+activitypub does not provide new buttons because you can use previous ones and fallback to "copy link" modal if web+activitypub does not have any handler assigned on your device.

@matthias.pfefferle you can't introduce new generic schemas for every action you want because fediverse have for example special likes with smiles in misskey. ICANN wouldn't be happy with that :D I suggest `web+activitypub` because I think it's better to employ AP server-client interaction and json-ld extensibility to simplify integration and implementation in fediverse. Using `web+activitypub` you can do cat likes in misskey or even introduce new interaction types just by employing mechanics and protocols defined by W3C. And yeah, `web+activitypub` does not provide new buttons because you can use previous ones and fallback to "copy link" modal if `web+activitypub` does not have any handler assigned on your device.

matthias.pfefferle commented

2023-05-21 20:48:36 +00:00

Not that generic :)

As I mentioned in my previous comment, I would like to vote for web+like instead of web+activitypub:Like. Let's not make any new silos and try to fix things, so others can adopt, with a basic set of protocols with a set of attributes that can be extended.

I understand that it might be nice to add some special meta-data (like object, actor, ...) especially for ActivityPub, but you could easily do that using query strings. That would allow clients to choose what they want to support and ignore the rest.

Not that generic :) As I mentioned in my previous comment, I would like to vote for `web+like` instead of `web+activitypub:Like`. Let's not make any new silos and try to fix things, so others can adopt, with a basic set of protocols with a set of attributes that can be extended. I understand that it might be nice to add some special meta-data (like object, actor, ...) especially for ActivityPub, but you could easily do that using query strings. That would allow clients to choose what they want to support and ignore the rest.

matthias.pfefferle commented

2023-05-21 20:57:43 +00:00

To be more specific. Let's use an example from the proposal https://github.com/activitypub-schema/proposal/blob/main/PROPOSAL.md

web+activitypub:Follow?object=https%3A%2F%2Fmastodon.ml%2Fusers%2Fbano

why not use:

web+follow:https%3A%2F%2Fmastodon.ml%2Fusers%2Fbano

instead?

There is no need for any additional data in that case (object might be implicit) and if so, you can add it via query strings.

If your web+follow handler is Mastodon, it will start the follow request, if it's your feed reader, it looks for the rel=alternate header and subscibes to the feed, ...

To be more specific. Let's use an example from the proposal https://github.com/activitypub-schema/proposal/blob/main/PROPOSAL.md `web+activitypub:Follow?object=https%3A%2F%2Fmastodon.ml%2Fusers%2Fbano` why not use: `web+follow:https%3A%2F%2Fmastodon.ml%2Fusers%2Fbano` instead? There is no need for any additional data in that case (object might be implicit) and if so, you can add it via query strings. If your `web+follow` handler is Mastodon, it will start the follow request, if it's your feed reader, it looks for the `rel=alternate` header and subscibes to the feed, ...

wesleyac commented

2023-05-21 21:02:10 +00:00

@matthias.pfefferle How do you envision that working in practice? The reason I want ActivityPub links is because there is a lot of software that works with ActivityPub objects, which doesn't work with other types of things. Say I open a web+follow link that points to a RSS url with the default thing I have set to open that, which is Mastodon. Or the reverse, I open a web+follow link to a ActivityPub object with my RSS reader. What's supposed to happen in this case? The software just says "sorry, no" and I'm out of luck?

The reason to have a protocol is to have something that's well specified and encodes what software is needed to deal with it. Making this more generic makes it less usable.

@matthias.pfefferle How do you envision that working in practice? The reason I want ActivityPub links is because there is a lot of software that works with ActivityPub objects, which doesn't work with other types of things. Say I open a `web+follow` link that points to a RSS url with the default thing I have set to open that, which is Mastodon. Or the reverse, I open a `web+follow` link to a ActivityPub object with my RSS reader. What's supposed to happen in this case? The software just says "sorry, no" and I'm out of luck? The reason to have a protocol is to have something that's well specified and encodes what software is needed to deal with it. Making this more generic makes it less usable.

matthias.pfefferle commented

2023-05-21 21:11:01 +00:00

@wesleyac You do not link directly to a RSS feeds, as you do not directly link to the JSON representation of an ActivityPub profile. You link to the HTML version of the profile page and an ActivityPub client gets his information by calling it with the Accept header application/activity+json and a RSS reader is trying to find the rel-alternat link header.

Yes, there might be cases where a handler would have to fail, because there is no way, but I would take this risk in favor of a more generic solution.

But this can all be defined in the spec.

An other argument: What about multi protocol networks, like Friendi.ca and Hubzilla? They simply need the URL to follow another account, independently of the protocol. If we think in protocols, they need a follow button for every supported spec. Same with like, boost, share, ...

@wesleyac You do not link directly to a RSS feeds, as you do not directly link to the JSON representation of an ActivityPub profile. You link to the HTML version of the profile page and an ActivityPub client gets his information by calling it with the Accept header `application/activity+json` and a RSS reader is trying to find the `rel-alternat` link header. Yes, there might be cases where a handler would have to fail, because there is no way, but I would take this risk in favor of a more generic solution. But this can all be defined in the spec. An other argument: What about multi protocol networks, like Friendi.ca and Hubzilla? They simply need the URL to follow another account, independently of the protocol. If we think in protocols, they need a follow button for every supported spec. Same with `like`, `boost`, `share`, ...

rodsilva commented

2023-05-22 01:08:21 +00:00

@matthias.pfefferle I understand your concern but I also don't think it is the best solution. "Following", "liking" and "boosting" are all protocol dependent actions as you need an account on a service that talks the same protocol as the service hosting the content you're interacting to. For example, it wouldn't be possible to "web+like" a Twitter post from a Mastodon account.

For this reason, I also think it gets too generic. It'd be like having a messageto: handler instead of mailto but not every message format (like Matrix messages) would work correctly.

The specification could enforce "web+like" should be used only with ActivityPub compatible services but what would it happen if in the future another Fediverse protocol was created to replace ActivityPub?

@matthias.pfefferle I understand your concern but I also don't think it is the best solution. "Following", "liking" and "boosting" are all protocol dependent actions as you need an account on a service that talks the same protocol as the service hosting the content you're interacting to. For example, it wouldn't be possible to "web+like" a Twitter post from a Mastodon account. For this reason, I also think it gets too generic. It'd be like having a `messageto:` handler instead of `mailto` but not every message format (like Matrix messages) would work correctly. The specification could enforce "web+like" should be used only with ActivityPub compatible services but what would it happen if in the future another Fediverse protocol was created to replace ActivityPub?

jeherve commented

2023-05-22 05:43:33 +00:00

You do not link directly to a RSS feeds, as you do not directly link to the JSON representation of an ActivityPub profile. You link to the HTML version of the profile page

What if that HTML page can relate to multiple protocols?

It may be a Mastodon profile page that I want to follow from my RSS reader, or my Fediverse client.
It may be a WordPress author archive page that I want to follow from my RSS reader, my Fediverse client, and possibly more in the future.

Like @rodsilva mentioned, I don't think we can be too generic. We'd need to be specific enough so the link will be able to open the right default software on my device.

If we want to remain generic, we would have to link directly to RSS / JSON, just like we do today for RSS feeds on many websites. I do not think that's ideal.

What about multi protocol networks, like Friendi.ca and Hubzilla? They simply need the URL to follow another account, independently of the protocol. If we think in protocols, they need a follow button for every supported spec.

In this case, the Friendi.ca / Hubzilla client installed on the user's device would be declared as the default software for multiple different web+protocol links.

> You do not link directly to a RSS feeds, as you do not directly link to the JSON representation of an ActivityPub profile. You link to the HTML version of the profile page What if that HTML page can relate to multiple protocols? 1. It may be a Mastodon profile page that I want to follow from my RSS reader, or my Fediverse client. 2. It may be a WordPress author archive page that I want to follow from my RSS reader, my Fediverse client, and possibly more in the future. Like @rodsilva mentioned, I don't think we can be too generic. We'd need to be specific enough so the link will be able to open the right default software on my device. If we want to remain generic, we would have to link directly to RSS / JSON, just like we do today for RSS feeds on many websites. I do not think that's ideal. > What about multi protocol networks, like Friendi.ca and Hubzilla? They simply need the URL to follow another account, independently of the protocol. If we think in protocols, they need a follow button for every supported spec. In this case, the Friendi.ca / Hubzilla client installed on the user's device would be declared as the default software for multiple different `web+protocol` links.

matthias.pfefferle commented

2023-05-22 09:58:32 +00:00

@rodsilva let's not use a silo like Twitter as an example for like. I still think "like" is a general operation, that should work platform/protocol independent. You should simply provide the URL that should be liked and leave the logic how to like this URL to the client. There is for example the IndieWeb community that supports liking through a blog post, with some HTML-Semantics + Pingbacks/Webmentions: https://indieweb.org/like So web+like:https%3A%2F%2Fmastodon.ml%2Fusers%2Fbano should work for ActivityPub in the same way as for the IndieWeb, but with different protocols on different platforms.

I agree that this might not be working for everything/everyone in the first place, but you have the same issue with every new proposed standard, even with web+activitypub, because it first has to be adopted by all ActivityPub platforms.

@jeherve

In this case, the Friendi.ca / Hubzilla client installed on the user's device would be declared as the default software for multiple different web+protocol links.

That makes sense in one direction, but what about Friendi.ca is the provider? If someone wants to follow a Friendi.ca profile, Friendi.ca has to provide a bunch of different follow buttons (https://indieweb.org/NASCAR_problem), one for every protocol they support.

If we want to remain generic, we would have to link directly to RSS / JSON, just like we do today for RSS feeds on many websites. I do not think that's ideal.

We invested a lot in discovery mechanisms like WebFinger, Host-Meta, HTTP Link-Headers and HTML Link-Headers. This allows us to simply provide the User-Friendly HTML version of a Link (profile URL) and let the other party choose what to use. Lets take my profile URL on my blog https://notiz.blog/author/matthias-pfefferle/. You can try finding protocols using WebFinger

https://notiz.blog/.well-known/webfinger?resource=https%3A%2F%2Fnotiz.blog%2Fauthor%2Fmatthias-pfefferle%2F

If you can not find a matching service there, you can have a look at my Host-Meta:

https://notiz.blog/.well-known/host-meta.json

or you can check all HTML rel-alternate headers of the HTML page.

From my profile page, you find an ActivityPub profile, RSS, Atom, JSON and WordPress API feeds and the site itself is readable using Schema.org, Open Graph and Microformats: http://php.microformats.io/?url=https%3A%2F%2Fnotiz.blog%2Fauthor%2Fmatthias-pfefferle%2F

If we start using the protocol handlers as generic as possible and keep them extensible, we might be able to motivate other platforms to adopt it. Might be difficult with Follow, but Like and Share are easy to go.

@rodsilva let's not use a silo like Twitter as an example for `like`. I still think "like" is a general operation, that should work platform/protocol independent. You should simply provide the URL that should be liked and leave the logic how to like this URL to the client. There is for example the IndieWeb community that supports liking through a blog post, with some HTML-Semantics + Pingbacks/Webmentions: https://indieweb.org/like So `web+like:https%3A%2F%2Fmastodon.ml%2Fusers%2Fbano` should work for ActivityPub in the same way as for the IndieWeb, but with different protocols on different platforms. I agree that this might not be working for everything/everyone in the first place, but you have the same issue with every new proposed standard, even with `web+activitypub`, because it first has to be adopted by all ActivityPub platforms. @jeherve > In this case, the Friendi.ca / Hubzilla client installed on the user's device would be declared as the default software for multiple different web+protocol links. That makes sense in one direction, but what about Friendi.ca is the provider? If someone wants to follow a Friendi.ca profile, Friendi.ca has to provide a bunch of different follow buttons (https://indieweb.org/NASCAR_problem), one for every protocol they support. > If we want to remain generic, we would have to link directly to RSS / JSON, just like we do today for RSS feeds on many websites. I do not think that's ideal. We invested a lot in discovery mechanisms like WebFinger, Host-Meta, HTTP Link-Headers and HTML Link-Headers. This allows us to simply provide the User-Friendly HTML version of a Link (profile URL) and let the other party choose what to use. Lets take my profile URL on my blog https://notiz.blog/author/matthias-pfefferle/. You can try finding protocols using WebFinger https://notiz.blog/.well-known/webfinger?resource=https%3A%2F%2Fnotiz.blog%2Fauthor%2Fmatthias-pfefferle%2F If you can not find a matching service there, you can have a look at my Host-Meta: https://notiz.blog/.well-known/host-meta.json or you can check all HTML rel-alternate headers of the HTML page. From my profile page, you find an ActivityPub profile, RSS, Atom, JSON and WordPress API feeds and the site itself is readable using Schema.org, Open Graph and Microformats: http://php.microformats.io/?url=https%3A%2F%2Fnotiz.blog%2Fauthor%2Fmatthias-pfefferle%2F If we start using the protocol handlers as generic as possible and keep them extensible, we might be able to motivate other platforms to adopt it. Might be difficult with Follow, but Like and Share are easy to go.

jeherve commented

2023-05-22 11:08:09 +00:00

From my profile page, you find an ActivityPub profile, RSS, Atom, JSON and WordPress API feeds and the site itself is readable using Schema.org, Open Graph and Microformats: http://php.microformats.io/?url=https%3A%2F%2Fnotiz.blog%2Fauthor%2Fmatthias-pfefferle%2F

Right, that's what I meant. This is one of the examples where being too generic becomes problematic. In this case, what should a web+follow:https://notiz.blog/author/matthias-pfefferle/ link do? Open my RSS reader? Open my Fediverse client? Something else?

what about Friendi.ca is the provider? If someone wants to follow a Friendi.ca profile, Friendi.ca has to provide a bunch of different follow buttons

That's a good point. I'm not too sure how to avoid that.

> From my profile page, you find an ActivityPub profile, RSS, Atom, JSON and WordPress API feeds and the site itself is readable using Schema.org, Open Graph and Microformats: http://php.microformats.io/?url=https%3A%2F%2Fnotiz.blog%2Fauthor%2Fmatthias-pfefferle%2F Right, that's what I meant. This is one of the examples where being too generic becomes problematic. In this case, what should a `web+follow:https://notiz.blog/author/matthias-pfefferle/` link do? Open my RSS reader? Open my Fediverse client? Something else? > what about Friendi.ca is the provider? If someone wants to follow a Friendi.ca profile, Friendi.ca has to provide a bunch of different follow buttons That's a good point. I'm not too sure how to avoid that.

matthias.pfefferle commented

2023-05-22 11:21:31 +00:00

ight, that's what I meant. This is one of the examples where being too generic becomes problematic. In this case, what should a web+follow:https://notiz.blog/author/matthias-pfefferle/ link do? Open my RSS reader? Open my Fediverse client? Something else?

Ah, got you. Ok, maybe than mayb RSS is not a good example for "follow", and should be better done by web+subscribe! Makes sense!

And maybe there is an option to register multiple handlers for the same protocol-handler, so that I see maybe two services I could choose from. Would make also sense for ActivityPub alone, because maybe I have an Mastodon and an Pixelfed account.

Nevertheless, I think my point is still valid.

> ight, that's what I meant. This is one of the examples where being too generic becomes problematic. In this case, what should a web+follow:https://notiz.blog/author/matthias-pfefferle/ link do? Open my RSS reader? Open my Fediverse client? Something else? Ah, got you. Ok, maybe than mayb RSS is not a good example for "follow", and should be better done by `web+subscribe`! Makes sense! And maybe there is an option to register multiple handlers for the same protocol-handler, so that I see maybe two services I could choose from. Would make also sense for ActivityPub alone, because maybe I have an Mastodon and an Pixelfed account. Nevertheless, I think my point is still valid.

circlebuilder referenced this issue from fediverse/fep

2023-05-29 06:59:08 +00:00

My dream: Opening posts or user accounts in the proper app automatically #106

helge commented

2023-05-29 17:07:22 +00:00

Poster

Owner

I also took a shot at implementing it now. You can find the relevant commit here. Functionality is as follows:

Open https://tags.mymath.rocks/ and click on "Add protocol handler". You are then prompted to enter a mastodon domain, e.g. mastodon.social.
This sets a cookie used for a later redirect.
When looking at a post, e.g. here, you can find a little share button at the bottom. These use the web protocol handler to redirect you to mastodon/share.
This only worked in Chrome for me, but for Firefox I needed to
- Open about:preferences#searchResults
- Search for applications
- Search for web+share
- Select "Use tags.mymath.rocks" instead of "Use System handler"

Anyway, this shows that implementing something as web+share can be done "quickly". One can later refine this, to e.g. map a web+share to an Announce activity or similar. However, I believe that something as above should be enough to get the process started.

Opinions?

I also took a shot at implementing it now. You can find the relevant commit [here](https://codeberg.org/bovine/hashtags/commit/360788af10f5bea924e942c729f67c2e86ba0eb6). Functionality is as follows: - Open [https://tags.mymath.rocks/](https://tags.mymath.rocks/) and click on "Add protocol handler". You are then prompted to enter a mastodon domain, e.g. mastodon.social. - This sets a cookie used for a later redirect. - When looking at a post, e.g. [here](https://tags.mymath.rocks/#/cowsofmastodon), you can find a little share button at the bottom. These use the web protocol handler to redirect you to mastodon/share. - This only worked in Chrome for me, but for Firefox I needed to - Open about:preferences#searchResults - Search for applications - Search for web+share - Select "Use tags.mymath.rocks" instead of "Use System handler" Anyway, this shows that implementing something as __web+share__ can be done "quickly". One can later refine this, to e.g. map a web+share to an Announce activity or similar. However, I believe that something as above should be enough to get the process started. Opinions?

❤️ 2

j12t commented

2023-06-03 22:46:22 +00:00

To make sure it doesn't fall under the table: a solution for this needs to support multiple personas/accounts.

Use case (1):

I browse a website with an interesting article
I want to share it with my friends but not my professional acquaintances (or vice versa)
(That's why I have two different Fediverse accounts likely on two different servers)
As I take the action ("share"), I am being asked which of my personas/account to share it to.

Use case (2):

I browse a website with an interesting article
I want to post it to my Lemmy account, but not my Mastodon friends (or vice versa)
As I take the action ("share"), I am being asked which of my personas/account to use.

To make sure it doesn't fall under the table: a solution for this needs to support multiple personas/accounts. Use case (1): * I browse a website with an interesting article * I want to share it with my friends but not my professional acquaintances (or vice versa) * (That's why I have two different Fediverse accounts likely on two different servers) * As I take the action ("share"), I am being asked which of my personas/account to share it to. Use case (2): * I browse a website with an interesting article * I want to post it to my Lemmy account, but not my Mastodon friends (or vice versa) * As I take the action ("share"), I am being asked which of my personas/account to use.

👍 1 ❤️ 1

helge commented

2023-06-06 16:44:37 +00:00

Poster

Owner

https://www.w3.org/TR/web-share/

- https://www.w3.org/TR/web-share/

BANO commented

2023-06-07 17:58:53 +00:00

Just a note on related effort by centralized index (podcast index) to use special hash urls for fast follow podcasts.

Just a note on [related effort](https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md#guid-enabled-fast-follow-share-links) by centralized index (podcast index) to use special hash urls for fast follow podcasts.

tchambers commented

2023-07-07 15:49:03 +00:00

What is the status of this idea lately?

helge commented

2023-07-14 06:41:26 +00:00

Poster

Owner

- https://datatracker.ietf.org/doc/draft-soni-protocol-handler-well-known-uri/ - https://portend.place/notice/AXfa06xMeen4I9wAzI

👍 1

matthias.pfefferle commented

2023-07-14 12:49:32 +00:00

Oh, thanks for sharing @helge ! interesting read!

smitten commented

2023-07-14 13:32:35 +00:00

I've been following this thread as well as the mastodon github issue, also took a look at the activity-schema proposal. I opened a PR in Akkoma with a demo implementation.

In my view there's been too much focus on the actions the user can take (follow, announce, like, reply). Any URL which indicates an action must also have a confirmation flow once you navigate to the URL. Otherwise it would be open to CSRF attacks and any other malicious link attack.

So that means that if we go down the route of building the specific actions into these URLs, then the fediverse software that implements the spec needs to implement confirmation flows for every possible action. That's a lot of friction, when there's already very little energy to implement this concept as-is. It also would be confusing UX for the user- it would be a confirmation flow that's different from their normal view they're used to.

So I would recommend that we scrap the actions themselves and just focus on resource identifiers. There are two main use cases in my opinion:

I want to see a user profile, with a link like web+ap://portend.place/users/smitten. I would see this link on someone's blog or another social platform, so they can link to their fedi account.
I want to see a specific post, with a link like web+ap://portend.place/notice/AXfa06xMeen4I9wAzI

The use cases would already provide the 'confirmation flow' because you could take any action you want on those resources once you opened them. Using the standard UX that you already use, which is already implemented by your fedi client. This way, the URLs are simplified to be about locating something/someone on your server, that's it.

This matches Soni's fedi-to proposal which I think is straightforward.

I've been following this thread as well as the mastodon github issue, also took a look at the [activity-schema proposal](https://github.com/activitypub-schema/proposal/blob/main/PROPOSAL.md). I opened a [PR in Akkoma](https://akkoma.dev/AkkomaGang/akkoma/pulls/589) with a demo implementation. In my view there's been too much focus on the *actions* the user can take (follow, announce, like, reply). Any URL which indicates an action must also have a confirmation flow once you navigate to the URL. Otherwise it would be open to CSRF attacks and any other malicious link attack. So that means that if we go down the route of building the specific actions into these URLs, then the fediverse software that implements the spec needs to implement confirmation flows for every possible action. That's a lot of friction, when there's already very little energy to implement this concept as-is. It also would be confusing UX for the user- it would be a confirmation flow that's different from their normal view they're used to. So I would recommend that we scrap the actions themselves and just focus on resource identifiers. There are two main use cases in my opinion: 1. I want to see a user profile, with a link like `web+ap://portend.place/users/smitten`. I would see this link on someone's blog or another social platform, so they can link to their fedi account. 2. I want to see a specific post, with a link like `web+ap://portend.place/notice/AXfa06xMeen4I9wAzI` The use cases would already provide the 'confirmation flow' because you could take any action you want on those resources once you opened them. Using the standard UX that you already use, which is already implemented by your fedi client. This way, the URLs are simplified to be about locating something/someone on your server, that's it. This matches [Soni's fedi-to proposal](https://github.com/fedi-to/fedi-to.github.io/blob/main/webap.md) which I think is straightforward.

smitten commented

2023-07-14 14:00:49 +00:00

To make sure it doesn't fall under the table: a solution for this needs to support multiple personas/accounts.

Use case (1):

I browse a website with an interesting article

I want to share it with my friends but not my professional acquaintances (or vice versa)

(That's why I have two different Fediverse accounts likely on two different servers)

As I take the action ("share"), I am being asked which of my personas/account to share it to.

The way this would work is that each server you're on would register its own web protocol handler. When you access the URL, the browser would ask you which application you wanted to handle it with. This is the same interface as opening a magnet URL if you've ever done that while having more than one torrent client installed.

So if each persona is on a separate server, this is very easy to address. Creating multiple handlers on a single server, each attached to a specific login, I don't think is possible. Or at least it would be very complex.

If a server exposes multiple handler addresses, then it becomes more difficult to set up fallback behaviors. Soni's draft proposal recommends using a single /.well-known/protocol-handler?target=%s route, so that it would be easy to craft fallback URLs if a user did not have the web protocol handler registered. I like this idea, but it does mean that each server doesn't create ad hoc target routes e.g. /api/protocol-handler?accountId=[id]&target=%s

> To make sure it doesn't fall under the table: a solution for this needs to support multiple personas/accounts. > > Use case (1): > > * I browse a website with an interesting article > * I want to share it with my friends but not my professional acquaintances (or vice versa) > * (That's why I have two different Fediverse accounts likely on two different servers) > * As I take the action ("share"), I am being asked which of my personas/account to share it to. The way this would work is that each server you're on would register its own web protocol handler. When you access the URL, the browser would ask you which application you wanted to handle it with. This is the same interface as opening a `magnet` URL if you've ever done that while having more than one torrent client installed. So if each persona is on a separate server, this is very easy to address. Creating multiple handlers on a single server, each attached to a specific login, I don't think is possible. Or at least it would be very complex. If a server exposes multiple handler addresses, then it becomes more difficult to set up fallback behaviors. [Soni's draft proposal](https://datatracker.ietf.org/doc/draft-soni-protocol-handler-well-known-uri/) recommends using a single `/.well-known/protocol-handler?target=%s` route, so that it would be easy to craft fallback URLs if a user *did not* have the web protocol handler registered. I like this idea, but it does mean that each server doesn't create ad hoc target routes e.g. `/api/protocol-handler?accountId=[id]&target=%s`

silverpill commented

2023-09-08 11:56:10 +00:00

https://fedilinks.org/

It might be a good idea to register these specs as FEPs: https://codeberg.org/fediverse/fep

https://fedilinks.org/ It might be a good idea to register these specs as FEPs: https://codeberg.org/fediverse/fep

❤️ 1

helge commented

2023-09-24 06:30:11 +00:00

Poster

Owner

We have a FEP: https://codeberg.org/fediverse/fep/src/branch/main/fep/07d7/fep-07d7.md

- We have a FEP: https://codeberg.org/fediverse/fep/src/branch/main/fep/07d7/fep-07d7.md

❤️ 2

helge added the

FEP Exists

label 2023-09-24 06:30:53 +00:00

helge referenced this issue from bovine/bovine

2023-09-30 10:58:48 +00:00

Support FEP-07d7 #54

bumblefudge commented

2023-10-09 20:51:19 +00:00

Meanwhile, in the Browser Extension CG at W3C... some people have been talking about how browser extensions might be able to signal to underlying OS when an in-browser handler is registered...
https://github.com/w3c/webextensions/issues/451

Meanwhile, in the Browser Extension CG at W3C... some people have been talking about how browser extensions might be able to signal to underlying OS when an in-browser handler is registered... https://github.com/w3c/webextensions/issues/451

Web-based protocol handlers #1

Idea

Goal

Difficulties

Links