nostr-protocol
NIP-11: Pay to relay clarification
This PR does too many things, between changing formats and updating actual NIP semantics. Can you split them up? BTW, I don't think expanding the json to one line per character is helpful for readability.
@staab Style changed removed, I'll move them to another PR. Also, the reason for expanding this JSON (pay-to-relay document example) is to add comments and make it clearer to understand.
This looks good to me, but we'll want someone who has implemented this to confirm that it's all accurate. Maybe nostr.wine?
Here is wines document:
{
"contact": "[email protected]",
"description": "A paid nostr relay for wine enthusiasts and everyone else.",
"fees": {
"admission": [
{
"amount": 18888000,
"unit": "msats"
}
]
},
"icon": "https://i.nostr.build/567z.jpg",
"limitation": {
"auth_required": false,
"created_at_lower_limit": 94608000,
"created_at_upper_limit": 300,
"max_event_tags": 4000,
"max_limit": 1000,
"max_message_length": 524288,
"max_subid_length": 71,
"max_subscriptions": 50,
"min_pow_difficulty": 0,
"payment_required": true,
"restricted_writes": true
},
"name": "nostr.wine",
"payments_url": "https://nostr.wine/invoices",
"pubkey": "4918eb332a41b71ba9a74b1dc64276cfff592e55107b93baae38af3520e55975",
"software": "https://nostr.wine",
"supported_nips": [
1,
2,
4,
9,
11,
40,
42,
50,
94
],
"version": "0.3.2"
}
They are only providing admission rule, but based on their website I can see they have different models to do that.
But the admission is following these changes. or better to say it won't break any existing NIP-11 implementation.
Looks ok to me, but I don't trust myself to review this one correctly, it's an area of nostr I just haven't paid any attention to yet.
@staab Cool, thanks. I think that's important to clarify this part. I think we can ask other friends to check this and make the final decision.
Can someone help review this and make the final decision?
Things are not merged until 2+ implementers have this change in production. That's your actual review. "Reviewers" here just try to see if things are aligned between NIPs. The rest is up to implementers. If this is being actually used, it will be merged.
As a client that consumes NIP-11, I don't think any of these new items are actionable to me. It's not that I can show these to the user and they are going to pay without any extra sales pitch to them.
@staab Yes, there is nothing new. just adding the details of the existing NIP-11. which is required for someone to implement it properly. we need to clarify what are these fields and what they can contain as value.
@vitorpamplona FYI.
Let's make sure we have people actually using these fields. Otherwise, we should go in the opposite route and delete them entirely from the spec.
@vitorpamplona OK, I can see wine and nsotr land are using them at the moment. Also I have plan to use it on my own implementation. So, let't wait to see how it goes.
@staab @vitorpamplona guys, can you help to decide on this? as I said, this is just a clarification of what clients and relays are currently doing. for relay, i mentioned wine and land, which are using strfry, as i know. Also, our rely (immortal) is now using the same convention. on the other hand, clients like keychat are showing and using this data the same way i've explained. so this is just an explanation of fields that are already in use.
You moved the admissions property out of the array. Is that how people have been using it? It conflicts with the nostr.wine example above.
Other than that, I am fine with it.
But I don't actually know if any one uses these fields...
@vitorpamplona about admissions i may missed new changes or something like that since I've been away for a while, i'll take a look and fix it soon.
about use, i can see it in different software as i mentioned and also i can see a potential to be even more used in the future.
will mention you when i add the changes and mistakes soon.
@vitorpamplona @staab i tried to update the changes and turn admission back to an array. but here is what i encountered:
admission is a one-time thing. like you pay 1000 sats and then you have the access. or you just paid the admission. if we define 2 admissions one for 1000 and one for 2000 sats, then they are the same things and the user can't determine to pay for which of them. we can make a difference between them with a time or interval which makes them subscription. so, i can't see any helpful thing behind multiple admissions.
another thing we can do is to consider they may have different levels of access with different amounts for them, then we need to add a description or name field to admission.
for now, i consider the second one without adding a name or description field. then we didn't change the current behavior and have a reason for it as well. (we consider they determine the difference by different fee amounts).
update: i've added an approach for relays to show supporting nips with hex numbers.
This looks good to me, but we'll want someone who has implemented this to confirm that it's all accurate. Maybe nostr.wine?
@nostr-wine what do you think?
Nostr.land also should work with the paid relay changes
yes, afaik all of them work with this model and this pr don't change a spec a lot. the only relay which don't support this is keychat relay. their document contains cashu mint stuff so you can directly pay to them (i think...).
update: for supporting hex nips, ive added a new field called suppored_nips_extended which is an array of strings.
i have another idea that originally came from the thank god for nostr podcast which says a better way to introduce relays is a landing page, not this document. (@fiatjaf and @staab) based on this i made a full document for immortal as its home page: https://docs.dezh.tech/docs/category/immortal
i think this kind of home page must be available for all relays, and they need to advertise it in the website, landing, or homepage field on this nip-11 document.
any ideas?
I'm implementing a relay and I've bumped into this change now. I didn't understand the purpose of changing the supported nips to string with hex. What's the advantage of that? Because I only see extra complexity without any gain. It will generate a lot of confusion with nips names with some saying in decimal and others in hex. Not everyone who writes nips and contributes are developers and can read HEX and think decimal instantly.
@frbitten having nips with hexadecimal numbers is something else which happened on other prs and i don't know why as well in detail.
so here im just trying to fix that. my idea was showing nip number representation in decimal and put it again on the same array. @Semisol suggested a new extended field. it makes sense since its also backwards compatible and won't make 2 names or identifiers for each hex nip.
also with that people won't need to understand hex exactly. they can simply consider that as another identifier for another nip. that's it.
changing this field to string it worst action as well. makes a lot of relays and clients broken.
and thank you for implementing/following these changes on your relay. now there are 2 relays following this. (im sure some parts thay are clarification is accepted by all relay as well.)
and thank you for implementing/following these changes on your relay. now there are 2 relays following this. (im sure some parts thay are clarification is accepted by all relay as well.)
I'm still trying to understand what the change is and why. As it was, NIP-11 was fine. I see no reason to change.
This idea of NIP in hex was a huge mistake and for me it should be reversed.
This PR suggests creating the "supported_nips_extended" field which I don't see the need for. For me, just continue using the existing "supported_nips" field with decimal numbers.
@frbitten sadly as i said this change only tries to support new numbers as well without breaking anything. there is no new nips with numbers defined in this pr.
maybe @fiatjaf can explain this or you can check #1621 for their conversation.
@frbitteninfelizmente, como eu disse, essa mudança apenas tenta suportar novos números sem quebrar nada. Não há novos nips com números definidos neste pr.
The NIP-11 that is in the master still has the fields as numeric. So I understand that this change has not been merged yet. So just don't do it and there will be no problem.