Why Nostr? What is Njump?
2025-04-02 13:49:11

Sebastix on Nostr: 🏗️ 🤓 ...

🏗️ 🤓

You can follow the work in progress here in this pull request https://github.com/nostrver-se/nostr-php/pull/68 on Github.

Before my 3-month break (Dec/Jan/Feb) working on Nostr-PHP I started with the NIP-19 integration in October ‘24. Encoding and decoding the simple prefixes (npub, nsec and note) was already done in the first commits.

Learn more about NIP-19 here: https://nips.nostr.com/19

TLV’s

Things were getting more complicated with the other prefixes / identifiers defined in NIP-19:

  • nevent
  • naddr
  • nprofile

This is because these identifiers contain (optional) metadata called Type-Lenght-Value aka TLV’s.

When sharing a profile or an event, an app may decide to include relay information and other metadata such that other apps can locate and display these entities more easily.
For these events, the contents are a binary-encoded list of _TLV_ (type-length-value), with _T_ and _L_ being 1 byte each (_uint8_, i.e. a number in the range of 0-255), and _V_ being a sequence of bytes of the size indicated by _L_.

These possible standardized TLV types are:

  • 0: special
    • depends on the bech32 prefix:
      • for nprofile it will be the 32 bytes of the profile public key
      • for nevent it will be the 32 bytes of the event id
      • for naddr, it is the identifier (the "d" tag) of the event being referenced. For normal replaceable events use an empty string.
  • 1: relay
    • for nprofile, nevent and naddr, optionally, a relay in which the entity (profile or event) is more likely to be found, encoded as ascii
    • this may be included multiple times
  • 2: author
    • for naddr, the 32 bytes of the pubkey of the event
    • for nevent, optionally, the 32 bytes of the pubkey of the event
  • 3: kind
    • for naddr, the 32-bit unsigned integer of the kind, big-endian
    • for nevent, optionally, the 32-bit unsigned integer of the kind, big-endian

These identifiers are formatted as bech32 strings, but are much longer than the package bitwasp/bech32 (used in the library) for can handle for encoding and decoding. The bech32 strings handled by bitwasp/bech32 are limited to a maximum length of 90 characters.

Thanks to the effort of others (nusa (npub1636…qpl4) and Rik 🔥🌊 (npub1efz…f9s4)) during my break, some contributions are made (modifiying the bech32 package supporting much longer strings, up to a max of 5000 characters). At this moment, I’m integrating this (mostly copy-pasting the stuff and refactoring the code):

So what’s next?

  • NIP-19 code housekeeping + refactoring
  • Prepare a new release with NIP-19 integration
  • Create documentation page how to use NIP-19 on https://nostr-php.dev
Author Public Key
npub1qe3e5wrvnsgpggtkytxteaqfprz0rgxr8c3l34kk3a9t7e2l3acslezefe