That provoked an authentic LOL.

The way gossip actually works, you get both intelligent relay discovery and also the ability to manually configure relays.

New default theme is 👍.

As an experiment, I bought a pixel 6a and installed grapheneOS on it and after some monkeying around for a few weeks I am now having the best "phone" experience I've ever had (including iPhones in the past).

The two best parts:

1. The phone is de-Googled by default and it was easy for me to make it work for my purposes without it ever making a network connection to Google without my knowingly making that connection.

2. I have so much more control over what I have installed and how it is configured that I've been able to make the phone work largely the way I want it to work. Not the way Google or Samsung or Apple want it to work. It's like a linux box where you can set it up your own way if you have the skills.

Both of these things are probably pretty specific to my use-case and may not be as do-able for other people. But for me Graphene has resulted in my not feeling bitter about picking up the phone for the first time in years.

An excellent alternative to fdroid is obtanium https://github.com/ImranR98/Obtainium which is an app you install on Android that lets you then keep track of releases and updates of APKs directly from their own repos. I use it to keep Amethyst up to date directly from the github repo.

Given the current set of incentives in the protocol, it seems like this is the only possible outcome. Anything that makes relays not interchangeable has to end up this way, right?

If relays were like Internet routing hardware where nobody even knew which relay they were connected to (who knows which brand of BGP router their traffic flows through?) then using some kind of refined version of the gossip protocol could (maybe?) be able to spread the load.

Unless people are ONLY going to use nostr to create little private silos (which is a perfectly fine limited use-case), I think "global" (public commons) nostr is going to have to move in the direction of clients only showing you content from people you specifically follow and then optionally (WOT-style) also people your follows follow.

If relays have to try to "block" stuff (as opposed to just not sending stuff that clients aren't specifically requesting), then: A. nostr won't be able to scale and B. nostr will eventually have to become twitter (or mastodon).

Nobody should be looking at so-called "global feeds" (except in private nostr-driven silos). The global feed of "global" (public commons) nostr is like a high-bandwidth fiber cable with TCP/IP traffic on the Internet. That's something that carries what you are interested in along with a vast sea of what should seem to you to be garbage you are not interested in. Why would anyone want to try to look at all that garbage?

I run on macOS, compiling from source. It's pretty simple. You might actually be able to build macOS packages on Linux if you want to with https://github.com/burtonageo/cargo-bundle -- i didn't try it on a linux box yet but on my mac all i had to do to build a binary was create a very simple Cargo.toml file and then issue a command and it built an executable mac bundle. Since gossip is totally self-contained maybe you could cross-compile / bundle for macOS - at least intel mac hardware.

And that's in a context where you can ACTUALLY count followers. You can't actually count followers for real in nostr.

If nostr becomes what it could be, looking at so-called "global feeds" would literally be something like looking at TCP/IP traffic on global Internet routing pipelines with wireshark. That traffic should not be remotely interesting to most normal people most of the time.

Should gossip also be fetching metadata for npub mentions within the text of notes? As far as I can tell it currently doesn't - if the npub metadata has already been fetched gossip renders a NIP-05 name but if it has not, it renders a truncated npub as a link. i guess you'd want to limit how many of these you did so if someone posted a note with a thousand npubs it wouldn't DDOS you, but in the case where there is just a few mentions i think it would be a good addition.

This seems to be working great. Excellent refinement.

LOL, I @-ed mikedilger in a reply to the other mikedilger (sorry didn't realize that was you, Mike).

Thanks! Still wondering if note text could be selectable. #[0]

Question: should I be able to select and copy that text from the note in gossip (I cannot)?

I was also freaked out when I recently read that at least one splashily public mobile client is completely not verifying signatures by default. I can understand alpha testing in that mode with plenty of DISCLAIMERS everywhere, but in my mind, signature verification is so completely and totally fundamental to the nostr protocol that i don't see how you can call it nostr with a straight face if your're not verifying signatures by default. I don't think it's correct to even have an option to not verify them.

Personally, I don't see how anyone can release a public version of a client that isn't verifying signatures on every note that the user sees (but not every note! - see below).

Which brings me to the question of parsimony. Years ago when I was messing with scuttlebutt I was disturbed by the amount of "waste" overhead that the whole protocol relied on. It felt to me like everyone who wanted to participate had to download and lug around their own redundant copy of the entire Internet. That made me feel that there was no way SSB could scale beyond toy use but I was looking for something that could topple the platforms.

I've seen @vitor exploring the use of merkle trees or bloom filters as a way of pairing down the amount of events that a client is receiving from a relay. I don't understand enough about either to know if that is a viable approach but it seems like some kind of significant deduplication is needed at the client level. Ideally it could happen in the negotiation between client and relay so it saves bandwidth, but every event includes a globally unique, content-addressable ID and at the very least clients could/should be discarding any event they get from a relay that they already have, right?

In my naive mental model of client data, events are stored in a DB table uniquely indexed by their event.id. So whatever code is inserting new events into that table would first query whether the db already has that id (which should be a relatively instant query) and toss it if so. If not, then verify signature and then insert. Is something like that scenario not workable in practice? Or is this already what all the clients are doing and that level of optimization is still not adequate to make signature verification viable on mobile?

At the very, very, very least, it seems like every client should absolutely verify signatures on any events posted by a users follows.

But maybe this all speaks to how people are using nostr. I personally do not at all get why or how anyone cares about the firehose of "global" feeds. That to me seems like 100% anti-value. Who the hell cares to see (for more than a second out of curiosity) what a mad mixture of bots, spammers, scammers, and people they don't know (or know of) are spewing into the interwebs? That is attention pollution. It's totally toxic. But, whatever, I guess. Maybe I should add a Seinfeldian "not that there's anything wrong with that".

But I can definitely see where mobile clients could optimize on signature verification by not verifying events in global feeds (which are 99% garbage anyway). Every event from a follow should be verified though. Maybe also every event from a follow of a follow too if that doesn't get too expensive. Would that work?

That's a beautiful photo.

Welcome to the great dumbing down. Where "AI" ends up being "intelligence" by making humans so stupid that mechanism seems smart by comparison.

BTW, I don't even see the baby photo post in my timeline - the first post in that thread I see is the one that starts with "This is wild" (https://twitter.com/Snowden/status/1627021515207196672), I had to follow that tweet into the thread to even see what you were talking about.

Awesome! Thanks Mike.

I like this post (how hard was that?). Instead of sending large integers across the interwebs, I'll pay tribute by adding this:

In addition to all these good points, there's also the fact that unless nostr turns into something that is not nostr (i.e. not meaningfully decentralized) or someone invents magic, there is no way to get accurate aggregate real-time counts of anything (not likes, not followers, not anything). And what are "likes" without counts of likes?

There are many ways that decentralized social media is going to diverge from what people are used to on centralized platforms. As I think you wrote somewhere, part of nostr is embracing the chaos.

For the tags, when I mentioned it, I was thinking of 't' tags on kind 1 events using NIP-12 queries. Is that what you have in mind?