Nostr Web Client

After nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 explained there are enough kind numbers and why we need to use them, nostr:npub1manlnflyzyjhgh970t8mmngrdytcp3jrmaa66u846ggg7t20cgqqvyn9tn argued that clients and relays, as the front line of “great user experiences”, should be able to share new and needed content types with each other “ad hoc”🤔

https://yakihonne.com/article/naddr1qq257drt244x6ufkx3xyzs6kdpuh5n3jg459qq3qmanlnflyzyjhgh970t8mmngrdytcp3jrmaa66u846ggg7t20cgqqxpqqqp65w7gtxrh

What do you think? Leave your comments on YakiHonne👆

Reply to this note

Please Login to reply.

Discussion

ManiMe 2y ago

Oh Snap!

nostr:note1e6kvv3qc3j7m38zf0ze8hpczd3rhvdk8pp7aew3rv6eaaptw0cyq0pyx7w

fiatjaf 2y ago

No, that's an awful idea. We need compatibility between apps, not each app coming up with their own encoding scheme.

ManiMe 2y ago

Decentralized compatibility is “baked in” to the design, by implementing a bidirectional “handshake” for clients and relays to be learn about and adapt to each others capabilities.

https://github.com/nostr-protocol/nips/issues/862

fiatjaf 2y ago

It is not baked in, it has to be programmed. Code has to be written, strings and constants have to be hardcoded.

ManiMe 2y ago

True.

beep ⚡️ 2y ago

Drivechains for the other stuff?

ManiMe 2y ago

A formalized approach for clients and relays to design, test, and publish novel content types for end user needs. It’s a rough start.