We want a divorce. These people are nothing to do with us, they are homophobic, misogynistic, and above all liars who should never have been associated with us in the first place.

#transgender #GetTheLOut

https://www.youtube.com/watch?v=onz8-1EnLyY

You must be very bitter about losing those 4 aircraft in one go.

https://edition.cnn.com/2023/05/14/europe/russia-aircraft-downed-ukraine-bryansk-intl/index.html

In order for zapping even to be possible they had to create the Lightning Network on top of Bitcoin because otherwise the maximum frequency of Bitcoin transactions would have made zapping (and most small transactions) impossible. The Lightning Network opened up several known exploit vectors, so it didn't strengthen Bitcoin, it weakened it.

As far as tracking is concerned, you are talking about security through obscurity, which any security professional will tell you is a terrible approach.

https://en.wikipedia.org/wiki/Security_through_obscurity

Zapping doesn't strengthen the Bitcoin network, and it doesn't make it harder to track.

Also what you wrote doesn't rhyme.

Apart from these minor flaws though, it's all good!

It's only par for the course because you capitulated.

If you had said "OK, no Twitter for you in Turkey then", then it wouldn't be par for the course.

wat

He can always compete in the men's events with the other biological males.

The poor snowflakes. If anyone disagrees with them in their debating society and puts forward an alternative point of view, they feel faint and have to lie down with a cup of tea and a reiki massage.

Well yea, males competing in women's events is clearly unfair to women.

You kinda have to, unless you already know everyone's pubkey that you want to follow.

Depends if they keep on asking after being told no.

Seconded :)

In Canada I think this qualifies as public mischief and you can get up to 5 years in prison for it.

re.: downloading the same events from multiple relays, this is pretty much the same issue as the one I was describing.

In NIP-01 there is specified a REQ message that contains a JSON object. This object specifies #e, #p, since and until. since and until are great, because since means the opposite of until. But there is no opposite of #e and #p. What is needed are properties that mean:

not-#e: do not give me any of the listed event ids

not-#p: do not give me any events that contain the listed pubkeys

Then the client notes, for each relay it connects to, when it last issued a REQ message, call that t. Any subsequent REQ it sends to that relay will have since:t .

Next, the client will go through its list of relays one at a time, not all at the same time. In order to prevent a situation where any one relay could perform a denial of service on the client, the client can specify a minimum time for relays to respond in and remove relays from the list or put them at the end if they respond too slowly.

The first REQ will have an empty not-#e list. Then for subsequent REQs on later relays in the list, all the event ids retrieved from previous REQs are added to the not-#e list. This ensures that duplicate events are not retrieved from different relays.

In addition we can specify a not-#p on all the REQs containing the pubkeys that the user has specified they are not interested in (blocked, etc). This does the optimization I talked about before.

Once the client has performed this batch of REQs it updates the times t for each relay, so future REQ batches will contain the new since value.

This should ensure that, for requested events:

1. the client only gets newer events

2. the client does not get duplicate events

3. the client does not get events they know they won't be interested in and have to discard

I don't know if new properties can be added to the object and be compliant with the specification NIP-01. If not then a new message type would have to be added that replaces REQ, e.g. "REQ2", in a new NIP, to add the new filter properties.

Next we have the problem of asynchronous events (events issued by the relay after the EOSE message).

During REQ processing, it might be necessary to inform a relay that no new asynchronous events should be sent until the client specifically requests that it is ready for asynchronous events. Otherwise we might still get a duplicate event while the client is processing results from other relays later in the list.

Then we have to specify a new message type sent from the client to the relay, let's call this SEEN. When the client receives an asynchronous event from any relay it is connected to, it immediately sends a SEEN message to all the other relays it is connected to with the event id. That way the other relays know not to send asynchronous events with that id. There may still be a small amount of duplication due to time windows in processing, but it should reduce duplication by a large amount.

What do you think?

OK 👍 Thanks for reading it anyway!

nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft brought up in this interview that one of the big problems with Nostr he acknowledges is the fact it is very data intensive which translates to cost on mobile networks.

I'm trying to get him interested in adding something to the base protocol that could drastically reduce the amount of network chatter between relays and clients, reducing cost, time and energy. I'm not a developer though so I don't know how to do this through the proper channels, please talk to me if you want to take it forward.

What did you mean when you were talking about a "consciousness emerging from (Bitcoin) code"? Could you elaborate a little on that?

Megyn Kelly is disgusted by transgender Pulitzer award-winning Andrew Long Chu's blatant autogynephilia and misogyny, and wonders how the institution could have sunk so low. She is not alone.

#transgender #YWNBAW #misogyny #autogynephilia #AGP

https://www.youtube.com/watch?v=zB5YxAzo5PQ