Nuclear is back.
1. Google backs the construction of seven small nuclear-power reactors in the U.S (500 megawatts)
2. Microsoft struck a deal to restart a reactor at Pennsylvania’s Three Mile Island (835-megawatts)
3. Earlier this year, Amazon purchased a data center at another Pennsylvania nuclear plant (960 megawatts)
I might end up using Trusted Assertions to cache computed values that Amethyst calculates on Citrine. And maybe other clients running in the phone can also process their stuff and serve attestations back to Amethyst via Citrine.
https://github.com/nostr-protocol/nips/pull/1534
Like caching the last message from each user/group chat to easily build the user list in the DM tab without loading any actual messages.
nostr:nevent1qqsytppyu2my7qcz9pk5wm0yp372rchef6sacep39u37j00u42h8vpqpzemhxue69uhkummnw3ex2mrfw3jhxtn0wfnj7q3qgcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqxpqqqqqqzlg2m6x
nostr:nprofile1qqsdpg0lhpmph96va39rh6xtevhfdfcfph85vhl74jpe4fx2yry6t8spzpmhxue69uhk2tnwdaejumr0dshsz9mhwden5te0wfjkccte9ehx7um5wghxyctwvshszyrhwden5te0d4hhxarj9ec82c3029cgkl added Right to Vanish to nos.social and relay.nos.social. I hope more relay implementations follow suit.
Amethyst will have a purge account button soon, but Account Management mini clients are also welcome to code and help people migrate relays and delete their stuff from unwanted servers.
https://github.com/nostr-protocol/nips/pull/1256
nostr.band becomes the first provider to offer their trust analysis as assertion events, enabling users to select their service and display additional info about each pubkey from a global network standpoint. I hope more service providers join.
This is particularly useful for summaries about users and events that are impossible for clients to compute locally, like the total amount of zaps sent and received by users, average daily zap amounts, most common topics a pubkey talks about, etc. https://github.com/nostr-protocol/nips/pull/1534
If you use open relays on Nostr, all your data is available for anyone to surveil you.
This is why choosing the right relays for your content is important.
Imagine registering for a new account in your favorite Nostr client and instead of getting the boring global trending, you are presented with posts from your city/neighborhood.
That's where we are going.
Yeah. You can just connect to a local relay.
Or you can connect to a global relay and search for posts from a city/state/country, depending on how many posts you want. Obviously that filter can be from anywhere, it doesn't necessarily mean you are in those locations.
Nip 29 could work, but we can also just do geotagged kinds 1s in the default relays. The key part is helping people to setup the feed and to help them post exclusively to locations like on https://github.com/nostr-protocol/nips/pull/1233
Which should we develop next on Amethyst?
- a Jobs board where you can offer your services and find people to hire, fiverr style.
- local feeds, where the app will present a feed based on locations and allow you to post only to people in your location.
- integration with nostrnests, with voice participation, like on Nostur/Twitter spaces.
- realtime voice and video calls that integrate with 0xchat.
The public inbox relays should receive your notes if you are tagged on them. So all your replies, likes, zaps etc go to your inbox as well. New notes shouldn't. Because a reply cites a post, that goes also goes to your inbox/outbox to make sure your follows can find it when loading replies from you.
But then if you use 10 clients, you get 10 duplicated databases. It's not an efficient way to use nostr, especially if we start using more micro clients.
It varies if the network is busy or not, but the average user doesn't notice a difference on an average day.
I have used it for everything for the past 4 weeks or so. Tor disconnects when the app goes to the background and reconnects when it comes back. Connecting takes about 200ms but from there it all loads with a couple frames of difference.
Yeah, I was surprised as well. It will never be the same speed as the open web but extreme speed is overrated. You can design things in ways that minimize the impact on users while significantly increasing privacy and decentralization.
Does nests uses NIP-100 for webrtc? nostr:nprofile1qqsr7acdvhf6we9fch94qwhpy0nza36e3tgrtkpku25ppuu80f69kfqpramhxue69uhkummnw3ez6un9d3shjtnyv4ex26mjdaehxtndv5hsz9mhwden5te0wfjkccte9ehx7um5wghxyctwvshszxthwden5te0wfjkccte9ekk7mt0wd68ytnsd9hxktc79dllq nostr:nprofile1qqsx8lnrrrw9skpulctgzruxm5y7rzlaw64tcf9qpqww9pt0xvzsfmgprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qyvhwumn8ghj7un9d3shjtnndehhyapwwdhkx6tpdshssfnq7m?
The Jobs board will definatelly be a NIP. There are some clients already have something and I might just integrate with them.
The local stuff can have both. NIP-29 local relays can certify themselves if their posts are indeed local while just posts that tag a location can be more open to anyone posting on it.
My only need is to make sure if you post to a location it doesn't show up in your global timeline at the same time, like on: https://github.com/nostr-protocol/nips/pull/1233
Final ruling in Epic v. Google, ordering Google to effectively open up the Google Play app store to competition, is some awesome news.
Google will have to distribute rival third-party app stores within Google Play, and it must give rival third-party app stores access to the full catalog of Google Play apps, unless developers opt out individually.
It also forbids Google from requiring the use of Google Pay on apps shipped through their store, freeing devs to offer other payment APIs to go around the 30% fees from Google.
This is a separate judgement from the DOJ vs Google that is considering a breakup of Google, forcing it to sell Android, Chrome and some other units.
It should but I doubt it will. Apple will put up a much bigger fight because the Apple Store is more fundamental to Apple's survival than the Play store is to Google.
Yep, it would be super easy to make a push notification mini client that simply receives a push event and redirects to installed clients based on NIP-89 and a simple URI intent.
Many push clients could use different stacks: Google/Apple/Samsung/UnifiedPush/Foreground service that keeps connection to the user's favorite relays etc.
Checking some padding/marging/rendering issues with under screen camera placements in some phones today. Can you reply this post with a screenshot of your Amethyst home feed (make sure only public info is there) and the phone brand/model you are using?
Thanks!
Yes I know the difference. The state can force you to show your Nostr posts. They can do this literally with everything, including Bitcoin as well. In fact, most health checks were made with the regular CDC card, which is not signed. Adding things to Nostr doesn't change any of that.
Tech is tech. The state can always fuck any stack.
Also, the state already has access to your health data on today's system centralized systems. Adding Nostr, removes some of their existing knowledge of you because you can store it in your own relay, away from governments and b8g corporations.
You are mixing things .. I am not talking about the key. It's about your posts. The things you sign.
Also Health data is encrypted.
Also, you can just put your health data into a Nym account. It's up to you.
What you don't understand is that if people allow, government can always put you in jail for anything they want. During COVID, people allows governments to check if you have taken the vaccine or not. They dont need a signed QR for that. The CDC card was used more than any QR code was.
It's about how gov uses the tech, not the tech itself.
Why would opening the option to put your relay data on Nostr, on any relay you choose, reduce your options? I don't think you understand what we are building.
No one is requiring you to use Nostr, or any particular client or relay.
We are pushing the amount of options to the limit.
The health care system has been doing this for 20 years. We are breaking that up by allowing users to choose relays, clients and which keys they want they data encrypted to.
> You had and still have this fucked up view that the State is all powerful and the people, individuals, don’t have any say in the matter.
What did I say that makes you think that?
I said in this post that it's all about what people let their governments do. I don't know how do you even go from there to your conclusion about me.
In the end, you can use Nostr and opt out of the health care system as it is today and keep your info with the government or not. It's up to you.
I have 15 years in multiple levels of health care. Believe me when I say that if the government wants your data they WILL have it. They have all the power over the rest of the players inside health care, both officially and unoficially. Picture what happened on the censorship level with Twitter and Facebook over the past decade and apply the same methods to ALL health care companies, constantely, over the past 30-40 years.
If you trully think government doesn't have the power, you are the one being naive about this.
But yes, obviously all juridictions are different and get your data in different ways. I know particularly well the US, canadian, european, indian, chinese and brazilian system. Other than that, all dictators out there have full access to your data. Indian, Chinese and brazilian systems do have your complete health record with the government. Europeans and Canadians also have large chuncks of their health information with the government. US is per state. Some states have a lot, some states have little info. But all states have SOME info. The Federal information usually comes from the insurance companies when you use them.
Anyway, if you trully think the status quo is good and you want to support the government surveillence that exists TODAY you can keep using it.
All we are doing is to create a balance of power, where patients can decide where to store their data, which clients they cant to use to access and manage that data, and which keys they want to encrypt that data with.
It's Friday... You know the drill. We ship.
nostr:nevent1qqs959p8r87kg2v5hwz5wcs0ypr8arwgs96agjj7dn4y8zntkmgzt4cppemhxue69uhkummn9ekx7mp0qgs24yz8xftq8kkdf7q5yzf4v7tn2ek78v0zp2y427mj3sa7f34ggjcrqsqqqqqp7ha8d6
Yep... And this is one of the reasons people tend to use a large number of relays. The reply times are quite "random" from the set of relays they have. Adding more relays just makes things work out of luck.
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?
The idea is indeed to disallow re-sharing.
Picture a company relay. All the information should be strictly contained into that main relay.
However, for Nostr clients to work, they need to verify events by themselves. Which means they receive a full copy of the event and can re-broadcast that copy to another relay very easily.
That creates a problem.
We could just delete the signature field and ask Nostr clients to not verify and "trust" that the company or its relay is not modifying the message from its original author. But relying on trust defeats the purpose of using Nostr in the first place.
Since the company relay authenticates who is connecting to them, it could easily modify the event to make sure only that user can verify it.
My initial solution was simply to encrypt the signature field to the pubkey of the connecting user. Then the client would have to decrypt it before verifying. The issue is that once the user has decrypted, the user has access to the full signature in plain text and can add it back in the event and re-share it with another relay.
Which is not really a solution to the problem.
This led me to the question in this post. How do we make a modified event signature that only one user can verify. It could be still possible to allow other people to verify the new event, but that implies having to make the user's main private key public and hopefully there is enough sensitive information in that private key to serve as a deterrant from users doing so.
Interesting... I need to do some testing, but maybe this is the beginning of a modified Nostr protocol for enterprises and trully private groups.
I do think there is a lot of need and money waiting for solutions in that realm.
Oddbean new post about login | logout
Notes by Vitor Pamplona | export