astro / buzzrelay

Source to relay.fedi.buzz: relay the streaming API of Mastodon instances
https://relay.fedi.buzz
GNU Affero General Public License v3.0
70 stars 9 forks source link

Add /ingest relay endpoint #11

Open M2Ys4U opened 11 months ago

M2Ys4U commented 11 months ago

This adds a new /ingest endpoint to allow instances to opt-in to relaying their users' posts to a buzzrelay instance without necessarily subscribing to receive posts from the relay (or to subscribe to only selected hashtags or instances as they do now).

This allows instances that have upgraded to 4.2 but still want their posts on the relay to participate without requiring that they provide an API token for their streaming API (#6).

It'll probably help with #10 (update and delete posts not being forwarded), too, for posts that originate on a cooperating instance.

Note: I have not tested the code in the PR.

astro commented 11 months ago

Not sure I get the idea here but I actually prefer buzzrelay following back eventually...

M2Ys4U commented 11 months ago

The idea is that this would allow buzzrelay to find posts in a way that's closer to a "real" relay (which is clearly the direction that the Mastodon devs want to move people towards).

You (or whoever else is also running this) won't have to manage accounts or deal with API keys on a bunch of different instances in order to collect posts from their streaming APIs - the admins of those instances can just add this endpoint to their relay config instead.

ClearlyClaire commented 11 months ago

I think this goes in the right direction, but a quick look at the code makes me think the relay currently only understand Follow and Undo Follow activities (https://github.com/astro/buzzrelay/blob/276b78e8e0eafb2f6695e9c3e07e7ed14ad44a99/src/main.rs#L173), so adding a post-only endpoint would not actually be enough for content to be ingested. The relay code should support Create, Update and Delete as well for this to work.

By the way, what you probably want to do on those activities: