Oddbean new post about login | logout @fiatjaf @jb55 @hodlbod et al if we are stuck with centralised NIP repo then might as well put a wiki on it, no? explain why no.
Isn't that sort of what the nips repo is? A wiki with drafts and merge approval. A real wiki would probably have been a better solution though, I'll give you that.
no, because how do i learn about what is in tags? let me just read the whole damn repo or search for the word "tag" that will solve it
i personally hit this problem not expecting that i had to json-escape strings in tags because all the ones i was familiar with were human typed text and hex strings nope, zaps have embedded json in tag fields and this kind of unclear nonsense is rife through the whole thing
Do they really? Didn't know that. Interesting.
yeah, you would only learn such things by building the base level parsing code clean to discover this if you weren't following all the chaotic goings on in the repo
Literally everything. The specs are often not self-explanatory. Npubs should be able to just fork, add what they just learned, the others with a merge request, and move on with their lives.
One more thing Write coding guidelines for the specs. Then rewrite all existing specs to match them, as close as possible. Then you don't have to have senior engineers saying "No json in the content field" or "make sure to use asciidoc or markdown compatible with asciidoc" to every new entrant.
yes, coding guidelines help a lot i have some unusual preferences in that for my own projects because i get intensely curious about neat things i see... like, almost nobody else except a few smart guys know that you can do one line functions in Go, or that you can break lines after dot operators, and my current little thing is using a script to drop a "common" file into every package that gives you lots of handy type aliases and a few common functions that you can update just by changing one version and running a script like, why would i type []byte when i could just use B and in local scopes, who uses B anyway? that's an exported variable name, in a local scope? yes! that's the point, you aren't going to mistake it and why write []byte when you can write B! it also injects loggers and such into the code, and honestly i think it would be a great feature in Go if you could write one file at the root of a repo that automatically is part of every package for this kind of stuff, it's not a macro system, it's aliases, and the aliases make the code more readable and easier to type anyway, going off track, but JSON doesn't forbid JSON inside strings except that the quotes have to be escaped, pretty much, probably some shortcuts can be taken for this... as it is, i already experimented with this because tags are "free form" but there is a whole bunch of rigid structures defined and in many cases they use hex encoding which is automatically double the binary version and for runtime why the fuck deal in encodings when you match faster on the binary and if the binary is what your database uses??? but it's work that i'm doing because of my own personal distaste for convention and love of elegance and conciseness in my own work, this leads to me recognising bugs in my code faster because i spend less time ignoring fluff and more time actually understanding the code there is some hilarious morons who like to chant "the code is the documentation" but you read their code and it's like reading beat poetry, good luck making sense of it, and the time it takes for the compiler to turn it into assembler... that's a big hint that the code is unclear
GitHub wiki won't help you with that.
then we should not be using MICROSOFT's property but instead have someone get funded to run an actual competent wikimedia wiki? no? why not?
Benefits are unclear.
detriments are very clear just saw one today experienced several personally (the way the zaps have escaped text in them for zaps, notably) you want to all run off building code but don't want someone to keep track of your protocol designs and architectures? do you actually really not want anyone to come along and help? or is it in your mind that anyone new coming in is a hostile element to be fought against? then obviously we need a small team of moderators keeping the data and impartially maintaining this separation and acting as adjudicators and documenting the state of it let's say, like court secretaries because having the judges be the prosecution at the same time is pretty uncredible
I do want someone to help organize this mess, but it can't be you, you're too opinionated and aggressive (which is not necessarily bad, but it's bad for this task specifically).
By that definition, a wiki is anything under source control. Wikis tend to have people assigned to "watch" certain pages, because they take a particular interest in the content or are some sort of expert, not one team managing the entire wiki site.
And that's still too much "asking permission", to me. We're working on increasingly obscure and niche OtherStuff implementations and I don't see why I have to give someone who has nothing to do with our project veto-rights over biomedical vector analysis or CAN bus communications or refrigerant logistics, etc. We're the experts. That's why we're building the implementation. 🤷♀️ And it starts lower down. Why do I need to discuss a publishing spec with people who aren't experienced with publishing or internal auditing? If they were experienced in publishing or internal auditing, they would be writing the spec. What does their approval even mean? Are they checking for typos?
This is what I mean by Stempelarbeit. The nice lady in the office has no idea if there was any point to the trip or if the trip was worthwhile or a good use of funds. She probably couldn't care less, that you took a trip and is just like *sigh* another stupid trip form to review. Those are 15 minutes of my life that I'll never get back. She's just in charge of stempling and giving permission. But, on what basis? In whose name? To what purpose? She is stempling because she has a Stempel. 🤷♀️
Do you want more administrative overhead or less? If you want someone to "watch" pages that can be done on the NIPs repo (again, wiki software is better, but not essentially different). But this is a massive increase in overhead. The NIPs repo contributors aren't there to debate ideas (although that happens too), just to vet whether a NIP has the requisite number of implementations, and merge corrections. This is a pretty lightweight role, but still quite taxing. If you want a permissionless wiki, then use the one that currently exists at wikifreedia. No one is stopping you. In fact, fiatjaf drafted https://github.com/nostr-protocol/nips/pull/1214, and to my knowledge I'm the only one so far who has published a NUD there. But this presents the opposite problem of potentially too little curation. I'm all for trying it, because forks are cool, but I'm not convinced it will be easier to navigate or more useful than the NIPs repo.
there are quite a few people ignoring the NIPs repo and making standards elsewhere and it's impossible to find them
I've noticed that too. This is not hard to solve, if the person writing the NIP wants it to be found. They can do a NUD, or they can submit a PR to the NIPs repo to link to an external NIP, which is also something that exists. But if people don't want to make sure people know about their own standards, there's not much anyone can do.
You basically announce what you are doing. If others like it, then they will also use, even help refine it. Point me to the exact places in the spec to help me find information i need to know - an address. Or a comment someone said on nostr relating to the situation. Sure, things could be super mixed up, but you could weight opinions or endorsements to find the best way to find your answers. There are ways to filter out noise, or they will be found because of need. I wrote two specs on Nostr Knowledge Bases (NKB). How can we navigate nostr's information, on any event. I'm not a web developer, so I have 2 NKBIPs out there (wikifreedia), asking for fast feedback and quick iteration. If people really like an idea, but if its not actively being worked on, other's can still see and work with it. There may be changes, but wouldn't that be good? The original author can still be in the conversation.
Yeah, you basically need an index. That's the github nips repo README. Of course, it's incomplete because people don't submit PRs to it, but it's there. Wikifreedia's #nud tag or something else could also serve as an index. We just have a tragedy of the commons because these things (or some thing thing) aren't being used.
TIL about NKBIPs. Are these conceptually the same as NUDs?
i wrote it up as a draft spec originally on github - just to have it out there. I'm not asking any change to the protocol, but ideas on how events can be organized and retreived. Its been on github since December, but its gotten way more visibility and feedback here.
Cool, I missed it on github then. The spec on wikifreedia seems much more generic than NUDs, almost a competing spec to the wiki one. So maybe it's not as applicable as I thought?
Generic is the point, i wouldn't say it competes however. A wiki has a spec for their articles. This spec is attempting to distil ideas individually so they can be worked with an grouped together. It comes with a 30041 which is very related to wikis 30023, but 30041 are just fragmented notes - and wouldn't be typically be shown by themselves. 30041 basically is an indication that it belongs to something broader - you can decompose a existing blog or paper, or you can just publish a modular article with the explicit concept that the ideas can be separated. You'd show them as a modular article, or note collection, via 30040 which can be a collection of any event type. I wouldn't expect any client other than what we are making to display the individual fragments.
that stands for Nostr Knowledge Base Implementation Possibility because it's a spec describing how to form a knowledge base. a spec for a specific use case, not a new type of spec
Ok, so NUDs are a new idea then? What do you dislike about them? They seem to solve most of your complaints, in that they're: - Permissionless - Published in a wiki format - Forkable and can be voted on - Nostr-native
I personally don't have a problem with the specific idea. An NKBIP can perfectly have a NUD tag if someone wants to add it, i just don't think it adds more meaning than NKBIP. Not an argument against a NUD, just that if things are already going to be so different, a global naming convention wouldn't make sense, and that NKBIP announces the purpose within its name.
1) Most standards don't need to be found by most devs because they don't use them. Nobody uses all of the NIPs, either, after all, and that effect is about to go parabolic. I think everyone just needs to sort of give up on spec management. 2) It's not impossible to find them. There is a list in the wiki for events or you can simply use elasticsearch on nos.today. Or just #asknostr. Make a DVM spec discovery tool. 3) You can see the events popping up on relays and just search for the ones that seems stick around for a while and add them to the list yourself. This is dynamic discovery and someone already built it. https://undocumented.nostrkinds.info/ 4) I don't need an event to announce the event that I'm publishing on relays and writing about in the wiki and in articles and discussing in communities. That's the same event being announced like 50 times and would encourage people to reserve NUD numbers that they don't end up using, or having NUD numbers assigned to unpopular events, like we have with the NIPS. This creates an ID "honeypot". 5) We don't need the "NUD". We have our own prefix. It's obvious that it is a Nostr spec, if it deals with Nostr and is a spec. 6) Implementations should lead. Marketing is proof of work. The best implementation will get the most attention and their spec will float to the top of the wiki or dominate the timeline for the people interested in that topic, and become the de facto standard. 7) We publish our specs on the wiki or other long-form articles, give the event a searcheable identifier, and then we implement it and talk about it all on Nostr. That gives everyone enough opportunity to find it, who is genuinely interested. https://wikifreedia.xyz/nip-event-register/npub1m4ny6hjqzepn4rxknuq94c2gpqzr29ufkkw7ttcxyak7v43n6vvsajc2jl
> We don't need the "NUD". We have our own prefix. Apparently, but this is the first time I've heard about NKBIPs. The least you could have done is mention it on the github repository. We're directionally aligned here, I just really don't understand the hostility toward the existing forum for talking about nostr.
Why should we go back there? We are trying to move all of our interactions to Nostr, not away from it. We are putting our code and our documentation where our ♥️ is.
If you decide you want to change a venue in real life, you don't just show up at the new one and expect everyone to be there.
Y'all built the venue. I assumed that you would all be arriving, eventually.
Would you and/or nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qg3waehxw309ahx7um5wgh8w6twv5hszxmhwden5te0wfjkccte9ehx7um5wfcxcetzwvhxxmmd9uq35amnwvaz7tmwdaehgu3ww35x2umpd4jkxct59e5k7tcprdmhxue69uhhg6r9vehhyetnwshxummnw3erztnrdakj7qguwaehxw309a6xsetrd96xzer9dshxummnw3erztnrdakj7qgkwaehxw309a3x2an09ehx7um5wgcjucm0d5hszrnhwden5te0dehhxtnvdakz7qpqm3xdppkd0njmrqe2ma8a6ys39zvgp5k8u22mev8xsnqp4nh80srqtqc5tv like to come on the TGFN podcast to talk about it?
This topic, i don't know if I'd be too comfortable talking about 😅
Yeah, it's ehspicy. I was looking at your profile to find out more about you, but didn't really find anything. Do you have a project you work on I could read about?
nostr:nprofile1qqsd6ejdteqpvse63ntf7qz6u9yqspp4z7ymt8094urzwm0x2ceaxxgprdmhxue69uhhg6r9vehhyetnwshxummnw3erztnrdakj7qguwaehxw309a6xsetrd96xzer9dshxummnw3erztnrdakj7qg3waehxw309ahx7um5wgh8w6twv5hshhq5j3 kickstarted things with this article: https://highlighter.com/laeserin/1719204947236 Which was picked up by nostr:nprofile1qqsx8zd7vjg70d5na8ek3m8g3lx3ghc8cp5d9sdm4epy0wd4aape6vspz4mhxue69uhk2er9dchxummnw3ezumrpdejqzyrhwden5te0dehhxarj9emkjmn9qyxhwumn8ghj7mn0wvhxcmmvycz39a and he added some cool extrapolations 😁 https://fountain.fm/episode/5D7Ds8tpivptu5OPy0lQ https://fountain.fm/episode/RtokKi1qHtjPNHGY7yuK And an article on Zettelkasten, a personal knowledge management system that we're brainstorming how to scale up for collaborative uses. https://www.lesswrong.com/posts/NfdHG6oHBJ8Qxc26s/the-zettelkasten-method-1
Cool, I've been listening to nostr:nprofile1qyw8wumn8ghj7un9d3shjtngd9nksmrfva58getj9e3k7mf0qyt8wumn8ghj7un9d3shjtnddaehgu3wwp6kytcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszxthwden5te0wfjkccte9ekk7mt0wd68ytnsd9hxktcpzemhxue69uhhqatjwpkx2un9d3shjtnrdakj7qgkwaehxw309ajkgetw9ehx7um5wghxcctwvshszythwden5te0dehhxarj9emkjmn99uqsuamnwvaz7tmwdaejumr0dshszxrhwden5te0dehhxerjd9mx2tnpwpcz7un9d3shjqgnwaehxw309aex2mrp0yhxvdm69e5k7tcqyp3cn0nyj8nmdylf7d5we6y0e5297p7qdrfvrwawgfrmnd00gwwnythrc95 , I'll give that article a read.
We will be doing an interview with @NunyaBidness soon. That's what he wanted the calendar entry for.
GitCitadel also has a private group, now, at https://coracle.social/groups/naddr1qvzqqqytlgpzqzp7p4ekweu59qlue8u46gtfjm30w33r527zr6n2hz89ejg4cnyxqqgrywfjx5cnxvfexsursv3hxccny2z3luq/ but I can only seem to login to Coracle using nos2x with Kiwi browser. Nos2x with chrome and Nos2x with firefox and anything with Amber, all seem to not work. 🤷♀️ I can't figure out what I'm doing wrong or why it worked in that one particular case.
This is what I see. https://i.nostr.build/Dj2cKjQmsOJMOept.png
If I click on "Authorize forever", it just pops up again and again and again.
It pops up four time. A fifth time if you post a note. It forgets them all if you close the tab.
I think this is a nos2x thing. The authorizations are for different things. nostr:nprofile1qyd8wumn8ghj7urewfsk66ty9enxjct5dfskvtnrdakj7qgmwaehxw309aex2mrp0yh8wetnw3jhymnzw33jucm0d5hsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qy88wumn8ghj7mn0wvhxcmmv9uqzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vahj2kfz
That's nos2x-fox, not my code, not my responsibility, I am forever free from having to fix that bug.
Same thing in brave I'm afraid
Same thing in chrome with nos2x.
https://github.com/nostr-protocol/nips/blob/nuds/71.md I've never heard of NUDs. NIP-71 is actually video data, not NUDs. 🤷♀️
And I'm on Nostr, not GitHub. Talk about stuff here. This is a protocol designed for communicating and the feed is full of software developers.
I'll publish a NUD, but I doubt anyone will look at it.
At that point, I'd also argue that naming should be descriptive. If you're not asking for change to the protocol, I don't see a need to stick to a convention.
This is part of the point of NUDs. They don't need to be on github, and they don't need numbers. The collision on number is part of the reason NUDs were proposed. Of course, they were proposed on github, because that's where people have historically requested feedback for additions to the protocol. If you don't want to participate in that conversation you don't have to, but don't complain that people aren't doing exactly what you're asking for if you're choosing not to read about it.
I'm not asking them to do anything. That's my point. They're the ones upset that major spec writers are starting to ignore the repo and document on the wiki, instead. We like the wiki better. 🤷♀️ I have no idea why anyone finds this hard to believe. Nostr > GitHub
I’m confused. Where do I look for the definitive NIPs?
There is no such thing as a definitive NIP.
As nostr becomes fragmented and lineages diverge, the definitive NIP repository will be the developer circle you are a part of. There is nothing wrong with that. Be interoperable with your friends or just use your own relays.
This is all by design in a decentralized, permissionless infrastructure. The github nips repo works for a circle of developers, of which many take influence, and would like to contribute but doing so on a permissioned platform is getting annoying. There is nothing wrong using it as the defacto repository or a model for "The Nostr" local to everyone that wants to take influence. The problem is that nostr is too good and using any other system is starting to get painful (damn you developers! ✊). Just let the ideas compete with other specs. Make a whitelist relay where you and others curate and incubate the ideas. Others could fork on their own relays, but no one needs to listen - unless it actually makes sense for the client. Ultimately, its a public announcement of "i'm using this spec" and you don't need to leave nostr to be part of the "official" conversation.
I basically agree, but I don't think people are spending the necessary time on making sure consensus works. Fragmentation is ok, but the target is maximum interoperability, not maximum fragmentation. Everyone making up their own specs is an unbalanced approach, just as running everything through one permissioned source is unbalanced. Of the two, I personally prefer the github model, because it's proven to work, while the bizarre bazar is untested. But I'm willing to participate in experimentation with a middle ground.
The events produced are their own interoperability check.
You could say the same of all software. Just because slack doesn't talk to discord doesn't make them members of the same protocol. Interoperability doesn't happen by accident.
Maybe you're arguing that standards can be inferred by published events. Sort of. I think that was always the goal for NIPs. But that's like saying documentation isn't necessary, just go read the source code.
Static documentation isn't necessary, it's true, but it's useful marketing material or a basis for discussion. Nostr has a built-in incentive for people to use other people's events, so that they can capture part of the same audience. An open protocol is a novel idea whose time has come. We're just embracing it.
You mean the GitHub wiki? No, that's stupid.
the github is stupid, explain why using the wiki is not worse it has the same posting controls, you won't be overrun with spam
What do you want to write there?
you ever used a wiki? they have these "talk" pages attached to each page in there, you can see relevant content how do i do that with PRs that are being developed but not yet finalised - or maybe finalised in implementation but nobody has bothered to attend to merging? it's a huge amount of friction, like @Laeserin so aptly described it - rubberstamping is causing a huge amount of problems for developers, just watched it unfolding this afternoon for @cloud fodder over the issue of mentions... nip-08... no, nip-27 - but wait, tags are defined in nip-01 please take a number and wait in line ser, this is a wendys
i duno if a wiki would be much different. *unless it is organized wayyyy different. say, by Kind and client. like kind1, quotepost (here's what damus, amethyst, coracle, nostrudel, etc do).. maybe then each client or userbase could edit more freely or etc. i often wonder what kind is what, or if i make a new one, how often will there be a collision? and have each kind searchable with wiki tags like "drafts", "notices", "auth". and then link from there to the official nips. have comments on, etc. ya i was surprised mention didnt work, its been a while since i tried it. so i just had to find some real kind1 json to inspect fafo
yes, exactly, there would be a page for every kind in a wiki there wouldn't be NIPs at all, these are some dumbshit idea that presupposes the existence of a working protocol that does enough to be usable nostr is not at that level yet, how long was it between the inception of the bitcoin network and the inception of the BIPs? a lot longer than it's been here, that's for sure and yeah, unfortunately that's the chaos of the protocol at this point - you have to pick a client or several clients and examine their outputs to understand what you want to do for automated processing and not just dumb relaying if you'd asked me about mentions i would have referenced what i have seen in raw JSON of mention containing events, and the "mention" string in the tag and the "nostr:bech32" thing were both part of that, and i only caught the gist of that because of Uncle Bob's client using the prior scheme with tag-numbered references in square brackets a wikimedia style wiki, like the one used to run wikipedia, would totally work, with the same "staff" manning the moderation roles as the non-searchable git repository with zero-information numbers referencing everything and creating an in-group of people who have memorised them due to building - mainly - clients building actual smart relay services is outside of that bubble and the guys inside it have been insulated from reality for so long that they think they are invincible and omniscient
put it this way, i could convert the repo, and all the PRs into the wiki version in a week, but i got bills to pay and i have to spend 20 hours a weak at least on earning an income, so, unless someone wants to pay me equal to 700 euros a week to run the wiki i'm busy doing things that are paying me that much
Sounds good but I'm not convinced the benefits are worth the hurdle of changing.
there can be a transition first step is migrating the data into the new format next is keeping track of the way the data being put into it is disorganised, and especially investigating the actual code of those who are contributing to measure against what they have pushed to their PRs i don't think a whole new protocol is required, just some competent, adequately paid moderators who make sure vandals don't mess up the talk pages and make them useless it just really doesn't translate to a git repository do you want to have 65535 separate folders for kinds? they have to exist!
Do you know who is that person capable of meticulously classifying all the things all day every day? Also why can't we keep the current system but have that amazing person do the job on the side? It would be great and eventually people could naturally transition to the new document since it would be better and more complete as the person could also incorporate Blossom and other rogue specs that exist out there.
the benefit of a wiki is delegation within the wiki topics. something a git repo cannot achieve..
for example, a kind, could be 'managed' by a set of all client teams that implement that kind. when an implementation diverges, the kind is categorized into client sections or pages (depending on how combative). a page or section that describes a client implementation and is maintained by that clients team.. that way the updates can flow. people can subscribe to the kinds to get notified of changes to them (another pain point of the git strategy)
Updates are a bad thing in open standards, so that's an argument against this approach.
it doesnt have to update the nip unless everyone agrees.. im just looking for more data on how things are used. right now i have to try every client, and i dont have an iphone so i have to find someone that does to try it for me. if it was in a wiki, this would help a lot. one example is quote notes. another is as i found today all clients need a "mention" in the tag to mention someone, yet this is not in nip01 all clients have already moved onward to some other nip that uses kind1 new ways. i also frequently search for nip-Xx or a, keyword, or kind # and github doesnt show results for it .. some of these specs have updated (like zaps?), so its not like they never do, and right now theres no feed for this. anyway, i know this would be quite an effort and require some hosting etc.. just brainstorming what might augment the git
Endorsements, weighted endorsements, how would that be different? How many forks and edits would be concerning? Popularity is likely power law distributed - find the one that is most popular and implement that, or you can try something else and let it compete with the rest. In any case: nostr:nevent1qqswszxz7tcj2e0hh70tjd58plum89cd753q0vs2gszetc5v72t0p6spr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qgsdcnxssmxheed3sv4d7n7azggj3xyq6tr799dukrngfsq6emnhcpsrqsqqqqqp2ewuqq
I don't even understand the point of this conversation. We already moved all of the NIPs and the event register to Nostr's wiki months ago. I don't even look at GitHub anymore and I don't need to use some other wiki.
sauces: nostr:nevent1qvzqqqqqqypzqlxr9zsgmke2lhuln0nhhml5eq6gnluhjuscyltz3f2z7v4zglqwqqs9wle2hydxay62l5mpqaycnj6sjlzwkl3rjqpswcyycmzuy6cx6vggey078 no because mentions is about tags and tags is nip-01 - instead you look at nip-08 and nip-27 don't make me get out the angry sauce
github maybe is a central point, but gi makes open to everyone to keep their instance and selfhost a mirror
a wikimedia wiki can have a repo behind it the same still need moderators, and they need to be reputable actual moderate characters, smart enough to understand the content but only protecting the sanctity of the discussion and not any side of it
also, at this point, who are the moderators? yeah, the devs of the main clients and the founder of the protocol they are not an easy bunch to present ideas to and i dunno about you but i just bitch about it in notes rather than try to waste my time on the issues and because i'm just trying to build a competent relay, i really have no actual contributions to make except for issues, and i'd feel a LOT more free to do that if there was an actual discussion forum possible on each of these topics git repo is the wrong format markdown documents were invented FOR wikis, and here we are with a repo full of would be wiki entries without any of the standard wiki contribution workflows
I think standards will evolve organically, the apps that want to be compatible in the ways that are important will talk and make it so. the nips repo is no longer reliable and nips are edited at will without discussion. It has become meaningless except for the core nips.
and that's largely because it's not a collaborative document workflow, but a codebase workflow and nip numbers have extremely complex, contextual relationships that are hard to follow without simply reading everything and then digging through all the PRs as well just to find out if you should put something in a field or expect something in a field or not mostly it's a problem for client devs also, which also really reinforces my point about how while you all are busy making clients you are also gatekeeping the specs seems like a recipe for loss of focus to me
