I consider the obesity epidemic a failure of free markets to offer healthy food without government oversight and a failure of individual freedom to choose better foods for themselves.
Yes, I know it's not completely free market and choosing healthy is not possible sometimes, but the point stands. Even with all gov interventions we have had, the market should have solved this.
Now RFK Jr is literally pitching more regulation to make America healthy again.
Cloning apps? Easy. Building something truly new on Nostr? That's the hard part.
We need to 100x the number of devs and designers to make it happen. Most projects will flop. Most designs will miss. Only a rare few will shine.
Winning is a numbers game.
True. But entrepreneurs don't understand what problems exist. They are relentless proposers and testers. They just test so much that eventually they get something right.
I did a bunch of marketing in the past. I think non-marketing people severely overestimate how much magic marketing can do. Yes, it is important. But word of mouth, not marketing, rules any real sales growth.
Exato. Não apenas não era um número confiável, mas permitia aos nossos servidores trackear tudo o que os usuários estavam vendo em tempo real. Nada bom.
Getting more convinced that onboarding someone into Nostr can follow two paths:
1. Onboard into a Client, not into Nostr. You "sell" a specific client and don't even use the word Nostr. You are onboarding people into Primal, Amethyst, Damus, etc. Not into Nostr. The protocol doesn't matter.
2. Onboard into Nostr. If you want to onboard to the "protocol", you should onboard them to a Nostr app store, like Zap Store. The store will then on board them into everything else, including a client of your choice.
In practice, you can choose to keep them attached to a brand or to take them into a freedom journey.
But don't sell Nostr and then lock them into Amethyst. That doesn't work. Either sell Amethyst and get them into Amethyst, or sell Nostr and get them into a Nostr store.
Back in the days, Nostr was just a few apps and all of them were kind 1 apps. It's much bigger now and people are getting confused by the options and how to set things up correctly.
These days with so many NIPs doing different things that don't show up in every client makes it hard to figure out what event kinds your friend is using so that you can find the app that displays that kind.
Moving forward it's going to get harder and harder onboard people in the clients with the right features.
When people migrate from Twitter to.. say... Threads, they are not looking for a new tech stack or a new app. They are looking for a new **community**. There is a fundamental misunderstanding that people care about the apps. No. They care about the communities. And they so happen to be using specific app brands.
Communities make the apps. Not the other way around.
Had big plans to crush code today, but nostr:nprofile1qqs8y6s7ycwvv36xwn5zsh3e2xemkyumaxnh85dv7jwus6xmscdpcygprpmhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0ekucf3 & nostr:nprofile1qqspw5udc2nzw6wsj3plrrphe0343744h0ucz9e4g248chl3w8kh03qpzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxgqgjwaehxw309ac82unsd3jhqct89ejhxqgswaehxw309ucngvpwvcmh5tnfdu4c0sa3 hijacked me into a 3hr call to discuss user onboarding. Result? 1 new client to build, 3 new NIPs to spec, and 0 lines of code written. Productivity? 🤷♂️
We are trying to see if we can do a Nostr invitation deep link that installs zap.store first and then opens the invitation data with a picture of your friend and a create a new Nostr user screen. When the user inserts his/her name to create a new account, zap.store installs a My Nostr Profile app (a signer, like Amber) and, in the background, asks the signer to create a new user. With the new user created, zap.store follows the friend recommendation to install a client.. say Amethyst. After installed, zap.store sends the users to an Amethyst that was already logged into from Amber straight into the user profile of the friend.
Flow is:
- New user receives a link (or scans a QR Code)
- Zap.store is installed, opens to a new user screen.
- User inserts the name, Amber is installed.
- Zap.store points to Amethyst to install.
- Amethyst is installed, logged in and ready to be used.
Lots of things happening on the backgrond to simplify things. The new user gets a new key, a signer and an app installed and ready to go.
You are not the average new user, but it will be explained that apps will be installed. They just don't need to know about nsecs, permissions and all that.
Users don't tend to "accept/reject" installing new apps. Only techies understand that to be an option. Others just follow the flow. If the installer is asking them to do it, they will do it. If in order to use Facebook they have to install Instagram, WhatsApp, Messenger, they will do it. We will get to the same level of easiness in time.
That's the plan. nostr:nprofile1qqsrxra3gv0lnkxz2pcxh0xuq9k4f9dr7azwq3aypqtnay4w0mjzmtqpzemhxue69uhkummnw3ezu6m0wdkk7uewdaexwqgkwaehxw309aex2mrp0yh8qunfd4skctnwv46qzxnhwden5te0dehhxarj9ehhyctwvajhq6tvdshxgetkvjvusy and team are working on it :)
A great onboarding client could work, but the issue is that it needs access to an App store to install everything the user needs in order to see the different things different friends are doing.
If I have friends using Zap.Stream, the onboarding must suggest a client that can see streams. If I have friends using NIP-17 DMs, the onboarding clients MUST suggest apps that support that specific kind, install and make them ready to use without any additional setup in each app. There are 100s of new kinds now and figuring out what I need to install to see my friends is the most important task of the onboarding tool. That's why a Store app can be a good place for this.
Onboarding people to Nostr is basically onboarding them to a new app ecosystem.
I gave up on FDroid last year. They are worse than the Play Store in terms of centralized control and app censorship.
Use Obtainium or nostr:nprofile1qqs83nn04fezvsu89p8xg7axjwye2u67errat3dx2um725fs7qnrqlgzqtdq0 if you truly care about freedom.
Feed algorithms on Nostr should not only be signed, open source and free to choose, but those running those algorithms must provide cryptographic proofs they are running them without any changes.
Trustless feeds for the win.
Nostr is verifiable data.
Sign code into Nostr events, and you get Verifiable Code.
But here’s the problem: you still have to trust the environment running that Verifiable Code. If you rely on a third-party machine, how can you guarantee it’s executing your code as intended and not something entirely different?
Enter Verifiable Computations. Runners take verifiable data + verifiable code, execute them, and return the results + a cryptographic proof that nothing was changed.
Now, recipients can verify if the script ran exactly as intended, making runners trustless partners.
Welcome to verifiable, trustless DVMs on Nostr.
https://video.nostr.build/699106b3c505e8a953b1508a497ea5b4c8019ea2f321e53d6ddf707a144ccd03.mp4
nostr:nprofile1qqst3axzay8sm4n8zg2n84acmt7hwwztpdg9r7p89e2f83v007f7zjcpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqgjwaehxw309ac82unsd3jhqct89ejhxqgdwaehxw309ahx7uewd3hkcws8qva's post on ... Twitter 😞 https://x.com/dimahledba/status/1857399684928552973
DVMs can sign provable structures of which event IDs they have access to and make that available (Bloom filters, hyperloglog, etc).
Clients can even send signed Bloom filters from other DVMs as input to tell your DVM which events should be included as part of the verifiable computation process.
Having a network of third-party proofs so that not everything needs to be verified by the phone in real time will make this possible.
Yep. We can add this to nostr:nprofile1qqs04xzt6ldm9qhs0ctw0t58kf4z57umjzmjg6jywu0seadwtqqc75spz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0wfjkccte9ec8y6tdv9kzumn9wshszxnhwden5te0wpuhyctdd9jzuenfv96x5ctx9e3k7mf0dv4ph5 infinite stream of dumb names. :)
I am just saying that your comment about how the customizations and lack of usability will confuse granny is false. Like you said, the poor (and thus less educated) people are using Android.
Lol, who is up for forking the vote chain? 🤣
nostr:nevent1qqsgqeyjdyg8jx6smcjhjh7dj2rlc0x7hupzhnn6pandgkp9mlvld6qpz9mhxue69uhkummnw3ezuamfdejj7q3q64q45vfa8prpl7f63stsl9qm9n22v6julkasjdqxjc8kevchsj0sxpqqqqqqzhjll7p
No, there are concentration videos that people watch on repeat. But frankly something is wrong on the graphene side. Because the app does pause the video as soon as you leave the app. It's almost as if graphene never actually actually pauses the app when you send to the background.
Don't use kind 1 for chats. Never. They are feed posts and should always be rendered as such.
If MLS is just for chat messages, we can have a new chat kind just for it. But if anything can be transferred inside if it, then reusing kind 14 makes sense. But we need to figure out a way to encode the group info in every event kind.
One of the goals for NIP 17 was to not require separate datastores. You can just save the decrypted events in the store the client already uses. It's much easier. I would suggest doing the same on MLS.
Why does it guarantee insecurity? Clients have to store events privately already (many use hardware-kept keys), so I don't think the extra encryption from MLS payloads will make a difference. Plus, chat screens tend to require lots of secondary cache/storage to make sure screens load fast, like the last message of each person to build the chat's home screen, pre-parsing markdown/quotes into their own cache, etc. There is no way the protocol can protect from a lousy client.
Oddbean new post about login | logout
Notes by Vitor Pamplona | export