Core exists at this point only to turn Bitcoin into a Politburo that can be captured by the Courtier

There's zero excuse for there to still be a "default" repo in Bitcoin that undiscerning people turn to on account of its legacy

The only Pro-Bitcoiner move the Core repo can make is to archive itself and force the uninitiated to actively choose a distribution #ArchiveCore

That's the Core position, Loops bip has overwhelming support and dissent is banned or shadow edited

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.