NIP-11 extension for Relay Limitations

[doc-hex]

This PR is an extension to NIP-11 and allows the relay to specify its technical, and other, limitations so that clients can adjust their behaviours to better suit the relay.

This includes such things as:

• maximum length of incoming JSON (which has many impacts)
• retention times for specific event types
• political considerations
• content policies

To be very clear: this document DOES NOT propose any values for these limitations. It is merely a way for cooperating clients to know what they are dealing with. All are optional fields.

This PR could be merged into NIP-11 as it is a pure extension to that JSON response, or be its own thing. I'm proposing 111 as its number in that case.

[doc-hex]

Here is the NIP-11 reply for https://brb.io

% curl -sH "Accept: application/nostr+json" https://brb.io | json

{
    "name": "BRB.io",
    "description": "Nostr relay server by Coinkite. A work in progress.",
    "pubkey": "3c1ba7d42c873c2f89caf1ca79b4ead6513385de53743fa6eb98c3705655695c",
    "contact": "mailto:[email protected]",
    "software": "BRB-noserver",
    "version": "0.6",
    "supported_nips": [
        1,
        2,
        4,
        9,
        11,
        12,
        15,
        16,
        20,
        22,
        40
    ],
    "limitation": {
        "max_raw_json": 16384,
        "max_subscriptions": 100,
        "max_filters": 200,
        "max_limit": 5000,
        "subid_length": 100,
        "min_prefix": 4
    },
    "relay_countries": [
        "CA",
        "DE"
    ],
    "retention": {
        "default": null
    }
}

[fiatjaf]

Looks good at first glance, but the NIP number is overflowing.

[doc-hex]

If you assign a new NIP, I will update and add references needed. If you want it merged into NIP-11, that's also an option. Personally, I think a new NIP number is order.

[cameri]

@doc-hex should we add a setting for specifying whether the relay is private or whether it requires pow or payment?

[nvk]

@doc-hex should we add a setting for specifying whether the relay is private or whether it requires pow or payment?

+1

[fiatjaf]

I think this should just be shoved into NIP-11. Why not?

[cameri]

I think this should just be shoved into NIP-11. Why not?

yeah why not? it won't break any client and 1 less NIP

[doc-hex]

@doc-hex should we add a setting for specifying whether the relay is private or whether it requires pow or payment?

adding these limitations:

• min_pow_difficulty: new events will require at least this difficulty of PoW, based on NIP-13, or they will be rejected by this server.

• auth_required: this relay requires NIP-42 authentication to happen before a new connection may perform any other action. Even if set to False, authentication may be required for specific actions.

[doc-hex]

I will merge this into NIP-11 in my next pass.

[doc-hex]

Updated server response example:

% curl -sH "Accept: application/nostr+json" https://brb.io | json

{
    "name": "BRB.io",
    "description": "Nostr relay server by Coinkite. A work in progress.",
    "pubkey": "3c1ba7d42c873c2f89caf1ca79b4ead6513385de53743fa6eb98c3705655695c",
    "contact": "mailto:[email protected]",
    "software": "BRB-noserver",
    "version": "0.6",
    "supported_nips": [
        1,
        2,
        4,
        9,
        11,
        12,
        15,
        16,
        20,
        22,
        40
    ],
    "limitation": {
        "max_message_length": 16384,
        "max_content_length": 12000,
        "max_subscriptions": 100,
        "max_filters": 200,
        "max_limit": 5000,
        "max_subid_length": 100,
        "min_prefix": 4,
        "max_event_tags": 100,
        "auth_required": false
    },
    "relay_countries": [
        "CA",
        "DE"
    ],
    "tags": [
        "bitcoin-only"
    ],
    "retention": []
}

[fiatjaf]

I think it will be less confusing for everybody if we just add a section "extra fields" to NIP-11 and keep adding things there as required.

[Semisol]

I think it will be less confusing for everybody if we just add a section "extra fields" to NIP-11 and keep adding things there as required.

@fiatjaf See my review above.

[mikedilger]

Some of the text at the end is really big. I'm thinking it was not all meant to be a section title

[KiPSOFT]

In my opinion, as new additions are made to the extra_fields field, this field will become increasingly complex. If we are to continue with the same NIP (NIP-11), then I think @doc-hex proposal is a cleaner solution. There are no breaking changes here.

[kappaseijin]

@Semisol @fiatjaf Please give me a reaction my questions. https://github.com/nostr-protocol/nips/pull/163#discussion_r1106934867

[kappaseijin]

I got the answers to my questions. Nostream showed me a prior implementation. I see that relays around the world have already adopted it. I have no more question on this PR. Thank you very much. Hope to have it merged in the near future. https://github.com/Cameri/nostream/commit/b9a13c886811f8ab1c8a479783905dc16cab6959 https://snowcait.github.io/nostr-relays/

[fiatjaf]

Who volunteers to take this stuff here and shove it into NIP-11 directly?

[staab]

Looks like this was merged indirectly? Closing.