Compare commits

...

7 Commits

Author SHA1 Message Date
Christian Moss
b98826da89
Merge 611b714cef into a1ca7a194b 2024-12-11 11:44:52 +00:00
Jon Staab
a1ca7a194b Change strategy for naming groups 2024-12-10 19:25:28 -03:00
mandelmonkey
611b714cef assigned nip number and added video link 2023-06-07 11:54:05 +01:00
mandelmonkey
c8edb06a66 formatting 2023-06-06 21:14:40 +01:00
mandelmonkey
de2ea2b4ee updated to use new json based scheme 2023-06-06 21:09:04 +01:00
Christian Moss
fa95a31def
Rename NIP-XXXX to NIP-XXXX.md 2023-05-02 21:57:35 +01:00
Christian Moss
fe31479822
Create NIP-XXXX 2023-05-02 21:49:11 +01:00
3 changed files with 84 additions and 3 deletions

4
29.md
View File

@ -30,8 +30,6 @@ When encountering just the `<host>` without the `'<group-id>`, clients MAY infer
Events sent by users to groups (chat messages, text notes, moderation events etc) MUST have an `h` tag with the value set to the group _id_.
`h` tags MAY include the group's name as the second argument. This allows `unmanaged` groups to be assigned human-readable names without relay support.
## Timeline references
In order to not be used out of context, events sent to these groups may contain references to previous events seen from the same relay in the `previous` tag. The choice of which previous events to pick belongs to the clients. The references are to be made using the first 8 characters (4 bytes) of any event in the last 50 events seen by the user in the relay, excluding events by themselves. There can be any number of references (including zero), but it's recommended that clients include at least 3 and that relays enforce this.
@ -242,3 +240,5 @@ A definition for `kind:10009` was included in [NIP-51](51.md) that allows client
### Using `unmanaged` relays
To prevent event leakage, when using `unmanaged` relays, clients should include the [NIP-70](70.md) `-` tag, as just the `previous` tag won't be checked by other `unmanaged` relays.
Groups MAY be named without relay support by adding a `name` to the corresponding tag in a user's `kind 10009` group list.

2
51.md
View File

@ -29,7 +29,7 @@ For example, _mute list_ can contain the public keys of spammers and bad actors
| Public chats | 10005 | [NIP-28](28.md) chat channels the user is in | `"e"` (kind:40 channel definitions) |
| Blocked relays | 10006 | relays clients should never connect to | `"relay"` (relay URLs) |
| Search relays | 10007 | relays clients should use when performing search queries | `"relay"` (relay URLs) |
| Simple groups | 10009 | [NIP-29](29.md) groups the user is in | `"group"` ([NIP-29](29.md) group id + relay URL), `"r"` for each relay in use |
| Simple groups | 10009 | [NIP-29](29.md) groups the user is in | `"group"` ([NIP-29](29.md) group id + relay URL + optional group name), `"r"` for each relay in use |
| Interests | 10015 | topics a user may be interested in and pointers | `"t"` (hashtags) and `"a"` (kind:30015 interest set) |
| Emojis | 10030 | user preferred emojis and pointers to emoji sets | `"emoji"` (see [NIP-30](30.md)) and `"a"` (kind:30030 emoji set) |
| DM relays | 10050 | Where to receive [NIP-17](17.md) direct messages | `"relay"` (see [NIP-17](17.md)) |

81
77.md Normal file
View File

@ -0,0 +1,81 @@
# NIP-0077: Nostr Data Sharing URI Scheme
**Author**: Christian Moss
**Status**: Draft
**Type**: Standards Track
**Created**: 2023-05-02
## Abstract
This NIP proposes a new URI scheme for apps to share data, such as text or images, between Nostr clients.
## Motivation
It is commonplace in apps, such as games or photo libraries, to share one's achievements and moments on social network platforms like Twitter or Facebook to receive recognition and/or interaction from a community. Given the culture of "zapping" and gifting sats in Nostr, it would make sense to create a protocol that allows users to share an image and/or text with a Nostr client frictionlessly. For example, a user could achieve a high score on a mobile game, click a button in the game, which would then open up the user's Nostr client on their mobile device, allowing them to post a screenshot and caption of their achievement. Other players could then zap the user sats in recognition of this achievement.
## Specification
It was previously proposed to use a URI scheme such as
``nostr-share://?parameter=value&parameter2=value2``
Where parameter1 and parameter2 would be something like img, msg, etc., denoting the type of media to be shared.
However, after feedback, it was considered a better approach to keep it more generic and include a single JSON blob as the main parameter in line with Nostr notes.
An additional "hint" parameter would also be added to allow the recommendation for a particular relay.
Resulting in
``nostr-share://?msg={urlEscapedJSON}&hint={urlEscapedRelayUrl}``
The JSON by default should include at least the following parameters:
``text`` contains a message to be displayed analogous to a tweet or post.
``imageUrl`` contains an image URL to be loaded by the receiving Nostr client.
``videoUrl`` contains a video URL to be loaded by the receiving Nostr client.
``imageBase64`` contains an image encoded as a base64 string to be displayed by the receiving Nostr client.
In order to contain more images and messages, the JSON could be expanded to contain ``text2`` ``imageUrl2``
Example JSON:
``{
"text": "What sounds does an ostrich make?",
"imgUrl": "https://pbs.twimg.com/profile_images/1604195803748306944/LxHDoJ7P_400x400.jpg",
"videoUrl": "https://i.imgur.com/WC7LW4t.mp4",
"imageBase64": "iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs+9AAAAbElEQVQYGWOc6nznPwMOkLVHmWGay12wLBMONWBhmCIQhwVF4T9Ghqx9SihCMMUIE//jVgTSiVDI+B/uHhQjoRwUq5n/s+JUjDARqPMv429shoHF4CaCggIbwPQMFlVz3J7AReEmwnTCZdAYAGPIHXIm/AOjAAAAAElFTkSuQmCC"
}``
Example encoded URI:
``nostr-share://?msg=%7B%22text%22%3A%22What+sounds+does+an+ostrich+make%3F%22%2C%22imgUrl%22%3A%22https%3A%2F%2Fpbs.twimg.com%2Fprofile_images%2F1604195803748306944%2FLxHDoJ7P_400x400.jpg%22%2C%22videoUrl%22%3A%22https%3A%2F%2Fi.imgur.com%2FWC7LW4t.mp4%22%2C%22imageBase64%22%3A%22%22%7D&hint=wss%3A%2F%2Fnostr.zebedee.cloud``
Clients implementing this NIP should register the `nostr-share` URI scheme with the operating system, enabling other applications to share data directly with the client.
## Explainer Video
I created a short video explaining the NIP and showing the sample apps
https://youtu.be/VAH_g_Nhq0Y
## Example Implementation
I have developed a sample integration in the form of 2 android apps.
The first app is an example game that generates the nostr-share URI containing a message, imageUrl, base64 encoded image, a video URL, as well as a route hint.
https://github.com/mandelmonkey/nostr-share-sample-game
<img src="https://i.imgur.com/ym6azwT.jpg" width="200">
The second app is an Android app which receives the nostr-share data and displays the media.
<img src="https://i.imgur.com/qmFYUmz.jpg" width="200">
<img src="https://i.imgur.com/MCItlcV.jpg" width="200">
https://github.com/mandelmonkey/nostr-share-wallet-demo
## Cavaets
In practice as long as any base64image is small or replaced with an image url this is not a major limitation
## Copyright
This NIP is licensed under the Creative Commons Attribution 4.0 International License.