Add ninvite and relay access requests#1062
Conversation
|
I recognize the need for an ninvite style URI. Love this! I am implementing invites on nostrmeet.me that have optional "expire" timestamp and "limit" integer parameters. I am also implementing "use welcome message" and "use announce message" flags. Welcome message is sent as DM to new account. Announce message is published to inviter's timeline when new account is created. Both messages can be pointers to (another NIP?) existing message templates. (I am implementing a simple client config for these templates) Also... Invites URIs may need to be signed to verify truthiness of these additional params. |
|
I wonder if this should be a bech32 link or if it should just be a full event kind that is signed by the sender so that you can show the sender's information when the friend opens the link. "Jon is recommending the following people, relays and groups" If it is an event, the ninvite could just be a regular nevent. |
Interesting idea, showing sender would be kind of nice. But:
I don't think this is workable, since there are secret invite codes in the entity, which you wouldn't want to publish.
What are these for? |
|
Nice thing about my (any dedicated) onboarding app is that a user does NOT need to be logged in to create invitations. This provides an easy flow for getting more people to share nostr, by sending them a link to their personal QR invite code. Even without logging in, nostr users are (will be) able to customize and generate new invitations simply by clicking a link shared in a nostr note. https://nostrmeet.me/hodlbod@coracle.social https://nostrmeet.me/_@vitorpamplona.com Implementing invites as a nostr event would break this flow. EVEN expiring invites are (will be) able to be customized and sent without logging in to the client. Use case for Expiring invites is most apparent with private group invites and might even be applicable to general WoT invites. EVEN these (non-event) ninvite URIs can reference the user who sent the invite... simply by indicating as such in one of the attributes. (0 could be sender with only one allowed) |
| url: string | ||
| claim?: string | ||
| }[] | ||
| groups?: { |
There was a problem hiding this comment.
Sorry for the basic question, but what exactly does "groups" refer to?
There was a problem hiding this comment.
Any replaceable event that can be "joined". So my intention here is NIP 72 communities and (draft) NIP 87 groups, but anything else analogous that comes up.
There was a problem hiding this comment.
Is the reference to those events set to "address"?
There was a problem hiding this comment.
Yep, same value as an a tag
There was a problem hiding this comment.
I understand and thanks for your answers.
With private zaps, we encrypt a fully signed event and bech32-encode the ciphertext with Something like:
Then you can:
It maybe overkill for your needs, though |
|
Yeah, at that point we should just do a regular query string. Which I might actually do, because I'm not sure this has to be interoperable, since a client recommendation is just the link's base url, and is just as relevant as relay/group/pubkey recs. |
|
It feels like to make it interoperable we would need to design invitation payloads for every event kind. Then if the Client happens to support that particular kind, it can show the invitation but if not then it can send it to other clients. njump could then point each invite item to a separate client. I don't know... |
4 participants
This is probably poorly organized, suggestions on where to put the various parts of this welcome. This PR does two things:
ninvitewhich encodes a few different entities. This is meant to help with onboarding and sharing content outside of nostr.I'm adding support for both to Coracle this week.
https://coracle.us-southeast-1.linodeobjects.com/invites.mov