Oddbean new post about login | logout I said this before and will say it again: The most underrated feature of Nostr is the event kind as Integer and not a String. That simple choice alone is the reason why Nostr apps are MUCH more interoperable than any other signing standard. I worked for 3 years with Verifiable Credentials where schemas and types are strings. There is no real interoperability between Verifiable Credentials. Everyone just creates their own names/types and fuck everybody else. There is no effort to reuse names somebody else is already using and/or to standardize what values those names take. You can verify the signature, but you don't know what the signed payload means or does unless you go talk to the issuer directly. String types create the false impression of documenting what the type is without having to write it down somewhere else. Nostr's integer kinds require you to explain what you are doing in some other place than the type name itself. And that creates a possibility to explain the entire sematics of what your type is doing. It's just a better "system" for real interoperability.
Do you think a NIP-string format still makes sense though? Numbered nips when we already have numbered kinds seems a little vain
Yep, those are helping as well. They create a sense of community that names alone wouldn't have. But they are less important than kind numbers.
We still have this IMO, like sometimes I see arbitrary kinds when my signer asks me to sign something. Fortunately, the most popular kinds are now recognised and labelled but it doesn't change that there are still arbitrary kinds.
yep, but the number creates the user pressure on the dev to label it in a NIP otherwise users don't know what those are. Usually pro users are quite vocal and can be pretty annoying about these things. Useless kinds will remain undocumented, but they are useless, so who cares.
As a big fan of stringifying all the things I think you make some good points.
Me too, but it's hard to dismiss evidence.
The only problem i see with this is itʼs easy to have two cempletely different NIPs that use the same kind number; with textual IDs itʼs hard (although not impossible) to do that.
yep, and that is good: Don't fuck up your choice of event kinds.
The only proper I'd is some long random number like UUID.
yes, i’d totally prefer that over the current, (seemingly) monotone increasing number; I mean, if the biggest kind number i ever saw is 63, how should i know if someone else is already working on a NIP with a kind 64 or if i can use it in mine?
Just query all relays for the event you want: crawler.amethyst.social
This is on purpose. You HAVE to know what others are doing otherwise your own apps are in danger.
Commenting so I can share this knowledge with the plebs in future educational sessions
Bizarre bullshit. A correct random number generator will produce IDs that no one uses, with certainty.
Who cares? Picking a unique number is not hard.
You may find this useful https://undocumented.nostrkinds.info
How about both? Make everything a 256bit integer. Generate those from a hash of your string that can be found somewhere else. The point being that integers are easy to deal with (byte array really) but harder to collide giving permission for "bank/transfer" to an app requesting access to "garbage/spew".
Interesting post nostr:nprofile1qy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcqyprqcf0xst760qet2tglytfay2e3wmvh9asdehpjztkceyh0s5r9cscy77s Thanks for making it. #Learning
Errr no. You've clearly not read the verifiable credentials standards. Not than im promoting them, they have serious flaws. Numbers are neat in a small eco system. But as you grow named types become a valuable way to scale. String types power a big chunk of the internet, many orders of magnitude bi bigger than nostr. I like nostr and numbered types are suseful. But string types scale more. Both strings and numbers work well enough for different things..
I helped make 3 billion verifiable credentials for multiple vendors, all in the same field. None of them talked to one another. They all use the same name but each issuer defines what the name means. There is no interoperability. They all need to talk to one another offline to figure out how to use each other's signed payloads. They all thought that just using the same name would solve everything. Nothing was further from the truth. Verifiable credentials are cool and all but it's not interoperable AT ALL. Nostr beats them with both hands tied up. It's not even close.
That's simply due to poor implementation. Not due to the standard. The named types are part of a set of standards, not defined in VC. Frankly, most of the VC folks didnt read the specs, and that was most of the problem. Take for example schema.org which uses strings for types. It uses the same standards and achieves many orders of magnitude more interop then nostr. That's just one project that uses the standards. But it's all good, nostr can use both numbers and strings for types in different contexts, via websockets, and the web. For example: https://w3id.org/nostr
My point is that the standard can massively help interoperability. The VC standard leaves it to the implementers, which is terrible because, like you said, they REALLY suck at this. What more proof do you need than 175 different did methods? We have 3 separate Bitcoin DID methods alone. If our closed community can't even agree on this, imagine the rest of corporate devs that have no incentive to work together... It's the same issue in Health Care with HL7/FHIR data. The standard is cool, but unhelpful to keep implementers looking at one another and reusing their way of doing business. Zero interoperability, even though everybody offers the same type of payloads.
Agree with the first part. They even gave lots of bogus examples so people were copying and pasting things that were not best practices. DID got messed up even worse, but was not designed to do that, I designed it to make a uniform interoeprable interface for the bitcoin block chain, but it got co-opted. But the lack of interop doesnt come from named types. There is lots of other technical debt, bad examples, and deviation from the standards. The named types are probably the one useful thing in there. ActivityPub uses named types and its growing faster than nostr. I do like the nostr number system, because its simple and works. But if you had an OO system and every class was a number, it's going to struggle to scale at some point. Numbers work well because nostr is early and small. I was actually thinking of rewriting the whole of DID and VCs, taking the good bits for nostr. It might happen one day, but magic numbers vs types is not really a deal breaker. Plenty of other things are tho. VC/DID is frankly a mess, the data structure is a set, no arrays, no canonicalization, the examples are wrong, the context breaks everything, the document is not defined, no one knows how to make a vocab excapt dave and manu. Even they cut corners. The list goes on and on.
Agree w/ everything. If you end up proposing a new one, make it ultraspecific. Don't let other people fuck your stuff up. :)
I roughly know that is needed, this time round - take the taproot data model and apply expand ways it can be used - structured profiles that can have developer defined extensions, e.g. for subkeys - tighter integration with on-chain transactions allowing timestamping, versioning and smart contracts - uniform caching and scaling interface, layered, stateless, with CDNs and proper etags - proper json based data models with schemas that work, can be versioned, have an audit trail - schnorr signatures over simple json data structures, as today - lightning fast profile and roster apps, allowing things like chat - personal storage, access controlled - everything payments ready, with audit, and observable reputation - close AI integration so that nostr builds itself - proper web of trust including punishment zaps for bad actors, spammers, scammers - wide range of micro apps, including chat - incentive structure to support long term growth, on a level playing field and so on ...