[Feature Request] [API] Support subscription to pushes for timelines

[inga-lovinde]

Pitch

The existing notifications/push (https://docs.joinmastodon.org/methods/notifications/push/) method is very useful not just for smartphone apps, but for relays between Mastodon and other systems (e.g. Slack, Matrix, Telegram, etc).

However, this method is only implemented for notifications. One cannot subscribe to new timeline posts. This prevents a whole another set of apps from being created - such as TweetItBot (which worked as a Twitter<->Telegram bridge, providing users with a convenient way to use their timeline from their Twitter app).

Motivation

I want to create a bridge/relay between Mastodon and Telegram similar to TweetItBot. This will give users several benefits, leveraging the existing Telegram features:

• Ability to use Mastodon on platforms where native and fast Telegram clients are available, but not native Mastodon clients.
• Ability to have an infinite timeline (in existing Mastodon clients, timelines are limited to the last 400 toots as described in Show more than 300 toots in home timeline #8336; for me that means that if I accidentally pressed F5 while reading the timeline, all toots posted earlier than several hours ago are lost);
• Ability to search over the timeline (I might remember that I saw some toot a week ago, but right now Mastodon does not offer any way to find it; full-text search, even if enabled, will search over all toots on this instance, while with such a bridge it would be possible to search in timeline or in replies etc);
• Ability to browse timeline by date ("what was on my timeline on April 1st?");
• Instant View support (in-app simplified view of the link content).

Basically that will allow an user to turn Telegram (or Matrix, etc) into just another Mastodon client.

Making and hosting such a relay, and making it accessible to public, would be possible if there was a way to subscribe to the new posts on timeline. streaming API method was designed for front-end clients, and is not really suitable for such a relay: a relay could serve dozens of users (which would mean dozens of open long-lived connections to various instances); making it resilient against possible disconnects would be quite difficult; and it would be much less scalable, not allowing one to use serverless functions.

Implementing pushes for timelines (in addition to notifications) would solve this problem.

Illustration

This is how TweetItBot looks like on Windows 10 Mobile (in Unigram client). Standard Mastodon web UI is almost unusable on this device, none of the alternative web front-ends work well, and there are no reasonably working clients for this platform.

[inga-lovinde]

For example, there could be /api/v1/timelines/push/subscription endpoint.

Just as the existing /api/v1/push/subscription, it would accept POST (create a new subscription), GET (get current subscriptions) and DELETE (remove subscription) requests. (PUT is probably not needed because it does not make a lot of sense to change the existing subscription instead of removing it and creating a new one).

It would work with TimelinePushSubscription datatype which would be similar to PushSubscription, except that instead of alerts map it would accept stream string, with the same supported values as /api/v1/streaming websocket method (that is, user, public, public:local, hashtag, hashtag:local, list and direct), and optional tag and list parameters.

For example:

{
  "id": 328183,
  "endpoint": "https://yourdomain.example/listener",
  "stream": "list",
  "list": 12249,
  "server_key": "BCk-QqERU0q-CfYZjcuB6lnyyOYfJ2AifKqfeGIm7Z-HiTU5T9eTG5GxVA0_OH5mMlI4UkkDTpaZwozy0TzdZ2M="
}

It could probably send the same payload to the app endpoint listener as the existing /api/v1/push/subscription does (it is hard to say because the payload does not seem to be documented).

[ThisIsMissEm]

I think you could archive what you want with the admin webhooks, which can send you every status the instance receives, but I think a generic webpush with configurable settings is likely not going to be implemented.