-
Notifications
You must be signed in to change notification settings - Fork 511
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NIP-55: Unix Domain Sockets #1222
base: master
Are you sure you want to change the base?
Conversation
Nice! Let's go! |
Why the link to Twitter, though? :) |
Thanks @vitorpamplona, also I've had a lot of issues with kind 1 web clients. |
A few thoughts:
Also, here's a reference implementation in Rust containing a working server and client which uses the message structure and encoding mentioned above: https://crates.io/crates/nip-55 |
You can also use the Android Signer spec as a reference: #868 The interesting part of the Android spec is that it has two modes: with UI and without it. It always tries to do the operation without transferring the user to the other app and only if it fails, it brings the signer UI up. |
Cool. It's not nostr, because it's not websocket communication through relays. Maybe nostr should be a layered specification, with the top event layer defined in one spec, relay-client messages in another lower spec, websocket transport in a lower yet spec. In that world, this demo would be using not just a different transport, but a different sub-event protocol. |
IMHO, it already is like that. The NIP description is just not up to speed. The real Nostr Protocol is only the event definition/sign/verify. Everything else is layer 2+. |
@mikedilger does that call into question the validity of nip-7 since it is not websocket communication through relays? I left the nip relatively open but I'm not necessarily suggesting we should send any and all events over the socket, for now just the utility methods from nip-46 that would provide a similar benefit as nip-7 but outside of a browser context and specifically native to the desktop. |
Yeah I think nip-7 and nip-6 too are not really nostr. It doesn't mean we can't put it in a nip, we are sloppy about a lot of things. |
Why not just do local http? |
@alexgleason one reason is that I don't want to deal with figuring out how to get the server and client to agree on a port. @mikedilger right, maybe it's worth outlining some place in the future to put things like this nip, nip-7 etc, since standards like this allow more streamlined development for clients and greater security. |
I see two reasons:
|
It looks like Windows has supported UDS since 2017 when they added support for the SOCK_STREAM socket type (see here). We could include Named Pipes as an alternative/fallback for Windows (although I don't think that's necessary - I just figured it's worth mentioning). SOCK_STREAM is analogous to TCP and is what we'd want to use for JSON-RPC 2.0 as I mentioned here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this does not define how the socket is used, how to handle multi-user environments, and other options for non-Unix-like OSes
I think maybe we should narrow it down to just passing the JSON defined in NIP-46. Maybe in the future other events could be passed via UDS but for now I think this is fine. I'll think about multi user, I'm open to suggestions here. This NIP does not apply to non Unix systems. |
I would switch |
@vitorpamplona I think that's probably a good idea to manage it in the users home directory, maybe we could define two standard locations in this nip, one that is system wide and one user specific? |
would a concrete implementation in JS or Python be helpful to add to the nip? |
Example using unix domain sockets with two desktop apps where one is acting as a remote signer: https://twitter.com/chrisatmachine/status/1786549455967154312