Some thoughts:
how do I find which relay you're on?
User relays are stored in their contact list. it would be trivial to make a website that connects to and indexes known relays, finds a contact list via some search mechanism, and then shows what relays they connect to. then you could add one of those to your relay list to start communicating with them.
Clients could do this as well, no-one has built this out yet.
how do I find the data I want?
Connect to the relay that has the data! In a stacker news world it seems like it would make sense for stacker.news to run their own relay. clients could provide easy ways to discover and connect to these relays. There is a relay recommendation note that can be sent on the network, so clients can gather these, as well as relays stored on user profiles (you can show what are the most popular relays amongst all your peers)
You can query a relay for metadata (NIP11), it could show a stackernews icon with the relay operator's pubkey so you can follow them. The UX on this could be pretty nice!
how do I know a relay will continue to host my messages without trusting them?
There is of course no way to guarantee this, typically you would just run your relay to have a way to host messages without trust
how do we prevent the system from suffering as it scales and becomes beneficial to attack?
Your relay doesn't have to accept all messages. A stacker news relay might have an option to associate a nostr pubkey with your account. It could only accept messages from those registered/whitelisted keys.
Cheers,
reply
Speaking in broad strokes, "we solve them by sort of layering in centralized things." And this is a fine answer! We do this with DNS and certs and it's obviously pretty dang robust.
For context: I mainly want to decentralize SN for censorship resistance (with the added benefit of interop) while understanding the main trade off is UX. Most of these questions illuminate my concerns decentralizing SN might cost more in UX than we gain in censorship resistance. Meaning, I want to gain a lot of censorship resistance and lose little UX.
SN on nostr is obviously more censorship resistant than it currently is, but I feel like today the UX cost is large and the increase in censorship resistance is small - at least until these problems are better understood by me.
Again, nostr is the most promising protocol in the decentralized social media space IMO and I want it to be the protocol that we use. I just need to believe I can build into it good solutions to these problems and tbh I haven't thought about it enough to assure myself I can.
reply
The benefits of stacker.news integrating would nostr at this point would be interoperability with the wider nostr network. responding to comments from other clients, etc. maybe it might make sense in the future but right now the benefits would probably be marginal. stacker.news already seems bigger than the current nostr network anyways.
reply
oops failed to reply to @k00b
reply
I'm very excited about nostr. It has all the signs of bottom-up protocol development that I would want to see in something we use to decentralize.
It's going to be the first thing I investigate when we begin working on decentralizing SN, which we'll probably begin working on after I create user generated subs.
That said, being bottom-up and very early and has quite a few unsolved problems afaict:
  1. discovery
    • how do I find which relay you're on?
    • how do I find the data I want?
  2. data availability
    • how do I know a relay will continue to host my messages without trusting them?
  3. DoS/spam prevention
    • how do we prevent the system from suffering as it scales and becomes beneficial to attack?
Further, how do we get these properties trustlessly?
I think these are solvable in layers, but afaict aren't solved and I'll need to have at the very least hints of solutions before I begin building into it.
reply
Can you take a look at this NIP proposal please? https://github.com/nostr-protocol/nips/pull/31 (sorry for the mess, that is a PR from the bolt.fun guy to another branch that had the original proposal from me, but you'll get the idea)
I'm hoping Stacker News could publish events that would conform to that NIP and reference URLs (since all stacker.news comments already are references to URLs) and also to previous events when necessary. Then these events could show up in clients like Damus with the URL context attached to them. That would be pretty nice already.
Stacker News doesn't have to "run a relay" for this, it can just listen to Nostr requests from clients, conjure the events based on data from its internal database and return these to clients, and never accept any event from the outside (although in the future you might want to accept comments to Stacker News posts that come from the external Nostr network based on whatever criteria you choose).
If you could comment there on that proposal just to make sure we aren't missing anything that could be specified better that would be great.
reply
Commented!
I agree, publishing/duplicating SN stuff to nostr automatically would be awesome independent any other change.
reply
Stacker News doesn't have to "run a relay" for this
sure, I was just responding to the question about data availability. if they feel ok with broadcasting all their data to public relays and hoping they won't be deleted then broadcasting would be fine and easy.
reply
I wasn't contradicting you, I was just trying to contest the popular understanding that "to run a relay" means to have a dedicated storage and server and accept events from everybody and their cousin.
reply
1a. Similar to Lightning, have a pubkey@relayaddress that can also resolve from customname@relayaddress or name@customdomain with .well_known authentication
1b. Everything is tagged with date, author pubkey, plus any tags you like. Easy to filter.
  1. Pay for hosting or get a guarantee (requires authentication)
  2. Authentication, maybe web of trust? :-D
reply