#1 seems like something that can be done client side. You say you need a big database of all content in order to sort it properly, but I don't think it's true. Each user's web of trust can be based on their own follow lists and the people their follows follow. They don't have to all be identical. You don't need a "mega relay" for this -- just follow lists, which are already very popular on nostr.

We don't want follow lists for this to work though. We use zaps and trust to rank content. The ranking we use is something that is created while you use the product by the product and not something you maintain yourself. So this zap data must be stored somewhere, no?

Algorithmic feeds in general seem to require a lot of content and a dedicated source of truth to work properly at some point. For example, @k00b mentioned "oldest events first" or "search" in the ticket:

I agree with the fat client ideal. However, one of the most naive algorithms I listed is technically infeasible to perform on a client as is, e.g. oldest events first. A case can be made for not needing many of those algorithms and that perhaps many of the algorithms people actually want can, in fact, be conveniently provided by clients.

But, to steelman myself, some algorithms people want do require a relay-sized (or even network-sized) amount of data, e.g. search. Assuming clients don't want to download a relay's worth of data, what should we do instead?

I thought running search on relays using a standardized search algo which clients "combine" or "reduce" was the next best decentralizing thing. If I haven't misunderstood this thread, the more experienced nostratis disagree:

1. standardization on relays (more than that which already exists) is centralizing
2. "mega-relays," relays that attempt to store and index all of the network's data, will fail or otherwise be neutral in their centralizing effect
3. relay diversity on things like search once it emerges (or gains more adoption if it has already emerged) will be maximally decentralizing

#2 and #3 have nostr specs and your client could implement them. Other people might view deleted notes and "pre-edit" notes in a separate app but I don't think you're saying "that's" a problem. (Are you?) Because they can do that on stacker news already and there's not really anything you can do to stop it. I hope you guys aren't operating under the assumption that anything you delete from your site is gone forever.

It's not a problem that we can solve 100% ("the internet never forgets") but it's a different mode of operation.^[1]

Imo, it's a difference if you have to delete something in one place to make sure that it's deleted in "most cases" or if distribution of content is built into the protocol that is used to create content. We can argue about web crawlers indexing content, malicious actors saving all content for their own purposes and if that happens in most cases or not but maybe it boils down to this:

If I post something on nostr, some clients don't even allow me to attempt to delete the note.^[2] It's not very transparent how it works. On SN, it's transparent: You click "delete", we delete it in our centralized database. Everything else is subject to how the internet works. On nostr, there are more layers to this problem. More layers, less control.

However, "no reliable deletes on nostr" is definitely not a good argument to not be a nostr client, I agree.^[3] But imo, it's still an argument one could make together with other arguments.

#4 seems like you have a roadmap for this. If SN is serious about moving toward full self custody then this won't be an issue once you do. Any wallet that can be connected to or built into stacker news can be connected to or built into a full nostr client too.

#5 seems combined with #6. If you had a way to collect fees, do you think it would be easy or hard to distribute rewards to the most engaging nostr users via zaps? It sounds easy but maybe I'm missing something.

#6 is something I've talked with Keyan about. I think he he knows how to collect fees on lightning using "wrapped invoices" in a similar manner to how Geyser does it. It does require users to "opt in" to sending some money toward the reward distributor, but people "opt in" to using Stacker News too so it sounds doable.

You're right, #4, #5 and #6 are most likely solvable and we're actively working on solving them in a way that is more compatible with something like nostr. They fall into the category of me not explaining myself well in my initial reply. It's mostly about it being a lot easier at our stage to do it the centralized way first (like we did and are doing) than building SN on nostr (like we tried) while we're still figuring things out as we go.

#7 is a strange objection to me, part of the point of nostr is that all specs other than #1 are optional. If you want to do something that isn't in the specs, or violates a nip (other than #1), just do it, and maybe it will become a spec if other people want to do it too and ask you how you did it. (That's how zaps started btw. I implemented tipping in anigma before there was a spec for it, and then Will wanted to do the same thing so he just copied what I did, and then he added receipts and renamed tips as zaps.)

With #7, I wanted to say that we would probably not focus on spec compliance so if someone expects that we make sure that we don't build something that will never be a NIP when they talk about "SN as a nostr client", they would be disappointed.

So maybe it comes down to the question of what is meant exactly with "nostr client" or "full fledged nostr client"?

If SN being a "nostr client" means that it's actually a fat client built on top of a fat relay that people can't just spin up themselves, is it still what people mean with "SN as a nostr client"? I don't think so. There would still be a centralized database due to SN prioritizing UX over "being a nostr client".^[4]

In summary, I think all of the issues you identify as standing in the way of SN becoming a full fledged nostr client are solvable.

I hope it continues to progress in the direction of full nostr integration.

I could ask again what "full nostr integration" is but I will leave it there :)

We will continue to integrate nostr where it makes sense. And I think there is much to gain from the nostr ecosystem since I am a big fan of open protocols.

However, it's probably more important to know exactly what users want. Maybe we won't need nostr for that, maybe we will.

1. There is discussion regarding this topic all over SN. Here is one example: #361063 ↩

2. Maybe I am just ignorant and dumb and it's only supposed to work for some event kinds (if so, why?). ↩

3. For example, I just quoted your content to format my reply and now it's already out of your control. Or on nostr, you could just only write to relays that you trust to respect deletes. ↩

4. UX is our main selling point imo. ↩