Add NIP-XX: Static Payment Addresses

[0ceanSlim]

Summary

This NIP introduces standardized static payment addresses using a dedicated event kind 10780.

Motivation

• Provides consistent way to include payment info without bloating user metadata
• Supports multiple cryptocurrencies and networks
• Improves interoperability across Nostr clients

Implementation

• Uses dedicated kind 10780 (replaceable event)
• Simple 3-element tags: ["asset", "network", "address"]
• Supports BTC (bitcoin/lightning), LBTC (liquid), ETH, XMR, USDT
• Includes client implementation guidelines

Reference Implementation (Work in progress, current code is the older kind0 implementation)

Updated implementation will be available at: https://github.com/0ceanSlim/link
Current demo (old implementation): https://link.happytavern.co/npub1zmc6qyqdfnllhnzzxr5wpepfpnzcf8q6m3jdveflmgruqvd3qa9sjv7f60

(Draft 2)

[0ceanSlim]

I'm not against just making a new kind with the same scheme and not adding them to the user metadata directly. It's just the route that made the most sense to me since people usually would want this displayed with the rest of their metadata.

[vitorpamplona]

@greenart7c3 is this better than what you have on the PR?

I am not sure if we need all this asset / network splits.

Also, liquid BTC is not BTC, it's LBTC.

[0ceanSlim]

Also, liquid BTC is not BTC, it's LBTC.

Fair enough. Still wondering if it should just be a new kind or in the metadata.

[vitorpamplona]

To me the asset type is not use-case dependent. So, it's not like NIP-17 will use one wallet address and NIP-68 will use another. If every nostr app needs to load this second metadata kind just to get addresses somebody is using, it defeats the purpose of the extra kind.

Also, it's not like people will fill their metadata with 100s of addresses. They will use it 3-4 at the most. This doesn't really increase the size of the metadata kind that much.

[0ceanSlim]

@vitorpamplona whew! So I won't have to change my implementation too much 🤣
I already made LBTC it's own asset. Waiting for more comments.

[greenart7c3]

@greenart7c3 is this better than what you have on the PR?

I am not sure if we need all this asset / network splits.

Also, liquid BTC is not BTC, it's LBTC.

I think we could change to use this, we don't use the asset/network split but other apps can use it to get price or the icon
Wallets and people showing their donation addresses can also use this instead of the way I was doing in the amethyst pr

[0ceanSlim]

How does one even go about assigning a new nip number these days? 😂

[dluvian]

Kind 0 is already overloaded. I would prefer to have this in a different kind.

[0ceanSlim]

@dluvian In what way do you mean it's overloaded? Every field is optional. Clients don't have to implement everything if they don't want to. But this is static data that is specific to the user. I think it makes most sense to go in kind0. And kind0, even with everything filled out, is still not that large. I'm open to whatever, I just want the feature added in most clients, but @vitorpamplona has also pointed out some reasons for it to go in kind0.

[dluvian]

Clients don't have to implement everything if they don't want to.

Clients still need to keep track of all fields or they will remove them and the user gets confused why fields are suddenly missing.

And kind0, even with everything filled out, is still not that large.

People treat it as a data dump. If we keep adding fields it will be large. It's already larger than it should be.

I just want the feature added in most clients

Kind 0 is not a shortcut for getting into other clients. Most clients which fetch this profile event don't care about donation information, why should they have to download it?

[fiatjaf]

Kind 0 is already overloaded. I would prefer to have this in a different kind.

This.

Remember that a client downloads thousands of these events all the time from every simple mention, reply or just scrolling a feed. The more we add to them unnecessarily the worse it is for everybody. Having a dedicated kind, like 10780, just for donation addresses, would be much better.

Now only clients that care about this need to fetch it, and only when a user actively clicks on a profile, for example.

[0ceanSlim]

Clients still need to keep track of all fields or they will remove them and the user gets confused why fields are suddenly missing.

No they don't, my implementation (link) just takes all the current fields and adds the w tag while just keeping anything that isn't changed the same. I'm not sure why you would need to know what their previous one had in fields you are not concerned with. If you concern yourself with all possible fields in your client even though you don't use them, that's just poor implementation.

People treat it as a data dump. If we keep adding fields it will be large. It's already larger than it should be.

How large should it be. I would think it should be as large as a user wants it. It should contain metadata about the user, which this is. If you want to arbitrarily split user metadata fields then why not have a seperate kind for lightning address, name, picture, etc? We don't because those are user metadata and that's what kind0 is for. A new kind makes less sense to me.

Kind 0 is not a shortcut for getting into other clients. Most clients which fetch this profile event don't care about donation information, why should they have to download it?

I wasn't suggesting this is a shortcut to get in clients. I was only saying I don't care what we actually do, let's just agree on something and do it. Clients will implement what they want. Users want this. This PR opens discussion to actually get something done. I don't care what the end result is. I just want a result period. That's all I meant by that statement.

Again, I'm not against a new kind, but until there is a large signal from other devs here that that is how they would want to see it, I'm not changing it.

[kehiy]

Is it neccesary to integrate shitcoins?

[fiatjaf]

These tags shouldn't be single-letter. There is no need for them to be indexed.

[fiatjaf]

If you concern yourself with all possible fields in your client even though you don't use them, that's just poor implementation.

Take a look at this: https://github.com/0ceanSlim/link/blob/c213ddf48a5f4fd9d371bde84743ecb5df40c8c1/src/types/userMetadata.go

If this UserMetadata type is used in a normal and reasonable way to write a user's metadata it will overwrite other fields that exist in that JSON object, like name (defined in NIP-01), nip05, banner, lud16 and others.

I know the current proposal uses tags and not fields in the JSON object, but I'm just pointing out that "poor" implementation is everywhere, and the specs should have that in mind and try to minimize both user error and programmer error. I'm not taking shots at you either, my library probably does the same, it's just that writing decent code for inheriting existing unknown fields in a parsed JSON object in a typed language is not trivial.

[dluvian]

No they don't, my implementation (link) just takes all the current fields and adds the w tag while just keeping anything that isn't changed the same.

That's keeping track of the whole data dump event.

[0ceanSlim]

No they don't, my implementation (link) just takes all the current fields and adds the w tag while just keeping anything that isn't changed the same.

That's keeping track of the whole data dump event.

I suppose you're right...

[0ceanSlim]

After reading @fiatjaf and @dluvian comments I'll revisit with an alternative and see how that floats in comparison. Is there another PR that does something similar with a new kind?

[0ceanSlim]

Take a look at this: https://github.com/0ceanSlim/link/blob/c213ddf48a5f4fd9d371bde84743ecb5df40c8c1/src/types/userMetadata.go

It only uses that type to display that information, not to assemble the new event. It just uses the old event for that since I'm not modifying any content, just adding tags. But I understand your point completely.

minimize both user error and programmer error.

I've taken comments into account and changed the proposal significantly. Let me know @fiatjaf @dluvian any more criticism. I'll start on making changes to my implementation if this is mostly okay.

[fiatjaf]

Looks better now. Thank you.

I hate the shitcoins, but if we are going to have them at least this is a saner way that doesn't hurt too much.

Since we're shitcoining now maybe you should also include all those fiat-related payment methods such as Paypal, Ko-fi, Patreon, that thing that allows you to send money through the postal office, Buymeacoffee and so on?

[0ceanSlim]

Ethereum and Tron are only specified to support the transfer of USDT on those networks. I have the same personal reservations of shitcoins as you and many others do. I think moving forward USDT will become more and more prevalent, especially in economies that are dollarizing as their own currency goes to zero. That doesn't mean I think it's the best choice for them. I personally think that they should start using Bitcoin instead. But if someone wants to send me USDT or even Ethereum for that matter I would like to be able to accept it so I can then exchange it for something that's not shit.

The goal was to provide a framework that could support 90% of use cases.

Fiat payment methods were not included as this only applies to digital blockchain currencies. A new nip for adding a cash tag or a PayPal email address is not a bad idea though.

I think it should be supported if millions of people actually use it instead of just supporting the things that we personally use.

[0ceanSlim]

Of course I could just take All of the asset and network identifiers out and just leave it up to the client and user to implement whatever they want but that seems less helpful

[dluvian]

Looks good to me. But I would remove the Supported Assets and Networks section and just have them as example tags in Event Structure. I would also add one example tag for fiat payments. Clients SHOULD gracefully handle unknown assets as you pointed out so no need to specify must have assets. And most people don't care about crypto, it shouldn't be forced.

[dluvian]

And most people don't care about crypto, it shouldn't be forced.

Ok nvm, this event is specificially for crypto if I understand correctly.

[0ceanSlim]

And most people don't care about crypto, it shouldn't be forced.

Ok nvm, this event is specificially for crypto if I understand correctly.

It doesn't have to be. I'm good with your suggestion. Make it as broad as possible and just provide some in the example.

[vitorpamplona]

Should bolt12 addresses be an option here?

[ConorOkus]

Should bolt12 addresses be an option here?

And by extension BIP353 - https://github.com/bitcoin/bips/blob/master/bip-0353.mediawiki

[TheAwiteb]

Can you also update the README.md with the new kind (after rebase)

[TheAwiteb]

Can you change the format to this, like other NIPs. It's good to have a standard format for NIPs viewers.

Suggested change

	# NIP-XX
	## Static Payment Addresses
	`draft` `optional`
	NIP-XX
	======
	Static Payment Addresses
	-----------------------
	`draft` `optional`

[Silberengel]

@0ceanSlim they really talked this one to death.

I went with #2119

[0ceanSlim]

@Silberengel they added it to external identities NIP.

[Silberengel]

they didn't

[Silberengel]

And I think it's better in a separate kind.