Tuba

Tuba copied to clipboard

Describe the request

There is a web service for sharing articles to Mastodon. I discovered this while using the GTK app called "Newsflash". If I share to Mastodon, I can choose from a supported app, in this case only Firefox and GNOME Web showed up. It's really basic. The URL is formatted as such:

https://sharetomastodon.github.io/?title=<ARTICLE%20TITLE>&url=<URL>

It would be cool if Tuba could handle these sharing links so we can share from apps like Newsflash directly through Tuba! Here's a sample generated by Newsflash:

https://sharetomastodon.github.io/?title=New%20in%20Fedora%20Asahi%20Remix&url=https%3A%2F%2Fasahilinux%2Eorg%2F2024%2F01%2Ffedora%2Dasahi%2Dnew%2F

This will share the (currently) latest article from Asahi Linux. I think this project is a cool initiative to allow people to easily share things on Mastodon!

This pops up when you click "Share to Mastodon"

Implementation Details

• [X] This follows the GNOME HIG.

I don't think this is possible unfortunately

Apps can register 'scheme handlers' but they can't filter based on host part for example. Browsers register http, https (among others). If Tuba registered that, it would be a suggestion for any link which is a bit of an overkill. Tuba already handles 2, tuba:// (used internally for callbacks) and web+ap which is the closest to what you request. It doesn't support composing at its current state (the spec is here https://fedilinks.org/spec/en/6-The-web-ap-URI) but it does support general activitypub links, like web+ap://floss.social/@Tuba should open tuba's profile in tuba

What I can do is either add support for composing like so tuba://compose?text=... with a browser extension that modifies 'sharetomastodon' links orrrr write a spec for that and propose it to other clients so we have a universal fedi://compose?text=...

Chiming in with a use case for tuba://compose - I'm using Newsflash, which allows me to add a custom share handler (and URL encodes it properly).

I know it isn't supported right now, but this is an example of how it looks:

And I know this error is expected, I'm just highlighting how the constructed URL looks with your example:

I can probably add it under tuba://compose but I'd really prefer a general standard so other clients can use it too. I can start with tuba://compose and then write a generic spec for fedi:// (or whatever we choose) and bring it up to other client devs for collaboration

Another benefit of a generic spec would be the maintainers of "Share on Mastadon" could add a "Use Local Client" button that just calls the generic variant of the handler, allowing the browser to prompt to open in Tuba (or whichever client).

We can skip 'Share on Mastodon' altogether and let news sites and whatnot to directly use fedi://compose...

I'm writing the tuba://compose one rn and the main thought that comes up is, how far is too far? Should it handle polls, attachments, alt text etc? Or should we keep it very simple? Maybe content warnings?

?text= &cw= &poll[0]= &poll_expire= &attachment[0]= &attachment[0]alt= ...

I don't really like those, but it will be up to the other clients to decide. (issues at the top of my head: polls & attachments have limits per instance, mastodon doesn't allow polls+attachments and no video + other attachments...)

I think for starters we should at most follow mastodon, so only text (maybe I can sneak cw in too)

I think what exactly is supported could be more defined when spec'ing the structure itself. Especially since "fedi" implies "the fediverse" which has more support than just what Mastodon supports as well. It could probably go very far indeed.

#1131

changed /compose to /share so it matches Mastodon's share urls

https://github.com/user-attachments/assets/6e0d0edc-8051-4d84-8d64-fcbbb03f9117