Nostr Web Client

yes i think i need to add nip05 services.. its been requested many times, and also told it was ded and useless many times.. but the requested tipped the scales..

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

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

Reply to this note

Please Login to reply.

Discussion

cloud fodder 1y ago

kinda like what primal does, but expose it as a relay vs requiring a custom app.

Yonle 1y ago

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.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

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 😉

Yonle 1y ago

For a relay with normal client, Implementing nsecbunker and dealing with it is a bit complicated as there's still some client that didn't have a working NIP-42.

Yonle 1y ago

For bostr2, It's what we're running right now as a public bouncer. As i have problem with memory management & concurrent download problem in NodeJS one.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

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

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

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

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

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

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

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