-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Design a standard way of following people / replying to toots #31
Comments
Thanks, the protocol handler is a good catch you found. Thanks. And actually https://jsfiddle.net/pvyoof6L/3/ worked in my test. (totally independent of this add-on.) I only got this chooser before (OS-dependent AFAIK): It has the advantage you can then also use applications like Tootle or Android apps, if you use them for Mastodon. So as we have this, the use case is quite satisfied already, is not it? |
Not exactly. There is no graceful fallback when using the protocol handler. For example for some unknown reasons I have never seen the dialog to register the protocol handler on mastodon.social and clicking on these links only show The worst part is that if the protocol handler doesn't work then there is no feedback to the user. There are also no good polyfills/workarounds to detect "web+mastodon not supported" on the page. A generic Web Platform solution would allow to specify multiple URIs to be handled in succession (e.g. "if web+mastodon works try it, if it doesn't try this HTTPS link") but I think it would be more complex to add. (For the record there are some HTML elements with fallbacks such as |
Well… to get realistic solutions and not make hypothesis on how we would want the web platform to be like (ehm… don't know where to suggest that… WHATWG/W3C? Maybe do so, if you know how/where.), maybe this add-on could actually try to intercept This would then provide this "graceful fallback" that you wish and could satisfy your use case then? (And it would still built upon currently existing standards.) |
The problem is not graceful fallback when addon is installed but rather graceful fallback when the addon is not installed. Then Currently only |
Oh yeah well, but yes, I could make this thing optional and it would help in the current situation. As for other proposals or graceful fallback things, I guess you need to discuss this with Mastodon and many many Fediverse communities. In the best, a standard like ActivityPub would be needed, and as you see, even ActivityPub is not (yet) adopted by all platforms. Whatever, for this add-on I take away that we can support this custom web protocol. I've opened #32 for this. All other things need to be brought up to bigger communities, and I personally would support such ideas. However, this is nothing this add-on could do much about or is related to, so I'll close this issue here. -- That all said, BTW, obviously web devs could implement such a sharing button with some JS fallback that gets triggered in the background or so. |
BTW @wiktor-k let me know if you continue this idea… (i.e. just comment here, so anyone else can also follow it) |
Okay, I'll make sure to cross link discussions if I pursue the idea further. |
Hello,
Current design uses URL detection and, as such, will always need to track all Fediverse software in use.
I think it would be useful to define or reuse a semantic set of marker data that is common for all Fediverse software. That would standardize "follow" and "reply to" actions (maybe all of them) so that URL detection will no longer be needed.
I'm showing a problem here, the solution is up to discussion.
Some solutions from top of my head:
rel=me
to follow links, the addon would detect and hijack it,This is a continuation of the following thread.
It may be useful to mention that Mastodon experimented with
web+mastodon://
protocol handlers. See mastodon/mastodon#4511 for more info. (Some other software tried to implement it too: tuskyapp/Tusky#633).The text was updated successfully, but these errors were encountered: