Nostr

now, back to your regularly scheduled programming of NWC subscription by zap implementation

just had a random thought too... when users post events referring to other events, if the reposted event entities have relay hints, the relay could fetch the referred to event as well... unless it is on the owners mute lists. this would end the "event not found" message if you were using a client that doesn't parse that entity and fetch it for you.

probably not very important tho. but it would be a nice feature.

#ORLY relay is all about privacy, personal, community/association and business relay use cases. the spidering stuff is more about the first two use cases tho.

Reply to this note

Please Login to reply.

Discussion

Silberengel 5mo ago

Yeah, I'm thinking about forking it and also turning it into a broadcaster, with a sending-queue, so that I only ever need to use orly in a client.

Adding the feature of auto-syncing in the background, depending upon the quality of the Internet connection. And BT-LE support.

Just pack all of my network-y stuff and business logic into Orly and then the client is just application logic. And then do the same with Citrine.

Then they're like local filter.nostr.wine relays.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago

i have also thought about this "relay as proxy" idea as well, but the limitations of nip-42 auth make it difficult.

but if you added a HTTP proxy to orly, and configure your client apps to use the http proxy, then it can intercept requests to itself, ok, fine, but then your client can auth to remotes, and then orly takes over and can then publish to them with auth enabled.

this is a bit of a complicated, advanced feature. part of the reason why i haven't done it is because HTTP proxy auth methods are pretty weak and i wouldn't trust that on a remote server.

but it could be done.

extending nip-42 auth and nip-01 req/event methods could also fix this problem by enabling relays to issue an auth token that can be used in place of the regular auth flow, and then the relay can proxy these queries, cache the results and then forward them back to you.

there is multiple ways to solve this problem but the first version with http proxy interception is probably the most practical right now.

Silberengel 5mo ago

I wouldn't do this on a remote relay, yeah, too insecure. It's actually building a tiny backend-client into the relay, to handle traffic cross-client.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago

ah yes, that's the easy solution, local only and configure it with your nsec so it can auth to remote relays as you. then it can read and write to your relay list when they have auth required.

that's probably something you can actually feasibly do without having to step outside of the confines of the nostr protocol too.

i definitely want that PR merged if you make it!

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago

if the changes you make fit with the existing code, do please PR them back :)

the problem of proxying auth to paid relays tho, as i mentioned, probably the best solution for that is a http proxy interceptor that captures auth messages destined for outside and then once it has an authed socket it can fetch on that channel as well.

it's complex stuff tho, advanced network programming. i totally want this too, have done for at least a year now, but it's complicated to implement. same with the thing you are saying about internet connection monitoring. this requires some glue into system services like network connection lists and a ping/bandwidth monitoring tool to dial back the activity when it disconnects or is on a thin/metered connection.

whatever you manage to do tho, if you think it can fit with the existing repo, PR it back when you have it working, and i'll merge up ASAP.

i'm not an ambitious man, but i guess i could say that i want orly to be the new strfry. and then, ideally, to have a whole business model around using this tech so that i can pay devs to improve and maintain it and build out auxilliary services. that would be rad. low key.

Silberengel 5mo ago

I've built mutliple versions of the network monitoring into clients, already. I think next-alex already has it running. 5 minute intervaly with a background auto-sync into the local cache.