mozzius / community-handles

community handles for bluesky
https://community-handles.vercel.app
132 stars 90 forks source link

Request: Add NIP-05 support for each registered subdomain so the same handle can be used on both Bluesky and Nostr #5

Open saltedlolly opened 1 year ago

saltedlolly commented 1 year ago

It would be great if each registered sub-domain could also support Nostr's NIP-05 standard, in addition to Bluesky. That way the same subdomain URL could be used on both services. I currently already use the same domain as my handle on both Nostr and Bluesky so I know it is possible. It would be great if this could be supported. My developer skills are unfortunately very limited. If not I would try and make a PR to add it!

The NIP-05 standard is detailed here: https://github.com/nostr-protocol/nips/blob/master/05.md

Here is some further reading: https://nostr.how/en/guides/get-verified https://orangepill.dev/nostr-guides/guide-to-verify-nostr-profile-nip05-identifier-with-your-domain/ https://medium.com/moonbeme/nip-05-verification-in-nostr-and-how-to-do-it-e4918cb950d9 https://patrickulrich.com/2022/12/26/how-to-setup-nip-05-verification-using-github-pages/

saltedlolly commented 1 year ago

Looking though the examples, it seems it would be a case of:

  1. Prompt the user for their Nostr npub key in hex format (or to be even more user friendly, it could prompt them for their npub itself and convert it into hex automatically which would save them from having to figure out how to convert it themselves). Damus have a key convertor here.

  2. Create a nostr.json file in the root folder of the sub-domain containing:

{
  "names": {
    "_": "0f563fe2cfdf180cb104586b95873379a0c1fdcfbc301a80c8255f33d15f039d"
  }
}

The above example HEX value would obviously be replaced with the one submitted by the user.

  1. If needed, create a second file in the root folder of the sub-domain called _config.yml containing:

include: [".well-known"]

Once the DNS had propagated, they would then be able to verify the domain in their Nostr client of choice (e.g. Damus)

mozzius commented 1 year ago

Thanks for this very detailed issue! I am not particularly interested in supporting Nostr since I don’t use it, however I’d consider accepting a PR if it didn’t mess too much with the core functionality/flow

That said, I won’t be available for the next few weeks, so you may be better off forking this into your own project

saltedlolly commented 1 year ago

Fair enough. I will see whay I can do but since I only know basic Javascript, and have never used React, this could be a challenge!

I have a couple of questions:

  1. How does it know that the user owns the existing handle they have submitted?
  2. what happens if another user tries to take a sub-domain handle that has already been claimed? Does it prevent them from doing this?

I'm thinking that the way to do this is to add a prompt between steps 1 and 2 that optionally asks the user for their Nostr npub if they want to use this sub-domain for Nostr as well. If they include it then the relevant nostr.json file is created along with the Bluesky stuff.

One consideration would be, what happens if someone has already claimed a sub-domain for Bluesky, but wants to add support for Nostr as well. I'm wondering, could they simply enter the existing handle - e.g. myhandle.bsky.london - and then enter the npub, and enter the same subdomain again - myname.bsky.london - for the new handle. Would this give an error, or would it simply replace the old record with the new (even though they are the same)?

saltedlolly commented 1 year ago

This is a good overview of the similarities and differences between Bluesky and Nostr: https://www.youtube.com/watch?v=iIwBDvkkEnQ&t=4s