Avatar
Bryan
f07dec60e40c0f0d6baf9a9f18c4ceba266266fa4fa0e322c1925498cb293c36
Christian, husband, father, bitcoiner.

Beautiful night at the pee wee fields

Bitcoin accepted -> Bitcoin preferred -> Bitcoin only

Will be interesting to see how far down that progression we see society and the vendors within it go.

Replying to Avatar BTC_P2P

Power

This may be heresy but that’s a little bit under done for my tastes…🤷

Little bit disappointed the funds available in my HSA don’t include the bitcoin ETFs.

That time you are listening to the Stephan Livera podcast and the ad read is for a service that is for one million dollar net worth and above. I didn’t get into Bitcoin early enough for that madness.

I can’t imagine the panic of being in a suit like that if the water cooling systems failed. I think I’m just too claustrophobic for that.

I’m not quite sure how to measure its accuracy. But it seems pretty close. I did a couple of mile walk that day to get those steps.

Is my watch telling me I slept walked? Don’t remember getting up…

I mean I know two people that died of Covid who didn’t get the vaccine. There might be some survivorship bias. That being said, I don’t think it should be forced on anyone.

According to my wife a cruise thru the Drake passage isn’t an acceptable bucket list item.

Replying to Avatar JeffG

GM Nostr 🌞

🆘 I need feedback on an idea related to private group messages.

I'm working on the format for sending group messages via relays and had an idea on how to encrypt messages in a way that saves a lot of work for both relays and clients. But it has some tradeoffs. Here's how it works:

1. Imagine you have a group of n people. The group has an ID value (random string) and each group has shared context that means they will know how to decrypt messages but if you're not in the group, you won't be able to decrypt. This shared context rotates regularly, ensuring forward and PCS security.

2. To avoid having to send each participant a gift-wrapped message, we encrypt the message content using shared group secrets and put that in the content of a Nostr event. This is an encrypted blob that is NOT using NIP-04 or NIP-44 encryption, instead it will be using MLS native encryption which has information about the sender as well as the message content itself. This event is published to group relays using a disposable identity, not the user's main nostr identity.

3. We put the Group ID value in cleartext in an indexable tag on the Nostr event.

This last point is important. Let's break it down:

– Clients only have to publish a single event to send a message to all participants (nice) ,

– It's trivial for members of a group to watch for messages they care about via a tag filter (very nice) and ;

– (the tradeoff) Observers can see how many messages are being sent within a group and when they're being sent but they can't tell who is in the group or who is sending the messages.

I think that this is a fairly reasonable tradeoff. I'd love to hear thoughts or — even better — suggestions on how to improve this.

If I understand this right, the relay would be able to see the public IP of every client and correlate that to the group IDs that they are downloading? In the worst case of a note being published to a single malicious relay, that relay would know the public IP of every client that downloaded the note and know that they where a member of the group (or at least have high confidence of it)?

There doesn’t seem to be enough momentum or resistance in these measurements. They seem to swing wildly from one extreme to another based on whatever the news of the day is.

I wondered about this as well. How does the podcast economics work? Does the host pay for bigger names to come on their show? Do smaller names go for free just for the publicity?

It’s a sad day… nostr:note1mnyfl9hjck35mw67hd659j6a2gxltmyhzq684lm99xnf6wzyeunsh33fy8