Nostr Web Client

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).

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 10mo ago

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

Reply to this note

Please Login to reply.

Discussion

fiatjaf 10mo ago

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.

Mazin 10mo ago

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.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 10mo ago

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

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 10mo ago

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

fiatjaf 10mo ago

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?

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 10mo ago

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

fiatjaf 10mo ago

The problem is that you don't understand that if everybody does whatever they want no app will be compatible with no other app.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 10mo ago

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

Silberengel 10mo ago

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

https://next-alexandria.gitcitadel.eu/publication?d=gitcitadel-project-documentation-curated-publications-specification-7-by-stella-v-1

Mike Dilger ☑️ 10mo ago

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.