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
-
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. -
@devnull The
stateproperty is not necessary. I send regular Follow and Undo activities, that works.May I ask why this FEP is finalized? There haven’t been any implementors (except for Fedify, above?) who have submitted comments about this.
There were no objections. FEP process doesn't require implementations, a rough consensus is enough for finalization.
-
@silverpill @protocol @devnull if the state property isn't defined in any json-ld context won't that make validation fail if anyone bothers to do it? -
@sun In the JSON-LD playground, a property that is not defined in @context results in a "blank node". I don't know how bad that is, but at least it doesn't throw an error.
-
@silverpill @protocol I read more about it and apparently it's never supposed to throw an error because it will just be assumed to be resolveable against the base vocabulary, so it some kind of problem but not a parsing one and can be ignored -
I'm putting in notes as I'm attempting to implement a relay subscription following the Litepub-style.
Asserting the relay server actor proved problematic as
subjectas provided by the relay is missing the schemeacct:.
