remove bloat that no one cares about from nip11 #1946
Conversation
|
At least keep privacy policy and tos. @dskvr might have opinions. |
|
i've seen people using payment_required and auth_required. No idea about the other fields |
|
Also, flotilla uses auth_required, payment_required, and min_pow_difficulty (just to display to users). |
|
Amethyst shows all of them to the user. And I believe all clients MUST do so. |
|
I really wish none of these limits existed. They just make clients more complex by requiring clients to go around them and break one thing down into multiple parts. You only take 20 filters for a sub with 40? Ok, I will do 2 subs of 20 filters each. In the end, the relay ends up doing more work than before. It's just more work for everybody. |
|
What if the relay limits the number of connections by IP? You will use a VPN and use a different IP for each connection? (This is an honest question on how this ends.) |
|
I also wish none of these limits existed for the reasons you mention, but at least the default limit of events to be returned is necessary otherwise clients would inadvertently end up downloading a million events when they just wanted to display the first 10 just because they forgot to specify the "limit". Vibecoders won't even notice it ever. Limits in the number of open requests are also useful sometimes to let the vibecoder know that they are leaking a ton of open subscriptions without even realizing. |
|
Let them load the 10000 or even millions of events. They will notice the mistake in the first time they test. If we hide it, we just make things worse. |
11.md
Outdated
| "auth_required": true, | ||
| "payment_required": true, |
11.md
Outdated
| ### Pay-to-Relay | ||
|
|
||
| Relays that require payments may want to expose their fee schedules. | ||
|
|
||
| ```jsonc | ||
| { | ||
| "payments_url": "https://my-relay/payments", | ||
| "fees": { | ||
| "admission": [{ "amount": 1000000, "unit": "msats" }], | ||
| "subscription": [{ "amount": 5000000, "unit": "msats", "period": 2592000 }], | ||
| "publication": [{ "kinds": [4], "amount": 100, "unit": "msats" }], | ||
| }, | ||
| // other fields... | ||
| } | ||
| ``` |
There was a problem hiding this comment.
Damus uses this to display payment information and other clients do too, I believe.
11.md
Outdated
| @@ -100,270 +86,18 @@ are rejected or fail immediately. | |||
| ```jsonc | |||
| { | |||
| "limitation": { | |||
| "max_message_length": 16384, | |||
There was a problem hiding this comment.
On a web environment I do not think the WS bytes limit is not accessible. So this is useful.
I agree with this. For NFDB I implemented a ratelimit policy based off of IP address, and based off of how much work is being done (how many events read from DB, and memory size of subscriptions) instead. |
I am already using an Embed Tor to create multiple exit node IPs that reach out to Relays. |
Agree.
|
|
Please take a look at this new commit. Mostly I've removed the "content" guidelines this time. I've kept the restriction numbers and the payments stuff. |
Is anyone using any of these things?