Damus doesn’t respect event deletions currently. If it cached the original note, it will stay there because it doesn’t query for deletions.
https://github.com/damus-io/damus/issues/14
It was amazing to talk to Nostriches and builders at BitBlockBoom last weekend. Got a major pep talk and motivation boost from @montzstar@jonb@arkinox@elsat@Marks and others to keep laser-focused on building Comingle. I’ve dragged my feet long enough with it. I ran out of gas after introducing the NIP-52 calendar spec and implementing NIP-52 in Nostr SDK for Apple Platforms, but I’m back now. I started integrating those building blocks into Comingle iOS and it feels great. My goal is to launch the Comingle conference app with a real integration to the NIP-52 calendar spec, in time for the Nostriga and Baltic Honeybadger Bitcoin conferences in Riga, Latvia this coming August. 🫡
Hey, @Fabian Do you see a possibility where Nostur could migrate to use Nostr SDK for Apple Platforms? It’s a pure Swift library. We’d like to rally the Nostr Apple platform developer community to use and contribute back so that there’s consistency and reduced interoperability issues across Apple platform clients and build features where everybody gets it for free. I know you’ve refactored a bit of logic out from Nostur into a separate library, though.
https://github.com/nostr-sdk/nostr-sdk-ios
@miljan@nikola@pavle Do you see a possibility where Primal iOS could migrate to use Nostr SDK for Apple Platforms? It’s a pure Swift library. We’d like to rally the Nostr Apple platform developer community to use and contribute back so that there’s consistency and reduced interoperability issues across Apple platform clients and build features where everybody gets it for free.
https://github.com/nostr-sdk/nostr-sdk-ios
I disagree with that view, it’s too absolutist and not aligned with actual reality of the OS market share. Don’t worry. We’ll take the KYC hit so that Apple users can experience freedom of speech and censorship resistance. We’ll keep applying pressure on Apple. Somebody has to do it. I’m also building on Android.
@vita ‘s candle business, Fire Rabbit, is at the Sip Shop Eat market in Brooklyn, New York this weekend! If you’re around, come support her business by checking out her incredible candles!
12-5pm Saturday
12-5pm Sunday
Hook Studios
76 Verona Street
Brooklyn, NY 11231
https://www.sipshopeat.com/rsvpbrooklynhttps://i.nostr.build/xE75G.jpg
Neat! Did you ever consider using Nostr SDK for Apple Platforms? We’re actively building it and supports a bunch of NIPs already. We just cut the 0.1.0 release.
https://github.com/nostr-sdk/nostr-sdk-ios
Cool. I didn’t know about Swift Adwaita. I knew it was possible to use Swift to build on non-Apple platforms but never really looked into it. Nothing wrong with building your own.
Contributions are welcome!
Be careful! I was going to use the selfie camera but I read it can damage the sensor so I decided against it. It took me only 5 minutes to make, it’s pretty straightforward.
Ente looks great. I want to use it. Although they open sourced all their code, I don’t think it’s quite there in terms of fully self-hosting.
I tried to set it up on my local machine and the account registration apparently went to their remote server rather than to my local machine. Moreover, their Photos mobile app doesn’t give you the ability to switch to a custom server, yet. This all is when I tried a month ago.
I don’t know the answer to your issue, but I’ve had a similar problem. I added NIP-44 support to Nostr SDK which required a simple import of a C library function. This broke Swift documentation generation for our public documentation site but there’s absolutely no information or logs about why it failed. So now I’m trying to find an alternative library because I don’t want to revert just because of documentation issues.
I don’t know the answer to your issue, but I’ve had a similar problem. I added NIP-44 support to Nostr SDK which required a simple import of a C library function. This broke Swift documentation generation for our public documentation site but there’s absolutely no information or logs about why it failed. So now I’m trying to find an alternative library because I don’t want to revert just because of documentation issues.
Worst UI ever. Do I check or uncheck to unsubscribe? Just kidding, I tried all the permutations and I still get marketing emails. Blocked. https://i.nostr.build/9z2zQ.jpg
This is the same person who said the following, so it’s not too surprising that he’d authorize running a man-in-the-middle attack on his own customers. He is evil.
Zuck: Yeah so if you ever need info about anyone at Harvard
Zuck: Just ask.
Zuck: I have over 4,000 emails, pictures, addresses, SNS
Friend: What? How'd you manage that one?
Zuck: People just submitted it.
Zuck: I don't know why.
Zuck: They "trust me"
Zuck: Dumb fucks.
Source: https://www.businessinsider.com/well-these-new-zuckerberg-ims-wont-help-facebooks-privacy-problems-2010-5
@miljan do you know why the Primal iOS GitHub is 2 months out of date? There’s been releases that are more recent but the public source code hasn’t caught up. I had found bug I wanted to fix but couldn’t because of it being stale.
https://github.com/PrimalHQ/primal-android-app
It’s a request for deletion, not an actual deletion. Relays should delete only after verifying that you are the original author. I believe the green success doesn’t necessarily mean it’s actually deleted.
After working on this on and off for 7 days, I've finally finished implementing NIP-44 encryption in Swift for use on Apple platforms! This will replace the unrecommended NIP-04 encryption. Definitely lost a few hairs and gained a few gray ones. 😅 Thanks to @montzstar for reviewing my PR to Nostr SDK for Apple Platforms and thanks to @mplorentz from Nos for pair programming with me when I got stuck.
https://github.com/nostr-sdk/nostr-sdk-ios/pull/138
I’ve submitted a forked copy to the shared nip44 repo. Please review and double-check my work if you’re able to read Swift code. All the test vectors pass, though. @paulmillr@Vitor Pamplona@Magister Michael Dilger M.Sc.https://github.com/paulmillr/nip44/pull/11
The claim is that every time you encrypt a message with NIP-04, it decreases the difficulty for an attacker to determine your private key. I’m not a cryptographer, so I can’t verify the claim. The design and professional cryptography audit of NIP-44 was funded by OpenSats, mitigates that attack vector, and is allegedly a better encryption scheme than NIP-04. It does have known limitations as mentioned in the specification. NIP-04 is unrecommended but it has not yet been replaced in all the other NIPs that use it. The developer community needs to work on moving towards implementing NIP-44 encryption for all encrypted messages, including DMs, while still maintaining backward compatibility with NIP-04 encrypted messages.
https://github.com/nostr-protocol/nips/blob/master/44.mdhttps://opensats.org/blog/nostr-grants-december-2023#nip-44-cryptography-audit
The way I see it working is:
1. Have all the major clients and SDKs support encryption and decryption for both NIP-04 and NIP-44 for some time but have NIP-44 be the default for encryption.
2. Clients can allow users to migrate their signed NIP-04 encrypted events by decrypting them and creating new ones with identical content but encrypted with NIP-44.
3. Once most people stop creating new NIP-04 encrypted events, remove support for encrypting in NIP-04 and support only decrypting NIP-04 moving forward. NIP-44 becomes the only way to encrypt events.
Nah, I was cleaning out my old belongings. This page was from my textbook 15+ years ago and I was commenting that it’s still relevant today. This month will not be the only month I’m hearing about it because Nostr, Bitcoin, and many other things use cryptography. I just implemented the NIP-44 encryption spec this week.
In fact, I sent a request for deletion for two of my notes (that I self-censored because it might cause me trouble in the future) to a couple hundred relays and they were wiped out from relays that I was aware of almost instantly. Sure, they might still exist somewhere, but deletion is inherently part of the protocol.
You're not wrong. It's voluntary. What should get communicated is that you can absolutely send a request for deletion from clients that support it and that it is a best effort delete, but the data might still exist in perpetuity until the end of time on machines that don’t respect your request for deletion. Even if the signed content gets deleted from all machines, people can still take screenshots! Expectations should be curbed.
@miljan do you know why the Primal iOS GitHub is 2 months out of date? There’s been releases that are more recent but the public source code hasn’t caught up. I had found bug I wanted to fix but couldn’t because of it being stale.
https://github.com/PrimalHQ/primal-android-app
I submitted a fix for the backwards incompatibility issue in Primal iOS. This should make new replies from Primal iOS display properly in Damus and other clients that are still using deprecated positional tags.
https://github.com/PrimalHQ/primal-ios-app/pull/124
Not a bad idea. Chaos engineering.
I wonder if there’s a way to crowdsource relay trust status. e.g. if you find an event on a relay that has an invalid signature, you broadcast a kind to all your relays that indicates that this relay can’t be trusted. People or clients who deem your pubkey as trustworthy can make a determination of if they want to stop subscribing to that bad relay. Basically as a mechanism to not need to perform as many verifications of signatures on events as it could be expensive on computation and battery if you’re on a smartphone.
Oddbean new post about login | logout
Notes by tyiu | export