seems like you have it back to front

outbox means your follows tell you where to look, that's a manual path

gossiping proxy relays are gonna have to use some kind of data set to make decisions about where to look, and use your follow list to dictate what you want to look for, which means it is gonna require approximations, guesses and brute force, expensive, and slow scanning traffic

then, separate from this, is where you look by default, your "app relay" set

just look at how #nostrudel implements it

it gives you the best of both worlds, like a hybrid stick shift

and if i was to choose what way i'd prefer, i'd go with the stick shift, but look at how it's implemented on a motorcycle: up and down...

so it's a bit of a mess of analogies to talk about but let's just say that i think "outbox model" should be renamed "rendezvous" because that's what it's about .... meet me here, i'll meet you there, depending on who is initiating

as a relay dev, my biggest problem with the views you are expressing is that as a user, it gives me ZERO control over where my client looks for data, whereas with NIP-65 i define where i publish, where i search, and everything outside that, ok, let's go goblin mode, but if everyone can see this data most of the time goblin mode will be unnecessary

Reply to this note

Please Login to reply.

Discussion

My main point is if you give control of lookup to some random algorithm in the client, then you no longer have the ability to push this logic to a proxy server, or to have a setup that is a private relay group, or many other closed relay set ideas.

The relay set is the base layer, outbox makes the most sense in a public social networking setup, but it should not replace user-configured relay sets. Maybe the better analogy is dhcp vs hardcoding ips. Actually this is even beyond dhcp, but something like dhcp for relay sets would be cool.

it's not a random algorithm when that in/out box set is given to the network by your follows

as for the phobia i hear here in the "private/paid" relay side of things, that's because you haven't thought about the idea of being able to access - for one - DMs by being party to them (what would be the point of having a paid relay to post your DMs to if your recipients couldn't get them from there???)

there is such thing also, as rate limiting systems, that provide a "free tier" access accounting that ... DEPENDS on authentication

so, if i am in a discussion with someone, and they reply to my message, and my NPUB is in the tags of the event, then a paid relay should rightly deliver me that event on request AFTER AUTH

any further stuff you talk about comparing DHCP versus IPs you fall into a quagmire because literally NIP-65 is about registering locations to the equivalent of a DHCP server using your MAC address as reference to a "leased" IP address

i'm happy to keep explaining this stuff until you, especially client devs, get it

I am specifically referring to scenarios where you connect to a specific relay over VPN for a corporate network, or within a geolocked region such as japan. If the algo is “pull notes from other random peoes relays, that random people are telling me to pull from, that I don’t want to connect to in the first place” then you are killing many use cases right off the bat.

well, that's unfortunate, but that's not a thing we should be engineering for

it's too complicated... and it's something that VPNs solve

what do you mean? I think have a private twitter for your own company is a great idea. It was one of damus’ original tag lines.