Use it is the critical part: you gotta receive bitcoin with it to gain the value of running the node. We need to see far stronger growth of p2p money and merchant adoption.

When you said the change being proposed is “fucking trivial” it naturally led me to believe you supported it being merged.

Do you or do you not?

And if you do, do you also support Core removing the option for node runners to change their settings?

You can use Public Pool. Also Datum will work with Core once the Core package on StartOS is updated to suport blocknotify.

Filters work in the same way a tall fence and guard dog works. They can't stop every possible attack, but they deter most and raise the cost of success.

We should be adding filters, not removing them. And all filters should be configurable.

Power to the nodes.

Learn more about OP_RETURN and why making standardness less restrictive isn’t just Bitcoin Core navel gazing, it’s actually very important for Bitcoin!

nostr:note1pky0j2dlmvrfce37890m659sww3ksqcg0swaq9e2gc8vmxkmex6sud9haj

#bitcoin

Old Nostr DM (NIP-4) integrates four capabilities into a single Nostr key—it serves as an ID, an encryption key, a receiving address, and a sending address.

The encryption key in NIP-4 does not change, so NIP-4 messages lack both forward secrecy and backward secrecy.

Consequently, if the private key is compromised, both historical and future messages can be exposed.

The receiving and sending addresses remain constant, which poses a severe issue for metadata privacy in NIP-4 messages;

Everyone can see who (ID) is sending messages to whom (ID).

Currently, most Nostr apps use NIP-4 for DM functionalities, such as Damus and Primal.

——————————————————————————————————————

New Nostr DM (NIP-17) integrates three capabilities into a single Nostr key—it serves as an ID, an encryption key, and a receiving address.

Kind-17 separates the sending address from the ID, making the sending address random and concealing the sender's real ID, thus improving metadata privacy.

The encryption key in NIP-17 does not change, so NIP-17 messages also lack forward secrecy and backward secrecy. Once the private key is leaked, both historical and future messages will be compromised.

The receiving address remains constant, so there is still a slight issue with metadata privacy in NIP-17 messages; everyone can see who (ID) is receiving messages.

Apps like 0xchat and Amethyst use NIP-17 to implement DM functionalities.

——————————————————————————————————————

In Keychat, the ID, encryption key, receiving address, and sending address are separated.

The encryption key, the receiving address, and the sending address are updated independently and continuously.

Keychat's encryption key is derived using the Signal protocol, and each message uses a unique encryption key, which is deleted after use.

Thus, Keychat messages have both forward secrecy and backward secrecy. Even if an encryption key is compromised, only the current message can be leaked, and historical and future messages remain secure.

Keychat's sending address is randomly generated for each message.

Therefore, external parties do not know the sender's ID.

Keychat's receiving address is derived using the Signal protocol, with almost every message using a unique receiving address.

Thus, external parties do not know the receiver's ID.

——————————————————————————————————————

However, it's important to emphasize that NIP-4 and NIP-17 offer superior multi-device synchronization capabilities because they integrate three capabilities into a single Nostr key—it serves as an ID, an encryption key, and a receiving address.

i drink pasteurized lol

A simple way to understand WebView is that it’s the web browser engine built into the mobile operating system.

Both nsec and ecash are stored locally in Keychat.

When logging into a website with your Nostr ID, Keychat only provides the signature to the site — it never gives out the nsec.

I very much appreciate your guard against & sensitivity to threats to mining (& thus bitcoin) decentralization 🙏

Interesting. I'd admit I was one that had an opinion based on the censorship surrounding discussing the PR more than the actual code aspect of this. I do find your "*finally* enforcing the rule piece is interesting" comment interesting.

Why are they choosing to start enforcement now? Will they conveniently go back to not doing so after this one is wrapped up?

I feel like I've seen this sort of thing before, about a year or so ago, but I cannot recall the nym so I'm not going to speak authoritatively. But if memory serves, someone voiced they had issues surrounding a PR and they too were banished to the cornfields by some of the same people IIRC.

It sounds like the Github needs a group of impartial moderators at this point to remove the perception that opposition gets censored/treated unfairly? Some food for thought from an outside observer.

Most smartphones no longer have a home button. Instead, users swipe up from the bottom edge to exit apps and return to the home screen — and this gesture is reserved by the system. That leaves us with only two options: placing it in the top right corner or at the center bottom. But putting it at the center bottom would block part of the screen content.

Perhaps we should try placing it at the center bottom and see how it feels.

In saying that, Pixel phones are not cheap devices in themselves.

So, I should have to buy one type of device because it’s the only device you can relock the bootloader and still boot using a custom AVB key.

If you tried that on any other Android device, you would brick it, that’s the point of AVB, so you have already made a compromise before you have even flashed anything.

Now that you’re limited to one OEM, you now have to learn at least a basic understanding of flashing ROMS, only to see a lovely warning every time you boot up. Not as bad as the warning from an unlocked bootloader, but still bothersome.

Naturally this last side effect is rather minute, since you would only see it on boot, but I still like to mention it because it further reiterates that buying a pixel and flashing graphene isn’t really an answer either.

Don’t even get me started on SElinux. 🤣

I appreciate that for some iOS users cost and/or inconvenience of a second device may prevent, but a pixel 8a with graphene may be a way for many. Be careful to avoid Verizon and other models with a locked bootloader. Again, if two devices are feasible, doesn't have to be daily driver. Begin to free yourself from the walled gardens, and start enjoying the wonderful world of FOSS!

Fun fact: our latest iOS release got rejected by Apple 4 times yesterday 🤡

It was over mundane items, and in our view the reviewer didn’t understand their own guidelines. We got through it, but this delayed our release by one day.

This is a reminder that iOS developers don’t get to decide when / if they ship their products. Apple decides. That’s a problem.

gm, what's your agenda anon?