Replying to Avatar david

I can sympathize a bit with nostr:npub1qfkcklnmes45z75y7y8dkud5yll8vp5eq5ysk9rmgqdxeasv8unsrfj6kq's frustration. When I built my desktop nostr client I found myself doing a lot of reverse engineering from other clients and apps. Particularly when I added support for NIP-51 lists; I remember it being unclear whether to use kind 30000 or 30001 for a list that has both people and events. So I just looked to see what existed in the wild and figured there’s my answer.

Also, it was unclear whether importation of items using the a-tag should be recursive but I couldn’t find anyone who had implemented it so I just did what I thought made the most sense. (Yes to recursive.)

But I also understand that every additional detail that fiatjaf adds to the nip repo is another opportunity to piss someone off, and/or potentially to lock something in that we later discover was a bad idea.

Avatar
hodlbod 2y ago

I sympathize too. Things being out of control is not easy, but it's also not a priori wrong. Maybe gardening is a good metaphor. You attend to what you can, but a good garden isn't defined by "use cases".

With the lists stuff, you did exactly the right thing, which was observe what existed in the wild (and should have been documented in NIPs as far as that goes), then invent your own solution when you hit a wall. The interesting question is what do you think about the recent NIP 51 re-write? It deprecates 30001 entirely, replacing several ad-hoc solutions with new, different kinds. This was done with the consensus of an overwhelming number of developers, but was top-down (i.e., spec first, then implementation).

Just watched your talk. I love the project! I've also thought long about the WoT problem. Two things to look into — are you aware of NIP 89? It solves the client cataloging/recommendation problem in a WoT-compatible way. And are you familiar with NIP 32? I wrote that one, the goal was basically "decentralized lists" — basically, you apply an adjective to any target (event/pubkey/link), and then anyone can filter those adjectives based on WoT or some other criteria. Seems less cumbersome than merging recursive lists, but I'm not closely familiar with the work you've done.

Reply to this note

Please Login to reply.

Discussion

Avatar
david 2y ago

Oh I didn’t even know NIP-51 was rewritten! Ever since my Nostrville talk I’ve been focused on writing up my approach to WoT from a slightly different angle, with some ideas from that talk and some ideas from a 30 minute talk I recorded in 2022, linked in my nostr bio. Title and abstract of my current draft is below. The tapestry method, mentioned in the abstract, is summarized in a series of figures in this post on substack:

https://prettygoodproject.substack.com/p/the-tapestry-model

Avatar
david 2y ago

I haven’t looked into NIP-89 I don’t think so ty for pointing that out. I recall going through NIP-32 a while back and having questions about how Namespaces are (or should be) managed. I think my plan was to wait for its implementation in coracle and elsewhere and come to a better understanding. To me, lists are a precursor to a “concept” which is of central importance to the tapestry model — see the substack link in my previous note for an explanation.

Avatar
david 2y ago

This figures from the current draft of my paper will help explain the tapestry model / method.