LISP and Smalltalk managed to put the whole language definition in half a page. Nostr puts the whole network definition in the really short NIP01. It may feel naive, but that's why it will be successful. The multiple experiments by inexperienced developers, the interactions, the re-learning and the attention captured is more valuable than the efficiency of a system "built the right way" from scratch. The "right-way" is awfully similar to design by committe, or central planning. It's what W3C did to DID, VC, and many other (now failing) standards.
Reading code is still harder than writing it.
The low-boilerplate, little-planning approach taken in nostr or BRC20 may be short-sighted, but it allows for writing much more code than what you need to read. Other projects may be way better, but you just need to read so much before feeling productive, that most people just give up. (https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/)
Que suerte tengo de que la vida de los otros no sea una de mis preocupaciones, y además está bien visto no juzgarles las decisiones.
Existe un piloto de 1993 de un dibujito estadounidense "adaptando" los caballeros del zodíaco. Si yo lo vi ustedes también. https://www.youtube.com/watch?v=ODTQZfysM9s
Homstr
Not yet, I'm focusing on allowing nostriches to monetize their accounts with ads using RSK, so we get paid with DOC for likes and reposts. That will involve verifying nostr event signatures in solidity.
For the group controlled accounts my main use cases would be: a) my company nostr account of which I don't want to be the sole owner.
b) Replacing the current margin call emails from DeFi protocols with nostr, so these protocols don't need to deal with owning a centralized resource.
c) DAO's with centralized governance forums in tools like telegram, which usually have problems with censorship and account takeover.
I read comments from different devs on my recent #nostr PR (the link at the end of the post) and I think I start to understand why underdesigned protocols get higher adoption than thoughtfully-designed.
Thise is not accidental; devs adopt protocols because they are able to understand them and play with them - and most of the devs (grown on stackexchange) have limited capacity to understand and contemplate about something (or just do not want to bother) - that is why “AI” is already able to make a work better than they do. That is why it is not the robustness or security which matters, but simplicity and as few components as possible.
It is the reason why crazy-weird combinations like “Web technology” - an agglomerate of highly-inefficient and insecure HTTP, JavaScript etc - boosted internet adoption, while it took decades to solve this protocol issues with additions like SSL/TLS, HTTP/2, ECMAScript 6, TypeScript etc “ugly sticked as siding”.
IT differs in these terms from other forms of engineering in a way that if in a physical world you would build something with this approach, it will kill people (like cars and electrical equipment can do that) - while in IT the risks are much lower (usually financial) and more tolerable, thus less advanced and secure systems emerge.
So, there are two different strategies in protocol creation and adoption, similar r- and K-strategy in biology ( https://en.wikipedia.org/wiki/R/K_selection_theory ):
* r-strategy: very few devs, careful thoughtful design, high quality
* K-strategy: no design, “evolution as it goes”, development by a crowd of low-quality devs, until eventually something will start working due to a pure “mining of chances”
r-strategy always struggles with adoption, since “very few can understand it”. The only way r-protocols can be adopted is via products, which must be robust and good in UI/UX; i.e. not via dev community/crowd, but via people community/crowd. But usually r-products are not loud in marketing (the only exception is probably apple products - with NeXSTEP-based tech and product/language design teams being very r-like)
On the opposite, with K-strategy, things like JSON happen because they allow not to design a protocol - they are sufficiently agile and malleable to any protocol changes and things will contrinue to “sort of working” - thus devs can start with a “no design” and stick random elements into the network until something would start working. 99% of these protocols will die, but out of 1000 attempts one nostr will appear.
So any carefully-thought solution to nostr design issues (which will cause its painful growth/scaling in the future) is doomed: nostr devs see these not as a design issues but as features that allow them to build products without designing the protocol per se, leveraging JSON agility. So they agree to migrate to binary formats _only_ if they are same flexible as JSON - while the main problem is not a text/binary format but that flexibility, which will cause network decoherence - or centralization around oligopoly of “standard” relays. The funny part is that this r-strategy still can be the strategy which wins.
It is what it is. Embrace the BS.
BTW I can't believe I didn't find you here before. 😄
Also, together with nip 26 (delegated event signing) , this could open the door to social recovery of nostr accounts and replacing "Decentralized ID + Verifiable Credentials" with a system that's more opinionated but actually implementable.
I'm working on a NIP to allow "multisig" nostr to exist. The use case is to allow for a "group owned" entity. This could allow DAO's or other organizations to have their own nostr accounts and open the door to have federated bridges that feed nostr events into smart contracts. Have you given any thoughts to that? Do you think it may be useful for RGB too?
I still say I twitted it, but on nostr.
They will travel around europe for the next year or so, attending several bitcoin conferences, and organizing meetups along the way.
Anytime. Hope it works now.
You're using your bech32 pubkey, that does not work AFAIK. You need to use your hex encoded pubkey, which is 3181d8a718ab49b619776a8b744b4c7b4bfb27cc691dccba2765070472d1ce20 (I converted it with https://nostrcheck.me/converter/)
How did you manage to identify #nip05 on your subdomain? Doesn't work for me, although followed this advice: https://github.com/nostr-protocol/nips/issues/241
Hi. What domain / name are you trying to use?
The european Bitcoineta is here!!
Se me resecó un codo de apoyarlo en la mesa cuando codeo así que me voy a comprar una codera para codear más cómodo.