You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We already have a rate limit feature implemented on the relay side to prevent peers from flooding the relay with messages. This works fine. But what we haven't considered is since anyone can host his own relay he can configure his limits (or no limits) which means his messages will still be delivered over federation.
I was wondering if it's a good idea to also set the same limiting mechanism on the "federation" API so a source twin "total number of messages" is aggregated on BOTH ends (over the websocket end where he is connected directly) and the (http end if his message is federated from another relay)
The text was updated successfully, but these errors were encountered:
We already have a rate limit feature implemented on the relay side to prevent peers from flooding the relay with messages. This works fine. But what we haven't considered is since anyone can host his own relay he can configure his limits (or no limits) which means his messages will still be delivered over federation.
I was wondering if it's a good idea to also set the same limiting mechanism on the "federation" API so a source twin "total number of messages" is aggregated on BOTH ends (over the websocket end where he is connected directly) and the (http end if his message is federated from another relay)
The text was updated successfully, but these errors were encountered: