If you're in npub mode, you can't authenticate to that relay, so it basically won't receive you.
If you're in nsec mode, there may be additional restrictions regarding WoT(2), payment, etc.
If you're in npub mode, you can't authenticate to that relay, so it basically won't receive you.
If you're in nsec mode, there may be additional restrictions regarding WoT(2), payment, etc.
eventually the problem has to be solved and i'm quite sure that second degree follow list is the perfect solution because you essentially can then permit other users to reply and post to your relays, that implement this, transparently, without any further action but "follow".
it also solves the onboarding problem for new users, all they need is for one user to follow them, and copy their relay list, and they instantly become able to post to those relays.
no other solution i have read about solves this problem, follow packs, free to post relays, this "solution" has been the de facto solution up to now but it doesn't allow relay operators to control spam. second degree follow graphs does.
i forgot to mention:
public-readable relays do allow npub mode reading. but obviously, you can't author events without signing them.
that's the other part of the formula.
i developed this after a lot of thinking about the onboarding problem and the spam problem. this is the simple solution i came up with and it's implemented on https://orly.dev relay which is running at wss://realy.mleku.dev
Should I go ahead and run Orly locally, or do you want to tinker with it, some more, first?
i can't think of anything more i want to add to it particularly, but most of the features since adding the spider have been small refinements based on observations and reflection on what was done so far
there's probably the odd one or two more important small changes needed but yeah, it was probably fine for such use before.
i added one important feature today, a refinement, that allows designated owners to delete any event - only by e tag though, it would be a fairly big API change for the save/query functions to do a tag deletes as well. and kinda unnecessary, since for the most part you have already got teh option of owner mute list and getting all the IDs of their events and deleting them as owner.
so, yeah, should be good. do let me know if anything especially squirrelly happens. also be careful with the spider, this is why i have settings on it, privacy setting stops it reaching out to find events and there is three levels of spider, one is off, second is only to fetch directory events, and third is to pull in ALL of the second degree of follows into the relay, which happens on an hourly basis.
Ah, nice. It auto-fetches?
yes, and it does it initially when the database is empty when you set an owner, according to what you define for the spider. it doesn't become responsive until it has the follow lists of owner and follows, and the mute list of the owner, which functions as the relay blacklist (which determines who can store events)
the rest of the spidering happens in the background at first start, and is repeated hourly to update the events you tell the spider to spider.