Next time you see someone spreading Quantum fud, call them a scammer.

https://eprint.iacr.org/2025/1237.pdf

Glad to see this, an issue I've been running into is that nostr-tools isn't really up to the task of long-running services. Zig is the perfect choice for an alt implementation... and most notably isn't beholden to the politics of the NIP repo.

@nevent1qvz...

> I have my own lightning node for the first time

This is how we win


@nevent1qqs...

Oh no! then who will fund the NGO's that attack Bitcoin? 😭

No web-hooks

No LNURL server

No lame etrash or fake L2 shitcoins

Just a static page, with a Nostr static offer embedded, and nostr-native receipts powered by CLINK on a self-hosted Lightning.Pub

@nprofile1q... @nprofile1q...

We don't have an NWC adapter either

The W would disambiguate the kind if there's any collision, so you could reasonably query for the NIP-85 structure and find attestations that might be available where you don't necessarily know or care exactly what types they contain

zap_sats_sent would be a good type in my view, rather than just value, zap_sats_sent would be better having values under it... perhaps things like week month year. So yea to your point I don't think value is itself is a good top-level type example, I mostly like eliminating the registry in the NIP.

Ok that's more clear, thanks for explaining. "Type" really nails it, Schema may be good too, either would be a more concise label for the tag than categories.

Discoverability is a good argument for `w`, I'm sold.

Nice work 👍

it just uses the `name`

I see the new metadata, you're now the proud occupant "pip" 🎉

The formatting here is a little hard to grasp fully, if this could be a proposed diff on the github PR that would be ideal for review

What I do grasp I think I agree with, the NIP as currently constructed is mostly a registry... I don't think its a good idea to hard code a bunch of possible metric tags into the NIP itself... Mani's arbitrary string give it more forward-utility without future changes.

An example expansion in my case would be, if I want my paid services to signal that a user paid for something, or was invited/sponsored by another user, I might arbitrarily want to use NIP-85 to publish a paid_user attestation from that service so other services might whitelist them as a non-bot without their yet having a broader WoT in the form of followers etc.

(open to suggestions for a paid_user/invitation NIP or NIP-85 adaptation to bootstrap WoT)

I'm not sure I see the value in the W tag, seems superfluous with the kind and the fact I'd be looking for a specific tag anyway, but perhaps i'm missing something.

I also think the categories themselves being part of the NIP is the same flaw as the registry, unless they're just meant as examples for a top/bottom leveling tags. This may be where formatting of the site as opposed to git makes things unclear. Basically if I were to make a diff the NIP would be half the size or less.

Unfortunately can't make the call tomorrow but look forward to discussing further and reviewing a diff.

your kind 0 metadata shows as this, and I just re-ran it against your listed relays

"profile": {
"name": "pippellia",
"nip05": null,
"lud16": "whitebat1",

partial match only applies to the name field, and demarcated by spaces... we wouldn't want "pip" to also occupy "pi" for example... but would want someones first name to hit if they used name as First Last

Partial matches do not count in the lud16/nip05's prefixes since those wouldn't have spaces... but neither your nip05 or lud16 are populated with "pip"

Since your name field is "pippellia" that's what you occupy

yep that's him on telegram