Paso 1 de 6
El relay tiene su propia clave
Cada evento del lado del relay se firma con la pubkey del campo self del documento NIP-11 del relay, así los clientes pueden comprobar que realmente viene del relay.
NIP-43
BorradorEventosRelay
Da a los relays de membresía un vocabulario común: el relay publica quiénes son sus miembros y qué roles existen, los usuarios piden unirse con un código de invitación o piden salir, y el relay anuncia cada cambio como un evento firmado.
Edita el formulario o el JSON: ambos se mantienen sincronizados, la insignia indica si el resultado es válido y, al tocar cualquier campo, se explica qué hace.
Cómo se conectan las partes: Unirse a un relay de membresía
Aún sin firmar · Solo claves de demo. Las claves secretas de estos personajes son públicas a propósito.
Selecciona cualquier campo del formulario o del JSON para ver qué hace.
Paso 1 de 6
Cada evento del lado del relay se firma con la pubkey del campo self del documento NIP-11 del relay, así los clientes pueden comprobar que realmente viene del relay.
Ningún capítulo del curso cubre este NIP todavía. El editor de arriba es la forma más rápida de empezar.
Los eventos del relay se firman con la pubkey self del documento de información del relay, y el soporte se anuncia en supported_nips.
Todos los eventos aquí llevan el tag protegido "-".
Los canjes fallidos reutilizan el prefijo "restricted: " de NIP-42.
El método createclaim de la API de gestión de relays entrega códigos de invitación.
El texto de las especificaciones se cita en inglés del repositorio nostr-protocol/nips. Nuestras explicaciones y la interfaz están traducidas. Código fuente en GitHub en el commit 0046368
This NIP defines a way for relays to advertise membership lists, and for clients to request admission to relays on behalf of users.
Relays MAY publish a kind 33534 event which defines a role which may be assigned to members. This event MUST be signed by the pubkey specified in the self field of the relay's NIP 11 document.
The following tags are required:
- tagd tag defines the role id.The following tags are optional:
label - a label for the role.description - a description of the role.color - a hue value from 0 to 360 for the role.order - a order integer for the role (for client display only).{
"kind": 33534,
"pubkey": "<nip11.self>",
"tags": [
["-"],
["d", "28b7e50f"],
["label", "king"],
["description", "ruler of the relay"],
["color", "37"],
["order", "1"],
],
// ...other fields
}
Relays MAY treat members with a given role differently in terms of relay access policies, but no mechanism for introspection is defined at this time.
Relays MAY publish a kind 13534 event which indicates pubkeys that have access to a given relay. This event MUST be signed by the pubkey specified in the self field of the relay's NIP 11 document.
The following tags are required:
- tagmember tag containing a hex pubkey should be included for each member. Assigned roles may be included as subsequent arguments.This list should not be considered exhaustive or authoritative. To determine membership, both a kind 13534 event by the relay, and a kind 10010 event by the member should be consulted.
Example:
{
"kind": 13534,
"pubkey": "<nip11.self>",
"tags": [
["-"],
["member", "c308e1f882c1f1dff2a43d4294239ddeec04e575f2d1aad1fa21ea7684e61fb5"],
["member", "ee1d336e13779e4d4c527b988429d96de16088f958cbf6c074676ac9cfd9c958", "28b7e50f"]
],
// ...other fields
}
Relays MAY publish a kind 8000 event when a member is added to the relay. This event MUST be signed by the pubkey specified in the self field of the relay's NIP 11 document.
The following tags are required:
- tagp tag indicating the member's hex pubkeyExample:
{
"kind": 8000,
"pubkey": "<nip11.self>",
"tags": [
["-"],
["p", "c308e1f882c1f1dff2a43d4294239ddeec04e575f2d1aad1fa21ea7684e61fb5"]
],
// ...other fields
}
Relays MAY publish a kind 8001 event when a member is removed from the relay. This event MUST be signed by the pubkey specified in the self field of the relay's NIP 11 document.
The following tags are required:
- tagp tag indicating the member's hex pubkeyExample:
{
"kind": 8001,
"pubkey": "<nip11.self>",
"tags": [
["-"],
["p", "c308e1f882c1f1dff2a43d4294239ddeec04e575f2d1aad1fa21ea7684e61fb5"]
],
// ...other fields
}
A user MAY send a kind 28934 to a relay in order to request admission. It MUST have a claim tag containing an invite code. The event's created_at MUST be now, plus or minus a few minutes.
{
"kind": 28934,
"pubkey": "<user pubkey>",
"tags": [
["-"],
["claim", "<invite code>"]
],
// ...other fields
}
Upon receiving a claim, a relay MUST notify the client as to what the status of the claim is using an OK message. Failed claims SHOULD use the same standard "restricted: " prefix specified by NIP 42.
Relays SHOULD update their kind 13534 member list and MAY publish a kind 8000 "add member" event.
Some examples:
["OK", <event-id>, false, "restricted: that invite code is expired."]
["OK", <event-id>, false, "restricted: that is an invalid invite code."]
["OK", <event-id>, true, "duplicate: you are already a member of this relay."]
["OK", <event-id>, true, "info: welcome to wss://relay.bunk.skunk!"]
Users can request a claim using the NIP 86 createclaim method.
A user MAY send a kind 28936 to a relay in order to request that their access be revoked. The event's created_at MUST be now, plus or minus a few minutes. This event MUST include a NIP 70 - tag.
{
"kind": 28936,
"tags": [["-"]],
// ...other fields
}
Relays SHOULD update their kind 13534 member list and MAY publish a kind 8001 "remove member" event.
Clients MUST only request kind 28935 events from and send kind 28934 events to relays which include this NIP in the supported_nips section of its NIP 11 relay information document.