Nostr

Ah, okay. So, can be sort of secret through obscurity.

ah yeah, so, just to explain, this ties into the feature i'm working on now.

when the zap-relay-npub-to-subscribe feature is enabled, it will add a subscription secret key identity key which you link to a LUD16 LN address, and then make a connection on your NWC capable LN node (alby hub has this), the subscription management npub will automate updating its follow list, and this will then add to the relay's whitelist, enabling the user and whoever they follow.

the idea was it's very simple to create a nostr client that operates an nsec just for this purpose, and then orly will automagically adjust the relay whitelist as requested by the owner.

for a pure pay-to-play relay configuration it could be the only owner in the list. it's just flexible in that it allows you to also use it as a personal relay and aggregator. auto-inbox-capable with the second degree, for anyone you follow, if their client pushes DMs to the designated inbox relays.

Reply to this note

Please Login to reply.

Discussion

Silberengel 5mo ago

Okay, well it's running. I'm in. ☺️

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

i implemented the two features, you'll see it on the issues.

- can now configure the spider frequency

- can now restrict the non-ACL event spidering to only go first degree (ie, you can spider everything but just from your first degree follows)

- "directory" only spidering now also includes "guest" mute lists (guest = follows of follows), just for completeness so when they use the relay they get this list. most annoying to have it disappear or be unavailable.

now available on v0.4.11

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

i just made a small change, if directory is on, but second degree is off, it still does a fetch of *directory* events for second degree (otherwise guest users would not see their profiles and lists, and whitelisted users would not have these important events available for their follows)

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

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

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

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.

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.