melvincarvalho on Nostr: Great comment here from raucao: "I've been thinking about the Nostr architecture and ...
Great comment here from raucao:
"I've been thinking about the Nostr architecture and its place on the larger Web a lot recently, reading more of the specs and implementing a simple integration for Kosmos accounts. Since bitcoiners (but at the moment basically noone else) are going to use it anyway, unsolved problems be damned, I think it's worth making things more interoperable and connecting nostr and nostr keys more with federated systems for some easy win-win situations. Also, I'd like to explore using it for chat in Hyperchannel.
One of the main problems I see with the current architecture, especially if or when there is a real influx of millions of people, is that clients cannot really scale in a decentralized way by following more and more relays, which is going to be inevitable when people are distributed across more and more relays. Here's where server-side aggregation (and other functionality) will, if not be outright necessary, at least have the potential to improve performance and UX considerably in my (current) opinion.
So here is also where Sockethub, as a WebSocket-based, encrypted-session-offering, commodity, zero-config, opensource, proxy server could come in!
Let's say I'm on a fairly slow, high-latency connection on my phone and want to fetch someone's profile, or maybe all potential chat messages in a public chatroom, or all timeline updates for the 500 people I follow. I could either go directly to 20 different relays from that connection and wait an excruciatingly long time until I actually (hopefully) get all the data I want, or I could go through a proxy like Sockethub and have it fetch things from all relays it knows it can read from, over a data center connection (or at least a fast home connection).
Sockethub could also filter out unwanted information from pubkeys that don't interest me, or that are on a spam blocklist I follow or whatever, before sending it to my clients, further minimizing traffic and improving performance."
https://github.com/sockethub/sockethub/issues/655#issuecomment-1505434529
"I've been thinking about the Nostr architecture and its place on the larger Web a lot recently, reading more of the specs and implementing a simple integration for Kosmos accounts. Since bitcoiners (but at the moment basically noone else) are going to use it anyway, unsolved problems be damned, I think it's worth making things more interoperable and connecting nostr and nostr keys more with federated systems for some easy win-win situations. Also, I'd like to explore using it for chat in Hyperchannel.
One of the main problems I see with the current architecture, especially if or when there is a real influx of millions of people, is that clients cannot really scale in a decentralized way by following more and more relays, which is going to be inevitable when people are distributed across more and more relays. Here's where server-side aggregation (and other functionality) will, if not be outright necessary, at least have the potential to improve performance and UX considerably in my (current) opinion.
So here is also where Sockethub, as a WebSocket-based, encrypted-session-offering, commodity, zero-config, opensource, proxy server could come in!
Let's say I'm on a fairly slow, high-latency connection on my phone and want to fetch someone's profile, or maybe all potential chat messages in a public chatroom, or all timeline updates for the 500 people I follow. I could either go directly to 20 different relays from that connection and wait an excruciatingly long time until I actually (hopefully) get all the data I want, or I could go through a proxy like Sockethub and have it fetch things from all relays it knows it can read from, over a data center connection (or at least a fast home connection).
Sockethub could also filter out unwanted information from pubkeys that don't interest me, or that are on a spam blocklist I follow or whatever, before sending it to my clients, further minimizing traffic and improving performance."
https://github.com/sockethub/sockethub/issues/655#issuecomment-1505434529