pull down to refresh
1846 sats \ 6 replies \ @supertestnet 4 Feb \ parent \ on: [meta] Renewing ~econ(?) econ
I think I can summarize the issues in the way of SN becoming a "full" nostr client:
- web of trust
- edits
- deletes
- wallets
- rewards
- fees
- specs
#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.
#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.
#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.
#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.)
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.
#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:
- standardization on relays (more than that which already exists) is centralizing
- "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
- 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.
Footnotes
-
Maybe I am just ignorant and dumb and it's only supposed to work for some event kinds (if so, why?). ↩
-
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. ↩
-
UX is our main selling point imo. ↩
reply
Nostr already has clients for long-form content (Habla.news and Yakihonne), but their UI/UX sucks ass compared to SN.
Someone just needs to slap a SN skin on them, improve the comments feature, add ezy zapping icons like on SN, and a proper home page to find new posts.
Stacker.news can and MUST become a nostr client. Decentralization is the only path for the future. Centralized servers that have to obey laws and IP ban users based on their country are not the way forward. I'm not hating on SN btw, I love this platform!
reply
reply
Also I think nostr has as much promise to be the decentralized thing as anyone, but people acting like it’s inevitable isn’t doing nostr any favors.
It has a lot of unsolved problems and anointing it a solution to every centralized problem before it is will make the community complacent and miss real opportunities to improve.
reply
Just to help establish the current facts ...
They don't have to all be identical
They don't and ours aren't.
just follow lists, which are already very popular on nostr.
That's not the way we build our web of trust. We look at a person's entire zap history and compare it to everyone else's. A web of trust based on follow lists can be called a web of trust, but the resulting web is not the same as ours.
The problem with #1 isn't that it's impossible. It's that it takes a long time to gather and compute scores for events and to gather relevant events and re-order events.
This kind of thing will be remedied somewhat by clients storing more historical data in clientside relays or things like nostrdb but Primal is still going to serve the current version of your feed faster (because they built it while you were offline) and Nostr Band is going to perform thorough searches more quickly (because they gathered all the data while you were offline).
I'll be more optimistic that this is remotely as easy to do as all The Sayers say it is when clients stops using megarelays to provide algorithms and search.
reply