first pass at nip42 authentication #93
No reviewers
Labels
No Label
1000k
100k
10k
200k
20k
500k
50k
5k
75k
backend
blocked:design
bug
dependencies
documentation
duplicate
enhancement
good first issue
help wanted
invalid
P1
P2
P3
question
scope:intl
scope:nip
scope:query_tracing
scope:ux
wontfix
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Kieran/snort#93
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "feature/Nip42-Support"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This is a first pass at implementing Nip42 Authentication.
I wasn't really sure where to put the auth function so I put it into the publisher since it has all of that type of logic there.
But I didn't really know how to get the publisher (or the event signing) into where the connection and AUTH message is handled.
There is probably a much cleaner way, maybe creating an event listener?
I figured I'd put down some code and test things out against my NIP42 relay and get some feedback on how you'd best want to accomplish this.
What relays support auth?
I don't see any of the current public relays I chat on support it, but I've been coding on:
https://github.com/fiatjaf/relayer
It currently uses NIP42 as a guard around querying for Kind 4.
Can put this off 'til later if you don't see a need for it.
Will be happy to re-implement when that time comes.
@LiranCohen what is your npub? want to follow you on Nostr.
I think we can implement this into the snort relay i like the idea, as well as the search nip
@verbiricha I'm
npub148jmlutaa49y5wl5mcll003ftj59v79vf7wuv3apcwpf75hx22vs7kk9ay
I'll have some time this weekend to try and re-do this in a cleaner way.
@v0l @verbiricha I made some changes here to use events instead of passing in the auth function to the relay on connect.
Not sure I love this solution, but am open to any suggestions. It shouldn't be hard to re-implement in a different way as the primitives are there are should be the same.
I did some tests and it REALLY doesn't like this timeout.
That's fine the subscriptions will just be re-requested on auth, which happens. I'll do some further testing.
nostr-rs-relay
recently added support for this so it should be coming soon@ -77,6 +77,16 @@ export default function useEventPublisher() {
}
You can simply just not return anything here instead, undefined is fine
@ -24,8 +25,13 @@ export default function Layout() {
const readNotifications = useSelector<RootState, number>(s => s.login.readNotifications);
I think it would be simpler to just attach a function to
System
at startup which can handle these auth methods, instead of using the window event listener@ -24,8 +25,13 @@ export default function Layout() {
const readNotifications = useSelector<RootState, number>(s => s.login.readNotifications);
Yeah, that does seem cleaner.
I just made some changes and pushed.
@v0l made the suggested changes, definitely is cleaner than passing events to the window.