Client based aggregators make me a little nervous because I always think of Primal and their weird cache server model. Obviously, it could be made a lot smarter and less obstructive, but I think doing that on the client level also negates some of an aggregator's benefit, namely the reduction in data use. If the client is doing it, then all the relays being aggregated are still being downloaded per device. Just some initial thoughts, but I think it's valuable to query these ideas, and brainstorm them because that's how we arrive at great solutions!

Reply to this note

Please Login to reply.

Discussion

I meant an aggregating relay, like relay.band or lumina.rocks, or even someone's local relay.

Clients could just let you list a fallback relay, where you'd like them to look for notes that seem to be missing because the outbox relay is down, or something.

Zap test on this note… we made seven attempts to⚡zap this note, using your lightning address starting with "slcw", over a period of 14 minutes. All seven attempts were successful. You should check on your end to be sure you received these. Average zap time was 6057ms (6.1 seconds). We consider this zap time slow... generally, zaps should complete in under two seconds. (Other Nostr users might think your zaps are broken, might not zap you again.) We recommend you receive zaps with a well-connected, cloud-based Lightning node to reduce inbound zap latency.

I received seven 1 sat zaps 8hrs ago, which I'm assuming are yours. I have my incoming sats routed to a different wallet via my @getalby.com address. So those zaps hit that wallet. I've had no other problems sending and receiving from my node. Everything appears to be in good working order on my end.