Liberal societies are approaching China like surveillance states, and Musk is part of the movement with X.
#nostrasia
Trivial quiz:
How many times nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft is on stage? 🤔 
The real question is how many Pablos are there 😁
This seems to be F7z.
nostr:note12cxtq6ng93lz6p8fgu4876cszuw6mcvmr9mjwr9tylxnpcfaatyqll3g8r
When freedom is the primal directive and everybody can experiment unexpected things can happen.
It’s called innovation and progress.
See the #nostrasia day two live stream: https://www.youtube.com/watch?v=MvIOT9cYS3s
Having a VC funding strategy can force you to focus on the wrong metrics in the beginning. Should you focus on growth metrics when you have just started to build the product?
Similar networks and even Twitter take gradual growth over a long time to find their users and match with them: trialling.
Yet, safety seldom is a compelling reason to join and explain to others why they should join (it’s not fun/exciting).
Woz talks about how learning by doing and being guided by your curiosity leads to unexpected outcomes. Build for yourself, and great stories from his early years 👇
“Dot doesn’t forget what you said with every new session. It remembers everything (well, almost). And whereas LLMs like ChatGPT can spin up a Shakespeare sonnet or bit of code on command, Dot is after something more longitudinal and perhaps existential.”
There seems to be a lot of momentum for people joining Bluesky now since they don’t know anything better and it has the feel of familiarity from X.
Yet, it feels less developed than nostr in many aspects. There are no possibility of viewing videos, the lists are barely existing, the API gives random errors etc.
I have come across arguments where people justify it because it’s open-source and you can export your data etc. Lot of the things are still intentions without practical actionable substance but they are part of the reasoning. Like Telegram managed to create a reputation for things that it really never was but people still repeat those points.
Hold it in your hand long enough and it melts like your fiat.
Someone said some days ago in some NIP proposal discussion that we will run out of kind numbers because currently we're limited to 40000. Some weeks before someone else had complained that I had written somewhere that the kind number should be a `uint16`, which can only go up to 65536.
In the meantime, some people make NIP proposals that involve very different events, but that use just one kind number and differentiate events by adding `d` tags or by other tricks. That is justified in the name of _flexibility_: the idea is that by having a string in which people can write anything the protocol is automatically more flexible, extensible, powerful, magical.
But this is not true. Using strings to differentiate between what could have been differentiated by a number doesn't make anything more flexible, it just adds confusion and inefficiency. Take [NIP-58](https://github.com/nostr-protocol/nips/blob/master/58.md) for example. It's the NIP that defines **badge creation, award and acceptance**.
It makes sense for the badge creation to be _parameterized replaceable_ (kind 30009) and differentiated by the `d` tag, as each pubkey can create multiple badges, and it makes sense for the badge award to be a normal, non-replaceable event (kind 8), as badges can be awarded to many people and the awards never change. But it **doesn't** make sense that for each badge receiver to craft a list of badges they have accepted and want to display they have to use a _parameterized replaceable_ event (kind 30008) with a `d` tag set to `"profile_badges"`. Why this magical string?
I believe the idea was that people would be able to craft different badge lists. For example, they would use the `"profile_badges"` value for badges they want to display in their main profile, and some other value, for example, `"hidden_badges"` for badges they have accepted but don't want to display in their main profile, and `"rejected_badges"` for badges that they want to explicitly reject -- or something like that.
The idea makes sense, but does it really? We could have done the same with a kind 10007 meaning _profile badges_, kind 10008 meaning _hidden badges_ and kind 10009 meaning _rejected badges_. That would save disk space and bandwidth, it would make it easier for relays to index these events and, most importantly, it would make implementation simpler. In the world of `d` tags, every programmer that tries to implement creating these badge lists have to go to the NIP and hardcode the kind 30008, then look for the magical string that must be set at the `d` tag and write it, exactly like in the NIP, as a string, and add that as a tag to the event, the same is valid for when a client wants to support reading the tag lists. While in the multi-kind world you only need to hardcode one magical number. It's undeniable that `{"kinds": [10007]}` is a simpler filter than `{"kinds": [30009], "#d": ["profile_badges"]}`. You may say the differences are negligible, but I'm just trying to illustrate a principle.
I have the impression that in the minds of many programmers to be able to write a string gives them the impression that everything is more flexible and magical: "oh, I can write _anything_, while if the stuff is in kinds I would have to first get authorization from the NIP overlords". Maybe the NIP process can be improved, but ultimately this makes little difference. You can definitely write _anything_ in the `d` tag, but you can also write _anything_ in the `kind` field too, the actual requirement that exists, and that exists for both, is that others start using the exact same kind number or `d` string that you're using, and vice-versa, and there is no shortcut for that, you necessarily have to come to an agreement with others -- which is what the NIP process tries to facilitate.
It seems nostr hosts evil numbers!
nostr:note1vny0vlqccx3wr97scpxxxud0sg3czymvecqp3qk9rh0evpup67ussdpxnd
User retention is something we must work on nostr:npub1k0jrarx8um0lyw3nmysn50539ky4k8p7gfgzgrsvn8d7lccx3d0s38dczd #nostrasia
Are the major clients in Japanese?
Maybe the UX is not there for the non-builders / early adapters.
I’m having real trouble being in all the places at the same time here at nostr:npub1nstrcu63lzpjkz94djajuz2evrgu2psd66cwgc0gz0c0qazezx0q9urg5l 😅
When in Nostr you have arrived.
They have for sure thought about the spec way more but it does not mean that it’s better at the end As Rabble mentioned in his speech today: Betamax did not win even though it was superior.
The speed of Nostr is amazing. The trial-and-error messiness is going to give results that are hard to beat. The multithreading by so many users, apps, builders and ideas at work at the same time.
What if you 🔥Mojo it?
nostr:note1rvas62zj62nhvdezt3e0wfths6xedqzp3lj73v9x0wa6fwepdhrsdjl3qu
Some great app examples by nostr:npub107jk7htfv243u0x5ynn43scq9wrxtaasmrwwa8lfu2ydwag6cx2quqncxg if you haven’t tested them already
#nostrasia
(Timestamp 7:23:00 if the link does not go directly)
https://www.youtube.com/live/gOIZMMvHSZw?feature=shared&t=26580
Why nostr and not Mastodon, Bluesky or others for innovation and new business models?
#nostrasia
Check also the workshop stage that's live, too!
nostr:note1c0gtvwkmpzhgj8wfkfd40pqwf3fl73vdw09jnxlljs7lsfjhmw0stkn0an
nostr:npub16vrkgd28wq6n0h77lqgu8h4fdu0eapxgyj0zqq6ngfvjf2vs3nuq5mp2va The live feed for the workshop stage seems to be 480p only. Maybe just a stream config issue?
Nostrasia live feed
And edited on Mac but was it with Davinci Resolve 😁