I’m sad https://github.com/nostr-protocol/nips/pull/851 never got merged. We built a nostr.wine NWC service that relied on this improved onboarding flow in December of 2023. At the time Mutiny was leading the effort.
I don’t understand why it wasn’t merged then when we had 4 working implementations. It is the only reasonable NWC on-boarding flow I’ve seen for services (like nostr.wine).
Gotta nag the maintainers, there are 1000 open PRs. Looks like nostr:nprofile1qywhwumn8ghj7un9d3shjtndw46xjmnewaskcmr9wshxxmmd9uq3wamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet59uq3uamnwvaz7tmxv4jkguewdehhxarj9e3xzmny9acx7ur4d3shyqg3waehxw309ahx7um5wgh8w6twv5hsz8thwden5te0wfjkccte9e3x2mn5dpjkxctjd4skutnrdakj7qpqu8lnhlw5usp3t9vmpz60ejpyt649z33hu82wc2hpv6m5xdqmuxhsys5fsc was going to do some additional work and forgot about it.
Ben did a lot of nagging back when he was actively trying to get it merged. He responded to a lot of feedback and kept pushing it for months.
There isn’t even much constructive feedback in the thread just a lot of confusion. The proposal was (more or less) ready to merge from the beginning and was quickly supported by multiple implementations (both on wallet and service side).
What implementations?
If it is ready and working in many places, is it so bad that it didn't get merged? It can still work without being merged, right?
But of course we can still merge, or is it too late now and everything has stopped working?
I remember just saying we should shove it into the NWC NIP, but I don't really understand NWC and never looked at it, so I didn't have much more to add.
Well 2 of those implementations were Mutiny Wallet run so the proposal has died with them it seems. They were the only wallet provider that supported it. Alby used to say they would implement it (and presumably would if it had been merged). Now it feels fully abandoned.
We have just moved on with using the flawed onboarding flow and as such virtually no services interact with NWC at all.
I don’t think it can be merged as is anymore unfortunately. I think Alby is working on some other flow now 🤷♂️
The implementations that worked at the time were listed here: https://github.com/nostr-protocol/nips/pull/851#issuecomment-1879569550
Aren't nutzaps a better flow? (I don't even know if it's related).
They force you to use a custodial wallet or run your own mint, I think? NWC allows for both custodial and non-custodial wallets.
Running an NWC server probably requires the same amount of work as running a NWC server if you want to plug it in your own node.
Nutzaps have the advantage of not requiring any setup from the Nostr side.
Well maybe now that we know Mutiny is dead it was a good choice after the fact to not push this protocol, right? We could have merged and then Mutiny died and then it would be abandoned anyway, but now we would have another confusing unused spec in the repo. Maybe Mutiny died specifically because they implemented this? Who knows.
I know everything could have been the opposite, maybe Mutiny wouldn't have died if we had merged this, but just consider the possibilities.
Hahah yes but if you read the actual proposal you can’t believe any of these “possibilities”.
The entire purpose is to simple reduce an extra roundtrip from the onboarding process. Instead of having to leave our site, go to your NWC wallet, create and copy a URI, then come back and paste it to us all you have to do is scan a QR code from our website and approve the request on your wallet.
Do you really think this flow improvement killed mutiny? Who knows indeed lol
the biggest problem of nostr is that relay and client devs are not teaming up
the fact that they call them "possibilities" (dis you nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 ) and yet they require some absurd requirement where 2x as many clients have to support what the relay supports, means they are not possibilities but this is a dictatorship and people respond to that instead of it just being a record of people's attempts to converge on a spec on both sides
interop means not just many clients use it it means many clients and relays use it and if you put this obstacle against publication and make it hard to find them, thank you github PRs then you see exactly where this problem originates
it's not a consensus if there is no easy to access congress to access the actual discussion
but you have to use telegram for this group or simplex for that group and nobody even considered making it a moderated wiki, oh yeah, i suggested this but then i got some retarded answer from fiatjaf about it
and here we are, where shit just isn't happening because the spec is borken so nobody can actually implement it and nobody has the balls to implement it without getting approval first on the nips repo which is a total contradiction
wen nips wiki, and fuck off with your excuses, the problem is blatant at this point
it would be better if we moved nips to slack, then at least we could fucking talk about shit
nostr:npub18kzz4lkdtc5n729kvfunxuz287uvu9f64ywhjz43ra482t2y5sks0mx5sz Alby almost has a simpler version of NWA implemented for Alby Go. Flash wallet is also interested. We are getting there!
I will share a PR soon for the proposed updates to the NIP-47 spec (rather than a separate NIP).
nostr:npub1zk6u7mxlflguqteghn8q7xtu47hyerruv6379c36l8lxzzr4x90q0gl6ef simplified is good
yeah i'm in the process of implementing the one i have described on the https://realy.lol readme... got a bit of work to do on implementing the database access
because the people who control the nips repo are mainly client devs and because they didn't merge it they didn't implement it
we need to find a way to move outside of their control, and create a better protocol for propagating new API methods... and this is a big problem, most of the clients are web apps, so it has to be JS libraries for the client side, or you never see it get done, and your service is never providing any use to anyone
frustrating, but IMO the simple fact that Hoyte is not even part of the nips-repo push permitted users says everything
I get the impression that Hoyte is not interested in being part of all this drama and that he has a simpler life making cheese.
I too get the same vibe. He has no interest in arguing in the NIP trenches.
Give me your finished spec and I’ll implement it. I feel the same way the vast majority of the time.
it should not be a fight
people build protocol
make client and server implementations
other people can then use it
if they can find it
it should not be a task for decision to put the nips up there but rather simply compilation task, compliance to them is voluntary
the way it is now is not working, it is extremely inefficient, unpleasant, and is leading to the situation where i literally have a relay that is open readable except for a few kinds but neither nostrudel nor coracle can read from the relay because it *rightly so* refuses to do anything further until it gets its auth response
which is because the dictators of the nips are client devs
who don't actually understand protocol development
and this proves it, over 2 years and we still don't have authentication
imagine web 2.0 without auth, just think of it
nips repo should be compilation of the protocol specs people make not the thing they try to make their systems compliant with
and the problem is that most of you guys with push permission on that repo are just client devs (fiatjaf being one of the few exceptions)
asking the question about whether this is working might be the next logical step here, since clearly the current protocol for the protocol is not working
You have created a Nostr-like protocol yourself. Shouldn't your protocol also be a compilation of "specs people make" instead of a document created entirely by yourself in your head?
i see, and where did these documents that get compiled into the collection of specs come from in the first place then?
i already explain it in https://protocol.realy.lol - the apps should contain the spec they are working towards, and if other want to interop with that app (relay or client) they should read that spec, copy it to their repo and implement it
the nips repo is the wrong way to do it, at minimum it should be a wiki, and navigating the "unratified" proposals should be easy
that's not what PRs are for, they are very specific and narrow things and without a welcome mat to point people the way to these proposals nobody is actually joining the discussion, nobody even sees them
the number of times i have had to ask people for the PR link for not yet existing nip numbers i have lost count
if you are serious about making this community work, and you should be, since apparently you are some kind of leader, then you also want it to be easier to discuss new API methods
and that alone is part of the problem, you are in denial about what they are, they are API methods, and this is why nip-11 is a total mess and why almost no clients actually request these, or if they do' they don't seem to understand them, like nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn 's client clearly doesn't comprehend the idea of nip-42 demand to auth for specific reasons but generally not, and nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr his app also doesn't understand auth for specific reasons
reasons like, you know, protecting the fucking users privacy
The problem is that you don't understand that if everybody does whatever they want no app will be compatible with no other app.
the problem you don't understand is that the specs you are gatekeeper for have resulted in a dozen different interpretations because the spec is horrible and everyone thinks that fighting with you is the way to get this problem fixed, except you are busy with building your own stuff so in the end, what does that mean?
that we are supposed to just follow you?
that's the problem
there is no public forum about protocol at all, the minimal solution is people publishing their versions on their apps where they follow them to implement, then the interop problem is solved because you know who to ask
the way you have set this up has not worked for over 2 years but ok i'm wrong
We're just hosting our specs on Wikistr and Alexandria. We're still going through the PR motions, but it's hopeless getting anything merged.
Example:
https://wikistr.com/nkbip-01*fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1
IMHO applications that run on top of nostr should be referenced by the NIPs repo and have their kind numbers registered. But they shouldn't be defined in the NIPs repo. We've been doing this wrong all along and as a result we have run out of NIP numbers. PR #851 (Nostr Wallet Auth) just needs to register kind 33194 and have a link to whatever person or org wishes to own that spec.
IMHO the NIPs repo should define nostr, just the nostr layer, not everybody and their sister's app that runs on top of nostr.
Props on the effort nevertheless
