Oddbean

Well, guess what? We could solve this easily by providing services like "pay monthly, get more perks". While hosting relay, You also serve paid NIP-05 service. But on top of that, If user pays for one subscription, They could store their note forever while kept using their nip-05 address. And here's the thing. Why no one has thought doing about this? nostr:nevent1qqsxpd54sh4qeryffzanmapu7u8pe3euzy4v33sunvrts2ytq9hdpksprfmhxue69uhkymmnw3ezumr9vd682unfveujumn9wshsygrucv52prwm9t7ln7d7w7l07nyrfz0lj7tjrqnav299gtej5frupcpsgqqqqqqs3hh7pl

i think if a single relay could do everything, fetch and cache everything for you properly, so that your mobile bandwidth was always low, requests fast, everyone you want to see, visible, that would be huge it would only require a background worker process that catches users follow lists and queries and uses them to build a list of npubs to find and pulls in all of the data within the threads involving those users there might be other aspects of this i'm not considering but this is definitely one, and if there was many relays following this model they could form a federation, and charge a second tier of user type, other relays, who pay a higher total price but use a lot more bandwidth i've been thinking a lot lately about how to do this because it scales in a way that makes calculating costs and profit quite straightforward

It's exactly what one of my project is doing. https://github.com/Yonle/bostr (NodeJS) https://github.com/Yonle/bostr2 (Go) I am hosting bostr2 for free for everyone. See https://bostr.lecturify.net for list of bounced relays and how to connect.

i know about bostr but it is a bit useless unless it can proxy nsecbunker to access paid relays though what i just described doesn't necessarily need auth unless the relays you want it to search are paid ones the idea would be that relay operators charge each other for access to their data so it can be distributed by demand, then the user can use a single relay, or a couple of relays, instead of so many, save bandwidth, and get better performance (by using a relay with a low ping) i'm pleased to see that you have adopted a modern language to implement with 😉

yeah, there's a number of issues plaguing this business with the shitty clients but what i'm proposing to do bypasses their shittiness and also creates an entire ecosystem of relay service providers, and eliminates the islands in the network i also think the relay needs to have a run mode where it isolates subscribed users, who can be added by the administrator, but also allows a two way flow for designated types of traffic, such as messages tagged with a particular group so you can have stuff like issues boards, public support messaging, and so on, while keeping team chat and forum private and not distributing it of course, because nostr is self-authenticated messages, users can leak internal stuff but you could also have "watchtower" style services that the business runs that catch this and alert administrators of a leaker

oh yes, and it does need a slightly custom client that adds identifying tags to published messages, and an auth flow that disallows reading or writing to the relay without this extra auth step, it can't just be based on npub and auth and the auth of course requires teh client to be slightly custom in that it SUPPORTS FUCKING NIP-42

you will still have fun with doing that in Go but at least it's easier i can just give one tip tho - the concurrency code in fiatjaf's eventstore badger implementation is fucked, i am quite certain nobody has seriously tested it, because it has resource leaks that leave threads running chewing huge amounts of memory and after just 24 hours and users with outbox model clients it burns the cpu to the ground, and you have to restart it, which is unacceptable i've fuly rewritten the entire nostr message codec to use more efficient memory usage, enabling teh use of buffer freelists, and avoiding garbage producing strings (they are immutable so their memory must be GC'd) and benchmarked and optimized a bunch of things, added support for the fast bitcoin-core signature library it's gonna be a zinger when i finish it, but i have to focus on my paid gig building a nostr aggregator, and wrangling fucking bluesky protocol, which is evil and wrong and retarded

i'm hoping to soon be able to release something that does exactly what i'm describing, as well as integrate better with lightning so users will be able to DM the relay bot, get an invoice to pay for a subscription, pay it, and then add it to their relay list the relay will have a background process that keeps a second database that tracks users query activity and registers it in a decaying list that refreshes the expiry each time the query asks for a given npub, it will combine that with the user's follow and mute lists, and it will pull all data relating to conversations with followed and not-muted users, and the threads connected to them probably will also want to create a special "archive" configuration as well, that you open accounts with relays running these nodes that just pulls everything in a firehose and stores it on a gigantic database, maybe using a two level cache again (the fetching process will require a level 2 data interface that does the forwarding of queries when data is not found in the local store, and caching it as well as returning it from queries) these archive relays will be able to charge a higher fee to relays implementing this, and it will effectively mean that one need only pay for a couple of different paid relays and the network of connected relays will become your secondary data store and everything relevant to paid users will be kept hot and updated immediately