Shipping jsr:@innis/nostr-nip29 today. Pure domain helpers for NIP-29 relay-based groups. A group is owned by the relay that hosts it; the relay publishes a kind 39000 metadata event for each one. This turns those into Group value objects and builds the kind 9 replies. No I/O, querying and rendering stay in the consumer.
This is in the spirit of the relay-selection library I put out in May. This library is small, and only implements part of the NIP-29 spec, but addresses some inconsistencies I was encountering when building my client: the relay hint on the group h tag, how a chat reply should be structured, which metadata markers matter. I wanted to get those right, and after encountering differing implementations in the wild, decided to read how existing clients handle them, and where the spec is silent they each made their own reasonable call. Fair enough; there was nothing written to follow.
So I pulled that common core into one place, fully tested, with every step past the written spec flagged as a convention rather than passed off as protocol. I'm a perfectionist and I would rather be corrected than be quietly wrong, so this is published on its own to open the discussion more than settle it. If I've misread a NIP, or you'd shape one of these conventions differently, I'm happy to be corrected. The point is to improve everyone's code, mine included.
The scope is deliberately narrow. It models the parts of NIP-29 the app I've built against it actually uses: metadata, chat, replies, and nothing else. Admins, roles, the group lifecycle are not modelled, because nothing I've built needs them yet, and I would rather leave the shape unwritten than guess it from the spec and be wrong. They'll get the same scrutiny the rest got, when I eventually need them.
Built on @innis/nostr-core, alongside the signers, the pool, the event store, Blossom, and relay-management. AI was involved, same terms as before. The architecture is mine. The decisions are mine.
deno add jsr:@innis/nostr-nip29
https://github.com/johninnis/nostr-nip29-ts
MIT.
#nostr #typescript #opensource #nostrdev
Thanks to @Dawn @hodlbod @utxo the webmaster 🧑💻 @verbiricha and @Anjhc
This is in the spirit of the relay-selection library I put out in May. This library is small, and only implements part of the NIP-29 spec, but addresses some inconsistencies I was encountering when building my client: the relay hint on the group h tag, how a chat reply should be structured, which metadata markers matter. I wanted to get those right, and after encountering differing implementations in the wild, decided to read how existing clients handle them, and where the spec is silent they each made their own reasonable call. Fair enough; there was nothing written to follow.
So I pulled that common core into one place, fully tested, with every step past the written spec flagged as a convention rather than passed off as protocol. I'm a perfectionist and I would rather be corrected than be quietly wrong, so this is published on its own to open the discussion more than settle it. If I've misread a NIP, or you'd shape one of these conventions differently, I'm happy to be corrected. The point is to improve everyone's code, mine included.
The scope is deliberately narrow. It models the parts of NIP-29 the app I've built against it actually uses: metadata, chat, replies, and nothing else. Admins, roles, the group lifecycle are not modelled, because nothing I've built needs them yet, and I would rather leave the shape unwritten than guess it from the spec and be wrong. They'll get the same scrutiny the rest got, when I eventually need them.
Built on @innis/nostr-core, alongside the signers, the pool, the event store, Blossom, and relay-management. AI was involved, same terms as before. The architecture is mine. The decisions are mine.
deno add jsr:@innis/nostr-nip29
https://github.com/johninnis/nostr-nip29-ts
MIT.
#nostr #typescript #opensource #nostrdev
Thanks to @Dawn @hodlbod @utxo the webmaster 🧑💻 @verbiricha and @Anjhc
52❤️4❤️1🤙1
