Talking through things in #rust on irc.libera.chat was invaluable to me learning, several of the regulars are very knowledgeable and helpful. I think I can call myself an intermediate-level rust dev now but I'm far from an expert...
It's pretty funny to have someone with a shadow the hedgehog profile picture come and explain the lore.
Ok nostr:nprofile1qydhwumn8ghj7un9d3shjtnhv4ehgetjde38gcewvdhk6tcprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qy88wumn8ghj7mn0wvhxcmmv9uqzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vanaunjh you win, NIP 32 was a mistake. I still think it has valid use cases, but it looks too much like an infinitely flexible sub-protocol and is constantly being misunderstood and misused.
My misunderstanding isn't an indictment of NIP-32 lol
I think you're the only person to ever reply to one of my dev posts on nostr, and I dragged you in lol
I've left that as an exercise for the reader, but only nostr:nprofile1qyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcpzdmhxue69uhhqatjwpkx2urpvuhx2ue0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qghwaehxw309aex2mrp0yh8qunfd4skctnwv46z7qg6waehxw309ac8junpd45kgtnxd9shg6npvchxxmmd9uqsuamnwvaz7tmwdaejumr0dshszxrhwden5te0dehhxarj9enx6apwwa5h5tnzd9az7qgkwaehxw309aex2mrp0yhxummnw3ezumn9wshszxthwden5te0wfjkccte9eekummjwsh8xmmrd9skctcqyqtnnkfhmjxqcums4gn4skfccyv7yhzp7mzyrfwnf3kns5p7xymw7teljxj has really come up with a real ontology. I think maybe nos.social has one for reporting too, but I don't know if it's published anywhere.
Using labels for verifications would definitely work, although I think maybe badges would be a better fit semantically.
Thanks! I think you'd need a label on the badge so that automated systems know what the badge actually means. That kind of makes the badge an indirect label anyway. I'll have to think about it though. I suppose it actually opens up using more novelty badges for verification though, like a "1 year club" badge for instance, which has some verification value but it's more of a novelty.
Since I've got your attention on the original post, too, do you have an opinion on how to handle "proof" metadata? (URL to a twitter post, proof of fidelity bond, etc?) Just add the relevant tags? For instance, for twitter verification it might be an 'r' tag, and for fidelity bonds the proof might be some new tag type?
Also, where do you discuss nostr dev typically, so I'm not just harassing you ;-) (although my question was BIP-32 related anyway)
nostr:nprofile1qyd8wumn8ghj7urewfsk66ty9enxjct5dfskvtnrdakj7qguwaehxw309a5x7ervvfhkgtnrdaexzcmvv5h8gmm0d3ej7qgswaehxw309ahx7um5wghx6mmd9uq3samnwvaz7tmjv4kxz7fwvd6hyun9de6zuenedyhsqgyhcu9ygdn2v56uz3dnx0uh865xmlwz675emfsccsxxguz6mx8rygvgrphq secondary: have you considered defining some global/well known labels in NIP-32 kind of like the nip28.moderation namespace you included, especially for covering NIP-56 use cases? nudity and profanity are probably already covered by NIP-36, but "malware", "illegal", "spam", "impersonation" all would be nice to have a canonical representation with NIP-32.
Is there any built in nostr "verification" method?
I'm imagining something like a bip-32 label that would indicate a user completed some form of verification, which applications can use as an anti-spam measure. The specific form of verification is irrelevant, and many providers could exist, they'd publish an event to indicate the result:
{
"tags": [
["p": "verifiedpubkey...", ...],
["L": "verification"],
["l": "captcha-verified", "verification"],
],
...
}
{
"tags": [
["p": "verifiedpubkey...", ...],
["L": "verification"],
["l": "captcha-verified"],
["l": "email-verified", "verification"],
],
...
}
{
"tags": [
["p": "verifiedpubkey...", ...],
["L": "verification"],
["l": "phone-verified", "verification"],
],
...
}
{
"tags": [
["p": "verifiedpubkey...", ...],
["L": "verification"],
["l": "payment-verified", "verification"],
],
...
}
"payment-verified" might include the amount paid
{
"tags": [
["p": "verifiedpubkey...", ...],
["L": "verification"],
["l": "fidelity-bonded", "verification"],
],
...
}
"fidelity-bonded" might include a UTXO and BIP-127 proof
{
"tags": [
["p": "verifiedpubkey...", ...],
["L": "verification"],
["l": "twitter-verified", "verification"],
],
...
}
"twitter-verified" might include the URL of a tweet committing to the verifiedpubkey (and something from the verifiedpubkey committing to the twitter account?)
I'm not sure if the extra information might warrant a different kind than normal labels.
Local relays would need some extended support for application-specific indexing, filtering, and retention, I think, but it might be a winning idea if you can figure that out.
Hah I didn't realize you wrote NIP-32, nor that NIP-32 is newer than NIP-56... how are numbers even assigned? lol
To all client developers:
- Stop using note1 entities, or add e tags with hints when quoting stuff
- Add pubkey hints to e tags (https://github.com/nostr-protocol/nips/pull/1171)
- Publish kind 10002 relay selections so other clients can find your users' content
Coracle frequently has trouble loading quotes because some popular client or other is doing none of these things.
As a side note, it might be useful for NIP-56 reports and NIP-32 labels to be able to provably associate an e tag with a pubkey by providing the signature from the offending event.
NIP-56 requires a p tag for the event author, but the report author could have lied about the pubkey unless you fetch the (potentially illegal) event. But with (pubkey, event id, signature) you can be sure of authorship without ever fetching it.
(A side-side note: why does NIP-56 even exist separately from NIP-32? It seems like just a special case of NIP-32?)
Also, where the hell do you discuss nostr development? I always get crickets here, and if you can't discuss nostr development on nostr, that's troubling...
Am I crazy or is nip-56 a special case of nip-32? Why both and why a different kind?
Me too, hang in there. Although I'm pretty sure mine was caused by Zyrtec. Now I'm just suffering the worst allergies of my life instead lmao
C++ pays my bills but I have to admit the urge to go around shouting "rewrite it in rust" is getting pretty strong lol
The day job has been miserable lately too, makes it harder and harder to resist making the irresponsible choice lol
I like quod libet, although I'm not going to lie, I just cd into a music directory and mpv *.mp3 or mpv *.ogg these days lol