Nostr Web Client

RE: NIPs, implementations and compatibility.

Specs are hard. They often are unclear and miss edge cases. It’s why the only Bitcoin consensus spec I trust is the Bitcoin core source code - no written documentation or alternative project.

Nostr is moving at such a pace, and development individuals and teams are all self-funded, and frankly keeping up with their own development roadmap is hard enough - let alone trying to keep up with the latest NIPs; either draft NIP input, awareness around proposals, and where the most difficultly lies.. supporting NIPs that break user-space and create a negative user experience and feedback.

Solutions.. not sure exactly. But here are some ideas.

1. A regular 7-14 day reoccurring NIPs updates and presenting via community open video call session.

2. Implement breaking changes in smaller isolated test/POC projects - and not directly into popular app beta builds.

3. Difficult to say.. but perhaps slow down. We have major fundamentals in Nostr that are not great today.. we scrape by. Building on rocky foundations is a future curse - much works pretty well too.

4. Understand that creating work for other devs who are already struggling to keep up, builds more stress and tension.

I have around 500 TODO comments across my Nostr projects… some easy and some hard. It’s not easy to keep up.

Reply to this note

Please Login to reply.

Discussion

damien 2y ago

Makes sense 🤙🏾

சாரு-秋陽 2y ago

This 💯

As a near-addicted user, it's been astounding to see how fast Nostr moves & maybe it's time to slow down a bit and fine-tune before the next surge.

Moreover, wonder how few clients in alpha/beta stage like Camelus, Plasma, Nostribe, etc. will deal with this 🤔

#[0]

p2x 2y ago

This is great debate and it sparks a reflection that must absolutely take place: I’ve been jokingly adding a #fixthenipsystem hashtag since yesterday’s turmoil between Damus and Amethyst. Mind you, I do not know what I am talking about because I have not experienced the NIP system (not contributed to any NIP). So bear with me and forgive me for my outsider’s opinions.

You on the contrary, are bringing potential realistic solutions to the table which should be brought to @fiatjaf imo.

IMO, given the increasing number of users, more and more normies are on those *major clients* now. They don’t know the dev world, they don’t care about the early state of the network. They want to express themselves, bring value, they want their client to work.

If things change too much under their feet, they will compare it to the blue bird crap happening right now and think it’s no better.

Their UX is key to continued adoption. There needs to be some change management considerations and techniques brought into the development lifecycle of those clients.

Lead developers of major clients would benefit from surrounding themselves with UX skilled people. That’s independent, but also intricated with the NIP system: the NIP system should also think about UX if it does not already.

Adam 2y ago

#3: probably not possible, but necessary to avoid building up technical debt that's going to bite us later on.

Blake 2y ago

#3 can be reworded to ‘focus on fewer nips, seeking better outcomes, with greater collaboration’.

Often NIPs are read or worked on by five or so people, yet impact dozens of devs. Very commonly they don’t extract out the general use case, but target a single dev’s target problem today.

A good example is the server AUTH spec. It was never intended for general webapp or api login. Targeted websocket messages by adding a new command (Nostr literally only has four.. so adding a fifth is significant).

That NIP was so focused on a way for DMs to only be queryable by sender/receiver + pubkeys, that it excludes web app login, API auth, and all use cases where you may want or need to prove you hold the private key - like subscriptions or private relays.

If more a collaborative process was happening, it could have been generalised, people have realised websockets use HTTP to connect and supports headers, and we can create a common event kind that works for many use case, and apps can implement once and one NIP.

Devs get very excitable and tinker (including me). That’s important and valuable.. but we need some layer of collaboration on top of that.