mleku ✝Ⓐ☯︎ @mleku - 11h
my morning's work on #realy is going to be modifying the relay request processing policy what i'm adding now is a feature so when auth is enabled, certain kinds of events, which i'm calling "Directory" events, will be permitted without auth, and implemented by changing the "AcceptReq" method so that if the filters in the request have all of the kind fields except the directory kind are removed and only events of the Directory kind wil be returned, as well as sending a "notice" that the relay is only returning directory events this will enable paid relays to still deliver things like deletion and user profile metadata and follow and mute lists and user private relay (nip-17) associations so the users presence on other relays can be learned without being a paid user
mleku ✝Ⓐ☯︎ @mleku - 10h
i have an idea also that at some point i might add a background service that harvests all npubs that appear in requests and events to a list and periodically polls the network for updates to these kinds of events from another list that collects unique relay URLs as a service to the paid users so when they make reqs that hit their paid relay they get information about how to find other users discoverability is not really that hard a problem, just that nobody's really defined what it means... Directory events are my working hypothesis about an element of what makes nostr discoverability work, simply sharing information that essentially represents information akin to what you find in the old school "white pages" phone directories, in the times before spam becoming a huge industry
mleku ✝Ⓐ☯︎ @mleku - 9h
feature is now added... with auth not yet performed, reqs that have kinds out of the list ProfileMetadata 0 FollowList 3 EventDeletion 5 Reporting 1984 RelayListMetadata 10002 MuteList 10000 DMRelaysList 10050 (this is new from nip-17) are permitted, and if any are present in a req from an unauthed client, all but these kinds are stripped from the req and forwarded to request processing (and count, of course) i sorta feel like there should be a further flag that triggers so that after the request is delivered, the auth request is still sent but i think i'll just leave it like this, when requests are made that require auth, the request will be responded to with an auth request, but any requests that do contain these kinds in the kinds field will be processed without any notice or ok, false. nostr:nevent1qvzqqqqqqypzqnyqqft6tz9g9pyaqjvp0s4a4tvcfvj6gkke7mddvmj86w68uwe0qyghwumn8ghj7mn0wd68ytnvv9hxgtcpzamhxue69uhk6mr9dd6jumn0wd68yvfwvdhk6tcqyqljz82ghrxxj48m7tsuk2tk6r2qzl2mynm4v6q4g0c7vdr626p8s5gw8rj
yeah, it was an easy change to make, it now checks if the filter was rewritten, and this only happens if it was not authenticated but contained directory kinds
it now triggers an auth request after the matching filtered filter is returned, and even still it also adds the filtered ... oh i need to revise that too unauthed reqs containing directory events also open subscriptions ... this may not be wise, perhaps i should change that so it doesn't do that actually haha... so currently v1.2.9 version will still open a subscription to the unmodified filters in the request... the old events won't be returned but the incoming ones that match would be. closing this now with v1.2.10
just clarifying... unauthed requests containing directory kinds are processed, then after returning the results auth request is sent, which the client is free to ignore, and no subscription is created out of these requests, if the filter was modified it was because it wasn't authed so it just returns without starting a subscription on the filter
