Decent Newsroom
Sign In

Nips

by Decent Newsroom

NIP-01

This NIP defines the basic protocol that should be implemented by everybody. New NIPs may add new optional (or mandatory) fields and messages and features to the structures and flows described here.

by Agiota

NIP-05

O NIP-05 permite associar chaves públicas a identificadores amigáveis no formato de e-mail (como nome@dominio.com).

Cover image for NIP-05
by david · Edited

Community Curation of Custom NIPs

This article outlines a simple system to delegate curation of nostr NIPs to your personalized web of trust. Custom NIPs (kind 30817) at NostrHub.io will be enhanced using kind 7 reactions (+/−) for up/downvotes. Reactions will be filtered using personalized GrapeRank metrics communicated via Trusted Assertions. Additional features can be added in the future to ensure a rich, robust and truly decentralized system of NIP management.

Cover image for Community Curation of Custom NIPs
by The Nostr Review · Edited

Nostr Biweekly Review (23 Dec 2024-5 Jan 2025)

In the past two weeks, Nostr statistics indicate over 224,000 daily trusted pubkey events.The number of new users has seen a significant increase. Profiles with contact list amount is four times the amount from the same period. Public writing events have reflected a 50% increase. More than 9 million events have been published, with posts leading in volume at around 1.3 million, representing a significant 32% decrease. Total Zap activity stands at approximately 9 million, marking a 20% decline. Additionally, 16 pull requests were submitted to the Nostr protocol, with 8 merged. A total of 45 Nostr projects were tracked, with 13 releasing product updates, and over 337 long-form articles were published, 34% focusing on Bitcoin and Nostr. During this period, 1 notable event took place, and 3 significant events are upcoming.

Cover image for Nostr Biweekly Review (23 Dec 2024-5 Jan 2025)
by ManiMe · Edited

An Open Architecture for Content Types on Nostr

Nostr is a protocol for communicating events between clients and relays. Events can be anything from adding posts, deleting posts, reacting to posts, editing profiles, and on and on. Each kind of event is designated by a “kind number”. Even different types of user generated content get their own “kind number”. In theory, any client or relay can send or receive (or invent) any event kind number. In practice, however, new kind numbers for events are designated by adding a NIP to the protocol. In this way, developers can coordinate with each other to build clients and relays that work well together. But clients and relays should have the freedom to update and invent new content types for novel use cases. They are the front line of “great user experiences”, and should be able to share new and needed content types with each other “ad hoc”, without having to be “approved” by the NIP standards. This article explains why we should care, and how to resolve this conundrum with minimal fuss, before it gets out of hand.

Cover image for An Open Architecture for Content Types on Nostr