You want microapps? You are going to have micro apps!
nostr:nevent1qqstefmq6hrlyq0u2xgrgpxct73ryg7u77kl52cch60unxy4ufhg8dcpzemhxue69uhkummnw3ex2mrfw3jhxtn0wfnj7q3q8pudjhdhhp2v8gxnkttt00um729nv93tuepjda2jrwn3eua5tf5sxpqqqqqqzpjtmpd
I think the main points that nostr:nprofile1qqsdulkdrc5hdf4dktl6taxmsxnasykghdnf32sqmnc7w6km2hhav3gppemhxue69uhkummn9ekx7mp0qywhwumn8ghj7mn0wd68ytfsxyhxymmvwshx7cnnv4e8vetj9uq3uamnwvaz7tmwdaehgu3dwp6kytnhv4kxcmmjv3jhytnwv46z7qmml2f somewhat missed is that there is no SQL for Nostr relays and there is, currently, no easy replication scheme to support load balancing, especially for geo-distributed semi-mirrored servers.
Relays ARE databases in the sense they store stuff, but if you need advanced querying capability OR if your events are too big (binary or text) or has too many tags (too many indexes), the relay operator might not be able to support it and might either reject it or become super slow.
The lack of a query language is a limit we are forcing on ourselves. The rest is pretty much solvable with the usual enterprise stack without changing the protocol.
I don't think this is optional for non-personal relays. They will have to grow up to use thousands of servers if they want to serve users globally.
The Client won't even know if it is an enterprise stack or not. It will just use the same interface we have today.
True, bandwidth will always be high on Nostr. But Negentropy can help. Clients most likely will have to have a local relay to sync to and work with directly. And some of the Client-side processing will never be possible to solve, like like a true WoT with graph analysis.
It's New-NIP Friday!
Certain calculations in Nostr require access to the entire dataset of events and are impossible to do directly by Clients. This NIP offers a simple way for users to declare their trust in service providers for those calculations.
https://github.com/nostr-protocol/nips/pull/1534
I agree. We don't need to put everything on 30382.
What we do need is to specify what the "service" is calculating so that the user can chose which provider of that calculation they trust and clients can know what the value means.
There will be some differences between providers, but the goal and the final result spec (type, range, tags, etc) should be just one.
Hopefully this NIP enables that multiple provider specification to come together.
Hum.. it has nothing to do with NIP-78 because it is not client-based.
Its more like relay lists: you just select a few for the app to use.
Trust is needed because they are doing the calculation for you and there is no way to check if the calculation was done correctly.
Nice! Yeah, it feels like BTC Map can attest for who currenctly controls each place in this PR. We just need to create a new kind with the d-tag equals to the identifier of the place. That event would then have a "result" field with the pubkey of the current owner.
Or maybe the opposite, the event's d-tag is the user and BTC Map lists the locations that user owns.
I just added a "Common Topics" idea that will just bring up the common topics each of us write about and allow clients to display in each user's profile.
This could become a really cool NIP, with lots of real value-adds by decentralized services out there.
nostr:nevent1qqswhw3c4l60tcpvv99ul576akq9m3zwhhest00slutuqk8d8vea7uspzemhxue69uhkummnw3ex2mrfw3jhxtn0wfnj7q3qgcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqxpqqqqqqzdrmup7
0xChat users on iOS and Android, don't forget to set your DM relays on "Me" / Settings / Relays / DM Relays.
You can easily just add their relay into it: wss://relay.0xchat.com
The important part is to signal to the network that you are ready to receive private DMs.
Is there a way I can tweak an EXISTING secp256k1 signature with a user's pubkey so that only that user's private key can verify the event without allowing that user to find out the event's real signature?
Meaning, can I give an event to a user without allowing that user to reshare a verifiable version of the event without also exposing their main private key?
Nostr quiz: Which popular Nostr figure is absolutely obsessed with Jesus as a space traveler so much so that he repeated it 7 times in a single podcast episode?
Hey nostr:nprofile1qqs8y6s7ycwvv36xwn5zsh3e2xemkyumaxnh85dv7jwus6xmscdpcygpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz8thwden5te0dehhxarj9ekh2arfdeuhwctvd3jhgtnrdakj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qxvpy4, when are we going to get app bundles on zap.store?
I want a bundle with every single functional Nostr app for Android. I want to install all of them with a single click.
And, ideally, they are already logged in with my nsec somehow (Amber?).
Maybe I can search for bundles my follows are using?
Or just allow people to create their own bundles from apps they have installed + a few more they can dynamically add.
#Nostr101
"npub" is your public key. It never changes.
"nprofile" has both your public key and your current home relay. It changes as your outbox relay list changes.
When you are sharing your user, prefer to share it as an nprofile since the receiving user / app can quickly figure out where to get more information from the user.
If the receiving app only has the npub, it has to search for a relay that has the user. If the receiver is using the same relays as the sender, that's easy. But if the receiver is on a separate relay set, then it's likely the receiver will never load the user.
Outbox model fixes this but it requires you to share the nprofile, not just the npub.
My feedback is to work on app managers. Get zap.store to recommend micro apps given the apps you have installed or make a collection of apps that need to be installed to execute a use case.
For instance, today, it's virtually impossible for new users to get the idea of installing Amber and Citrine before installing Amethyst. And it's just 3 apps.
If we trully go forward with micro apps for everything, users will have to install 10s to 100s of apps at a time.
Almost everyone. Our operating systems make installing and managing 100s of micro apps virtually umberable.
We can break Amethyst today into 9 fully featured clients (Feeds, DMs, Shorts, Public Chats, Marketplaces, Communities, Live Streams/Spaces, Blogs, Events/Calendars), ~40 mini apps or about ~190 micro apps.
Even with today's breakoff, it's already very hard to get new users to install Amber and then Citrine before even opening Amethyst.
And it's just 3 apps that already work really well together.
Few people know this, but NIP-17 DMs are all yours to control. It doesn't matter if you sent them or if you received them.
Your DM relay can delete them at any time YOU want them to without affecting the other party.
You can download all your messages, both sent by you to your friends and sent by your friends to you, delete everything and even re-wrap and republish them all back to you. The sender cannot stop you. And you don't need the keys of the sender to do any of this.
If you want disappearing messages but your peer wants to keep them, you both can be served. Because once a DM event is received, it is completely detached from the sender or any other external state that must stay in sync with yours.
All the power to you.
nostr:nprofile1qqsvdac80utfn4gvly4fv54la0l6cp0udpptnm3ezzyajkdc44w53lgpzdmhxue69uhhwmm59e6hg7r09ehkuef0qyvhwumn8ghj7un9d3shjtnwdaehw6r9wfjjucm0d5hszymhwden5te0wp6hyurvv4cxzeewv4ej7egk2j9 which of your apps do you want me to add to the list? You have so many :)
Correct. You have to keep the ratcheting state outside of Nostr, which means that either only one client had access to your DM and/or different clients see different DMs, or that you have a way to import and export the ratcheting state from app to app manually, off from nostr.
The later becomes a better point of attack. You don't need to break the decryption if you can just get the state by attacking the import/export function directly.
Just add an expiration tag to your gift wraps and/or use a DM relay that only you can download them and that it allows you to delete these events in whatever schedule you want.
It's much easier for users than dealing with secondary keys for DMs that can't be saved on Nostr because if you do, you lose all the forward secrecy gains.
We are live! nostr:naddr1qqjrzety8qenzvfn94jkvcnx956xvenp95ux2e3395urzcehvg6rxenrvcmkvq3qeaz6dwsnvwkha5sn5puwwyxjgy26uusundrm684lg3vw4ma5c2jsxpqqqpmxw8etczk
nostr:nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgspz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszxmhwden5te0wfjkccte9emk2um5v4exucn5vvhxxmmd9uq3kamnwvaz7tmgdajxccn0vshxxmmjv93kcefww3hk7mrn3mpe85 is on fire. 👀
Here's a discord/slack Nostr client:
https://flotilla.coracle.social
?? That doesn't mean you can buy without a prescription...
It's the same as before.. docs write, patients get it.
If you write and you are not a doc, straight to jail as usual.
Yes, there can only be one Amethyst. 😎
nostr:nevent1qqsqqqp2zrs7836tyjlsfe7aj9c4d97zrxxqyayagkdwlcur96t4lasprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hsygpm7rrrljungc6q0tuh5hj7ue863q73qlheu4vywtzwhx42a7j9n5psgqqqqqqs2juafc
Coracle is trying, but nostr:nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgspz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszxmhwden5te0wfjkccte9emk2um5v4exucn5vvhxxmmd9uq3kamnwvaz7tmgdajxccn0vshxxmmjv93kcefww3hk7mrn3mpe85's mustache gets in the way.
Correct. And they are not replaceable (relays don't delete previous versions). They are all available to be rendered in sequence if the Client wants to show the history of edits.
Oddbean new post about login | logout
Notes by Vitor Pamplona | export