What’s bad about it?
-
What’s bad about it? It gives read access to their entire server, gives access to followers-only and mentioned-only posts, not just public posts.
I don't see what I can do about Mastodon's security issue in #FediBuzz. I was hoping the Mastodon people were using the time to make permissions more fine-grained instead of sabotaging useful services that simply help supporting decentralization.
I have added relay client functionality a year ago, subscribing to many of the other public relays. However, the resulting throughput is at 0.1 posts/s which is really poor compared to the 10 posts/s we get from the public federated timelines. Implementing it was wasted time but it totally validated the client API approach. I wonder why that is still recommended by operators of big servers as they don't seem to bother joining relays at all, otherwise there would be much more traffic.
Please stop telling me "you are doing it wrong." Posing as a person who wants to control a social network has strong Elon vibes. It will make me look into Bluesky and Nostr eventually where firehose feeds are public for everyone.
-
I'm creating this topic for discussions about Fediverse relays: sharing technical notes, discussing implementations, documentation collaboration, and so on. The goal is to create an FEP to document the relay-related status quo to help other developers who need relay support (building a server that uses a relay, building a relay, etc.).
AFAIK, there are two relay protocols for the Fediverse, the Mastodon relay protocol and the LitePub/Pleroma protocol. I don't know how much interop there is between them or if relays must do some normalization based on the type of relay client. I'm still investigating that topic.
I've been studying the Activity Relay (Go) implementation and @trwnh has been looking into pub-relay (Crystal). Are there other common relay implementations we should review? The relay protocols and behaviors will probably vary a bit depending on the implementation so it would be nice to have decent coverage of the variants.
I've started creating a small relay implementation in Python for educational and testing purposes.
/cc @bumblefudge
-
What’s bad about it? It gives read access to their entire server, gives access to followers-only and mentioned-only posts, not just public posts.
I don't see what I can do about Mastodon's security issue in #FediBuzz. I was hoping the Mastodon people were using the time to make permissions more fine-grained instead of sabotaging useful services that simply help supporting decentralization.
I have added relay client functionality a year ago, subscribing to many of the other public relays. However, the resulting throughput is at 0.1 posts/s which is really poor compared to the 10 posts/s we get from the public federated timelines. Implementing it was wasted time but it totally validated the client API approach. I wonder why that is still recommended by operators of big servers as they don't seem to bother joining relays at all, otherwise there would be much more traffic.
Please stop telling me "you are doing it wrong." Posing as a person who wants to control a social network has strong Elon vibes. It will make me look into Bluesky and Nostr eventually where firehose feeds are public for everyone.
@Astro we are, of course, always working on ways to improve Mastodon's security & safety posture, this is a continuous process. As mentioned in the original GitHub issue after the streaming API had security increased, the streaming API was never intended as a tool for mass data gathering nor mass data scraping without consent.
The streaming server is not intended for this usage, plain and simple: it's intended for end-users to get quicker updates in the clients that they use.
Right now, what you're doing exposes users to abuse that is invisible to them, but visible to their followers, because you're accessing our content without consent and then broadcasting it to servers we have defederated from.
This is an issue that existing Relays do not create, because they gain consent to access data.
-
I'm creating this topic for discussions about Fediverse relays: sharing technical notes, discussing implementations, documentation collaboration, and so on. The goal is to create an FEP to document the relay-related status quo to help other developers who need relay support (building a server that uses a relay, building a relay, etc.).
AFAIK, there are two relay protocols for the Fediverse, the Mastodon relay protocol and the LitePub/Pleroma protocol. I don't know how much interop there is between them or if relays must do some normalization based on the type of relay client. I'm still investigating that topic.
I've been studying the Activity Relay (Go) implementation and @trwnh has been looking into pub-relay (Crystal). Are there other common relay implementations we should review? The relay protocols and behaviors will probably vary a bit depending on the implementation so it would be nice to have decent coverage of the variants.
I've started creating a small relay implementation in Python for educational and testing purposes.
/cc @bumblefudge
May I ask why this FEP is finalized? There haven’t been any implementors (except for Fedify, above?) who have submitted comments about this.
I’m attempting to implement Litepub-style relay consumption as per this FEP, and there is no guidance on what
stateis supposed to be, besides being hardcodedpendingwhen sending the follow, andcancelledwhen Undoing.
