This is still happening, btw. Every relay is reponding with just 1 event for each author, except the nostr.land ones. eden.nostr.land (112), 140.f7z.io (1), a.nos.lol (1), atlas.nostr.land (75), eden.nostr.land (85), gnostr.com (1), nos.lol (1), nostr.land (128)

Why is it overriding my existing Mint configuration?

What was in the note?

There should be a name for when the market overvalues your company so much that you print new shares to buy bitcoin to justify that crazy paper valuation with real assets. Is that some type of shareholder valuation insurance? People have done this with land/gold/etc, but they never had a name for it. Isn't that how holding companies usually operate? Maybe it is just the same old "arbitrage". It's just too generic. AI doesn't seem to know a name.. so.. perhaps we need to choose one for these newer times.

Cropping skills suck though.

Gotta justify your title, dr Calle.

At some point, I will integrate 's Android bitchat code into Amethyst. We were already playing with P2P Nostr DMs 2 years ago. Bitchat just shortcutted its time to market.

The new Nostr DM system gets another player which might not even use relays, which enhances the privacy of everyone.

Hell yeah

https://github.com/square/okhttp/issues/8979

Bitchat is now a NIP-17 client! https://github.com/permissionlesstech/bitchat/pull/358

My next challenge is to deal with OkHttp's websocket write queues. Regardless of how many threads I give to OkHttp, the write queue to send Nostr requests to the relay is too slow. Which means that Amethyst updates the REQ before the REQ even gets to be sent out to the relay. And when that happens the relay gets two (or more) REQs of the same subscription. I need a design that I can delete or replace things from the OkHttp send queue. Or even better, the subscription should only be assembled when the socket is actually sending the message, so it gets the most up-to-date filters. Living the big app dream 🥳

How do you measure if this is worth doing? I did something similar on my recent DB adventures, but I realized that the bulk of the size on Nostr comes from the tag array and content, not the other fields. I ended up referring to the hex representation because it is much easier to work with and it doesn't really add much to the db (<1% in my tests).

Yep, graphene for the win

Hope to finish in a week or two. Lots of little bugs in the outbox version :(

New nostr client drops

There is no real privacy without decentralization.

There is always a Gary.